Nextgen-software rendering

[herrcoolness]

This stuff all sounds pretty neat. Would you be able to put together a small demo so we can see whats going on visually?

Hi Will. Just download 2 demos. One is scanline based, another tile based and check the fps, for example at the start. The objects and polygons are not sorted. So the scene is pseudo-randomly rendered. This is nightmare for the rasterizers. But the biggest nightmare is perfektly sorted poly's from back to front = ultimative slowdown.

tile :http://sourceforge.net/projects/phen...1.rar/download
scanline:http://sourceforge.net/projects/phen...1.rar/download

[herrcoolness]

Hi folks. So I updated the engine with new memory representation of texture. The texture is divided in to 8x8 tiles like in old version but now the tiles are bigger - 9x9 pixel. Why ? Because i implemented bilinear filtering and there was small problem with the right and bottom texels in the tile. There when i wanna access the 3 other texels i need to read the color from other tiles and i needed to calculate new adress because of tile change. So now when i am encoding the texture in to the tiles i write the colors in right and bottom extra texels from neighbor tiles. When i am reading the texels now, i am reading they all from one tile and calculating the adresses from other 3 texels is very cheap.

I implemented per triangle occlusion so we calculate the nearest Z coordinate from the triangle to the camera and then comparing it against Zmin from tiles which are in the bounding box of the triangle. Zmin is in separate array as the whole z-buffer so traveling thru the Zmin array is fast. It simulates the on-chip memory rough z-buffer in hardware. When there is one tile which is behind the Zmin from the triangle, the triangle need to be rendered else it can be skipped. Skipping the triangle can save nice amount of computation and the drawing is faster. This method is descripted in article "Method for accelerated triangle occlusion culling" (http://www.freepatentsonline.com/20030043148.pdf), but if you are thinking about the hierarchical z-buffer, you get the idea automaticaly. I've got similar idea, when i was programming the n-level z-buffer.

http://sourceforge.net/projects/phen...1.rar/download

[herrcoolness]

Ok guys, new update of my project.

Every programmer knows, that the 64-bit environment brings new possibilities, like more memory, more registers, extension of old general register to 64-bite size. As assembler programmer, i've got some problem with some functions because of small amount of cpu-registers. So i need to handle with this problem thru memory accesses to temporary variables and constants, which slows down the whole function. The speed for software rendering is very important so i changed the OS environment to get more horse-power from my cpu.

Changing from 32-bit to 64-bit brings some problems, because now we strictly need to use just 64-bit version of device-drivers. Some old hardware is not supported from his company with a new 64-bit firmware. So we need to buy a new... like me. Now the OS is fully functional.

I changed the version of FPC to 64-bit version too. I needed to rewrite the sourcecode of the render (changing the pointer and pointer operations from dword size to qword size) . I change the output from DirectDraw to GDI, because,i've got problems to run the program under the 64-bit environment. I optimized some parts for the 64 bit because now i have 15 general purpose and 15 xmm registers. Man i was feeling like a kid in toy-shop .. so many registers... . I changed some names of the variables like in the gradient calculation for better understanding, what they mean.

I compared the old rectangular traversal algorhytm with the recursive algorhytm, but the old was still faster. Anyway i uploaded the recursive algorhytm http://sourceforge.net/projects/phen...1.rar/download for study reasons. Added some more comments for better understanding the code, like in trivial reject & accept calculations. Cya

http://sourceforge.net/projects/phen...1.rar/download

[pixelwriter]

Hi Herrcoolness,

I tested your very fast demo and my plan is to research this type of software-rendering
in the second half of this year, but I already have some initial questions:
Do you know if your rasterizer is faster than http://code.google.com/p/msr-zbethel-tu/
Could you make a pascal-only reference version? The engine would be easier
portable (beyond x86) and modifications would be faster possible without ASM knowledge.

Thank you!