(that's one snappy title, I know)
Hey,
Recently I've become interested in the actual math behind rasterizing a line or a triangle, i.e. how OpenGL actually does things for me. My first step was to figure out the math behind it all, but now I'd like to put together a software renderer to play around with. Should I just build a texture and tell OpenGL to display it? Or is there some method of drawing where I could bit blit straight to the framebuffer? Surely I need a window of some sort open in any case? Am I just an idiot?
Thanks in advance.
How does a software renderer actually get things on a screen
In general, either:
* The software render draws it directly into video card memory with DMA. This is possible to set up in various platform-specific ways in some cases- the SDL library might do this for you, for example.
OR
* The software renderer draws it into system-ram, then copies the data
Both methods have advantages. System-ram is typically faster to write to (and particularly, to read from, for instance, if you're doing blending) than video card memory, but then the copy operation takes extra time.
If you're writing into video memory it's usually possible to use hardware page-flipping to avoid tearing or displaying partially drawn frames.
Your mileage may vary.
Have a look at the SDL library for platform-specific details of how software rendering typically works.
* The software render draws it directly into video card memory with DMA. This is possible to set up in various platform-specific ways in some cases- the SDL library might do this for you, for example.
OR
* The software renderer draws it into system-ram, then copies the data
Both methods have advantages. System-ram is typically faster to write to (and particularly, to read from, for instance, if you're doing blending) than video card memory, but then the copy operation takes extra time.
If you're writing into video memory it's usually possible to use hardware page-flipping to avoid tearing or displaying partially drawn frames.
Your mileage may vary.
Have a look at the SDL library for platform-specific details of how software rendering typically works.
on win/osx/linux I usually use http://sourceforge.net/projects/pixeltoaster/
it's very lightweight, allows you to output pixel and to get mouse+keyboard callbacks, what more would a software renderer need?
it's very lightweight, allows you to output pixel and to get mouse+keyboard callbacks, what more would a software renderer need?
PixelToaster is a good solution.
My (currently) windows-only rasterizer uses Win32 StretchDibBits or something like that. All drawing occurs in memory buffers I allocate with new, then I create a DIB section that points to those bits, and then I use the aforementioned call to get them onto the screen. Unfortunately Win32 doesn't expose vsync at all, so there's no way to avoid tearing in this way (though its usually not noticeable).
If you're interested in the Transformation and lighting aspect only, then you can use any old 3D API and draw with pre-transformed vertices that you've calculated yourself. If you want to actually set individual pixels, then Toaster is a turn-key solution.
My (currently) windows-only rasterizer uses Win32 StretchDibBits or something like that. All drawing occurs in memory buffers I allocate with new, then I create a DIB section that points to those bits, and then I use the aforementioned call to get them onto the screen. Unfortunately Win32 doesn't expose vsync at all, so there's no way to avoid tearing in this way (though its usually not noticeable).
If you're interested in the Transformation and lighting aspect only, then you can use any old 3D API and draw with pre-transformed vertices that you've calculated yourself. If you want to actually set individual pixels, then Toaster is a turn-key solution.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
