how to set a single pixel in opengl

[68030]

well, y'all may flogg me for it later, but right now, i'm trying to get back into

programming. and, as has been true in the past, i want to mainly do graphics

programming. nothing really useful. maybe somebody remembers the intros

and demos on computers back in the olden times.

i have done stuff like that in the past (actually years ago) all in the pre-3d

accelerated times. back then we used to write assembly code to set pixels

or initialize videomodes.

 

seeing as open gl is most likely the way to go (if you want to add 3d to the fun

later on), i acutally only have a very simple - and maybe ridiculous question

(to some of you) - to ask.

 

how do i set a single pixel? and yes, i know this sounds like complete utter bs,

given at one time i was doing stuff like that, in assembly (which i forgot most

about, but could still initialize a videomode and draw a pixel in it) as it was a

simple linear memory, you wrote individual values to and voila pixelmania.

so far i only found how to set triangles and stuff in the open gl docs. either i'm

getting old (or lazy & retarded), but i didn't find the most elementary routine

ever, set a single pixel at pos x,y with color c. i'm not interested in creating

triangles, rectangles or whatnot. individual pixels is what i aim for. sure i could

draw a 1x1 rectangle, what fun that is.

to be honest, this whole concept of using premade everything is pretty alien to

me. and yes, i haven't been doing code in all of this millennium - go figure.

the last i did was "code" some graphical nonsense on dos-boxes using pascal

its inline assembler or c to programm stuff for a psx).

 

 

pointers to good tutorials would also be appreciated, i found the docs at apple

dev to be rather confusing. maybe i really am getting lazy, but i don't want to

read the entire docs to just draw a friggin pixel or something. i'm not really

interested in application stuff or anything, more in the oldskool demo scene

stuff (if anybody still happens to remember that)

 

thanks for your attention

[NeSuKuN]

anyone that knows this better than me can correct me but AFAIK opengl just isn't meant to draw single pixels, it's like programming in a procedural fashion with a OO languaje, sure you somewhat can! but OO is supposed to use its approach to make things, opengl is about 3d, and a pixel isn't a 3d entity, opengl just takes the 3d entities and its attached textures and send it to the GPU which is the one that renders (process the info and generate the final frame which is sent directly to the screen), as you said you could render a square that fits a single pixel, also I propose you another approach, generate a texture with the pixels you want, generate a transparent square that fits the screen, apply the texture (I don't know if you need to reapply the texture to notice changes on the texture). anyway, if you want 2d acceleration on mac, use core image

Edited March 8, 2007 by NeSuKuN

[68030]

hm, yea. i thought something like this would be the case. to be perfectly honest,

i was expecting it. the thing with using polygons is that it is probably a waste of

performance compared to individual pixels. even if, in this case, it is only display-

ing a single pixel. still it needs to handle 4 values instead of just 2 and i think that

would be somewhat slower. whether that would be noticeable at all remains to be

seen, but my "guestimation" theory would have it run at /2 the speed.

 

well the idea i have is trying to bring some old plasma routines and use them as

a screensaver (with further additions apparently). something like the image you

see here:

 

http://www.pygame.org/pcr/numpy_plasma/plasma.png

 

of course not with candy colors like that and in a smooth fashion, as in more or

less individual pixels to not get as blockish an appearance as that of the linked

image.

also what kinda bothers me with this opengl malarky is the fact that you don't

seem to be using real pixel values anymore but relative ones ranging from 0 to

1. 1 apparently refering to the width of the drawing area. while this makes for a

neat scalability, it would probably make my plasma look {censored}e (depending on the

approach i take to the resolution of the plasma).

btw the plasma just being one example here. i have plenty of other ideas for old-

skool intro / demo routines to be used. basically i just want to do some basic gfx-

programming. and the way i learned it was based on pixels, not polygons (yea

welcome to 2007 , i know)

 

/edit

missed to reply to the render to texture stuff. while that is an idea that would

probably work, i have no idea how to sort of manipulate the texture in realtime.

as in draw a rectangle the size of the screen, then update the texture every time

the screen is done redrawing. that would probably be much like the way i'm used

to doing it. in this case i would "just" need how to manipulate the area in memory

where the texture is stored. could work. would need to know then whether i need

to reload / reapply the texture to the square every time i change it or whether it

is done automatically when the rectangle is redrawn (texture cached somewhere

maybe? that could case problems)

 

pointers to docs in that regard? thanks

Edited March 8, 2007 by 68030

[NeSuKuN]

think about code optimization made by the compilers, even the GPU, if the GPU notices that you just want a pixel (and believe me, engineers take that into account when making PUs) the GPU just won't waste resources, it will draw a pixel. Its like non visible 3d entities, if they arent in the FOV or behind a fully opaque and bigger entity, they won't be processed.

[68030]

they have occlusion in these things already, really? that would be like a good step towards

a real 3d engine. i'd have expected it to be more like a library of routines, draw_rectangle,

draw circle or what have you. interesting.

guess i'll be spending some times browsing docs now, looking for texture manipulation. at

first i was starting to dissect the 3d examples, but i didn't find what i was looking for there.

i'll go with opengl, as that makes it easier portable to other systems. though ci may seem

to be more to the point with this, but ogl is universal. might do the same for my windoze

box once i'm done (with whatever i come up with)

 

thanks for your input so far!

[68030]

ok, so i now managed to get a pixel on screen. and apparently there is a possibility of just

drawing a single one. there's a few good tutorials that take you through much of the opengl

worlds possibilities at

http://nehe.gamedev.net/

 

their examples are "easy" enough and fairly straightforward / simple. it's just that when

you download the mac osx source code examples to the actual lessons you go "wtf?". i

mean, i did the first two or three tuts and it was easy enough, coming up with my own

variants along the way. my code being roughly 40 lines total. now i look at the (supposed-

ly) sourcecode of those examples for mac osx that's also linked there and it is spread over

4 or 5 files (compared to my 3) and has at least 5 times the amount of code. seriously what

gives? i thought examples to be easy, that source doesn't help, at all. it's more confusing

than anything - but it works, yay that.

 

anyway.. what i also found is that the render to texture bit is probably the way to go, seeing

how opengl is nowhere near the way of olden days 320x200 linear videomemory addressing

bit. you don't have pixels with fixed coordinates per se, but points relative to the screencenter

with float values (yuck). in my days float was the killer, performance wise.

 

/more of a rant than a useful reply, this.

Edited March 11, 2007 by 68030