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.