Transport Tycoon Forums

Hello everybody!


After a bit of time since OpenTTD patching, here I am again

This time I bring you a little tool that can help you create a timelapse film of your OpenTTD game, such as this one by TheCoopCompany. From him I got the idea for this patch and I've already posted a previous version of this in his Thread in the problems forum.
I have also created two little timelapse videos with my patch. View them here: one two

What does it do?
* If you activated the option in the advanced settings, it will take a giant screenshot of the map every x days, where x is a number you can choose in the advanced settings menu. You can also choose which zoom level the giant shots will be taken in (higher level means less quality but also less time to take a screenshot and less disk space used).
* The screenshots taken in this way will be named "timelapse#000000.[ext]" (where [ext] is the file extension of the screenshot format you are using) onwards. The many leading zeros are so that a program or script which reads in the files sequentially by filename will get them in the correct order.
* You can also set up so-called "local views" by activating the option in the advanced settings menu, and then placing one or multiple signs on your map, naming them something that starts with # (important!). Every x days, a screenshot will be taken centered on those locations and named "timelapse#[signname]#000000.[ext]". The local views have interval and zoomlevel settings seperate from the giant screen.
* The local screenshots are usually taken with a resolution of 800x600, but you can set up anything from 100x100 to 8000x6000 by modifying the openttd.cfg


You can then use an appropriate program to create a video out of the screenshots (TheCoopCompany used Blender for his example video).
If you are wondering how to do this, here is a tutorial by TheCoopCompany.

The newest version of this patch (for r15870) is found here.
Please also check below that post if there's an even newer version, in case I've forgotten to update this link.

The main problem is that is work only good(bad) on 64x64 maps both ingame and outside. Larger maps creates more time to generate a great screenshot resulting in lags in openttd and outside openttd it generates big images, 4000x2000 just for a 64x64 map with 600kbytes (for png). Thats very big to handle with programs like convert/ffmpeg/mencoder. Maybe it doesn't belong to this patch but the screenshots should be smaller, or the giant screenshot should be taken from the most zoomed out level as noone cares in a timelapse sequence which signal you build on a single trackbit...
What about support not just giant screenshot but also "normal" screenshot like you can save the user interactions?

Well, you can add setting that will tell at which zoom level you want the giant screenshot (the basic as it is now ore one of the three zoom-out levels, so it can produce "reasonable" results even with bigger maps) - once you get to really large maps (like 2048x2048) giant screenshots become basically impossible (you'll get about 128000 x 64000 image = 24.5 GB of raw data. Luckily, PNG format supports images up to (2^31-1) * (2^31-1) pixels large, so that is not a problem, theoretically).

With maximal zoom-out the image is 8 times smaller, so you can have 8 times larger map (for example 512x512 instead of 64x64) and process it with same easy/difficulty as small map with basic zoom

That is a very good suggestion, and it will be a piece of cake to implement it. (the zoom level one)

As for the recording of normal screenshots: I implemented this in an intermediate version between the current and the last version, which I didn't release. I removed it again since it would have to take screenshots in such short intervals that it would almost definately disturb while playing. And it's easy enough to use some external program like fraps to record your interactions, and this will run on another process and thus not make OpenTTD run bumpy.

I will implement user definable zoom levels for the next version of the patch..
Oh, one downside just comes to my mind: the zoomed out levels of OpenTTD are relatively ugly - I guess most image manipulation programs have better routines of interpolation or something than OpenTTD has.. there once was a user patch here that tried to make the higher zoom levels more beautiful with some more sophisticated routines, but afaik it was never adapted to trunk.


----
Old version of this patch (for r14481). Changes compared to previous version are: minor fixes, introduce timelapse file names, turn off transparency for the giant screens.

Still, timelapses will likely be far smaller evene than the most zoomed-out level, so there is still plenty of space for a "sophisticated algorithm"

True (why the quotation marks plus rolling eyes? ), and here is the new version:

Changelog:
* New feature: specify zoom level to be used for the screenshots in advanced settings. Standard is "Normal", like used in previous versions of this patch, but if you want to create a timelapse video of bigger maps, a higher zoom level is recommended. (2x, 4x or 8x).

It took me pretty long time until I found software able to downsize giant screenshots of large maps (1024*1024 or so) for posting on forums without losing too much information. Most of them turned the shot into very chaotic mix of green and brown pixels.

And what software you found that is able to handle such large screenshots? I once tried to find same software (I had very large pictures with satellite imagery that won't fit in RAM) and I found nothing .... later I solved the problem by upgrading RAM :)

Out of curiosity, I tried to get giant screenshot of game running with my large map patch on 8192x8192 game. I ended up with 14.5 GB PNG image (524224 x 262112 pixels). Way too large for most software :)

Open it in acdsee and take a screenshot of it (it is unable to resize such huge picture, lol)

PS: I used AcdSee 10

I am proud to present a new version of this patch with a brand new feature

You may have seen TheCoopCompany's second timelapse video featuring some nice "local views" - I really liked them and he also added a little section to his tutorial how to make them.
However, it is only possible to make them if you use the normal zoom level for your giant screenshots. So this method is not really viable for larger maps.

For this reason I've implemented the possibility of "local screens" in this new version. To use it, activate the extra option in the advanced options window and choose an interval and zoom level of your liking. (Additionally, you can even set up the width and height of the local screens in the openttd.cfg)
Then, place one or any number of signs on your map and name them something starting with #. The game will then take screenshots in the specified interval, zoom level and proportions centered on this (or these) signs. You can add, remove and relocate those signs freely during your game.
Hint: deselect "signs displayed" in the option dropdown menu so they won't show up in the screenshots.

Of course, you again shouldn't choose too big sizes, too short intervals and/or too many signs for local shots at once, or your game will start to hang.
An example video can be found here: http://de.youtube.com/watch?v=q6_DbWRhmeE

And here's the patch (only the .diff for now, windows binary sometime else...)

These "#" signs are really cool. But I have added by mistake to #-signs with the same name and then the patch creating both screenshots with the same prefix, resulting in an image order with swapping locations. Its a little bit weird as the order is swapping all the time. Not sure if you should add the sign-id in the filename if there is such an conflict.

Hmm.. I rather wouldn't do this.. in my game I made the last video from, I renamed (taking turns) different signs to "#test", so those would already be in the right order (and at one point I used three local views at the same time, but this doesn't matter here).

I understand that it can lead to chaos if one has two signs with the same name, but still I don't like the idea of the signid in the filename.. sorry :/

But I think if some mishap like this happened it's still not too hard to "repair" it - if you resize the window of this directory so that exactly two files go in a row, you can make a big rectangle around all the "even number"-files (or the uneven ones) and copy them to some other location.

That's amazing! I like it a lot!

What about a patch setting for the prefix a sign must have? For #openttdcoop we use "{SPACE}foobar" for special signs like for junctions. If you set the prefix to a single space instead of "#" they get automatically catched instead of having one sign for the normal name and under that a timelapse sign for capturing the location.

Another suggestion is to have captching local views not only for signs but also for stations which use the prefix like having a station " COAL DROP".

I have test it on the #openttdcoop public server. It works very well but the inactivity may be a problem (several screenshots are the same). Is is possible to not just use a delay in days but also a delay in DoCommand*()s? Sth. like every "min(1month, 500DoCommand)" a screenshot, whichever comes first?

Hi Progman, sorry for not answering your post before; I'll answer both now..


Hm, I've never seen a patch setting that handles a string.. or a char if we restrict this on one letter. Well, for a char, I could just insert a patch setting that accepts a uint and interpret it as ASCII number. Yes, I can do this as a non-GUI patch option.. you have to look up the number for your preferred character yourself though. Standard would be 35 ("#") and you can easily change it to 32 (" ").
In the meantime, you could hardcode this yourself by changing line 88 in the latest patch file (r14511), or respectively that line in date.cpp after patching the source from

+            if (si->name != NULL && *si->name == '#') {

to

+            if (si->name != NULL && *si->name == ' ') {

I'm wondering though if it isn't a bit over the top - every such sign would get a local view, that can easily get too much...


This shouldn't be too hard to archieve. Again that would make performance worse - having to iterate through the list of all stations... but I can include it with an on/off option.


Now this is something I can't tell you if I can do it - have to investigate the code a bit and see...

By the way, what codec did you use to encode your videos? Unfortunately I can't watch them

I used the mpeg2video codec for mencoder.

I managed to watch them now on ubuntu without any hassle.. while windows media player just gave me an error
That's 1:0 for linux.

---
I implemented the first two things now - configurable prefix (non-gui only, use ASCII number of the preferred char) and local views for stations (changed the "enable local views" option from boolean to multiselect: Off, at signs, at stations, at signs and stations).

I've also looked into the Command counter thing and I should be able to do it. But is it really what you want? If you take min(500 commands, a month), you'll end up with at least one screen per month, but when activity is high, it will be fluctuating...
Maybe rather something like "Take a screen every month (or x days..), but skip it if since the last screen less than y commands were done"?

I think I'll introduce YAPO (yet another patch option)... "Parameter used for local screens: Time (every x days make a screen) / Activity (every y commands make a screen) / Both (every x days, but only if y commands were done since the last one, make a screen)"

The "1 month" delay was just an example, think more about an "1 year" delay. So you dont get too much pictures of the same but be able to get more screenshots if there is more going on. If you check the timelapses I have done you see a lot of stuff nothing changing (unless you watch the global.avi which is the global screenshot timelapse). And this is what I want to reduce somehow. Btw.: this only affects network games as you make the correct number of screenshots per year if you play a single player game.
Anyway, the changeable prefix should be fine enought if you dont have enought time

What about taking a screenshot every X commands? Not terribly accurate, but atleast it wont be taking screenshots when there's nothing going on.