pixels for fractals!

Mebbe this is an oft repeated graphics question but i would really like to know if or how i can use the graphics package like open GL to simply plot coloured points? i say this because i like writing fractal programs and want to be able to colour them nicely as they run. There does not seem to be any simple way to just colour a pixel or part of pixel at co-ordinates xy according to say, the number of iterations.

cheers for any suggestions!

So basically, you're just looking for a function like this?

Code:

---

void plot_pixel(int xposition, int yposition, COL colour);

---

It's really easy to do in 2D graphics libraries like the SDL. I'm sure it can be done in OpenGL, too -- you'd just have to look.

If you really had to, you could blit 1x1 squares. http://nehe.gamedev.net/data/lessons....asp?lesson=02

Touching pixels in modern graphics is a no-no. That's memory reserved for use by the hardware only which is why you find very few examples of it being done.

In modern graphics APIs you will have to either render to a texture (just like accessing a screen array in memory) and draw it or you will have to find some other texture based method like locking a surface, drawing, unlocking, and rendering a textured quad.

To plot pixels all you really need to do is be able to convert a one dimensional memory address of your image buffer to 2 dimensional co-ordinates, or the other way around. Heres a basic example to plot pixels with 32 bit colour:

Code:

---

void WritePixel(int x, int y, Uint32 col)
{
    Uint32 *pix;
    pix=screen->pixels+((x+y*GRAPHICS_WIDTH)<<2);
    *pix = col;
}

---

You may also want to use bounds checking to make sure you arent writing outside of the buffer.

[edit] Dont know what that thumb thing is doing at the top of my post. Dont know how to get rid of it either.[/edit]

[edit 2] Yeah locking image buffers makes pixel read/write operations a lot faster. Don't know how it all works in Open GL myself as I've never used it. [/edit]

orthographic projection?

Locking and unlocking makes the operation slower since you must issue the lock, alter the buffer, and issue the unlock. It's also a severe performance hit because lockable buffers can only exist in system memory. This means after you unlock the buffer it is finally pushed out to the video card to render. If you use render to texture methods then you are still operating within the confines of hardware. All you do is treat the texture like the back buffer and then draw a quad the size of the screen onto the primary buffer using the texture you created. Render to texture does not require any locks and the everything can exist in video memory instead of system memory. It is best to 'play nice' with the hardware or you will suffer some severe penalties in performance.

So locking and unlocking is not only the slowest way to do things it is also become the obsolete way to do things. Direct3D has provided many newer functions to remedy the oft problem of gaining access at the texel level and OpenGL has as well.

The easiest way is to create the texture in a pixel shader but that explanation/discussion is best reserved for a different thread.

Thats strange. I found that locking image buffers while you write to them was much faster. Admittedly that was in Basic or Java, and I don't know exactly how it all works. But it was definitely a faster than doing the same thing without locking the buffer. Maye that was because I never actually had direct access to the buffers anyway in these languages, or at least thats the only explanation I can think of.

Your checklist for modern hardware. If your algo or your thinking falls into these categories you probably need to rethink your design as it relates to modern hardware.

• If it requires anything with locking surfaces/buffers
• If it requires a significant amount of these locks/unlocks (locks/unlocks incur a performance hit, possible card render dead lock if done improperly, bandwidth issues as the new data is streamed over the bus to the card, and possible cache thrash and/or miss issues)
• If you feel you must absolutely have access to each texel
• If you are trying to use Direct3D/OpenGL like old school DOS video buffers
• If you are attempting to do special effects at the pixel level w/o using a pixel shader or fixed function pipeline texture blending (Direct3D).

Remember there is usually a way to get at the texels without really ever needing access to them. In this case you probably do have to perform a lock, get the surface and alter it, and then unlock it. If you use a pixel shader or fragment you can do the entire fractal in the confines of a vertex/pixel shader combo.

The ONLY ways to get the texels is either indirectly through texture blending, directly via locking, or directly using pixel shaders which do NOT require a lock.

Quote:

---

Touching pixels in modern graphics is a no-no.

---

That's really not true, there are API functions in GL and Direct3D for doing just that. I don't remember off-hand, but I think you should MSDN the glWritePixels function. If that isn't it then the 'related hits' tab should give you what you need. I believe I used this to transmit the results of a software raster function to the screen.

There aren't any functions in Direct3D for writing pixels. You can lock a surface and get a pointer to a buffer but that's about it. I believe Shakti and I tried glWritePixels for a buffer copy and had significant troubles with it.

The closest thing in Direct3D to glWritePixels is StretchRect.

And in all cases, the processor (CPU) is highly likely to be the better candidate for generating individual pixels, compared to a GPU - the CPU has a much shorter pipeline for example.

GPUs are excellent at dealing with "many" pixels at once, in parallell. But if you want to draw an individual pixel [independently of other pixels around it], then the CPU will be the "better" option.

Of course, it's certainly best if you can get the GPU to do LOTS OF PIXELS, rather than doing individual ones in the first place.

--
Mats

Now, if you can implement your fractal as a pixel shader, that's obviously cool, and probably the fastest way.

Quote:

---

Originally Posted by CornedBee

Now, if you can implement your fractal as a pixel shader, that's obviously cool, and probably the fastest way.

---

Yes, indeed. A collegue of mine working with graphics drivers actually wrote a "self modifying fractal shader", which was only a dozen or so instructions long.

--
Mats

Shaders can do a lot of fancy stuff and fast, but I think the OP was asking for the simplest way to draw 2d graphics. I would suggest TinyPTC as its very simple and only sets up the graphics buffers for drawing to.

That's the problem. There isn't a simple way to draw 2D graphics anymore. The simplest way is working with the hardware.

I read it's extremly slow because it's a lot slower to fetch from the hardware (gfx card) than it is to send? Or something like that.

Reading a pixels value from 2d co-ords requires modulo and divide, which is one reason its slower than writing.

One common way to speed up pixel writing is to allocate a buffer in RAM, kind of like a temporary screen, do all your drawing to the array and when everything is finished blit the whole thing to the screen (or whatever surface) in one go.

Wow, thanks for all the info, plenty of stuff to go at.... including a basic understanding of modern graphics writing haha!
merry christmas!