Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


How does a software renderer actually get things on a screen


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 drowsyn   Members   -  Reputation: 142

Like
0Likes
Like

Posted 18 November 2011 - 09:33 AM

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


Sponsor:

#2 markr   Crossbones+   -  Reputation: 1653

Like
2Likes
Like

Posted 18 November 2011 - 09:44 AM

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.

#3 Krypt0n   Crossbones+   -  Reputation: 2601

Like
2Likes
Like

Posted 18 November 2011 - 10:30 AM

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? :)



#4 Ravyne   GDNet+   -  Reputation: 7744

Like
0Likes
Like

Posted 18 November 2011 - 06:46 PM

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.

#5 ic0de   Members   -  Reputation: 880

Like
0Likes
Like

Posted 18 November 2011 - 10:40 PM

You can use SDL. You can write to SDL's buffer which will be in turn written to the screen.

you know you program too much when you start ending sentences with semicolons;





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS