Thread: pixels for fractals!

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

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]

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.

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.

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.

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.

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