Nextgen-software rendering

[herrcoolness]

Ok guys, i upload new test version's to the sourceforge - "no console" & "no console + low res". Test it and give me the result if the drawing window is showing or not. And give me precise description of your CPU & OS (like WINXP Pro, WINXP Home Edition and so). For example some programs like power cinema works on WinXP Home Edition but not on Pro edition. The output of my program is still DDRAW.

Ok and for faster interaction with you, the testers of my engine, i added ICQ number in my profile, so don't wait, write fast to me as you can.

https://sourceforge.net/projects/phenomenon/files/


Its not possible that i have a so trivial problem like to manipulating a damn window. Its like bad joke.

[de_jean_7777]

I tried the "window patch-1024x768 - no console - test.rar" test and it worked ok. I tested it on Windows XP Professional SP3, with a Pentium E2220. It's the same PC your previous test did not work on.

However, the other test "window patch - no console - test.rar" did not work properly. It behaved similar to the old tests.

[herrcoolness]

I tried the "window patch-1024x768 - no console - test.rar" test and it worked ok. I tested it on Windows XP Professional SP3, with a Pentium E2220. It's the same PC your previous test did not work on.

However, the other test "window patch - no console - test.rar" did not work properly. It behaved similar to the old tests.

So when i good understand.. its doesn't matter if the console is on or off. It matter the resolution of the window. The other test is with window of the size 1680x1050. So this can be reason, why it don't work,(or work's but show nothing). How is the resolution of your desktop de_jean_7777 ? If it is smaller then 1680x1050... then we have the solution of the problem why the window is not showing. The frame of the window is out of the screen and direct-draw can't blit to the window because right-down & left-up point is out of screen. How is the resolution of your desktop de_jean_7777 ?

[de_jean_7777]

How is the resolution of your desktop de_jean_7777 ?

My resolution is either 1024x768 or 1152x854. I never tested on any different resolution.

[herrcoolness]

How is the resolution of your desktop de_jean_7777 ?

My resolution is either 1024x768 or 1152x854. I never tested on any different resolution.

Thnx de_jean_7777. You helped me to solve the problem. So i will release the later demos in 800x600 window size. And more later i will implement the resolution and fullscreen-desktop-in window switching.

De_jean_7777 .. good work.

[herrcoolness]

News-news-news guys. So i implemented the hierarchical z-buffer with 3 basic funtions, for fast tile skip, standart per pixel z comparing and fast z writing without z comparing to old z values in z buffer.

I uploaded 2 demos. One with colored debug info and one without the coloring to see how it normal works. ..and now just in 800x600 resolution to don't get the old window problems (in old demo's are the rendering window's in 1680x1050 resolution, and that caused no-drawing on computers which have lower resolution on desktop) :
*black tiles - skipped tiles of the hidden small quad
*green tiles - tiles drawn with the fast write fucntion (no z comparison) and are not compared against the triangle edges
*cyan tiles - tiles are drawn with fast write function (no z comparison) but compared against the triangle edges
*gray tiles - tiles are drawn with function that compares the z-values agaisnt the z-buffer and are compared against the triangle edges


Next stop ...clipping and transform pipeline ... and first rotated cube?

[Luuk van Venrooij]

Cool stuff! Wrote my own software renderer a few months back. It wasnt really build for performance but more of a learning project. This seems a bit faster

[herrcoolness]

Cool stuff! Wrote my own software renderer a few months back. It wasnt really build for performance but more of a learning project. This seems a bit faster

Luuk ... aaaand it will be even faster, because freepascal is using for the vector operations standart procedures with calling convention (push-call-ret instructions) and not inlined procedures, because i use assemebler in overloaded operator procedures. So i need rewrite every vector operation in the triangle procedure in to sse assembler to gain more speed. You can compare for example vector addition: 3 sse instructions in assembler against freepascal's overloaded operator generated procedure with 10 or more x86 and SSE instructions and the procedure will using stack so in result , there are more instructions and it hurts the cache. There are many more optimizations possible. But i make them later.

[herrcoolness]

Ok guys. What's new?
Now the triangle input coordiantes are in NDC (Normalized device coordinates), so x and y postion need to be in +1,-1 interval. Why this? because this are using graphicards and helped me to solve the problem when you change the size of the window. Now the size of of the triangles is changing too and is propotional to the rendering window.

Aaand i added third texture filtering method for low-end pc's. Its almost fast like nearest texture filtering (because of 1 texture fetch) but looks almost like bilinear. Yes-yes you saw this method in Unreal. I found a description about this technique in old flipcode archive on net (http://www.flipcode.com/archives/Tex...n_Unreal.shtml)

There are 2 demos :
-one static to see how fast are all 3 techniques (push 1,2,3 to change the filtering technique)
-and dynamic to see the dither-bilinear technique in action (push 1,2,3 to change the filtering technique)

[herrcoolness]

News-news-news !! I added full transformation pipeline of vertices and homogeneous clipping of triangles based on direct 3d documentation (like orientations of model and camera in world-space, perspective matrix calculation and so). I added backface-culling of triangles against camera in model space, so some triangles don't go down thru the pipeline and just those vertices are transformed, which are really needed (just for visible triangles).I created small demo where you can move with the camera and see a big cube with texture of size 2048 x2048. About the rasterizer. I reimplemented Nick's rasterizer with fixed-point math because of its numerical stability near edge of the drawing rectangle. Sometimes after clipping and homogeneous division the positions of points of the triangle was going outside of the screen which caused an error in triangle rasterizer.
About the demo;
q,e - moving in y direction
a,d - moving in x direction
w,s - moving in z direction
1,2,3- filtering method
9,0 - vsync on-off

ps: the camera is spawning in the cube ;-)

https://sourceforge.net/projects/phenomenon/