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

[dstien]

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...

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...

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.

[Duplode]

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... ): 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)

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]

Speaking of that, I have one last solicitation (okay, you can kick me now... ): 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]

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]

Now to wrap my head around the culling...

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

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

[dstien]

What are your long term plans with Stressed?

Keep on adding stuff untill I get bored. Car tuning is next up.

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.

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.

Now to wrap my head around the culling...

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

(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...

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:

Code Select Expand


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


[Duplode]

Keep on adding stuff untill I get bored. Car tuning is next up.

- 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

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...

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

Code Select Expand


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]

Keep on adding stuff untill I get bored. Car tuning is next up.

- 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

Do you know how to draw the torque curve?

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.

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?

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]

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... ).

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...

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!

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).

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... 

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]

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...

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?

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.

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?

[Chulk]

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)