StuntsLegacyEngine

[GTAManRCR]

What's the current progress, Cas?

[Cas]

Well, the project status right now is like this:

The graphics engine can read all original track element shapes after being unpacked (with stunpack) and is able to render any track and you can look at it from any direction. Like Stunts, it uses a painter's algorithm, but since we don't know exactly how Stunts' original algorithm works, I am unable to make it do exactly the same. Therefore, if you use the original shapes, which are designed with Stunts' algorithm in mind, some glitches inevitably appear. If you design new shapes instead, it's easy to make them not have these glitches. Car shapes are still not drawn, but in theory, it can draw everything but wheels.

I've been considering to eventually make another version of the graphics engine that would use z-buffering instead, but this is a major change and I believe it's better to take the current renderer and advance into physics first, before replacing it, since anyway, any graphics engine that I make could be plugged together with the physics engine. Using z-buffering would mean virtually zero glitches and culling information would become unnecessary to process. It would also allow for polygons to cross each other completely and still look accurate, simplifying life for anybody creating new track elements. On the other hand, z-buffering is slower. This shouldn't be a problem for new computers, but I would have to use core routines in assembly unless I prefer to use OpenGL (which I don't, at least for this project).

The current graphics engine can do some things that the original engine cannot. For example, it can rotate track elements at any vertical angle, not just multiples of right angles. It can also place elements at any displacement. All this means that a track would not need to be strictly aligned to the grid. It can also dynamically change the material of track elements and incline them to match slopes, which Stunts can do, but does not open to the user, so with my engine, you can do things like putting a tunnel on a slope or create a dirty or icy ramp without needing to design new shapes for them. It also has one grille type that's not available in original Stunts.

The physics engine.... well, I'm stuck. I sat down to think about how to start and I couldn't come up with a good way. I've never done anything like that. In theory, it should be easier than graphics rendering, but I'm inexperienced. I think I will have to start trying things and fail several times until I start to grasp the idea. My confusion is especially strong regarding 3D collisions. Physical car parameters, I think I can work with reasonably well. With physics, another thing appears: a track comprehension engine. What this means is routines that allow the game to tell whether the car is on the road, which way the road must be driven, which path can take you to the finish-line, etc. These problems, I intend to solve, when the time comes, in a more "manual" way than Stunts, allowing the track designer to establish checkpoints and, if he or she wouldn't want to, have the track editor auto-generate them instead of the game engine.

Status of my own person

You guys know I'm busier than before since I started my new work, but I have to admit I do have some time. I've been dedicating some of it to CarWorks, which does have lots of pending things but at least, has reached a point at which it can do all the basic things that are needed from it. I've also been feeling pretty lazy, mostly because of the super-cold days we're having. It's hard to program when you're freezing, ha, ha. But if I feel like things are more active regarding this project, I'll probably retake it soon

[llm]

out of curiosity: would you replace the background images with a real terrain engine?

[Daniel3D]

I don't know what CAS thinks about that. But it looks cool.
I would personally only do a nearby terrain generation and a dynamic/animated horizon image.
But limited, stunts style terrain.

[llm]

I don't know what CAS thinks about that. But it looks cool.

if we ever get stunts fully ported/reversed (or Cas is faster) i would love to keep the flat shaded polygon style - but with 60fps+4k

like Racing Apex / Hotshot Racing

https://www.youtube.com/watch?v=QspneIhkGiU
https://store.steampowered.com/app/609920/Hotshot_Racing/
https://www.youtube.com/watch?v=1PvNgZewqOk

or good old Virtua Racing:

https://www.youtube.com/watch?v=iBv55iNxd2I
https://www.youtube.com/watch?v=dxe87MDWU_4

SEGA Wing War:

https://www.youtube.com/watch?v=ycxZmNZZVo0
https://www.youtube.com/watch?v=RDiSO_8NYis

I would personally only do a nearby terrain generation and a dynamic/animated horizon image.
But limited, stunts style terrain.

a image is not resizeable to 4k without problems - a real small terrain engine (simple one) is open

[Cas]

I have exactly the same aspirations as Ilm!  I love flat shaded polygons. No problem with that. But it'd be good to be able to use more of them (more primitives per shape) and higher definition so that they can be seen clearly. Direct colour would also aid in making very good models without the need to apply textures or shading effects.

Also, my current renderer is software based, like that of the original Stunts. I know that nowadays, hardware can do this much better, but I figure that if a 386 could do this in software, new computers must be able to do it too and I like working on the real part of it, because I learn a lot and it makes me feel much more proud of my project. However, it's perfectly feasible to do this in a way that allows to easily plug and unplug different rendering libraries and I would definitely separate it into layers, so the final rendering layer (the one that draws the triangles) can be redirected either to software or hardware or any library of your choice.

About the background landscape being generated in 3D, I begin to think that is probably the best option. All I have to do is define a "far field" made of large objects that are a lot further away than the track elements. Clouds and mountains would be placed there and they would automatically rotate with everything else, so the problem of rotating the image at the horizon would disappear. Of course, this means we would have to sit down to design these landscapes, which takes time.

[alanrotoi]

Is it possible to build a tool that runs paralel of Stunts and shows you the track map and your position, for replays and for live racing? Also with a tool like this it would be very interesting to watch live racing

[llm]

Is it possible to build a tool that runs paralel of Stunts and shows you the track map and your position, for replays and for live racing? Also with a tool like this it would be very interesting to watch live racing

everything is possible but we are currently stuck with closed source or asm-code only - its very hard to do changes in this stage - and limited time is always a problem :/

[Daniel3D]

Is it possible to build a tool that runs paralel of Stunts and shows you the track map and your position, for replays and for live racing? Also with a tool like this it would be very interesting to watch live racing

everything is possible but we are currently stuck with closed source or asm-code only - its very hard to do changes in this stage - and limited time is always a problem :/

If that were possible, we could also possibly translate the same positioning data to a different graphical engine for better graphics.

And it is sort of possible, but not real time.

[Cas]

Possible, yes.... But the big difficulty there is that it requires exact replication of Stunts physics, so we would have to extract the actual part of the code that does the thing. I know that Duplode has been able to recreate races so this is already half-done. But for this to really be live, we should insert internet communication code that would talk to a server and it'd put everything together and the thing is that code would have to be native to GNU/Linux and/or Windows, whereas the necessary Stunts code would be real-mode DOS code. Two ways to get this done come to my mind: one would be to completely translate Stunts to flat, protected mode code, which is the final objective of Restunts... very far, far away.... The other one would be to insert IPX calls at the right points in Stunts real mode code and then have DOSBox redirect IPX to TCP/IP and to a server. That server should be written to understand the inputs and combine them. That one is more feasible and still, a crazy lot of work.

Of course, there's another possibility: build a new Stunts engine from scratch   That should take a lot less time, that is... a couple of years? 

[Daniel3D]

It will take forever if you never continue..... 

[Cas]

I'm stuck with the collision problem. I imagine the car as a block and try to solve when it goes from a surface to the air and vice-versa and from one surface directly to another. It's really hard!

[Daniel3D]

I'm stuck with the collision problem. I imagine the car as a block and try to solve when it goes from a surface to the air and vice-versa and from one surface directly to another. It's really hard!

If it hits a plane, drive on it.
If it hits a wall, explode
If in air follow trajectory,
     if then hit plane on angle >X  explode.
     Else reset orientation, continue driving.
End if

I know it is more complicated than that.
But simplification can help get a different take on a problem.

[llm]

I know it is more complicated than that.
But simplification can help get a different take on a problem.

Its way more complicated in detail

Like how to port stunts to Windows
1. Disassemble the code
2. Rewrite everything to C
3. Compile for Windows

[Daniel3D]

I know it is more complicated than that.
But simplification can help get a different take on a problem.

Its way more complicated in detail

Like how to port stunts to Windows
1. Disassemble the code
2. Rewrite everything to C
3. Compile for Windows

For the original engine I can't even imagine how to get that done.
I was thinking about the collision part of CAS his engine. (Updated that post for clarity)