Ok, so i got my own .first. sw 3d rendering system up & running(i basiclly "reversed engeneered" OpenGL)...And now i understand why people talk so much about fillrate. I''m in serious need of it. 1. What *fast* ways are there to fill a triangle. Im using three edge buffers at the moment. And then drawing lines from edge.x1 to edge.x2. When i implemented the filler, framerate dropped from 36/fps to 6/fps. Suggestions? 2. What is the fastest way to store vertex data in memory? I suspect this can be one of the bottlenecks too. Currently i''m using dynamic arrays because of their simplicity. Like this: type T3DObject = record Vertex : Array of TVertex; end; And the like this: type T3DObjectList = record Object: Array of T3DObject; ObjectCount: Integer; end; This is my current structure for storing vertex data. Then for each render the data stored in the ObjectList is put thru the pipe. /Ekas78 (it works..it works...!! )

http://www.mesa3d.org/

There is the open source OpenGL library + software rendering support. I can guarantee that the routines etc held therein are all quite optimised because I''ve seen OpenGL games run on a P200 16MB RAM (No 3d accelerator) at a decent fps (15>) using Mesa!

Sorry I dont have a direct answer - but hopefully this will point you in a good direction to get looking yourself if noone else has an answer :D



-------- E y e .Scream Software --------
----------------------------------------
                                  /-\
    http://www.eyescream.cjb.net | * |
                                  \-/
----------------------------------------

Hrm, I dumped the dynamic array stuff, and went static instead.
Framerate upped a little.

Everything runs nice & fast when small...as soon as polys come close or big screen it chockes...guess it''s a bandwidth issue.

render to a system buffer, not vram. use a zbuffer. make sure you only draw the polys you need to. dont run anything higher then 512x384. stick to 16bit, stay away from bilinear filtering. keep blending to a minium. DONT create buffers during renders, it should all be static (this does not mean during inits you cant create buffers, just means you should not be allocating memory during your main loops). clip any poly not partially on the screen. make sure your textures (if you have any) are powers of two and use & to handle the wrap around. DONT use any floating point values in your renderer. by the time rasterizing comes around everything should be done in fixed point integer math. you dont seem to be using c/c++, switch to c/c++ for the rasterizing routines. it is MUCH faster then VB/delphi for things like this, especially with some optimized inline assembly for the triangle filler. DONT have scaling textures, unless you make sure that you NEVER use any conditional statements when accessing the texture, since the power of two dealie will ensure never get an overflow (ie you use the AND operator to clamp the values, instead of conditional statements).

DONT look at the mesa implementation. it will only confuse you and you will just rip code even if you dont want to. just to get faster framerates. DONT use the opengl api as a guide. its way too large for a software engine, instead build up your own api which is optimized for your rendering pipeline.

look for some old dos demo tutorials that deal with triangle rasterization. they should help point the way to a faster filler.

don''t use a zbuffer, look for c-buffers or s-buffers instead, much bether for software-rendering

a person: What i meant was that i''ve made my engine somewhat similar in syntax to GL. (Like glBegin etc.) Since that''s what i''m used to. (thnaxx for the answer btw.)

turns out i had some wierd things going on in the polygon filler "draw the x1 to x2 line" procedure. Somehow that procedure succeded to draw non-horisontal lines...and that made things real slow compared to when drawing horisontal only.

What''s the reason for using 16bit only in software? The PCI buss?
Iv''e noticed this in several games too. Like Q3 in sw mode usually is 16 bit.

What''s a system buffer or vram (virtual ram?) ?

/Ekas (things are faster now...)