I'm getting similar results to everyone else, 13ms to 45ms and averaging 25ms roughly (2nd generation i5 at 3.7GHz), single-threaded at 550x400 resolution (the default). Lots of artifacts at close range. It's pretty slow in fullscreen mode, which is to be expected for a software renderer, however I am seeing a lot of screen tearing - are you displaying each rendered scanline on the fly? Perhaps double-buffering could help with that, and might also simplify your pipeline.

could you say maybe what you mean fullscreen and pretty slow? (what reslolution?) (i know that timer is not visible there but it should be about the same as maksymalized to desktop)

you are gave me a numbers (about 2x faster than than my old core2) but not provided the client resolution -

(I got about 75 ms at 1200x1000 when traveling to make ship cover the most of the screen)

1920x1080 with the ship covering most of the screen. I'd estimate about 5-10 frames per second? I.e. 100-200ms frametime.

shouldnt be so slow i think i would het here about 120 ms (if extrapolated linearly) so your machine should have it about 70

or close

if not some cache deficency van come to play (i dont know) as

such areas are comparable to amounts of caches on machines

2000x1000 is 8 MB for framebuffer + 8MB for depthbuffer so twice smaller can fits in 8MB cache and twice larger not - but im not sure if such effects do occurs

you could maksymalize to desktop (alt+space -> maksymalize) and should see the number,

tnx for info

ps much nicer version with improved mouse and removing some bugs

https://www.dropbox.com/s/m682fm4bqo00gvf/tie55.zip

much nicer, worth take a look i think

If someone yet could test for some resolution it would be great - or spread some ideas on it

fir

(damn yet a bug with alt+tab - will mend it later - done)

Opteron 8389 @ 1.7GHZ DDR2 800MHz:

tie55c: 46ms

Opteron 8389 @ 2.3GHZ DDR2 800MHz:

tie55c: 39ms

Opteron 8389 @ 2.9GHZ DDR2 800MHz:

tie55c: 31ms

All in a windows emulator on a linux workstation. With the default resolution.

There is still a ton of z-fighting, sometimes triangles disappear.

allright tnx much for testing, testing is always welcome

tie55c - 18ms to 34ms (holding F1 - 12 ms to 29ms)

In default resolution (550x400), I'm for some reason unable to switch it.

unable to switch? this is most mysterious thing-

have you got mouse with wheel ? - rolling it up toggles to fullscreen

rolling down 'frees' the cursrsor co you could drag the edges etc

what it looks like - this 'unable to switch' ?

as to z fighting this is becouse my "vertex depth clipping" i mean i do

testing of each triangle vertex if all 3 vertices are "depth out" i do not rasterize it - it brings the artifacts but improves speed (you can off it by holding of v - i dont see this artifacts as clearly as you, come triangles

blinks but it was not so much problem to me - worse thing is plastic lightning (if v pressed are there still those z problems? i cannot clearly distinguish it) [tnx for info]

[attachment=22257:bar.jpg]

those two numbers show (24 192) triangles that are actually called to BurnOutTriangle2D routine (95 107) all triangles in the model - so it show

that 70k triangles is out by this "vertex depth test" of my "invention"

(this reduces many calls but got times 40 ms (without this depth clip, with no sllep - (both f1 and v pressed)) agianst 34 ms (with this clipping on (only f1)

I got curiously high value on empty space when sheep is in rear space (about 17-20 ms (i give numbers with no sleep) where each traingle is clipped by near plane test (even before the projection just matrix transformation - its strangely high maybe*)

ps. most strange is this inability to switch to other resolution (need tu use mouse wheel roll - than it should work, if no please give a description)

(nice that it worx on linux, i would like to write 'wine friendly' if possible)

*maybe this is becouse the size of the model vertex array

- this is nearly 100k triangles, each triangle is 9 floats that is 36 bytes

so input size of this model is about 3.5 MB, the size of the framebuffer is 550x400x4 this is 2200x400 this is 880000 , 0.9 MB

same with depth buffer - so the model itself is twice as large as

summ of the screen buffers

wonder if storing this in separate vertex separate index arrays could

shring the input model size making things faster - i was not yet doing this (this model it taken from blender option to sawe oryginal blender model to raw faces, probably there could be something to save this as sperate vertex and index (if somebody could hint something* i could test it - blender is complx in use so im not sure)

* or yet better send me something free to use in this format (separate vertices separate indexes) in raw format ;/ then i could test

(need also write an some more elaborate format loader but im a bit scary as riding format specyfications is often a bit scary to me)

PS as to testing

I would have yet some test if someone could do that

in the same link on tie55 -> tie55i.exe there i putted after the client size

the setup time measurement this is the time that last before the program

goes into its loop cycle - it would be much interesting to know for me if this

time varies over the machines

on my own i got 1.38 - 1.39 seconds here

tnx for testing..

EDIT: Pretty cool, though. A software rasterizer is one of the things I'd like to try writing someday. Anyway, here are some times for each specific exe you included in your download:

from my experience it shows that doing a software rasterizer is nearly mandatory (as it clearly shows how some things work) for anyone who want to do something in 3d graphics (not such hard but also not for total newbies as a bit of architecture, general coding, window and input management etc is needed)

though if it is okay for simple lightning probably for more quality results there shows a need for gpu as for example am not sure if shadows and other so called (as i could call them) 'gpu techniques' are sufficiently efficient to obtain or simulate on cpu side

Im moderately experienced and know almost nothing on gpu

There is still a ton of z-fighting, sometimes triangles disappear.

Not necessarily a problem of fir's rasterizer. The model is bad, it's not a proper manifold: Here a debug rendering of a wing, vertex normals as colors and extruded lines. There are no vertices within the wing, only at the edge, so we got lot of coplanar planes. No wonder there's z-fighting.

may be true anyway

I thougt it is becouse far near plane (setted to 20.0) where ship size is about 250 230 150 width/length/height - but now i changed near plane to 1.0 and also pressing v to skip this quazi-depth test and there are also vanishings in the wings - i dont know what is going on