StuntsLegacyEngine
This first post will serve to keep at hand the information we're handling and to keep track of the status of the project.
The source code of this early version of the engine can be found at:
https://notabug.org/xlucas/sle (https://notabug.org/xlucas/sle)
For compiling, FreeBasic can be found here:
https://freebasic.net (https://freebasic.net)
For creating track objects, you can get Blender from:
https://www.blender.org/ (https://www.blender.org/)
Currently, the engine can render objects at arbitrary positions and one can move around, define new objects with any rotation and place them. It accepts OBJ files. Ground and sky are not being drawn. It's easy, but better keep it clean for now. Some bugs present.
Alright. So now in more detail....
Source code and data files
You guys can get the source for this engine from the repository. I included a few data files, which so far are all text, so that should be fine, but I would like to be able to exchange data files more comfortably. I wonder if I can just edit the first post to add and remove attachments so that it's not accumulated, but just changed. Anyway, I'll try to find an optimal way to exchange this.
Getting the binaries
If you're going to be checking updates and modifying the source code, you can get FreeBasic and it'll be super simple. If you need me to pass the binaries, I can quickly get you the GNU/Linux 64bit executable, but for other platforms, it's pretty inconvenient for me to compile it. I have Wine on a portable computer and I have to pull it out, turn it on, copy the source to it, then compile it and then pass the binaries back. I could install Wine here, but it's like having two OSs running together all the time. I'd prefer to avoid it. But just let me know and I'll see what I can do.
Current status
If you've tried the previous engine and now you test this one, it will at first appear to you that I'm moving backwards :P But behind the scenes, this engine is superior. I haven't yet turned on the sky and ground, but that's easy to do and I'm more concerned on other things. There's a config file where you can load a materials file, then several OBJ files that can make use of the materials in the first file. After that, you can place these objects anywhere on the map. With the arrows, plus A, S, D, W and PgUp/PgDn, you can move freely in the map. CTRL+D toggles debug information and [ and ] will change the distance-to-screen. Everything is in meters. The engine uses a coordinate system just like the one in Blender, with Z going vertically. I like it because it looks nice with the right-hand rule and makes more sense for an engine in which Z has phisically a different meaning from that of the other two dimensions. Visibility can be changed by modifying the source. It's set at 1200 meters.
Creating objects
You can use Blender to create object files. Going to File->Export will do the trick. Blender, by default, uses the same coordinate system and also works in meters. But! I found that, at least the newest version of Blender, swaps Y and Z when saving OBJ files. This makes sense because other software will frequently use Z for depth, but I dislike that coordinate system as, to follow the right hand rule, you're forced to have Z grow towards the camera or otherwise Y grow down. Because of the swap in Blender, I decided to make my source code swap the coordinates back. In other words, work on your model as if the coordinates were exactly as shown in Blender. If your object appears rotated, though, let me know or check the LoadObj routine.
Materials
When you export an object in Blender, it will create two files: an OBJ file and a MTL file. You can load many OBJ files and many MTL files in the configuration, but it makes more sense to only load one material library. As you create materials in Blender, you're allowed to rename them. The name you give them will be passed to both the MTL and OBJ file. You could just append MTL files to one another to make one large material library. If you want to reuse a material you used for another object, just give it a similar colour while working in Blender, but make sure to assign it the same material name. When you load the OBJ file, the material will be loaded from the original MTL. Sounds confusing? Just play around or ask me. I'll be making a new simpler format for this purpose soon.
Bugs
I'm having a problem since the previous engine (although now I understand part of it and before, I understood nothing). Even though the triangle clipping routine works, I get strange artifacts when triangles cross the camera plane. I am not totally sure if the problem ocurrs when the cross the zero plane or just the screen plane. I suspect the first. You'll see some glitches when this happens.
While the clipping routine does look OK and you can see how it works when you move the clipping distance forward, this clipping distance gives the impression of not being in proportion with the distance-to-screen. Could this be just an illusion? No idea. But despite this, it is clear that rendering works better with the clipping routine active.
Some non-bugs are rather things to be done. Like, rotation can easily be optimised by creating a fixed matrix for each rendering iteration and then applying the same matrix to every object instead of repeating the calculation. Layers are not being taken into account, nor is pseudotransparency, like in Stunts, but that can be activated very easily. Same goes for the horizon.
Sorry about my absence here, but I have been working on the engine. It doesn't look like a lot, but I added horizon (which needs to be rewritten, as it's not perfect), I sorted out the clipping problems I had and I managed to optimize vertex rotation by creating a static matrix. The engine now can load .trk files (only the few elements that have already been recreated, of course) and I would like to make a configurable version so one can easily add and remove element bindings without having to edit the source.
With things working like they do now, I'm thinking the engine is more ready to become an X-Wing clone than a Stunts clone, but there it goes. Physics is going to be pretty hard to accomplish.
Cas. I had something nagging in the back of my mind about something I've seen that I thought was interesting.
Today I found out wat it was.
Maybe I interesting:
Scala programming language.
I have a book (software engineering from scratch) on it where you can build an OS.
So as far as I understand, no dependencies.
(Not sure. I'm not a programmer)
Uhm! I'm taking my first read about it! From what I see after a very quick look, there are very good intentions here. It looks like the idea is to create a "Java done right". I am very critical of Java, so that sounds very interesting, but the thing I dislike the most about Java doesn't seem to be in the list of the things that Scala wants to change, ha, ha: the fact that Java forces you to use OOP. On the other hand, it does make several very good points. The code looks much cleaner in Scala and even though it's very OOP, I am kind of able to read it without getting lost (and it's my first look at it).
The lack of dependencies, which you mention, is surely true about Scala, because while I dislike Java, that one also depends only on a Java Virtual Machine and Scala can produce Java byte code, so it should share that property. If I have to mention one thing I do like about Java, it's precisely that and Scala has it too.
It says in the article that Scala is part-OOP/part-functional, but I don't see in the examples non-OOP code because apparently the person who wrote the article likes OOP. I'll continue to read more to have a deeper impression of it :) Thanks!
And about the engine... I have to retake this and I'm feeling so lazy! I've been thinking of simplifying the engine and make it load Stunts 3D shapes but make it work always on the ground, without banking (like a classic car engine). From there, I could begin working on the physics... acceleration, breaking, grip, gear torque, etc. Once I can really handle that, I can add the third dimension back again.
Alright. Back to the engine topic. I finally overcame my laziness and got my engine working in a different sense: I made it display the shapes from 3SH files. Now I've noticed that while they look very good, there are a few things that don't look the same and they won't unless I either modify the shapes or modify the engine, but while the latter would normally be the obvious, I have some reasons to prefer the former, so I ask for your opinions.
What happens is this. Stunts uses a culling and layering system that consists of three attributes:
- Culling flags (bits that tell you for each orientation whether you have to draw a primitive or not)
- Z bias (a bit that groups primitives by priority: first draw all primitives with Z-bias 0 and then all primitives with Z-bias 1)
- 2-sidedness (a bit that indicates a primitive can be seen from both sides; otherwise, they are only seen from the side where points run counter-clockwise)
My engine uses a different system and I thought it'd be compatible, but I've noticed exceptions. It goes like this:
- No culling flags
- Layer number (like Z-bias, but instead of going from 0 to 1, it goes from 0 to 3, so you can stack more polygons)
- 2-sidedness (same as Stunts)
- Automatic primitive ordering by how far their average vertex position is
And yes, automatic ordering manages to make culling flags unnecessary in almost every circumstance... Except when you want to draw line segments on top of a surface, like the barn door or the "Joe's" sign. Because segments have only one "side", the only way to tell whether they're on top or not is layering, but this makes these lines visible from the other side of the shape! Solution? Either implement culling flags or replace the segments with other primitives, such as thin rectangles, so that they can be one-sided.
Another problem comes because Stunts shapes were created taking culling flags into account. In some circumstances, the shape could've perfectly worked without the culling flags, but Stunts developers made some objects Z-biased and gave them culling flags because Stunts does not have an automatic primitive-ordering system. This is the case of gas tanks in front of a gas station. Solution? Again, either implement culling flags or remove the Z-bias from those objects.
I don't feel like implementing culling flags because they would add up yet one more check and make the engine slower and more convoluted. Besides, when you're creating 3D shapes, being able to not thinking about culling directions makes design a lot more straightforward, in my opinion. But then, instead of creating a program that you can just place in Stunts directory and run it, probably the files will have to be converted first into another format and these details be taken into account.
Any opinions are welcome and if they add ideas, much more! :)
Well. Conversion only goes for shape file's. So the original track pieces, scenery and cars.
The only have to be converted once.
So I don't really see a problem besides that I would have been cool to have used the original unaltered.
I'm still not 100% decided. Maybe I implement culling flags after all... but given that all new objects to come will not need those flags and cars don't appear to need them already.... I have doubts. Also, because Stunts cannot sort primitives, the developers had to split some objects into two or more models, to make sure that one is drawn before the other. By creating a new set (which could perfectly look almost identical to the original), we could just make them one thing each.
A look into some engine tests. I found a bug and fixed it. It's loading the shapes well. I haven't configured all shapes, but I can make a translation table and it will be easier. Track opcodes are a mess! Why didn't they just ordered them all rotating counter-clockwise? No! Each track element has its particular distribution.
Anyway, I wanted to run this test with a few of the elements. In spite of the non-optimised routines, it runs very fast. I thought I was using heaps of memory, but no... Not even four megabytes. Not drawing the ground and the sky right now. I can add them quickly, but when not leveled, I'm doing something wrong with pitch and it doesn't match, so I have to rethink that part.
OK. Some more objects added, plus ground and sky. The engine still runs fast. There are a few concerns:
- Stunts shifts ramps automatically when on land slopes. I feel like it'd be better to create shapes for these. On the other hand, if somebody ever makes a new ramp style, it'd nice to have it automatically converted, but also prevents you from designing the way in which you would convert it
- Similarily, Stunts automatically changes the road material, so no extra shapes for dirt and ice. I could create new shapes for that or make a routine to do it automatically, like Stunts. For now, these things are not supported, so only paved roads
- Line segments sometimes are drawn when they're not supposed to because of the difference in culling systems. I can fix this by creating new designs
- No pitching or rolling with this ground and sky. While everything else rotates OK, I still don't have a good routine to rotate the ground and sky. It should be easy, but I have left it for the end.
- Windmills use an animation based on colours that change live. Those black regions are supposed to be sometimes transparent, sometimes brown. I can recreate this, but I prefer to do it in another way, so this is flexible and other objects can have animated things as well, so I'm not implementing what the original windmill would require. Instead, I will have to edit the windmill later.
Wow! That looks amazing! :) I don't think I've ever seen so many Stunts objects rendered on screen at the same time!
It looks amazing. Can't wait to drive test it.
(I know. I skip a few steps... Just excited by the looks)
With the high resolutions we have now (and this window is not even regular HD), small objects render well even relatively far and because computers are fast, there's no need to set the visibility so close. One thing I don't like very much is what road centre lines look like when they are far. Makes me think maybe there's still a reason to use lower detail shapes from a certain distance onwards. The current engine uses only one shape per element, but I could add that possibility later.
Still working on the rendering engine. It already works well (except I haven't made the ground/sky routine), but I was trying to tune it so that it renders Stunts original shapes as similar as possible. I guess I will have to give up a significant level of similarity to concentrate on what's important. I have no way to guess how the original engine interprets the Z-bias, but it's not the same as what I do, no matter what. With new shapes, there should be no artifacts, but inevitably, many will be present while using the original shapes... yet, at least, it will render the thing.
Later on, when there aren't other more important things to do first, I'll turn this into a Z-buffering renderer or at least, allow the option of using Z-buffering. I don't think of it as a priority now because it's a lot slower than what I'm doing and I'm sure Stunts didn't do it either. With Z-buffering, though, all culling problems would disappear.
As you can see in the picture, now materials can be changed freely. I also managed to convert ramps to horizontal. I have to test those to see if they align well, but it looks like they do.
Stunts never originally changed the ramp surface from paved even if the neighbouring track pieces were dirt or ice. Is this a new feature that you are adding?
I just wanted to demonstrate that it can be done. In fact, I believe Stunts internally can do this; it just chooses not to give the option. Original Stunts shapes do not include dirt and ice, so they have to be converted from the paved versions. This means that Stunts has a routine that performs this conversion, so I implemented this same thing. The conclusion is that Stunts could use it on any object that has pavement materials, but it limits this. I'm not surprised that it puts a limit for things like ramps, because it looks weird, I must admit, but for slaloms, tunnels and chicanes, it'd probably look OK. My engine can do it easily, but again, I think Stunts can too.
OK... This is an update... an important one!
I'm uploading the current state of the engine. The zip file includes the binaries for Linux 64bit and Windows, plus a couple of configuration files the program uses and the two game?.3sh files from Stunts. These last two files, you all have them, but because they have to previously be unpacked, I preferred to just pass them.
To test the engine, you will need a track, any one. Just copy the track file to the directory and run the program. It will ask you to enter the track file name. If you omit the extension, it will assume ".trk". Use the arrow keys to navigate over the track terrain and A and Z to move up and down. Also, < and > to "strafe". Visibility is set to full track. With very, very populated tracks, you may notice a very mild slowdown. I'm surprised that it takes so much to slow the engine, as it can still be greatly optimised and as I said, visibility is going to infinity (almost).
Of the strange things you will notice, there is one that I know exactly how to fix, which is the fact that large objects (bigger than 1x1) may look incomplete on top of hills sometimes. Apart from that, almost every other strange artifact is due to the fact that I use a culling algorithm that's different from that of Stunts and I have no way to guess exactly how Stunts does it, so it will always be different. A solution for all that is to redesign all shapes (not necessarily from scratch; a few modifications on each may do the trick). The most annoying thing is the tunnel as it is seen from outside.
Let me know what you guys think
This is a helpful software if you want to see the map from 3D before driving it, but feels like Test Drive 1's keyboard controls (Only reacts to 1 keypress at a single time)
Wow. It looks good.
Can't install it just yet. But I can't wait.
You said you'd have a fly over ready by the end of the month three weeks ago and I wasn't sure you would make it.
Great job.
I'm really looking forward to seeing the physics engine work. Then we can drive in higher detail.
And maybe online multiplayer this summer ???
Hey, guys! Thanks for your reviews :)
Quote from: GTAMan18feels like Test Drive 1's keyboard controls (Only reacts to 1 keypress at a single time)
It's only the graphics engine you're testing. I've done nothing about input and physics yet. The idea of this demo is to showcase the graphics capabilities and also, yes, with a few touches, it can work as a track previewer. I still have a few things to do before getting to physics.
Quote from: Daniel3D on February 28, 2021, 07:42:46 AM
I'm really looking forward to seeing the physics engine work. Then we can drive in higher detail.
And maybe online multiplayer this summer ???
To get into physics, I have to do a few things still. First, fix that problem that causes incomplete large objects on hills. Then, make the horizon rotate (the track elements can be rotated in every way, but still not the horizon). The landscape and clouds are not being drawn, but I could leave that for later. What I should do is facilitate creating new track elements or new versions of existing ones so the visuals can be improved. With that possibility open, I can start to write some physics.
About multiplayer, it all depends on how easy or hard physics turns out to be. I've never tried making something like that. Making a game multiplayer isn't very hard if you've left the "slots" for that during the making. And probably, before multiplayer, I will have to think about sound. In many games, that can be left for the end, but hearing the engine and the skidding is very important in a cars game.
Quote from: Cas on February 28, 2021, 08:53:39 AM
hearing the engine and the skidding is very important in a cars game.
That's very true. And important for debugging.
Although in the beginning there is no direct need for high end sound effects. Pc speaker style generated sounds are good enough for the beginning.
So you are creating Stunts v2.0?
That is the general idea. Since there are wishes for improvement but no source code the only option is to remake it.
Hence the research on corner signs, camera placement and what quirks define the game.
I can't program myself but I am a happy supporter of the project. (For a big part because I want to see it succeed unlike for instance Ultimate Stunts)
Ultimate Stunts just feels off in terms of gameplay, those cars have worse controls, I hope this project will have a very good handling model of cars (As the other Stunts fanmade projects have much worse, than the vanilla Stunts)
Exactly. And TrackMania for instance has similar gameplay, the original version has most if not all the track elements of Stunts, sort of the same game modes. It even stores replays by player inputs.
But it added a scoring system and options you have to buy or unlock. Frustrating as hell..
It's completely the other end of the spectrum in my opinion.
CAS wants to update and add features but stay true to the look and feel of the original. All old content can be imported. So all custom cars will be available to. But they may be converted to accommodate the new features. You will drive car0 and not car1 for instance.
Quote from: Daniel3D on February 28, 2021, 04:20:54 PM
You will drive car0 and not car1 for instance.
That's sound good to my ears. I am always disapointed when I saw my car under stressed with a lot of détails and on stunts.
What I'm making is not a new game; it's a new engine for the same game. Of course, it's not trivial to make it feel really like Stunts, but since that is my number one objective in the project, I guess I'll end up getting closer in that aspect than any other previous one.
About car models, I still haven't reached that part, that is, my engine can already load car models, but still not put them on track and such. So there are many alternatives on which to use. My engine uses floating point vectors, so models can be scaled from any base shape. The best option, I believe, is to create a new car format that can carry floating point vectors and can surpass the limit in number of vertices and primitives. You will be able to convert either the car0, car1 or car2 if you want of an original or custom car into this format and you can also create a new model from scratch specially designed for it (with more primitives or vertices than Stunts cars). Still, I think we shouldn't go much further than the 255 primitives. I think a car with some 500 primitives will look very good already. The engine allows up to 32767 primitives, but that would be too slow.
Are you planning to also remove the 32 car limits, and make tracks bigger than 30x30?
Yeah,
More cars, bigger grid, more levels of track and terrain.
Possibly:
- underground tunnels and new track elements.
- Besides different track types also different terrain types (like sand, dirt, snow and/or rock)
- content manager to upload/download share and create new cars, track or scenery
-Multiplayer modes
But first. Get to equal the original. Then build on.
Quote from: GTAMan18 on February 28, 2021, 08:06:48 PMAre you planning to also remove the 32 car limits, and make tracks bigger than 30x30?
This is pretty much like Daniel said. I'm concentrating in being able to reproduce Stunts first, but I'm leaving all the "slots" for the new things we all want to be able to add. Some are super easy to do, like the two you mentioned. They are immediate. Others require some work, but not necessarily a lot. For example, multiple layers is not hard to implement, but I have to be tidy and it forces me to create a new track file format.
I want to add more features, but more than that, I want other people to be able to add more features. That is, I want to make this engine "moddable".
One thing that a few people here don't like very much is that I chose FreeBasic to make the engine. I really had no choice. C is more standard, but it provides no graphics and I do not want my project to depend on external 3rd-party graphics libraries. But I can make it easy to plug C-based mods into the engine.
Quote from: Cas on February 28, 2021, 07:14:56 AM
OK... This is an update... an important one!
I've just tried it and even as a 3D track viewer, it is very impressive! :) I'm looking forward to the future development.
Thanks! Once we get the current race in R4K running again, I think I should add a project page there for the engine just like that of Bliss. I think I should be thinking of a permanent name now. Legacy sounds nice, but it's kind of cliché and SLE is an illness, ha, ha...
Ztuntz, or 4D Zportz Driving?
Quote from: Cas on March 01, 2021, 05:43:38 PM
Legacy sounds nice, but it's kind of cliché and SLE is an illness, ha, ha...
The name Legacy would be really a bad idea, because of legacy, people thing about retro/nostalgia, and would be confused, when they get a Stunts engine
Stunts Rebooted
Stunts return...
Stunts begins...
The Dark Stunts...
Stunts The Mission...
Stunts 2...
The ztuntz version of Stunts
More Stunts. < I like that one...
21st century Stunts
Just Stunts
Stunts [2.0]
Multiple Stunts
Stunts Resurrection
"" We all know Stunts..
but now there is a sequel..
MORE Stunts.. get it now.. ""
21st century Stunts ;D ;D
You're so good at names
I think it shouldn't contain the word Stunts, since it's an engine, not a game based on Stunts. So, to give an example, at a moment I considered calling this engine e3, because it's based on the third attempt made from scratch. Then when running Stunts with it, we could call it Stunts/e3. This is akin to how Linux in GNU's kernel and people refer to the system as GNU/Linux.
O, I understand now what you mean.
We were thinking of names for the game.
Not for the engine.
CRE3g / CAS race engine 3th gen.
I think the game is good as is but this engine CAN je interesting for the replay...we will have more details and less frustration...
Quote from: Cas on March 02, 2021, 04:21:32 AM
I think it shouldn't contain the word Stunts, since it's an engine, not a game based on Stunts. So, to give an example, at a moment I considered calling this engine e3, because it's based on the third attempt made from scratch. Then when running Stunts with it, we could call it Stunts/e3. This is akin to how Linux in GNU's kernel and people refer to the system as GNU/Linux.
Not containing the word Stunts? What about Ztuntz?
It's about the engine, not the game itself.
CREaTurE
Cas Race Engine Third Evolution
As reference, see the ego engine..
https://en.m.wikipedia.org/wiki/Ego_(game_engine)#Game_using_the_engine (https://en.m.wikipedia.org/wiki/Ego_(game_engine)#Game_using_the_engine)
Alright. I've placed the engine in www.raceforkicks.com and gave it the temporary name R5E. The idea is that it's a project that I started later than R4K, so that's where the 5 comes from and the E is of course for Engine.
I'm currently kind of stuck trying to start with the physics part. I can more or less easily make it move more fluently, like a car, but collision is bringing me headache. That's what I'm trying to move into now.
What's the current progress, 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 :)
out of curiosity: would you replace the background images with a real terrain engine?
(https://cdn.tutsplus.com/cg/uploads/2014/01/Blender_LP_Illustration_s04.jpg)
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.
Quote from: Daniel3D on December 13, 2021, 12:41:30 PM
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.mattmontag.com/media/2020/08/racing-apex.jpeg)
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.maniac.de/wp-content/uploads/2019/07/sega-ages-virtua-racing-TEST.jpg)
https://www.youtube.com/watch?v=iBv55iNxd2I
https://www.youtube.com/watch?v=dxe87MDWU_4
SEGA Wing War:
(https://pbs.twimg.com/media/DYLd1WqVMAEGEzP?format=jpg&name=medium)
https://www.youtube.com/watch?v=ycxZmNZZVo0
https://www.youtube.com/watch?v=RDiSO_8NYis
Quote from: Daniel3D on December 13, 2021, 12:41:30 PM
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
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.
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 ;)
Quote from: alanrotoi on December 13, 2021, 09:34:01 PM
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 :/
Quote from: llm on December 14, 2021, 09:21:51 AM
Quote from: alanrotoi on December 13, 2021, 09:34:01 PM
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.
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? :D
It will take forever if you never continue..... ???
;D
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!
Quote from: Cas on December 15, 2021, 12:32:03 AM
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.
Quote from: Daniel3D on December 15, 2021, 07:25:57 AM
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
:)
Quote from: llm on December 15, 2021, 07:42:00 AM
Quote from: Daniel3D on December 15, 2021, 07:25:57 AM
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)
Quote from: Daniel3D on December 15, 2021, 08:12:17 AM
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)
I know, but a greefield projects makes it still not easy in detail
Your description of the case will still result in 2000-3000 lines of code with more or less complex math
I just hope I can help envision the basic structure.
Quote from: Daniel3D on December 15, 2021, 09:01:43 AM
I just hope I can help envision the basic structure.
no problem - but your text was on such a high abstract level thats its compareable to "how to bring a man on the moon"
build a rocket, put a man in it, fly to moon, finished :)
I never said it be much of a help.
Nor did I claim to have the answer.
I'm not Sherlock Holmes, more like Dr Watson.
Blurting stuff out until someone else see's the light...
Alright, so these are more or less the difficulties:
- When in the air, you want to calculate the next position. If that position is also in the air (no collision), it seems easy, but it's not that much. The car is a non-point-like solid object and thus, it has an angular momentum. I have to calculate where each of the vertices that make the block are going to be and maintain the distances between them. Also, at the speed a car can fly in the air like in Stunts, air drag is significant, so the angular momentum will not be fully preserved. This has to be calculated too.
- When landing, there are several problems. I could say that the car will land if the centre of mass will cross from one side to another of a surface during that cycle, but this surface, while in a plane, does not go to infinity, so even if the centre of mass crosses it, maybe the wheels don't, or some wheels do and some wheels don't. And if the centre of mass does not cross it, maybe one or more wheels does, in which case, the car should rotate so that the wheel that crosses is forced to stay on top of the ground. Again, rotation of a solid. I don't know if I should individually calculate for each wheel and then put everything together or calculate the wheels from the car in general. Both options are complex.
- It gets even worse when going from a plane to another. In reality, because the car has for wheels, there is no guarantee that there will exist a plane that shares the positions that the four of them should have at any given time when transitioning between two planes. So one or two wheels might be in the air and their "right" position is undefined. I have to choose. Looking at Stunts, it seems it makes an "average". Get to a slow diagonally and you'll see what I mean. Suspension could be a solution, but it will add extra complexity.
- For an impact, if it happens above a certain speed, it should be a crash, no matter the angle. If it isn't that fast, then we have to see about the dot product between the car's normal and the surface normal first to decide if it'll land straight or upside down, but it shouldn't crash immediately even if upside down. It would just be uncontrollable. In Stunts, this is how it works. It stays like that for a moment and then it crashes alone.
- There are some configuration when Stunts clearly doesn't do the things the way it should and emulating it would require adding some tweaking or being smart enough to realise why that happens. One such case is when you drive by the side of the bridge part of a cork u/d. You only have the wheels of one side on the surface, yet the car remains straight. It'd be even harder to do if I wanted to create angular momentum from this. The other case is when driving upside down inside a pipe just staying on the ceiling. Almost the same principle.
- There's a lot more to consider
This is an abstract on racing game physics:
https://www.team-bhp.com/forum/attachments/technical-stuff/814811d1317211860-brian-beckmans-physics-racing-beckman_-_the_physics_of_racing.pdf
Do you have taken a closer look at "Hard Drivin" and "Race Drivin"?
https://www.youtube.com/watch?v=ofUj8rIgG4U
https://www.youtube.com/watch?v=4W3y-ZuCJg4
These arcade machines were visually and by gameplay the direct predecessors of "Stunts" and I think they did some graphics and physics tricks different. I would love to find out more about their inner working, because they were based on serious driving simulators and may have plenty of hidden featured.
I wrote more about them here:
https://forum.stunts.hu/index.php?topic=4156.0
https://forum.stunts.hu/index.php?topic=4155.0
E.g. they seem to load the race tracks into RAM (booting displays "uncompressing graphics") and so may be easily hackable to load custom race tracks. Has anybody looked closer at the data format?
I notice on MAME that the arcade versions had surprisingly high sight distance despite using 16bit CPUs from 1988. Strange glitches suggest that they build up the 3D world gradually object by object in front of the car (apparently using some kind of offscreen rendering buffer) instead moving through it. So the rotation of fast steering often e.g. results in crooked road rendering (with gaps and kinks in varying places), which I never saw in other early polygon game engines. Because the machine has multiple specialized CPUs, I suspect that when the car physics CPU rotates the car, distant parts of the graphics are still drawn with an only shifted version of the previous rotational position from the rendering buffer, and only the road section close to the car gets redrawn to the current rotation angle (similar like the reprojection trick for head motion in VR glasses) to keep frame rate high enough.
This is the arcade hardware description by one of the developers:
http://jmargolin.com/schem/schems.htm
It occurs to me that, if the game uses fixed-point arithmetic and is trying to draw polygons that are far, the precision loss will be significant, so rotation can produce very strange results. Stunts does use fixed point arithmetic... or at least, it seems to do because vectors are stored as integers (sometimes 16 bit, sometimes 32 bit, depending on the case), but even with the "full detail" configuration, it won't draw very far.
In my engine, I am not having much problem with drawing. Some glitches are visible in my engine, but that's just because the models were designed for a different engine and also, I've been a little lazy, trying to first get to display as much as possible. So I'm really not very concerned about drawing. I already know I can do it. It's collision that's killing me.
That PDF about car driving physics is super interesting! Thanks! This is more about realistic forces and kinetics, but there's a lot of information there that will surely be useful. Collision, in the meantime, remains difficult. I wonder how Kevin Pickell faced it. It's not very easy to understand the code.
The arcade Hard-/Race Drivin behaves different than any home versions and lookalikes. I don't talk of "missing Z-buffer" artifacts. When driving through sharp curves, it does something like screen tearing, but it happens not in the frame buffer but the polygon rendering itself, i.e. stopping the car keeps the jagged deformed road on screen, and the shape depends on speed and angle of previous steering etc. (So it may even do something advanced like dynamically decoding splines of the road curve into linear segments written to a buffer, while home versions simply store roads as linear segments of fixed length anyway. Possibly the objects in Race Drivin are even transformed into 2D polygon pieces those get shifted and zoomed during small motions like in a sprite based game (Outrun etc.) to save CPU time for permitting the high viewing distance, and the buffer of these is updated much slower than the frame rate.)
I haven't gone through the driving game physics pdf. I only found reference to it in a discussion about driving simulation (possibly mentioning research by Doug Milliken, who unofficially participated in development of Hard Drivin). Modern car simulation games can be tremendously more complex than Stunts - see e.g. "BeamNG", which simulates crash physics as solid body deformation (finite elements or such) to make objects actually crush and crumble apart. (I refuse to have a Steam account and so haven't played this yet. I don't even know if my Ryzen 2400G APU would be fast enough to run it well.)
I am also not a fan of Steam or in general, something that requires me to be logged in to be able to play and tracks what I do.
What you describe still sounds to me like a fixed-point arithmetic problem. Say you have a 3D polygon that must be drawn somewhere in your 3D world, but since you're moving, for the current frame, it has to be rotated from the original design coordinates to your current camera orientation. This would be done by applying a matrix that contains trigonometric functions and these functions, to execute faster, would be pre-calculated and would return numbers between -1 and 1.
To do fixed point math, you add some precision by shifting these values, say, eight bits to the left, so you have eight sub-decimal bits. If your polygon is to be drawn near you, its coordinates will be represented say, half in the lower eight bits and half on top of the decimal point, giving 16 bit precision. But if the same polygon is to be drawn far away, it'll first be scaled down, which will shift the coordinate values towards the lower part. Say it goes down 8 bits, then now you've lost the lower 8 bits and your full precision is only 8 bits. When you multiply by the trigs now, this loss of precision may cause your polygon to twist because the coordinates are rectangular, not polar, so the engine has no way to know which part of the precision to keep.
Stunts uses 16 bit precision and sometimes 32, but polygons are never drawn very far away, so the loss of precision isn't significant, but if a fixed-point 3D engine draws very far, it will need bigger integers and a decimal point more offset to the left. Floating-point engines would not suffer from this problem. I'm not saying this is necessarily what happens with Hard Drivin'. I'm just saying it still makes sense to me that this could be the case.
With Hard-/Race Drivin objects look the more distorted the closer they are to the viewer, but not in the way seen in typical home games (straight lines those should be curved in real lens distortion physics, or omitted polygons too close to the viewpoint). The faster the car was rotating when they first appeared in the viewfield, the more crooked they look. Not distant but nearby objects (particularly road segments) become jagged when the car is quickly drifting sideways or steering fast. I suspect that the graphics gets stitched together from already rendered parts (similar like reprojection) to increase framerate. Not much is known about the rendering beside this explanation of some video MMU tricks (writing multiple bitplanes simultaneously in hardware to increase pixel fill rate).
http://www.jmargolin.com/schem/schems.htm#p01
Regarding fixed point rounding errors, I expect that the position glitches when colliding too slowly with objects may have to do with it. E.g. when very slowly driving against a building, it does not make your car explode or simply bounce off to where it came from, but instead magically tunnels it to the other side of the building. Most blatant is this when slowly touching the train on the "Original Track", which can beam your car many meters away. The behaviour depends on the rotation angle of the car relative to the collided object. It should be easy to define a rectangular bounding square/box and test whether the car overleaps with it and simply makes it explode when inside or put it back to where it came from. I guess that with very slow motion, the numerical difference between stored previous positions may be considered zero and so fails to track where the car came from and simply beams it anywhere outside the bounding box. Also "Stunts" behaves a bit odd when touching buildings very slow.
The similar PC game "Car and Driver" does even much worse glitches, those make the car randomly explode/crash or bump between polygons like a pinball among 3 bumpers when driving over road irregularities (also at normal speed), which makes some spots sort of unplayable by totally unpredictable behaviour.
https://www.youtube.com/watch?v=jDy9sOLjryE
It may be that for error tolerance to avoid such very annoying results, Hard-/Race Drivin simply beams the car outside the bounding box when it fails to detect what happened. But it still has some spots where you can fall through 2 facets of the road when driving very slowly at certain angles. E.g. entering the corkscrew occasionally makes you simply drive through it and so makes the car crash as penalty for leaving the intended path. Also on the left edge at the start of the Original Track of Hard Drivin is a glitch spot where you can fall through the world and spin like mad, adding many 10k points for airtime until it finally explodes. (You have to make a u-turn and touch the now right edge of the road when seeing the orange bridge.) Another strange spot in Race Drivin is before the start of the Original Track. When driving wrongways (in reverse gear?) watching the rearview mirror, you can see the drone cars suddenly switch their orientation from facing forward to facing backward (changing between front or tail end). Their position and speed generally is computed in direct relation to your own (particularly noticeable at the start of Original Track), so they often move jerky when approaching them and changing speed. Likely this was done for adaptive skill and preventing random collisions from behind. (E.g. those in Lynx version keep crashing into my car when driving slow.) The Phantom Photon (blue car at "Championship" when you have beaten the qualifying time) is the recorded motion of an actual player and so does not respond to your car. Also some opponent cars in "Cars and Driver" seem to do this.
In "Stunts" the opponent car is driven by a too stupid AI. Even the best of its drivers fails to finish certain tracks at all and generally tends to crash randomly (I do not need this kind of mischievousness), which is annoying because an always finishing opponent (possibly at slightly reduced speed to stay fair) would be more useful to learn how to drive each track by trying to follow him at a certain distance. I expect that the algorithm anyway internally knows the correct speeds for each jump distance to avoid crashing, so there should be an option to select a "perfect" driver.
At some point, I heard or read somewhere that Stunts' AI doesn't actually generate the same control inputs as the user's, but instead, it "cheats" and follows a path and speed curve. This makes sense if we think how difficult it is to predict what a car will do based on the keys you will press in the following frames, especially with several different cars. If this is so, however, it's surprising that AI opponents are so stupid.
But then I saw this project by this guy who managed to plug the keyboard input from one instance of Stunts into the opponent's input of another to produce an effective dual-player mode and this can only mean that the above isn't true unless there's another layer and this layer has been skipped... I don't know. I'd like to know. Anyway, if this second theory is true, it'd explain why AI's are so dumb, but it'd mean that the DSI guys spent quite some time analysing a way to produce working replays from key presses and what they got would be very impressive.
I wonder why the opponent keeps crashing into obstacles after a jump in certain tracks even with proper car with that I can drive without crash. For an AI opponent it technically should not be hard to be unbeatable (so far the combination of car and obstacles is solvable at all) by rapidly testing thousands of trajectories (possibly even before the game starts) to find out how to jump correctly, or compute them reverse (like raytracing) to save CPU time. Then make him on noncritical places a bit slower or add some random to become beatable again.
But lousy programmed AI opponents seem to be very common. E.g. in the shuffleboard arcade game "Shuffleshot" by Strata (kind of indoor curling on a table), the opponent shoots his pucks to always exactly the same spots with a certain percentage of shots not earning points, but they never land outside the playfield or in the minus 10 points area. And when I land a puck on 10, he *always* shoots it away the next turn. So it only switches between predefined perfect trajectories with a percentage of 0 points shots instead of adding some random to his motion to feel reasonable human, which makes that game no fun to play.
https://www.gamesdatabase.org/game/arcade/shuffleshot
The same company made the nice 3D racing game "Driver's Edge" (featuring long hill jumps in Formula 1 cars) which unrealistic physics is quite fun but feels too easy.
https://www.arcade-museum.com/game_detail.php?game_id=7656
In a driving game at least the higher ranked opponents should be difficult to beat, and if well made, they should also react on my car and not try to steer into it from behind (unless it is meant as a crash race game) and so die too.
These are some patents related to Hard Drivin (websearch them), including some details about AI opponents and level design. I am not sure if they ever had been valid, because the German Reiner Foerst made many related inventions long before Atari. Never the less, they reveal interesting things about the backgrounds of Hard-/Race Drivin.
WO1992002917A1 HardDrivin driver training
US5474453 HardDrivin level editor,opponents algorithm
US5354202 HardDrivin multiple driver training
US5269687 HardDrivin recursive driver training
The Hard Drivin patents are all related to various kinds of recording/replay variants for driver training.
Patent WO1992002917A1 is most general and describes the "Phantom Photon" feature (transparent uncollidable ghost car) of Hard Drivin. Patent US5269687 (recursive driver training) goes more into details of the "Autocross Track" in Race Drivin, which shows on the road a wireframe ghost car replaying the recorded fastest lap, so the player can drive multiple rounds to improve his driving skills by overtaking it, which the next round will replace the ghost car recording when he was faster. The text mentions that the game apparently was cross-compiled on a Digital Equipment Company VAX computer with Green Hills Software, Inc. "C" compiler available from Oasys, a division of Xel, Inc. of Waltham, Mass.
Patent US5354202 describes a 2 player mode in that the 2nd player drives against the recorded ghost car of the 1st player to permit competition driving on a single headed arcade machine.
Patent US5474453 is most interesting. It describes the simulated traffic and scenario editor of the AMOS Police Trainer, which was a serious driving simulator for police chase training, which had multiple cars with real dashboards connected to networked Race Drivin PCBs (one per monitor) and an additional central desktop computer for control.
https://www.youtube.com/watch?v=__bvDrQQqT4
The text explains many technical details of the apparatus, those certainly also affect the inner working of how Hard Drivin implements its "drone cars" on the track. These follow prerecorded trajectories those can be replayed at different speeds and have start and end points to meet the driver's car at certain spots and synchronize in various ways (e.g. to simulate a car crash situation). The scenario editor was controlled by rocker switches on the physical car dashboard and an onscreen menu for the instructor to record the paths for each drone car by driving (teach-in method) and edit what they shall do. Particularly there could be a "rabbit vehicle" intended to be pursued by the police cars for training. The text explains data structures for the trajectories of drone cars. Unfortunately it tells nothing about a map editor or 3D object editor for making own levels. Interesting is that the archived paper original in the Patent and Trademark Office included a microfice sheet of the copyrighted source code. Because this bulky apparatus likely since long time has been destroyed and scrapped, it may be the only documentation of its original software. Obviously due to relation to AMOS, the arcade game "Street Drivin" (a Race Drivin prototype) did include also a police car.
The focus on replaying stored trajectories explains why opponent "drone cars" in Hard-/Race Drivin do odd glitches and don't care about car physics. While they appear in spots and velocity relative to the player car, after unexpected driving maneuvers (too far offroad etc.) sometime it draws 2 cars overleaping each other or hanging over banked road edges. Likely each of them starts by crossing an invisible checkpoint, which produces nonsense when checkpoints are crossed in wrong order or too different speed. Drone cars also don't respond to bumping into them (this algorithm can not simulate bumpercars). Possibly it was implemented this way because the car physics CPU could only handle a single car and so the rest had to be preprogrammed. So this is barely proper AI, although they at least attempts not to crash into the player from behind. Never the less, I prefer even a somewhat flawed opponent car algorithm over having no option for traffic populated areas at all.
Following the Line of stunts (DSI and EA Canada) and the feasible idea that Stunts was heavily inspired on Hard Driving.
The following games the studio made included NFS one and two. The second included traffic. I don't know if it was the first full 3D race game with traffic, but certainly up there.
I made a technical analysis of the "Hard Drivin" series, particularly explaining the editor of "Hard Drivin II" and the game engine physics and behaviour differences of home and arcade versions. It also includes a hires map of the Original Track and a little batch script to handle custom tracks with meaningful names.
Analysis of Hard Drivin and its variants
https://forum.stunts.hu/index.php?topic=4155.msg91042#msg91042