Hey, thanks!

For now I've uploaded the first 5 missions, and slowly will continue with the rest. I've calculated 1 week / run, and I won't be able to do it every day, so it should be around 2-3 weeks / video, and thus the whole game should be completed by the end of 2018. Speedrunning is not something you can do in a 20 hour marathon, I prefer to do it in 1-2 hour bursts a day to give time to think about it and penetrate my brain.

Mr. Assman

Hello!

I'd like my original Mission 1: Baptism of Fire speedrun removed. Link: https://www.speedrun.com/run/y675qv6m I was the using GoG.com version, and apparently it ran at 14fps at the time. It would be really confusing to leave it there like this. I have reuploaded a new video with the Steam version at 20fps.

I've found that the game was intended to run at 20fps by its creators afterall. At least it's supported by the fact that all training mission videos were recorded at this gamespeed. Such as this one: Just watch or measure how fast the cursor blinks.

1. There is a rule on this site that the first runner decides on game rules. gltz has already used 1280x720 in his video here (https://www.speedrun.com/run/oy2nod9y). This however is purely technical and I would consider using 1024x768 just to be on the safe side.

2. Or everyone will use 43-44fps if no limiter is used. I prefer using the same fps without mods if I can, hence I prefer Steam/GoG. (I'm sorry for people who have to rebuy the game from Steam or GoG.com, but hopefully they will give it cheaper in the future. $5 atm, but I've seen it for $2 before.)

2¤) New separate category suggestion: Pacifist/Don't kill category. In this category no enemy soldiers can be harmed! In case some soldiers have to be killed due to mission objectives or map layout, the player has to kill the MINIMUM number of soldiers she can. The number of kills are displayed at the end of each level, hence easily trackable (only human life matter, vehicle/building destruction does not). It's bit of a joke-category which fits this game surprisingly well. It would be the opposite of an all-kill category.

Your welcome!

The Pentium1 setup is the retail version. 800x600 is about 14fps, 640x480 ~ 20fps, 512x384 ~ 25fps. You can verify this if you frame-by-frame step the youtube video, using hotkeys , (comma) and . (dot).

I don't think the retail version is suitable for speedrun since its speed is very inconsistent, even on the same machine.

The other versions are at least consistent on the same machine. I wouldn't be surprised if there were some people with higher/lower speed then mine, but at least there is my video as a reference.

If the Legacy/GoG version has the wrong speed, try installing the Steam App and running it in the background. It might help.

Hello!

@Molotok I have recorded some gameplay with my Pentium1 machine for you, however this machine is way too slow to be taken seriously:

I have made some more precise framrate testings too:

Steam is the best again, though versions other than retail are also within 1% error radius. This video is also a reference point for others to compare their own gamespeed to mine.

Running SteamApp in the background alters other version's framerate too, now my GoG runs almost the same speed as the Steam version. I haven't installed SteamApp on WinXP, thus it has less consistent results (not a recording issue, on XP I have recorded via external device).

Working recording softwares: BandiCam (for all windows), Microsoft DVR (Win10)

Windowed mode sucks (except the steam version) both for gameplay and recording, do not ever use those.

OBS is a bad recording software, because it always wants to record in desktop resolution, even if I start the recording inside the game. This somehow conflicts with the game and causes lags. Good recording software can start the recording from inside the game and records only the game itself (for example, BandiCam, Microsoft DVR).

Mr. Assman

I don't know the Win8.1 fullscreen fps, because I haven't figured out how to record at fullscreen mode yet. If OBS worked in Windows 7, then it just might work in 8.1, I will give it a try when I can. (Or is there an fps-meter like fraps that I can run in fullscreen mode too?)

I might dust off my old Pentium1 if it still works, but I can probably only install the retail version. The GoG and Steam:Legacy versions might work from a CD (if my old cd-rom drive works that is).

Alt+Enter only works (in Win8 and 10) if you set a) Win98/ME compatibility mode, AND [ b1) set 65536 color compatibility mode OR b2) set your desktop to 16bit colour depth]. Alt+Enter does not work with the Steam: default release at all, only with GoG/Steam: Legacy/Retail.

#3 Record a sample. Open in video editor. Watch it frame by frame. Count how many times the screen changes during a 1 second period. Measure at multiple places to make sure. (My full screen measurements were based on this, except I've automated the counting process using ffmpeg. Currently I can only count with ffmpeg, if the mouse stands still.) It would be really nice if there was an fps-meter in fullscreen mode, we could even recommend to record it with the game to prove its legitimity. In practise of course, you will have an eye for this, and know patrol positions for various timings. Therefore all you need is one reference video, for which you have proven its legitness.

About question #5, I meant this. Is this legal for a speedrun? (the stopwatch is hovering over the topbar):

@Molotok Thank you! It all makes sense now. I think I've managed to unravel the great mistery.

You need no extra software to run the games in windowed mode. Just create a shortcut of the exe file and use Windows 98/Windows ME compatibility mode and 16bit/65536 color compatibility mode. Then you can switch to windowed mode using alt+enter, which causes crash the first time you use it.

I have got my hands on the steam version. I think I can make order in this chaos.

(I used decimal comma instead of decimal point)

This image shows my tests on 3 different machines. I could dig deeper and try this on older XP/Win98 machines, but I don't think it has practical use.

Conclusion: Ewil had a good intuition, the steam version is the most stable of them all, rock solid 20 fps. The GoG version runs 20 fps in windowed mode and 16 fps in full screen mode.

Details: I have measured FULL SCREEN MODE using a 10 second recorded footage and this ffmpeg command: ffmpeg -i input.mp4 -an -vf mpdecimate -loglevel debug -f null - (this one outputs which frames are duplicates of the previous ones, for this I have recorded 15 second footages of the game while the mouse didn't move) I am not able to use Fraps in full screen mode. I don't know other recorders than Microsoft DVR, that works in full screen.

You may download these test recordings from here: https://drive.google.com/embeddedfolderview?id=0B8_Z_EbKUdPlU2dLQXlfeXRQb0E#list

I have measured WINDOWED MODE using Fraps. Fraps is better than DxTory in this case, because Fraps doesn't count mouse movement into the fps measurement. However I think windowed mode is less stable then full screen mode.

Windows 10 windowed modes are UNPLAYABLE. If you make any move with the mouse, fps will drop to 0 instantly. Windows 8.1 windowed mode works perfectly fine, but the game instantly crashes when I hit the record button (tried with DxTory). I don't know any program that works. Windows 7 windowed mode recording works for Molotok, but it has fluctuating fps.

Steam has 2 gameversions, a default and a legacy. The default only runs if you log in to Steam. I've used the legacy versions on other machines, because I could run the games from a pendrive.

The legacy version has different fps if you run the Steam App in the background.

I've made some tests on BCD as well, showing that it's similar to BEL. Except it has a built-in gamespeed setting. I assume that needs to be set to the fastest level for speedruns.

Bottomline: I suggest using the steam version Win10 full screen mode with the build-in Microsoft DVR recorder.

QUESTION #1: Can FULL SCREEN mode be recorded in any other operating system, than windows10 (without a capture device)? QUESTION #2: Is the steam version any good in other operating systems than windows10? QUESTION #3: Can we agree on 20 fps as a standard? QUESTION #4: The steam version introduced 1280x720 widescreen resolution. Is this legal for the speedruns? (the original game had the max resolution of 1024x768) QUESTION #5: Is it legal to put a timer over the top bar of the game, where there is no movement anyway? Or the rules are strict, and timers have to be outside the recorded footage?

What program do you use to measure fps in Commandos BEL, Molotok? It would help if I could use some program to measure it.

I tried to use fraps, but it didn't work with commandos for me.

Right now I'm working on a method to measure fps of recorded footage, but it's not as accurate as comparing patrolling soldiers.

Commandos 2-3 has a steady 25fps. Commandos BEL, BCD GoG version: steady 16.13 fps Commandos BEL retail version: fluctuating 20-26 fps (23,08 avg), which is clearly unacceptable Commandos BEL Steam version: ???

Next up I will try running commandos on diffent machines to see if it makes a difference.

If it was up to me I would say 20 fps looks nice for this game, 25 looks a little fast, 16 looks a bit slow. What fps was intended for this game originally? It seems to me it was made dynamic, so it can adopt to faster/slower machines, so there isn't one proper answer to this question.

ffmpeg - remove sequentially duplicate frames source: https://stackoverflow.com/questions/37088517/ffmpeg-remove-sequentially-duplicate-frames

Using this tutorial I have removed duplicate frames from each of the 3 clips (Molotok's, Soda's and mine). This isn't 100% accurate either, but it's a hell of a lot better then counting on hand.

I have created a comparison video on youtube: I suggest to watch it frame-by-frame to see the details.

Unfortunatelly this did not syncronise any of the videos, not sure why.

Edit: Mouse movement seems to have higher fps, which distorts the results unfortunatelly. 2 identical screens will not be removed, if the mouse is at different locations.

Edit: Gltz's official run seems to run at 19-20 fps. ()

I have investigated further. I watched both videos side by side, frame-by-frame.

HINT: It's easy to detect lag or frameskips watching the movement of the green enemy line-of-sight triangles frame-by-frame (or anything that moves, even scrolling the screen).

Oddly enough, Commandos BEL seems to operate at 16 frames per second for me. In my video every other frame was the same as the previous frame (except for one frame each sec).

In your video the game frame rate varied between 18 and 20 frames per second due to the lag.

This opens up another debate. Which framerate is correct? We both did record our games at 30fps, but the games themselves ran at 16fps and 18-20fps respectively. Can the same game run at different fpses on different computers?

What fps does the Steam version have?

In Soda88's video each frame is unique. It seems his game operates at 30fps. So it could be that the joke's on us, this is the correct playrate and DeadShot was right all along.

I counted unique frames manually in a 2-3 second sample in each video. Is there an automatic way of detecting identical frames in a row?

I think neither the GoG, nor the Steam versions are official (none of them are called that). Has anyone compared the 2 versions btw?

I suggested GoG, because less people had flamed it in forum posts.

Hello!

I'd like to speedrun this game as well, but it's difficult since Commandos BEL lacks an in-game timer, and it seems to run at differnent speeds with different settings.

Time measurement proposal:

1. All use GOG version of the game, otherwise timing tests has to be made to confirm legitness
2. Patrolling groups' / patrollings' vehicle locations are completely parallel in each run (however facing directions seems to vary a little bit). Undisturbed patrol groups are our only hope to measure elapsed time in this game.

Example: The topleft patrol groups' move the same distance during these times (the leader just started facing right in the end): Soda88's video: 00-34 seconds (34s in total) -> Molotok's video: 06-23 seconds (17s in total) -> My video: 05-24 seconds (19s in total) ->

Since Soda88's video is clearly faster, for him the group had already made a full circle at this point. A full circle takes 30 seconds at normal speed (I measured it).

• do the math here - This concludes, that Soda88's video is 47/34 = 1.42 times faster than Molotok's, due to not using any framelimiter.

However I cannot explain why my video is 2sec slower than Molotok's. I'm hoping the problem is on Molotok's side :). I can see many lags/framedrops in his video, therefore it could have been a recording problem, or perhaps he used a virtual machine.

My testing config looks like this: Windows 10 64bit / Commandos BEL GOG.com version / Recording with Microsoft DVR (the XBox recorder built-in-windows) The only change I had to make was renaming the "Comandos.exe" to "Commandos.exe". This fixes the "Directx 5 not found" error apparently.

Yours sincerely, Mr. Assman

To display the elapsed frames since the start of the level, turn on "Show Cycle" in debug mode. It is the most useful feature for time measurement. With this on I've managed to pause the game at frame -1 (eg. the frame number display wasn't even on yet).

In the mission log file each row is one frame, hence it's easy to plot this in excel. You can treat each mission as a sequence of numbers, one number per each (mission) frame.

For the "game column", the starting sequence of eventIDs are these for the first 6 frames: 1283, 1284, 1369, 772, 774, 795, then 795 repeats until wheeler dealing starts (the tutorial mission doesn't change it), during the mission its 790 continuously, after the mission ends its 795 again.

Starting the wheeler dealing mission adds a new column and a new sequence of numbers: 938, 1594, 1595, 1383, 1385, 1386, 1387 (briefing message displayed at this moment), 1388, 1389, 1391, 1393, then 1393 repeats until the briefcase is collected, and so on. As you can see the mission has some initialization phase before it reaches its "wait until briefcase is collected" state.

I overlooked one option: "Do Mission Logging" in debug mode. This saves any mission related events into test/MISSLOG.txt. Sample lines: 5499: 1523 5499: 790 5500: 1523 5500: 790 5501: 1246 5501: 1523 5501: 790

format: #Frame: #eventID1 #Frame: #eventID2 #Frame: #eventID3

The number of columns change in time. Usually there is one column for each active mission, and one for the whole game. If I plot the data in excel you can see the intervals:

(imported the text into excel with TAB, space and semicolon as separators, and created a scatter plot chart)

I started Zaibatsu green mission: Wheeler Dealing, then followed the same route as you did in your 100% run. I picked up the token and completed the same kill frenzy. As it shows on the chart, tokens and wasted/busted events don't show up in the log file.

The Pros: Logging of all the mission events with frame precision.

The Cons: We don't know which ID number is for which mission. First an ID number - Mission event lookup table must be constructed, which takes a lot of time.

I was wrong about the "Log Routefinder" option. It seems to generate the same 330 lines (in Industrial), no matter what. So it's only a list of the junctions I guess, a check at the beginning, not frame-by-frame logging.

More about the log options:

I have version 11.44 and I also installed GTA2 Game Hunter, so that could be it. In my test folder I have 17 replay files, an error.log, a don't-delete-this-folder.txt and a warning.log.

There are 4 loggin options in debug mode. I've tested this a little in Industrial. The data is dumped to the warning.log file, when you close the game. It overwrites the previous content.

#1 Log Routefinder: logs all the junctions (not per frame, just the list of all the junctions :( ) sample line: (first number is the juncion ID) Junc: 329 (173, 250) n 326 s 0 w 0 e 0

#2 Log Random: every random number generated by RNG, about 30-40 per frame sample line: (first number is the frame) 5: random (get_int) 164

#3 Log Input: all the input made by the user sample line: (first number is the frame) 39: control_status = 2928645

#4 Log DInput: some sort of input check in the beginning, always 5 lines the whole game sample line: (first number is the frame) 21: input num_items = 1 dwOfs = 12; data = 0

Ah, good old pentium. Back then when you destroyed J-Lab the system would immediately run out of resources, and you could watch the glorious fiery explosion in slow-mo :)

For speedrun tests, there is a "Log Routefinder" option in debug mode, which I believe does saves your coordinates at any given frame. It's saved into a textfile, into GTA2/test/warning.log. All you need is to somehow decode this information.

Hi there!

It just came to my mind that GTa2 moves 30 frames per second, which is 33ms per frame. This could very well mean, that input signs that are shorter than 33ms are treated the same. So I'm gonna test this.

I have created a script which makes a button push for a certain period of time. I have tested this with 9 different values + with my original script (I pasted the script below).

First I measured the depress time for every script value with PassMark KeyboardTest. I got these values respectively: 1.1 ms 9.0 ms 23.3 ms 40.6 ms 54.6 ms 56.5 ms 71.5 ms 85.8 ms 101.0 ms 116.7 ms Note that measured values are differ from the times in the script by 10-15ms (that's why I had to measure them with PassMark). Also these values are averages of 20-20 measured value, and have standard deviation of 5ms.

Second I started spinning with Claude. I counted how many button pushes does it take to make a full 360 degree turn. From this I calculated the degrees of 1 turn, see on the chart below:

Conclusions:

#1: There is no difference in rotation between input times 1ms and 39ms (all of them make a 5 degree turn, or it takes 72 pushes to make a full circle). This means that if you are capable of making 33-39ms pushes with your keyboard, you can play GTa2 to a full extent.

#2: PassMark KeyboardTest measures depressing time very accurately, or at least it measures similarly as GTa2. Therefore we can use it later for benchmarking keyboards.

#3: Key 5 must be a measurement error or some weird bug. I have no idea why it's out of range.

#4: The formula for rotation is ( time/3 - 8 ) degrees if the time is greater than 39ms, and 5 degrees if the time is less than 39ms.

Cheers, Mr. Assman

SCRIPT FOR AUTOHOTKEY

; Custom function to hold down the Left Arrow key button for a given time of milliseconds HoldLeftFor(time_in_ms) { Send, {Left down} Sleep, time_in_ms Send, {Left up} Sleep, 100 }

; Mapping the custom function to keys 1-9 1::HoldLeftFor(0) ; Measures a 9.0ms key push on my system 2::HoldLeftFor(1) ; Measures a 23.3ms key push on my system 3::HoldLeftFor(30) ; Measures a 40.6ms key push on my system 4::HoldLeftFor(40) ; Measures a 54.6ms key push on my system 5::HoldLeftFor(50) ; Measures a 56.5ms key push on my system 6::HoldLeftFor(60) ; Measures a 71.5ms key push on my system 7::HoldLeftFor(70) ; Measures a 85.8ms key push on my system 8::HoldLeftFor(90) ; Measures a 101.0ms key push on my system 9::HoldLeftFor(100) ; Measures a 116.7ms key push on my system

0:: ; One tiny-tiny "tap" of the Left Arrow key Send, {Left} ; Measures a 1.1ms key push on my system Sleep, 100 return

Yeah, I would prefer the flying glitch too, it's much more reliable. However I'd like to test out some keyboards. I wanted to do some tests a long time ago, so this seems a good opportunity to do so. Unfortunatelly I mostly have budget keyboards, so that's what I'm gonna test on :P.

I have constructed two tests for testing keyboards for gaming (for GTa2 especially). Although I mostly had negative results, I'll publish them here, so someone might learn from it:

A) TEST DESCRIPTIONS:

Test 1, Measure DEPRESS TIME with Passmark Keyboard Test (30 day trial version, http://www.passmark.com/products/keytest.htm). Depress time means the time passed between pushing and releasing a button. The shorter time you can get, the finer your steering is in driving games. In this test I put my right index and middle finger on the left arrow key, then try to press it as gently as possible to reach the lowest depress time possible. I do this 20 times in succession, write it down, then calculate the average and standard deviation in excel. Unfortunatelly this software doesn't create a log file/statistics about which keys you press, so you have to do it manually. Otherwise I would have made a bigger sample.

Test 2, STUNT: Jump the ramp towards Token 17 in Industrial The ramp is near the Russian green phones. First get a cop car. Start on the Krishna/Russian border, or a little further. That will give you enough space to reach maximum speed. When you reach the ramp turn slightly right. The jump is only successful, if the cop car stays on the roof of the house (and doesn't blow up). The trick is to aim the very left side of the rooftop. First I practiced a little with each keyboard (30-60 minutes each), then made 20 jumps in succession. I use arrow keys to drive. My right index finger turns left, middle finger accelerates, and ring finger turns right. In this test I heavily used the aid of debug keys (transport back to starting point, repair vehicle, get rid of police). Otherwise it would have taken days.

B) TEST KEYBOARDS AND RESULTS:

Mitsumi KFK-EA4XT keyboard (DIN connector converted to PS/2, ~1997) Thoughts: very old, keys are moving too hard, too unreliable Test Results: Depress Time: 65,4 +/- 36,6 ms (deviation is way too high to be reliable) Stunt Success: 5/20

Smart Ez-9900 keyboard (PS/2, 2003) Test Results: Depress Time: 34,0 +/- 10,1 ms (best of all keyboards) Stunt Success: 8/20 (best of all)

Clevo laptop (embedded keyboard, 2003) Test Results: Depress Time: 71,3 +/- 15,1 ms Stunt Success: 7/20

Microsoft Comfort Curve Keyboard 2000 (USB2.0, ~2009) Thoughts: this is my current keyboard, pretty good for typing Test Results: Depress Time: 69,2 +/- 13,0 ms Stunt Success: 5/20

Acer Netbook (embedded keyboard, 2013) Thoughts: arrow keys have half the size of a normal key, not comfortable Test Results: Depress Time: 64,9 +/- 17,7 ms Stunt Success: 6/20

Script (works with autohotkey) Test Results: Depress Time: 1,0 +/- 0,0 ms (no keyboard can match this) Stunt Success: 7/20

C) Conclusions

#1 Take everything with a grain of salt. This isn't rocket science.

#2 The goal here was to find a reliable test that can decide which keyboard is the better. I think I've failed. The difference between keyboards is much smaller than I thought. To come up with distinguishable results you may have to continue this test up to a 100 trials or more, which is a waste of time (considering its only a special task).

#3 Tried googling "keyboard test software for gaming", or "keyboard gaming reliability tests" and so on, with no relevant results. There are tons of software which tests touch-typing precision, but none for gaming apparently.

#4 I've been disappointed with my Microsoft keyboard. Considering that I've been using it for quite a while, and I practised the most with it, I expected better results. Quite reliable and comfortable for typing, but not for gaming.

D) To sum it up

You can play this game with pretty much any keyboard you have. On the long run however, you may want to test out for yourself which one is right. (pretty much the same what Molotok said 3 posts ago)

What is your opinion of testing keyboard for gaming (or for GTa2)? What kind of tests would you prefer?

Mr. Assman

Hello Molotok, thanks for the quick response!

I created this script to get Token 17 in Industrial district (Token 49 is similar too). This one requires a long precise jump with a cop car, near the russian green phones. (see: for token numbers) The hard part is that you have to approach the ramp in a specific angle. You have to adjust at the very last second! Nevertheless I can do it after 5-10 tries (without script).

The challenge here is to push a key for the shortest amount of time. This requires skill & feeling your keyboard (just as you said), but trying out different keyboards might also help.

The toggle rapidfire button is just for fun. You can "poop" a long line of vehicle land mines if you wish, and other silly stuff. It's not a very useful one, I agree.

I really enjoyed watching your videos, I hope you can complete a 100% run for each district.

Mr. Assman

Here is my story:

I use a decent Microsoft keyboard with keys binded to near the arrow keys. Unfortunately my keystrokes are too long, thus it's really hard to make delicate movements. Driving high speed on the sidewalk, or aiming precisely at a certain direction is troublesome. To overcome my limitations I created a script in autohotkey, which I post at the bottom.

(Apologise for my limited scripting knowledge, but I'm new to this. I use modified sample scripts from other sites. Any correction/tip is appreciated.)

The script contains a toggle button for turning itself on/off (if you want to go back to windows): press "F12" to suspend/unsuspend script

It contains a script for sending the smallest amount of "keystroke" of certain keys: pressing "a" sends one press of "left arrow key" pressing "d" sends one press of "right arrow key"

Also I added a toggle rapid fire button for kill frenzies: pressing "f" once acts like the "right shift" button is pressed every 100ms. press "f" once again to stop rapid fire

The keys can be customized in the script text.

; AUTOHOTKEY SCRIPT STARTS HERE: ; Toggle Suspend Hotkey ; for turning on/off the whole script f12:: Suspend return

; Send the smallest amount of a target character ; hotkey: a:: ; target character: Send {left}

Sleep, 100 return

; hotkey: d:: ; target character: Send {right}

Sleep, 100 return

; Toggle Rapidfire toggle = 0 #MaxThreadsPerHotkey 2

; hotkey: f:: Toggle := !Toggle While Toggle{

; NOTE#1: right shift may cause a warning of stuck keyboard button in windows
; NOTE#2: if you change this to an alphanumeric character, you may be surprised what it does outside the gaming environment
; fire button:
    Send {RShift}

    Sleep, 100
}

return