Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by Jean-Francois Dube, posted on January 06, 2001

Image Description, by Jean-Francois Dube

Hi, this is a little software engine I did in my vacation week (entirly from scratch). Here are the software rasterizer features:
  • subpixel and subtexel accuracy
  • perspective correct texture mapping (every 16 pixels)
  • linear rgba vertex color interpolation
  • environment bump mapping la G400 & use the same bumpmap format (DUDV88).
  • You can download the demos at To run bumptest your desktop must be in 16 bits, and to run bumptest2 your desktop must be in 32 bits.


    Image of the Day Gallery


    Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
    Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.

    January 06, 2001, 03:28 PM

    WOW ! this time I'm really first
    My comment:

    Looks like example from DX7-DX8 SDK.
    Your cube is a little bit dark.

    Kurt Miller

    January 06, 2001, 03:50 PM

    That's a cool demo; nice and fast (~25 fps, 640x480 fullscreen ddraw, 32-bit). Was this just for fun, or do you plan to do something with it? As for the comment someone made about the DX examples, this demo is certainly more enjoyable to view than those with the reference rasterizer (0.2 fps).


    January 06, 2001, 04:00 PM

    I downloaded the demo, it was nice but after switching to fullscreen my display screwed up. I still was able to see that "there is something happening" but that's all about it (?).

    What language did you write it in?


    January 06, 2001, 04:01 PM

    Somebody mentioned that with reference rasterizer it runs with 0.2 fps ... Wrong ! Certainly it runs much faster ...
    BTW who will use software rasterizing today ? All really cool stuff can be done only using hardware acceleration.

    Jukka Liimatta

    January 06, 2001, 04:15 PM

    BTW who will use software rasterizing today ? All really cool stuff can be done only using hardware acceleration.

    Obviously Microsoft, among others, atleast Metal Gear Solid PC conversion had to have software rendering, or else, no dice, according to one of the developers.

    Also a lot of laptop owners, I am sure, will disagree with that aswell.

    There are also a lot of interesting portable devices coming out in the future which have limited "hardware acceleration" capability in that area, but a lot of potential.

    I'd not go and bury software rendering just yet. Sure the gaming elite won't appriciate it asmuch as some other circles do.. ;-)



    January 06, 2001, 05:05 PM

    MC BAXTON, maybe it is your hobby or so, but why to you bitch about every iotd that is released ? Can't you just enjoy/respect the work of others ?



    January 06, 2001, 05:46 PM

    Hey I think this is cool...
    A software-engine... wow... I like that!
    I think everyone can do that in hardware, but software?!


    January 06, 2001, 05:51 PM

    Cool image. Nice to know there are some people who write engines for non-Geforce machines (mine). I'm downloading the demo now, so I can't give you a framerate, but it looks nice!


    January 06, 2001, 06:29 PM

    Cool stuff!!

    27 FPS in a window :P


    January 06, 2001, 06:46 PM

    Bump mapping in software, cool!
    Is it just me or are the letters on the box a bit shakey in the edges? Looks somewhat like it would if it hadn't been presteped correctly (subpixel correction at beginning of scanline)...
    Anyway nice image!


    January 06, 2001, 06:51 PM

    Like Wog said, software rendering is far from dead.. not everyone has the latest graphics hardware although its certainly interesting to exploit it if you have it. Also, it's no mean feat to outperform Microsoft's Reference Rasteriser. So its a better idea to code your own rasterisers. Personally, I think writing an pure software-based engine gives you a better understanding of how it all works in hardware, and its fun. Spot, by Exceed, a pc-demo that won the Assembly'2000 demo-compo was software based, and it looked like a hardware-based engine. Pretty impressive. Anyway, nice IOTD once again, and it works. :) Keep up the good work guys.



    January 06, 2001, 07:19 PM

    Really cool!

    I'm also working on a software engine, but I have a problem with the sub-pixel accuracy causing a few dropouts. I'm using 16.16 fixed point numbers and a top-left fill convention, but it doesn't seem accurate enough. I checked the precision of all fixed point arithmetic and the float to fixed conversions. I trace the left and right edge of the triangle simultaneously. What method are you using and do you have any idea what I'm doing wrong?

    I very recently found this great site, but I haven't finished reading the articles yet (I should be learning my exams instead of reading this): Perspective Texture Mapping.

    It doesn't use fixed-point numbers but a bresenham-like algorithm. It doesn't explain why it's impossible to rasterize perfectly using fixed-point numbers...




    January 06, 2001, 07:19 PM

    Yes, that's very true sulphur ! I'm writing a SW renderer on my own, just because I want to learn all those matrix and rasterization stuff.

    Have you seen this heaven7 intro ? It looks liek realtime raytracing. They have many sphere and so on, looks like they don't do triangle based rendering, it's to fast for that. That's what I like about SW rendering. in HW rendering you are forced to do Z-Buffer triangle rendering, in SW rendering your imagination is the limit.

    Jean-Francois Dube: I know how damn hard all those stuff it, I'm messing with simple triangle filling and shading. You must be reallly good if you can code something like this from scratch in a week or so!



    January 06, 2001, 07:23 PM

    I agree that if you are able to make better software rasterizer, that's cool. Of course, it gives for you more understanding how it works. But I more care about how to make more interesting and impressive game, and trying to use best hardware which I can.

    I do not say that software rasterizing is dead. There may always be computers without appropriate hardware. But I personally simply can't run game in software mode. It gets ugly for me.

    And no, it's not my hobby to bitch about iotd's. I just think that it's better to show what's wrong for people, so they can do better. Actually my comments *usually* much more useful than Wow ! Good work !
    And when I will see really cool iotd I will say that, be sure.

    Warren Marshall

    January 06, 2001, 08:30 PM

    Oh yeah, I see what you mean ...

    "Looks like example from DX7-DX8 SDK.
    Your cube is a little bit dark."

    Those are comments he can really take to heart to improve his future efforts. Good work! *sigh*


    January 06, 2001, 08:44 PM

    Everyone here that posts an IOTD, picks up their own project, and I like the fact that you decided to practice with how things really work, and not just have the APIs do it all for you. You nkow, there was a time, back when your granddaddy was still in diapers, perhaps, that 3D gamews had to be written entirely from scratch. No external libraries, no APIs. You just wrote to video memory yourself. Lok at Quake. It was written in DJGPP -- and they did it all. So, making a software rasterizer is a good experience in that you get to know what really goes on.

    I have been working on one engine for the past year, and it has taught me a lot about the internals of 3D rendering. Just like that italian guy and his VB raytracer, I am impressed that you persevered to put it all together. Now, I think, you are a better 3D coder for it.



    January 06, 2001, 09:07 PM

    Actually this may be the first time he hasn't said something like that :) Saying it looks like the SDK demos isn't that bad a thing :)

    Alexander Stockinger

    January 06, 2001, 09:30 PM

    The Reference Rasterizer of the DirectX SDK is by no means intended to break any speed records. It's entirely written in C++ and is nothing more than a reference for driver programmers to see how things should be done (hence the name).
    It's written for readability (yes, the whole reference rasterizer is included with source in the DirectX DDK) and compatibility, not high speed.

    Anyway. Impressive thingie. I myself never got that far with my software engine. Very impressive. Especially the speed...

    Good work,


    January 06, 2001, 11:42 PM

    Pretty nice! Everything on mine was backwards though. The FPS was upside down/backwards in the bottom left, and so were the textures. I've got a GeForce DDR.

    Jukka Liimatta

    January 07, 2001, 02:13 AM


    I myself used to interpolate gradients over the edge, but never got rid of the overflow/underflow that resulted from roundoff errors(?).

    Then I changed the way I calculate subtexel "corrected" gradients, I did not interpolate them at all. I calculated the constant dudx and dudy ( for u coordinate, for example ) for the whole triagle. Ok, so far this is old-skool, and errors can result still.

    If you know constant gradients over X and Y axis, and pixel's coordinate ( in integer!!! ), you can do this:

    u_at_origin + ix * dudx + iy * dudy;

    And you get -perfect- solution, I'm not sure if this is best possible, but I haven't got under/overflows ever since.

    Now we see obvious optimization:

    iy * dudy is simple adder, for each scanline you can actually replace it with:

    foo += dudy;

    If you initialize the foo with:

    foo = dudy * iy_at_top;

    You get interpolation. You still need to do the ix*dudx calculation, and add, but those can be done in any precision you like: float, fixedpoint.. ( float if you want to do subaffine perspective correction but that's another story ;-)

    So we're left with multiply+add per scaline per gradient, this isn't so bad as you'd be doing this anyway if you did "subtexel" adjustment "manually", heh, now we correcting automatically to center of pixel ( or anywhere you like ), without even thinking "subpixels"-- it just happens when it's done right from the square one.

    .. hope my explanation wasn't too vague, it should be fairly clear if read it more than once.


    January 07, 2001, 08:07 AM

    Nice to see that there are still people interested in SW-rendering. To see how it all works.

    Heaven 7 is actually realtime raytracing, but I got now idea how Picard made this so fast. I encourage everybody to watch this intro. It's eye-candy and shows some really neat coding.

    C ya


    January 07, 2001, 09:26 AM

    what are peoples thoughts on the best way to do actual pixel drawing when not using hardware acceleration?

    The old 'fullscreen sized popup style window' and drawing into dib's? Or isng directX to set up some sort of 2d rendering context?

    (I know precisely nil about DX)

    Lightsaber - could you throw up an url for the demo? cheers



    January 07, 2001, 12:36 PM

    I use DirectDraw, it gives a void pointer to the start of the video memory, without detours. I don't know any other libraries that give direct access to the video memory, but I'm sure there are a lot of other possibilities.

    Rendering in a window is a lot slower because instead of being able to "flip" the whole screen you have to "blit" the backbuffer to the visible surface. Flipping pages is just waiting for a retrace and changing pointers. With blitting you have to copy the whole surface.




    January 07, 2001, 01:52 PM

    Hi Tim,

    Love your opengl site! keep up the good work, in response to your post, yeah - I have seen Heaven7, one of the most impressive 64k's I've ever seen. of course, there are tricks.. but Spot/Exceed used tricks also. =) have you done any real-time raytracing, or any raytracing at all?


    sulphur /


    January 07, 2001, 01:58 PM

    Here's one of the many places where you can download the Heaven7 real-time raytracing demo by Exceed:


    January 07, 2001, 06:02 PM

    Thank all for the comments!

    Nick: Are you perspectivly interpolating your texture coordinates? If so, maybe your problem is precision. When you compute 1/z and then multiply it by 65536 to get the 16.16 fixed-point value, you don't have enough precision. Use 32.0 fixed point for 1/z (I interpolate (65536.0f*65536.0f/z) in 32.0 fixed point, and I use that value too for my z-buffer).

    Also, to answer many questions, I wrote that in C and C++ (the rasterizer is in C, and the 3d engine in C++). The scanline interpolation have some MMX code, but I plan to convert it in plain ASM someday).

    That's it. If anyone have suggestions, leave me a mail!

    Jean-Francois Dube


    January 07, 2001, 06:06 PM

    Sorry, I meant 0.32 fixed point in my last post. :)

    By the way, i've also implemented the unreal filtering ( which gives really great results compared to bilinear-filtering. It's so easy to implement, and the speed cost is nearly zero!

    Have a great coding!


    January 07, 2001, 09:07 PM

    after directx, wing seems to be the fastest. but remember, youc an use directx and simply not use the acceleration :-)



    January 07, 2001, 10:41 PM

    Also, to answer many questions, I wrote that in C and C++ (the rasterizer is in C, and the 3d engine in C++).

    How do you differientiate between C and C++? (Just curious...) I mean, when you say, 'C', do you mean, C++ but using fewer features of the language, like: no objects; no overloading; etc... Or, do you mean, really 'C' so you're using separate compiler - or separate compiler options than your C++ code?


    January 07, 2001, 11:35 PM

    So if he says "it sucks" it's actually good because he usually says somehting worse ? ;-)


    This thread contains 34 messages.
    First Previous ( To view more messages, select a page: 0 1 ... out of 1) Next Last
    Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.