Graphics and collision engine

[Daniel3D]

Continuing the idea mentioned in the VCE file topic about the collision I noticed that there is no dedicated topic for this.

I include graphics and collision as one because they are in this case closely related.

Sound drivers had been around for a while in 1990. But this kind of graphics and the need for collision detection was fairly new.

It is clear by the way load.exe works that there is no graphics driver. The graphics engine is part of the main code. Even if we totally understand the code and port it to C, we would still have to rewrite all graphics related code to get SVGA.

The same applies to the collision. There is no separate engine written for it. But it is part of the main code. Finding how it works and changing part of it, like adding track elements, even if they share collision is impossible at this time.

At least. That is what I became to realise...

[Daniel3D]

Well,I can kinda follow what you are doing. But this is to advanced for me.

the implementation itself is easy if one knows the dosbox/16bit code internas a little
but the stunts related code (offsets etc.) needs stunts knowledge from reversing

I did find a code part where the track is loaded. It seems to be a sequence of multiple passes per tile. Maybe there are clues about collision data hidden

it sometimes helps to see the data live going through the functions for analysis - my tracer is something like that
debugging step by step isn't always the best way understanding it clearly

[Daniel3D]

it sometimes helps to see the data live going through the functions for analysis

True. I will look for the code again. I'm curious to see what happens then.

[llm]

...Even if we totally understand the code and port it to C, we would still have to rewrite all graphics related code to get SVGA.

but it would only take some short days to get higher resolution - if it was C Code

[Daniel3D]

...Even if we totally understand the code and port it to C, we would still have to rewrite all graphics related code to get SVGA.

but it would only take some short days to get higher resolution - if it was C Code

Wouldn't that not still be a fixed resolution?
I mean. If I understand the code correctly all graphics related code is based on fixed coordinates.
You can change that everywhere in the code and have a higher resolution but to make a dynamic resolution resolution is I think a lot more work.

[llm]

...Even if we totally understand the code and port it to C, we would still have to rewrite all graphics related code to get SVGA.

but it would only take some short days to get higher resolution - if it was C Code

Wouldn't that not still be a fixed resolution?
I mean. If I understand the code correctly all graphics related code is based on fixed coordinates.
You can change that everywhere in the code and have a higher resolution but to make a dynamic resolution resolution is I think a lot more work.

you're right - dynamic resolution would take some more time

[Cas]

Stunts internal functions, which I have only barely taken a look at, I must admit, seem to include primitives of the sort "draw a line from this point to that point" and "paste this bitmap at this location". As llm points out, if this were C, that is, if these functions were written as... well, functions, then it could be quick. There are a few caveats, but it should be feasible. In DOS, dynamic resolution wasn't used because it was always full-screen, so I think it's OK to have a fixed SVGA resolution.

Should this be done, the SVGA resolution should be a standard VESA full-screen resolution, such as 640x480. There is 640x400, that's more suitable (since Stunts is 320x200), but we should see if DOSBox's internal driver supports that one. Then, the internal drawing functions should be rewritten and their parameters should be scaled. Bitmaps would be scaled up so they would still look low-res, but polygons would look a lot better. Some small artifacts would occur because, while lines would be drawn in higher resolution, the polygon vertices would snap at 2X so sometimes, there would be a one-pixel wide gap. But yeah, it would work. It'd be much slower than normal Stunts, of course, because of paging, that can't be escaped in DOS real mode VESA.

[Friker]

What would be benefit of scaling polygons in game over some of DosBox's scaler (normal2x, hq2x)? Since you are talking mainly about running Stunts in Dosbox it seems to me that DosBox's scaler is more than enough for Stunts' limitations.

Anyway - I looked at this topic because of collision part of a title. How is collision code related to graphics code? These occurs to me as a two different things clearly separated in code.

[Duplode]

I hadn't read this or the connected topics back when they were posted last year, so I'm probably missing a lot of context. Anyway:

What would be benefit of scaling polygons in game over some of DosBox's scaler (normal2x, hq2x)? Since you are talking mainly about running Stunts in Dosbox it seems to me that DosBox's scaler is more than enough for Stunts' limitations.

Using scalers is always a bit of a compromise. Unless you specifically want some post-processing special effect introduced by them, you'll usually get better results by natively generating the graphics at the desired resolution.

(By the way, I have recently learned that -- at least with modern DOSBox forks such as DOSBox Staging -- the default recommendation, as long as your host system can handle it well enough, is to just use output=opengl or output=openglnb and let hardware scaling do its thing, rather than relying on software scalers like normal2x and hq2x.)

Anyway - I looked at this topic because of collision part of a title. How is collision code related to graphics code? These occurs to me as a two different things clearly separated in code.

They are separate indeed, though of course you'd ideally want to be able to change them in tandem. In fact, there are two different collision models: the car-surface (track, walls, etc.) one, and the car-object (opponent cars, trees, etc.) one. Some of it has been annotated in the restunts code (build_track_object is a good starting point for looking into it), and I had lots of additional annotations to it in my lost 2016 files.

[Cas]

Duplode has put it very clear already. I couldn't say that vector based scaling has a "benefit" over interpolation. It's just a very different thing. It would look different, it would be slow in a very different way, etc. In my opinion, if we wanted to add more resolution, a new engine should be written that ran natively on modern systems. Maybe, if we can isolate the physical collision code and interpret it, we can translate only that part into new native code and the graphical part, do it completely from scratch.

The physical engine in Stunts is completely blind to what happens with the graphics. And as Duplode said, there are two physical interaction types. Apparently, car-car collisions are calculated only based on distance, that is, to Stunts, cars are spheres when interacting with other cars. When a car is interacting with the environment, a car is a rectangular block (for collision) and it has a wheel system, which is use to calculate alignment with the surface and pitching while in the air.

This part of the engine, which is the more complex one, is not a general rule engine, that is, the car isn't all the time reacting to the environment in the same way. Instead, it switches from a status to another and the rules change. For example, a rule set is in effect when the car is upright on the ground, another when it's in contact with a surface other than the ground and another when it's floating in the air. There's no Newton here.

In many aspects, Stunts is a 2D game. Walls are always vertical and rotation vectors seem to behave like their components are always separate and aligned to the world. So a car pitches in the air in a way that's completely independent from its banking, for example. Truly complex to study.