Camera placement

[Daniel3D]

I believe that the cameras are placed every 3 track pieces. Sometimes not in the middle but at the edge of the piece. The loop is two tiles but counts as one piece. Same for corners.

[Duplode]

Fantastic!  I really want to be able to use that tool!

This map was done with Cartography in pretty much the same way the race reconstitution videos are done, except that I replaced the auxiliary program which extracts car coordinates from the repldump output with one that does it for a trackdata dump (the dump itself was obtained using the DOSBox debugger). If all goes to plan, a new version of Cartography will be released within the next week or two with support for setting up this kind of visualisation.

So each track element has a "position-for-camera" that serves as a potential waypoint. My guess is that this is established in the GAME resource files, together with the walls and that.

There indeed is an element-specific camera position offset, though I didn't look into it too closely back in 2016. IIRC it is defined into the executable, alongside other element information such as the connectivity flags.

I believe that the cameras are placed every 3 track pieces. Sometimes not in the middle but at the edge of the piece. The loop is two tiles but counts as one piece. Same for corners.

It does seem this three-element pattern is the primary rule used by the game. In Default, there is only one sector where it is not followed: the beginning of the long way (there is an extra camera just after the split, then the next one is four elements ahead).

[Cas]

What I'm feeling is, as I was saying, that perhaps it's not how many tiles ahead, but how much distance from the previous camera position. This distance is fixed and Stunts is looking for the tile camera position that's nearest that distance from the previous camera and on the same path. This would explain why most of the times it is every three tiles, but not always. If this is so, when it takes four tiles, it's because the place where the camera would go at that tile is nearer that fixed distance from the previous camera than the place in the previous tile.

So are you manually reading the memory dump?  I thought you were using something like rpldump to automatically obtain a file that Cartography would read. By the way, where do I get rpldump?

[Duplode]

On the cameras being positioned according to Euclidean distance: I'd find that surprising, as it seems most of the other track setup and checking is based on tile and element counting. But then again, some of those exceptions are really strange, specially that one with the dangling 1x1 split.

On reading memory dumps: the usual procedure, which I use for the videos, is (1) generate the binary dump from the RPL with repldump; (2) extract the relevant data from the dump to a text file with an auxiliary tool; and (3) have Cartography read the text file. The main difference is that this time for step 1 I manually created the dump with the DOSBox debugger because repldump doesn't dump trackdata. Steps 2 and 3 were largely the same.

(I could obviate step 2 by making Cartography read the binary dump directly, and I'll likely implement that at some point. Still, it can be convenient to be able to look at the data in a human-readable text format.)

On repldump: you can get the executable from Southern Cross and the sources from restunts' SVN repository at svn://anders-e.com/restunts/trunk/restunts . (Next time I boot into Windows I'll try building it from source. It would be useful to be able to tweak a few things in it.)

[Cas]

Thanks!  I'll take a look at it   By the way, does the default installation of DOSBox allow for memory dumping or did you have to install any mod to it?  I don't know how to generate this dump

[Duplode]

The default DOSBox installation doesn't include the debugger. To enable it, you have to give configure the --enable-debug option when building it from source. Two relevant threads from the official DOSBox forums: an usage guide, and a Windows binary.

[Daniel3D]

Fantastic!  I really want to be able to use that tool!

This map was done with Cartography in pretty much the same way the race reconstitution videos are done, except that I replaced the auxiliary program which extracts car coordinates from the repldump output with one that does it for a trackdata dump (the dump itself was obtained using the DOSBox debugger). If all goes to plan, a new version of Cartography will be released within the next week or two with support for setting up this kind of visualisation.

Did you release it and did I miss that? Or didn't it go as planned. I kind of want to continue this research and generating camera placement would help a lot.

[Duplode]

Did you release it and did I miss that? Or didn't it go as planned. I kind of want to continue this research and generating camera placement would help a lot.

I didn't properly release it yet, though the basics of integrating the trackdata functionality to Cartography have been done since November. The main thing I need to do now is compiling and wrapping up a Windows executable (which might be slightly tricky to do due to the GTK dependencies of Cartography). I'll attempt that either tomorrow or, failing that, next weekend.

[Duplode]

I didn't properly release it yet, though the basics of integrating the trackdata functionality to Cartography have been done since November. The main thing I need to do now is compiling and wrapping up a Windows executable (which might be slightly tricky to do due to the GTK dependencies of Cartography). I'll attempt that either tomorrow or, failing that, next weekend.

Update: I have managed to compile the current Cartography on Windows. There still are a few wrinkles to sort out -- most remarkably, using the current version of GTK requires me to put thirty DLLs in the zip if I'm to make a "naive" portable distribution (that is, just zip everything together), so I'll try to find tidier approach. In any case, I will wrap up and release a new version in the weekend.

[Duplode]

Update: I have managed to compile the current Cartography on Windows. There still are a few wrinkles to sort out -- most remarkably, using the current version of GTK requires me to put thirty DLLs in the zip if I'm to make a "naive" portable distribution (that is, just zip everything together), so I'll try to find tidier approach. In any case, I will wrap up and release a new version in the weekend.

One weekend later, it is finally done! Here is the Windows binary download link; see also the Cartography topic for extra information. Basic usage info on the t2c command, which generates Cartography annotation input from a trackdata memory dump, can be found in the readme, and of course please do ask if you want a more detailed explanation.

[Cas]

Does Cartography not have a Wiki article?

[Duplode]

Indeed it doesn't. A Wiki article would be a nice place to talk about how Cartography came into being, and what its different parts have to do with each other.

[Cas]

Yes, I think it'd be great to have one. Also, with time, when we develop a program, we tend to forget details about how it all happened, so it's very good to leave everything written. At least in my case, that happens a lot. My memory is very selective. Some things I remember very well, no matter how long. Others, I can forget to the point that I have no idea. Sometimes I forget what I have said myself, ha, ha