News:

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

Main Menu

Graphics and collision engine

Started by Daniel3D, July 16, 2022, 09:04:01 PM

Previous topic - Next topic

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...
Edison once said,
"I have not failed 10,000 times,
I've successfully found 10,000 ways that will not work."
---------
Currently running over 20 separate instances of Stunts or 4D Sports Driving.

Daniel3D

Quote from: llm on July 16, 2022, 01:07:57 PM
Quote from: Daniel3D on July 16, 2022, 09:11:13 AM
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

Quote from: Daniel3D on July 16, 2022, 09:11:13 AM
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
Edison once said,
"I have not failed 10,000 times,
I've successfully found 10,000 ways that will not work."
---------
Currently running over 20 separate instances of Stunts or 4D Sports Driving.

Daniel3D

Quote from: llm on July 16, 2022, 01:07:57 PM
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.
Edison once said,
"I have not failed 10,000 times,
I've successfully found 10,000 ways that will not work."
---------
Currently running over 20 separate instances of Stunts or 4D Sports Driving.

llm

Quote from: Daniel3D on July 16, 2022, 09:04:01 PM
...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

Quote from: llm on July 17, 2022, 07:32:37 AM
Quote from: Daniel3D on July 16, 2022, 09:04:01 PM
...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.
Edison once said,
"I have not failed 10,000 times,
I've successfully found 10,000 ways that will not work."
---------
Currently running over 20 separate instances of Stunts or 4D Sports Driving.

llm

Quote from: Daniel3D on July 17, 2022, 08:14:39 AM
Quote from: llm on July 17, 2022, 07:32:37 AM
Quote from: Daniel3D on July 16, 2022, 09:04:01 PM
...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.
Earth is my country. Science is my religion.