Live watch project

[Cas]

Hi, folks!  I've been wanting to do something for a very long time and I thought it was too hard and I didn't have much time, but recently, I decided to try and found I could very well do it. I've already told a few about this, but anyway... here it goes.

In the shared zip file, you will find:
- A DOS TSR program called stpeek.com
- A FreeBasic program called watchpeek.bas and its Debian-based GNU/Linux 64 bit binary as well as its Windows executable
- One of the Stunts builds we're currently using, stuntsp.exe

I'm sharing my binary of Stunts because what I've done currently only works with this binary. I can investigate a little and make it compatible with others, but generally, I can't make it compatible with "any" Stunts binary. It'd be a matter of selecting a few official ones later. So with this one, it works.

To try this, you copy stpeek.com into some directory that will be accessible to you while you're running DOSBox. For example, it could go into the directory of Stunts. I like having Stunts under c:\games\stunts when I start DOSBox and I put this TSR at C:\, but it'll work in any case. Then, you run watchpeek and it will show some numbers. For now, press a key and it will ask you for the path to a track file. Provide the path and it'll display a very crude and bad looking map of that track. Run DOSBox, then stpeek.com. It'll create a file at C:\ (relative to DOSBox) called LIVEDUMP.DAT, so make sure something is mounted at C:\. Then run stunts with stuntsp.exe. Ensure you can see both the DOSBox and the watchpeek windows at the same time and get in to drive a track. You should be able to see your dot following the track. If something fails, please tell me. I would like to see this tested in different environments.

Of course, the whole purpose of this isn't just to have a track map. I can plug this output into anything, for example, my 3D engine. Also, I can create a small server program to gather data from all pipsqueaks that connect to it and you'd be able to see all together on the same track map or in the same 3D realm. See what I mean?  I'll be testing these things soon, but I need to do some calibration to enhance how this works.

Currently, the "connection" is made via disk. The TSR writes to the file within DOSBox and the watcher picks it up by reading the file over and over again. This is not very nice. You can make it better by mounting a RAM drive to run Stunts, but I found that even with a slow hard disk, it's sufficiently fast. I am considering other ways of sending the data outside DOSBox.

Let me know your thoughts!

[dreadnaut]

Nice! But also: this software is preemptively banned from use in the ZakStunts competition! 😅

[Cas]

He, he... yes. This is more a curiousity than anything at this point. The actual good use for this will be in live races, I think

[Erik Barros]

What a cool project! I had two projects in mind that might be easier to achieve now: playing stunts in a 3DOF cockpit, with synchronized movements and an external dashboard.

Nice! But also: this software is preemptively banned from use in the ZakStunts competition!

That sentence made me laugh out loud.

[Cas]

Well, I've tested this with my 3D engine and it works. The speed is not great, but I know there's a lot to optimise there. Some things that can be done with this:

- Show a map of all pipsqueaks in a live race. Note that this does not require changing live racing rules. You'll see when somebody does crash recovery and it'll be like going through pits: other pipsqueaks take over, but then they'll need to stop too. Perfectly normal
- Render the 3D race from any position live. You'll be able to move around and see how a live race is going
- Race with Stunts running, but looking at my renderer screen instead. This implies you can see other pipsqueaks. Some things need to be improve for this to be practical. It's doing some 10 FPS now and wheels still don't look good, but apart from that, it does work, so I intend to measure how much speed is being lost at each layer and then work to optimise
- Practise and create replays while seeing your ghost car from your previous replay. Thanks @alanrotoi for pointing this one out. This again requires some work as described previously
- Have the server automatically monitor where cars are and broadcast which lap each one is on as well as other data
- Allow a race manager to live monitor a replay as it's being produced to confirm authorship later. This one I'm not super enthusiastic about, but it's something that will become possible, so I just wanted to point out that I'm aware of it. In this sense, replay handling could also be controlled. There are some caveats, though: it's impossible to tell if the data you're getting is coming for a replay being played, so you need to have a new track, same thing we do on live races nowadays

[KyLiE]

This is great news! However, I tried running it under Windows and while I could get it to display the track, it wouldn't show my position. The LIVEDUMP.DAT file was generated, but it's as though it wasn't reading it. I tried different directory structures, but I still couldn't get it to work.

[Erik Barros]

I tried testing it today, but I couldn't run the stpeek.com program; it says that Windows can't run the program. If you could give me some directions, I'll test it on Linux too

[Cas]

Hey, Erik. stpeek.com is a DOS TSR program. You need to run it in the DOSBox environment before calling Stunts. For it to work, you'll need to use the binary I provided because each binary has a different offset for the memory, so I'll need to generate a new TSR for each otherwise. I found this one to be relatively light, since the idea is using external graphics

[alanrotoi]

How is it going this project?

[Cas]

Well, @HerrNove shared a good amount of information I could use to sync it to Supersight. I haven't done much more on this now, but I would like to adapt the TSR to detect any Stunts binary if possible. If I find the time, I want to create a small server program to monitor a live race. Could be used to look at the map or to see it live in the 3D thing, but the latter is not fast enough currently to play that way, or maybe it is... We'll see

[Alain il professore]

In the 3D rendering, wheels (primitive 12) rotate just like when you swap the 6 vertices order in the car parameters. If it indeed comes from the vertices order, it has been once wrongly descripted on the stunts wiki. A front back / left right inversion breaks it.

The first three vertices in a wheel primitive mark the center and the boundary points along the y and z axes of the circle facing the inside of the car. The last three vertices do the same, in the same order, for the circle facing the outside.

Wheel transformations are performed on fixed vertex positions. Since the first eight vertices of car[0-2] shapes are occupied by the bound box, vertices 9-14 and 15-20 are front wheels. Misplaced wheel vertices will lead to corrupted shape rendering.

[Cas]

Well, my renderer shows wheels incorrectly for a different reason. It is true that the vertices in the wheel primitive where originally incorrectly guessed. My renderer does not calculate the rim widths this way. It's a fixed proportion.

The actual problem with rendering is that drawing ellipses is difficult and also slow. Of the different possible solutions, I chose to simplify wheels because my engine is already a lot of messy code. I would have to rewrite some things and also, it'd be slow. I have to find a more optimal way.

To be more specific, the current renderer uses a FreeBasic primitive ("Line") to draw almost everything, mainly triangles. Wheels can be drawn out of triangles by subdividing the drum into base polygons, but this would be very evident in high res. Stunts does it, but in 320x200, they don't need to be too many polygons and there's some simplification as well, yet not very noticed. If I use a very large number of primitives to prevent this, it gets really slow to draw them all.

There's also the "general ellipse" problem. An ellipse is a circle that you can stretch or collapse in one direction. If this direction is aligned with the X or Y axis of the screen, you can escape eliptic functions (which are numeric and very slow to calculate) by just using a factor on one of the axes. I could've used (and I tried to) this technique on the renderer. It would've given artifcats when there's a roll, but would've looked good otherwise. But I had issues that I couldn't solve without rewriting a reat part of the engine.

A general ellipse is one that's not calculated as a stretched circle, but as two foci and a distance sum, which is what an ellipse truly is. It can also be obtained by stretching a circle and then rotating, but that required again converting the ellipse to polygons. Not a trivial thing. Stressed does not draw its own ellipses (I am almost sure). It instead uses a some library for this purpose.