No, in this version clipping is not implemented.
And in the current version it is, but there is a serious bug, but I have no time to work on the project, maybe in June.

BTW: Geoff Crammond has announced STUNT CAR RACER PRO (sequel to SCR) for next year - I think I have to speed up!

Posted on 2003-05-21 14:10:19 by VShader
O.k., full 3D-Clipping works.
(The "serious" bug was a silly bug, but it was serious hard to find it...)

It uses mmx for point-plane-distance and fpu for dividing. There are two buffers while clipping for seperating mmx- and fpu-operations so it should be fast on first-generation mmx-machines.
It clipps now against the 6 VF-Planes, but it can clipp against up to 16 planes.

Use <F11> to observe the clipping (outlined triangles).

The issue with the accuracy while moving away from the center is gone because I do now (with mmx-matrix-transformation) only rotate/scale - translation is done by a simple mmx-add. So now you have everywhere in the scene max. accuracy.

16 bit-colour rendering is optimized - It should even with full 3d-clipping be faster than the last version.

You can dynamically move the farplane with <pageup> and <pagedown> (perhaps you must change the scale with <u> and <i> to avoid rendering-artefacts).

I attach a 16bit-colour exe (DX8 problem is NOT gone!) with the dog from above (picture). I modified it somewhat to stress the clipping-routine...

Have fun.
Posted on 2003-06-28 17:43:06 by VShader
There seems to be a pitchbug in the triangle rasterizer, I just get nasty shifted scanlines...
Are you perchance assuming that a scanline in memory is always width*sizeof(pixel) bytes long? It's not, the real length is called 'pitch', and you obtain it when locking a DirectDraw surface. So if this is the case, perhaps you can fix the bug, so I can see the program aswell.
Posted on 2003-12-15 15:17:59 by Bruce-li
Posted on 2003-12-15 15:58:21 by Delight
Delight, can you please start this version, make a screenshot and post it here? Please NO MOVEMENT before you make the screenshot ("PRINT"-key).

Posted on 2003-12-16 16:10:24 by VShader
Here how it looks without the pitch-error:

Posted on 2003-12-16 16:11:34 by VShader
i get this
Posted on 2003-12-16 17:32:14 by evil__donkey
We got a new computer @ work.
And there was that nasty graphics error (see above) too.
So now I could fix and test it: I think it was only the wrong pitch ( now I take the pitch-value from the direct draw surface, thank to Bruce-li ) - It should now run correct on all machines ?! (feedback please! Dx8? Dx9?)

If you want to run the racetrack-scene: rename y1.asc to y.asc .
Or you can start truespace 3.x , make your object and: ? File / Save object as / 3Dstudio ASCII *.asc ? ( name: y.asc ) to fly in your own scene.

Have fun.

(By the way: the only routine I now need to make a full game out of this is mixing wav-sound. Best way should be to use DirectSound from DirectX7 and above - Has anybody here a asm-file where DirectSound is initialized and used?)

Posted on 2004-04-27 17:16:14 by VShader
And here is the new engine:

Posted on 2004-04-27 17:17:35 by VShader
runs fine now (dx9.0b, winxpSP1, r9600xt, yaddayadda). Btw, even larger companies have made the infamous pitch error... I ended up writing a bugfix loader for the XCOM and TFTD windows ports because the developers hadn't considered reading the DirectX docs and used width instead of pitch :rolleyes:

PS: 800x600 version runs consitantly at 85fps (refresh rate) here - the wonders of a 2.53ghz P4 :). Planning on releasing source, or are you keeping it closed? And what about selecting the resolution dynamically? Would be fun to see how it does at 1280x1024 :P
Posted on 2004-04-27 18:40:01 by f0dder
Max. I can do (and test) here is 1152x864 .
But 16bit-integer-fixed-point-math is showing more and more in higher resolutions ...

Source is in this thread (but not the latest version).
I you have the pitch error search for "BytesProZeile" (=BytesPerLine) and insert something like this at startup:

;Linesize in Bytes (Pitch) from DirectDrawSourface
INVOKE Lock_BackBuffer
mov eax, ddsd.lPitch
mov BytesProZeile, eax
INVOKE Unlock_BackBuffer

( put it right after ";===_MyInit" )

"selecting the resolution dynamically": I have to set a parameter for fixedPointPrecision too, so: not in the near future ... :=)

Posted on 2004-04-27 19:42:49 by VShader
I ran the 1152x864 version, and just for fun turned off vsync. Speed varies from ~125 to 235fps, and is usually around 190. I guess it would be interesting to see the same engine in a float and a SSE2 version - and yes, I'm aware that would mean rewriting most of the code :).

PS: are you going to use this engine for a new version of 4D sports driving AKA stunts? :P
Posted on 2004-04-27 19:51:51 by f0dder
You might want to look into sub-pixel correction. This will make your edges 'flow' smoothly and give the whole scene a less 'jerky' look when moving around, because you will draw the lines at the actual fractional coordinates, and not just between two pixels onscreen.
Posted on 2004-04-28 02:05:17 by Scali
and just for fun turned off vsync.
( Sorry: ) How did you turn off vsync for DirectDraw (Matrox Mystique, Win95 here)?

...for a new version of 4D sports driving AKA stunts? :P
No, Kennedy Approach 3D !

... float and a SSE2 version
PMMX200 now, AMD64 soon: Not unlikely that I will add support for SSE2 then. (World can then be much bigger.)

... because you will draw the lines at the actual fractional coordinates, and not just between two pixels onscreen
I do compute the actual fractional coordinates but I have to draw at actual pixels (where else?). Filtering or AA would be to slow.

Posted on 2004-04-28 03:24:41 by VShader
I do compute the actual fractional coordinates but I have to draw at actual pixels (where else?).

Well, that's the point.
Say you have a line from point A( 0.01, 0.5 ) to B( 1.9, 10.0 )
You truncate the fractions, so you draw at A( 0.0, 0.0 ) to B( 1.0, 10.0 )
If you would draw out such a line on grid-paper, you will see that it passes through different cells than the first one.
With subpixel-correction, you can draw the actual line that passes through the proper cells (pixels).
This costs almost nothing extra, there is just an extra 'pre-step' required.
The idea is to define a hotspot inside a pixel. All hotspots are exactly 1 pixel apart.
So the trick is to align the start of the line to a hotspot. After that you can step one pixel at a time, as you normally do, because you will step exactly on the hotspots.
You might want to look closely at slowly rotating cubes or things, on hardware (they all have subpixel/texel/other gradient correction, and are therefore very smooth and stable), and compare it to yours. Your rasterizer will always divide a line up into an evenly spaced, evenly sized set of segments, like this:



And you will see it hop from one to the next.

With subpixel correction you can also draw the other lines, such as:



And this means that the edges will 'flow' more smoothly when rotating, because they are drawn more accurately.

Hard to explain, easy once you understand the problem.
The same goes for textures and other things, you want to sample the textures at the hotspots, not randomly inside a pixel because you just discard the fractions.
Posted on 2004-04-28 05:45:07 by Scali
Woah, I get like 393 FPS on the 32-bit version, I'm using a Thunderbird 900Mhz and an ATI Radeon 8500LE. Nice piece of work! :D
Ran the 800x600 versin, get like 120 fps, nice piece of work, hey one question, I'm writing an SMS emu and I'm quite disappointed at the flip speed, and I'm trying different recommendations by people like f0dder and the like, but how are you able to flip so fast!?!? My SMS emu on my PC is a DRAG at 800x600 and unreasonably fast at 320x240 (maybe because I'm calling a function every time I need to read the Z80 memory space, ick.., anways I'll optimize that out later), do you use hardware flipping?
Posted on 2004-04-28 15:18:06 by x86asm
Yes, hardwareflipping.

Rip out all the 3D-stuff from the source in this thread and use it for your emulator.

Please tell me how you disable VSync to get 393 FPS.

Posted on 2004-04-29 02:54:32 by VShader
Do you understand what subpixel-correction is/does now, or are you ignoring my post?
Posted on 2004-04-29 05:08:15 by Scali
-- ------
.... or are you ignoring my post?

Sorry, not all day online ...

I get the idea by your explanation but I have first to check out the effect on a lowres unfiltered scene on a accelerator.

Rememeber that this engine is mmx-based (16bit signed fixed point used for 3D-transforming) so the question is, if the accuracy of the transform is high enough that it is worth to implement subpixel correction (or if the transform is so inaccurate that you don't notice subpixel correction ).

Posted on 2004-04-29 06:16:39 by VShader
VShader, whether you can turn off flip-sync will depend on your video drivers. NVidia drivers have some registry hack iirc, ATI radeon drivers have it somewhere in the advanced display settings.

You should always leave it to the user whether to have flipsync or not, I personally hate games that disable it, as it causes ugly tearing. But it's useful enough when developing, to see what kind of framerates you are getting.
Posted on 2004-04-29 06:47:10 by f0dder