News:

Herr Otto Partz says you're all nothing but pipsqueaks!

Main Menu

Dissecting the Stunts files, trying to. Anyone know more?

Started by Cyberman, July 23, 2004, 08:15:12 PM

Previous topic - Next topic

dstien

Quote from: Duplode on October 27, 2008, 06:58:09 PM
Quote from: CTG on October 27, 2008, 09:42:11 AM
Only an idea for Stressed innovation: to make the car edition faster, it would be cool to have a special duplicating option which converts the new polygon to inverse X coordinates.

On that same line, one addition I'd propose would be vertex reordering in polygons, so it would be easier to flip their faces. Anyway, both major recent changes - culling data displays and weld coexisting vertexes - were really useful and help a long way in making Stressed a capable 3D editor for Stunts shapes, in particular for testing and experimentation.
Added both features in SVN, although this can already be done with existing 3d modelling software...

Quote from: Duplode on October 27, 2008, 06:58:09 PM
Just one small thing, Dstien: it seems you inserted back that 49x line on shaperesource.cpp which (tries to) export wheels as lines. Could you please revert it to r35 behaviour? Thanks in advance  :)
Hm, are you sure? It doesn't look like I reversed the change...

Quote from: Duplode on October 27, 2008, 06:58:09 PM
Now, on to further experimentation: after a lot of head-scratching, I have a reasonable, semi-functional, theory on how the four culling bit sets work.
Thank you! I'll need a little more time to digest it and do some experiments. I think we'll fully solve the mystery in time for Zak's submission deadline. 8)

Duplode

#241
Quote from: dstien on October 28, 2008, 02:08:35 AM
Added both features in SVN, although this can already be done with existing 3d modelling software...

Thanks for catering to our requests so quickly!  :) Although I use Anim8or for heavier edition work Stressed 3D capabilities are quite convenient for adding small overlaid details and doing quick tests - exporting to .OBJ means losing culling data and the other flags, as well as often some polygon reordering. Speaking of that, I have one last solicitation (okay, you can kick me now... :D): a widget for moving a polygon to an arbitrary position on the list - say, moving polygon #45 to position #110. The polygons shouldn't be swapped, however: in said example, polygon #46 should go to #45, #47->#46 and so on. This addition is important because of Z-bias, as it requires any overlaid polygon to be ordered directly after the base polygon. Fixing the order of a number of polygons can be a bit tiring sometimes, and that's one of the reasons why I often get lazy about exporting intermediate models to .OBJ...  :)
(PS.: And before I forget, I saw the improved material list, and it was a nice addition as well)

Quote from: dstien on October 28, 2008, 02:08:35 AM
Hm, are you sure? It doesn't look like I reversed the change...

As expected, you're correct. I had commented out that line manually and then placed a backup of the file on src/shape, so SVN must have messed up a bit during the multiple updates. Problem solved, anyway...

dstien

Quote from: Duplode on October 28, 2008, 03:04:56 AM
Speaking of that, I have one last solicitation (okay, you can kick me now... :D): a widget for moving a polygon to an arbitrary position on the list - say, moving polygon #45 to position #110. The polygons shouldn't be swapped, however: in said example, polygon #46 should go to #45, #47->#46 and so on.
Done, and I also made a new Win32 build. Now to wrap my head around the culling...

CTG

Quote from: dstien on October 28, 2008, 07:21:56 PM
Done, and I also made a new Win32 build. Now to wrap my head around the culling...

Great job again! What are your long term plans with Stressed?

cody

i have 2 ideas for stressed:
1, have the ability to scale ,move, rotate polygons from within stressed
2, add the ability to merge in excisting .p3s and .3sh's (this can be helpful when adding parts of another car)

Duplode

Quote from: dstien on October 28, 2008, 07:21:56 PM
Now to wrap my head around the culling...

Beware not to get hit! (as your head won't be visible... ;D)

(sorry for not sparing you from such a poor joke...)

dstien

Quote from: CTG on October 29, 2008, 12:18:14 AM
What are your long term plans with Stressed?
Keep on adding stuff untill I get bored. Car tuning is next up.

Quote from: cody on October 29, 2008, 12:52:06 AM
i have 2 ideas for stressed:
1, have the ability to scale ,move, rotate polygons from within stressed
I'm sorry, this would require a full rewrite and a lot of boring work. :-[
Quote from: cody on October 29, 2008, 12:52:06 AM
2, add the ability to merge in excisting .p3s and .3sh's (this can be helpful when adding parts of another car)
I'll add it to my todo list.

Quote from: Duplode on October 29, 2008, 02:06:10 AM
Quote from: dstien on October 28, 2008, 07:21:56 PM
Now to wrap my head around the culling...

Beware not to get hit! (as your head won't be visible... ;D)

(sorry for not sparing you from such a poor joke...)
I survived both the culling and the joke, but it looks like we have a casualty in terms of laptop screens...

Quote from: Duplode on October 22, 2008, 06:30:24 AM
There is no such a thing as vertical culling.
Indeed, the second culling data appears to be horizontal culling around the Y-axis as well. I just can't figure out where/if this information is used at all.

The flags indicates angle ranges between polygon planes and the global Y-axis:

Flag  Range
----  -----
Far+  0° - 135°
Far-  45° - 180°
Near+ 0° - 45°
Near- 135° - 180°

Duplode

#247
Quote from: dstien on November 04, 2008, 03:25:35 AM
Keep on adding stuff untill I get bored. Car tuning is next up.

8) - I don't know what your feelings are about elaborate graphical displays of torque curves and meter needle positions, but whathever the case, that will be sweet. It deserves another 8)

Quote from: dstien on November 04, 2008, 03:25:35 AM
Indeed, the second culling data appears to be horizontal culling around the Y-axis as well. I just can't figure out where/if this information is used at all.

The data we used to call "Cull V" is horizontal culling just like for "Cull H" indeed, but CH acts only on wiew positions facing the front of the polygon, while CV acts on views facing the back face. Or at least that's what the tests led me to believe on...

Quote from: dstien on November 04, 2008, 03:25:35 AM
The flags indicates angle ranges between polygon planes and the global Y-axis:

Flag  Range
----  -----
Far+  0° - 135°
Far-  45° - 180°
Near+ 0° - 45°
Near- 135° - 180°


Hmm, that sounds interesting and may poteintially explain quite a lot of stuff (my failure in controling visibility of bridge undersides comes to mind). I will play with this as soon as I get to boot Stressed again.

---

PS.: And BTW, a completely unrelated piece of info: while setting up the Skyline dashboard, I found that the two final 16-bit integers on bitmap resources "Unknown 1" are just X and Y screen coordinates for positioning the bitmaps.

dstien

Quote from: Duplode on November 04, 2008, 06:23:59 AM
Quote from: dstien on November 04, 2008, 03:25:35 AM
Keep on adding stuff untill I get bored. Car tuning is next up.

8) - I don't know what your feelings are about elaborate graphical displays of torque curves and meter needle positions, but whathever the case, that will be sweet. It deserves another 8)
Do you know how to draw the torque curve?

Quote from: Duplode on November 04, 2008, 06:23:59 AM
The data we used to call "Cull V" is horizontal culling just like for "Cull H" indeed, but CH acts only on wiew positions facing the front of the polygon, while CV acts on views facing the back face. Or at least that's what the tests led me to believe on...
I'm not sure what you mean by back face in this context, but I've implemented some code to compute the culling data. It took a while, ZCT89 almost made me lose all faith in this game. :D

I'm currently using rough approximation to set the number of bits based on the polygon's angle on the Y-axis. The number of bits was determined by analyzing 3000 polygons from the stock shapes. The direction is then set by rotating according to the angle around the Y-axis on the XZ-plane. Although we should check the range covered by each bit, the current solution appears to be surprisingly accurate. The only in-game test I've done so far was on Cody's Ranger. With proper culling data the glitchy polygons in the car selection screen disappeared! But will it make any difference performance-wise?

Quote from: Duplode on November 04, 2008, 06:23:59 AM
PS.: And BTW, a completely unrelated piece of info: while setting up the Skyline dashboard, I found that the two final 16-bit integers on bitmap resources "Unknown 1" are just X and Y screen coordinates for positioning the bitmaps.
I noticed your wiki edit, nice find! It looks like the game ignores these values when reading animation frames, I had only tested with opponent animations.

Duplode

Quote from: dstien on November 15, 2008, 05:32:47 AM
Do you know how to draw the torque curve?

Well, I know where to find the values (0x60 to 0xC7 of CAR*.RES) and have a reasonable estimate on how they correlate to "real" physical values, if that's what you meant by draw. By "elaborate graphical displays" I meant displaying the torque versus rpm values on the screen as a graph, and something analogous for the meter X and Y coordinates (and no, I can't program this sort of drawing... :D).

Quote from: dstien on November 15, 2008, 05:32:47 AM
I'm not sure what you mean by back face in this context, (...)

Front and back face were used in the usual sense of "sidedness", according to the orientation of the normal. If you change vertexes order from clockwise to counter-clockwise you exchange front and back faces, and so on. Now, if you pick a polygon and set both C1+ and C2+ to 77777 and 77777 you'll see that, for "large" distances, it will be visible regardless of whether you are looking at the front face or the back face. With 00000 and 77777 it will be as if the front and back faces were reversed. The vertex order and Z-bias flag only are active for "short" distances; for "long" distances C1+ and C2+ do the horizontal culling. I still can't understand C1- and C2-, though...

Quote from: dstien on November 15, 2008, 05:32:47 AM
I'm currently using rough approximation to set the number of bits based on the polygon's angle on the Y-axis. The number of bits was determined by analyzing 3000 polygons from the stock shapes.

:o :o

Quote from: dstien on November 15, 2008, 05:32:47 AM
The direction is then set by rotating according to the angle around the Y-axis on the XZ-plane. Although we should check the range covered by each bit, the current solution appears to be surprisingly accurate. The only in-game test I've done so far was on Cody's Ranger. With proper culling data the glitchy polygons in the car selection screen disappeared!

I tested the solution for the Skyline, and it seems to be working perfectly indeed, both for car0 and car1  :) Users should only avoid using non-planar polygons or polygons with three or more co-linear vertexes, or be ready to fix the culling data, as the normal determination may not work properly in those cases (that is, obviously, not fault of your code...). Re-calculating the culling data for the default cars, your approximation matches the original patterns very well, usually only setting one or two extra bits on at most per polygon (it's better to set more bits on than less, anyway).

Quote from: dstien on November 15, 2008, 05:32:47 AM
But will it make any difference performance-wise?

Testing with the downscaled Corvette car0 shape I mentioned some posts ago, the minimum number of DOSBox cycles needed for reasonable fluency with two cars loaded has dropped from 16000 to 14000. Some improvement, but still not enough to use shapes with ~200 polygons...  :-\

Quote from: dstien on November 15, 2008, 05:32:47 AM
I noticed your wiki edit, nice find! It looks like the game ignores these values when reading animation frames, I had only tested with opponent animations.

The game ignores those coordinates for moving parts of the dashboard as well, which have their positions controlled by CAR*.RES.
Speaking of bitmaps, there is one feature that will probably be necessary: a "Color to alpha..." option. I have not found a way to use the FF value of the palette and/or preserving the transparency within GIMP during the Import/Export cycle, so I had to paint the areas I wished to define as transparent with an unused colour from the palete and them replace it by FF on an hex editor. Allowing for that substitution to be done within Stressed is probably the easiest solution for the issue.

Duplode

Just checked in the new updates which include alpha handling on import; will give them a try in order to finish whl_ and ins_ details on the Skyline dashboard. Thanks!  ;)

dstien

Quote from: Duplode on November 16, 2008, 12:37:28 AM
Users should only avoid using non-planar polygons or polygons with three or more co-linear vertexes, or be ready to fix the culling data, as the normal determination may not work properly in those cases (that is, obviously, not fault of your code...).
I don't think this is a problem, it looks like polygons has to be convex anyway in order to render properly. Also, if you look at primitives such as 34 and 35 in STAUDI.P3S:car0 you'll see that the cull calculation failed for the game designers as well. The polygons in question are probably the result of integer rounding and should actually be discarded due to lack of precision...

Quote from: Duplode on November 16, 2008, 12:37:28 AM
Quote from: dstien on November 15, 2008, 05:32:47 AM
But will it make any difference performance-wise?

Testing with the downscaled Corvette car0 shape I mentioned some posts ago, the minimum number of DOSBox cycles needed for reasonable fluency with two cars loaded has dropped from 16000 to 14000. Some improvement, but still not enough to use shapes with ~200 polygons...  :-\
That's what I feared since the culling doesn't seem to affect close-up views. Have you tried running Stunts natively under Windows? I have mixed experiences with DOSBox overall performance, maybe we'll have more luck running DOS in a "serious" virtual x86 machine?

Quote from: Duplode on November 16, 2008, 12:37:28 AM
I have not found a way to use the FF value of the palette and/or preserving the transparency within GIMP during the Import/Export cycle, so I had to paint the areas I wished to define as transparent with an unused colour from the palete and them replace it by FF on an hex editor.
Ah, I never tested it. :D

SVN revision 50 introduced Y-axis correction in the 3d view. Shapes shouldn't look vertically stretched anymore compared to in-game rendereing. This doesn't affect OBJ import/export, but you can stretch the shape before exporting from your 3d editor. I'm currently using the ratio 1.0 in data set = 0.8 on screen, that's the ratio used by the stock car wheels.

Duplode

Which of these pairs of screenshots resemble more what you are used to see when playing Stunts? And which pair looks best? (it would be nice to have the opinion of both DOSBox users and people which still play on pure DOS, or at least remember clearly how it was like).

Pair 1:





Pair 2:




BonzaiJoe

I think the bottom one looks more familiar to me. Only it's a bit more grainy than usually. Lower graphics acceleration level?
But we can't be quite sure.


Chulk

Quote from: BonzaiJoe on May 02, 2009, 01:55:44 PM
I think the bottom one looks more familiar to me. Only it's a bit more grainy than usually. Lower graphics acceleration level?
Exactly my thoughts (in DOSBox)
Yes, it is me. No, I'm not back at racing (for now...)