Jump to content
  • Advertisement
Sign in to follow this  
drowsyn

OpenGL How does a software renderer actually get things on a screen

This topic is 2583 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

(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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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? :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!