Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
Good find, I totally overlooked the possibility of using the underflow trick for death warping back to the door.
IIRC you can only kind of "land" - or rather: bang your head and lose vertical velocity - if you release the jump button after falling AND there's a block right above Comic's head, i.e. in the third bottommost row of tiles.
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
Well written and exhaustive submission text! I added and changed a few things, feel free to keep or change them as you like :)
The run itself looks perfect to me, I don't see any room for improvement.
Probably too late - another glitch that's probably only useful for some extra fun: when hovering, if you're hovering against the top of the level and hold jump for too long, the vertical velocity underflows at some point, sending Comic down to near the bottom of the screen and if you keep on holding space Comic will fall to his death. But - if you let go of space, vertical velocity will overflow again, sending Comic back up - or, if his head touched an obstacle, he'll lose vertical momentum and stay at that vertical position. (EDIT: I don't think that it'll be possible to use this for exiting the crown room again...)
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
I would love to see a TAS of this game too, I'm just not sure how much faster this would be than a regular speed run since there is a lot of waiting for scripted or timed events. But these things have never stopped a true TASer ;-)
A good deal of information is available in the description of this speed run: http://speeddemosarchive.com/DungeonKeeper.html
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
I just had a look at VICE again and noticed that it, while being a bit cumbersome, looks well suited for TAS.
Would you allow (converted) VICE input files for submission?
What it offers:
* Frame advance (redefinition of shortcut keys highly recommened)
* Recording input (and other actions such as inserting disks)
* Starting new movies from reset (needed for valid TAS)
* Setting a single milestone and jumping back to it (not 10 like most other TAS-capable emulators do, but it's possible to swap files)
* Rerecording a given input file at any point
In default settings VICE will record input starting from the current emulator state and thus create 2 binary files: start.vsf (start snapshot) and end.vsf (end snapshot and all input up to that point). When starting from reset no start.vsf is created fortunately, also even after stripping everything but input data from end.vsf the movie will still play (you just won't be able to jump straight to the end any more).
To make it suitable for TAS an external tool will be needed that converts the end.vsf file to a text file containing a list of input so everyone can see that it's 100% legit, also this has to strip all binaries and replace them with sha1/sha256 sums (yeah, inserting a game into the emulator will append it to the input file); another tool will then be needed to reconstruct the end.vsf file from such a text file, asking to be provided with binaries as needed, and, if possible, launching VICE to play the file just reconstructed.
This tool creation should be a straightforward task since the file format is well known (open source).
Some minor details should still be figured out. VICE allows changing hardware details; there are 4 different video standards (major timing differences) and newer chip revisions can cause minor differences. I'm wondering whether such details are recorded in an input file, just in case someone wants to play NTSC games or just used a non-default machine.
For most old games there are original images (a few cartridges, many tapes, many disks) available, cracked versions are a no-go. At least for games that only load once at startup the publicated movie should however skip the loading sequence since that can be many minutes of boring screen flicker, especially for tapes.
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
Nice well executed run, and some surprise strategies :)
Hope there'll be a TAS of the PC version one day. This one allows for "mouse cheating", using the mouse as a joystick and, especially when combined with the "run" key, running at ridiculous speed (like 3x as fast). Kurt will be so hectic!
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
Adding frame advance to VICE isn't that difficult, I've done it before.
The biggest problem about C64 are "roms". If you're lucky you can get one of the following:
* ROM image of cartridge (.crt) (only ~50 games ever released on crt IIRC)
* Binary disk or tape image of unprotected game (.d64 or .t64) (usually magazine disks/tapes)
Then there are raw disk and tape images (.g64 or .tap) that can store protected games but for technical reasons there's no unique way for creating such a file from a medium, causing loading time differences.
The majority of downloadable games are cracked with a prepended intro and modifications to the game code. I don't like TASing such games for obvious reasons. (Even "remember" modify game code to the point that even without cheats there are timing differences)
As a compromise one might at least for games that don't load data from disk create a memory image at the moment control is transferred to the game itself and use that for TASing.
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
wellbe6 wrote:
That was an AMAZING and FAST speed run. Well, I'll be waiting to see a NON-TAS run as fast as this!
Yes and no. There's a non-assisted movie in 23:55 but that's due to emulation problems in the TAS run (world map slowdown). Without that the TAS run can hardly be beaten without TAS because at least one of the time-saving tricks (mini mario vertical wall jump) needs frame precision.
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
I've tried it again and recorded on video to measure what's better.
You need to start the level (World 8 Tower 2) with either:
a) fire flower or shell equipped (picking up the another fire flower for reserve won't cost time)
b) big mario and fire flower in reserve (you'll need to take a flower anyway sooner or later so the delay by picking up the fire flower at start couldn't be avoided anyway)
At about 1:22 in above video you can run up yourself (maybe even earlier). I've almost reached the savepoint at 457 in-game time while normally the platform reaches that point at 435. This is a difference of 22 (more likely a bit less since I just almost reached it and then died).
The time from death until you touch the platform to make it start moving after re-entering the level (including hammer bros walking) plus the delay caused by the game when picking up the fire flower taken from reserve is slightly less than 18 in-game timer steps. (Unfortunately a little more in emulation right now due to the world map slow down bug)
Thus IMO this is still worth further research.
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
2 possible improvements for NSMB runs:
* If you stomp sea lions they'll swim faster for a short moment.
* In World 8 Tower 2 it might be faster to climb, jump and walk over the spikes to the mid-level save point (at about 1:30 in http://www.youtube.com/watch?v=Db8Kn93kQPY jump off the platform and climb your way up), then suicide, because when you then re-enter the level the moving platform is already in front of you. I've tested this on a real DS and it seems to be a bit faster. Can someone confirm this?
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
Bisqwit wrote:
I suggest a video where the second screen is moved to be a thumbnail on the side of the first screen...
Btw, if you use MPlayer, use this option: -vf crop=256:192:0:0.
It does wonders. (Though it sacrifices the second screen.)
Sounds good, except for games where both screens are combined to create the impression of a bigger screen where this would destroy that impression (such as the mentioned games contra 4, sonic rush/adventure, yoshi's island 2).
Give the smaller screen a third of the bigger screen's edge length and both combined will perfectly fit into 16:9. In case main action switches the first screen could be shrunk and the second screen be enlarged if that's not too much video editing (preferably in a short animation as a sudden size change could irritate viewers):
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
Monty Mole wrote:
I hope I can help. You can find some original romimages in the net.
www.c64games.de is a good portal which hosted some original images without hacks or cracker modifikations.
Did you use "hosted" intentionally, i.e. there are no longer original images? I've taken a look there and the games there seem to be mosty unknown and mostly cracked.
Monty Mole wrote:
Even in the case there is no originalrom the cracks from the group "Remember" are a really good source for qualitycracks.
Yes I know. But in the case of Cauldron 2 they modified the game code even in the case that none of the builtin trainers (cheats) is used. While this shouldn't affect casual players this changes the timing of the game code a little and this matters for TAS as Cauldron 2 is programmed a bit sloppily and due to that collision checks return an incorrect result sometimes, depending on timing. Thus recorded gameplay is likely to desync if the game version is exchanged with another not containing these changes.
To see what I mean start Cauldron 2, go into one of the 2 rooms at ground level with a movable platform and let the pumpkin bounce. You'll see it changing its bounce height randomly. This is because they covered the chain below the platform with black sprites and as these overlap the chain a collision interrupt is triggered every raster line. Whenever a collision happens the code reads (and thus clears) the collision flags twice but only uses the first read's result. So as a result when the collision of pumpkin with the ground happens just in between these two reads that collision can get lost and the pumpkin will penetrate the ground a little further, causing the game to think the pumpkin fell a little further and thus making it bounce higher.
Monty Mole wrote:
What about making a TAS section there? Regular C64 speedruns could in theory get accepted on speeddemosarchive.com, but C64 TAS won't be accepted by TASVideos ("Movies for any other systems aren't accepted.") and this is unlikely to change due to little interest in this platform here and problems mentioned previously. What do you think about adding a C64 TAS section to your longplay project?
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
I'd like to see more Commodore 64 TAS stuff, too. But I doubt that this is going to happen on tasvideos for the reasons explained in this post.
With a few exceptions there are no "ROMs". Most games were shipped on disks only.
While almost all games are available on the internet on abandonware sites these are all cracked versions for various reasons. First of all most games were copy protected by using non-standard modifications to the disk data layout in order to thwart disk copy programs. Also, early C64 emulators also had no means for emulating images of copy protected disks (and emulation was not good enough to handle copy protected games correctly).
Obtaining original game disks is game of pure chance as data on floppy disks deceases within a few decades. Also, checking copy protected disks for read errors is impossible because copy protection itself often makes use of intended read errors.
Furthermore, the floppy disk medium itself consists of circular data tracks with no definite starting point. You have to define one yourself. The choice will influence how fast a game will load in an emulator. Also, because the disk drive motor is not 100% accurate when switching from one track to the next the track layout may desync a little, changing timing a little further.
In contrast, all cracked games use only a few simple file formats, either PRG for one-file games (which basically contain the contents of a contiguous piece of memory) or one or more D64 files for multi-file games (which resemble the standard disk data layout).
Using cracked games, however, is in violation of tasvideos' rules. Most cracked games contain an intro prepended by the cracker (which can easily be skipped), but the largest problems are the following:
* some cracked games offer cheats (of course with the option to play without cheats)
* for games that load data from disk the removal of copy protection often leads crackers to change the way data is stored and loaded, thus causing timing differences to the original
* some crackers even fix bugs in the cracked games (or do major structural changes to make cartridge games playable without cartridge); I've also seen cases of code being altered just to prepare cheats so the pure presence of built-in cheat options may change game behaviour a little even if cheats are not used at all
* there are bad cracks (i.e. gameplay itself altered, usually game malfunctioning sooner or later), either because the crackers themselves messed it up or because the game's files were damaged later on.
For my C64 TASes I've collected as many versions as I could get and compared them to see what's different and for what reason and to construct a game snapshot of just where control enters the game itself. This is of course not free of problems as it is basically starting a game from a prepared savestate but IMHO that's the best way available for single-file games not available on cartridge. Unfortunately this does not work for multi-file games.
I've also modified VICE a bit to handle speed running better, most notably frame advance. Unfortunately the game recording system of VICE is very unreliable and corrupted my work in progress many times, forcing me to keep lots of backups. While VICE is open source and therefore customizable in theory in practice this is very hard due to the IMO nasty coding style; unfortunately I was unable to change the recording system to a more reliable one as seen in many console emulators.
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
Yes I'm talking about re-writing the game.
Main reasons why re-written code is so much faster:
* E.g. the "adc" (add) instruction of the NES' CPU takes 30 lines of C code for proper emulation of all "side effects". When rewriting you usually don't need those side effects.
* When coding for 8 bit CPUs any value that doesn't fit into one byte must be split up into multiple instructions. Also some operations such as multiplication must be done "manually" on 8 bit CPUs (similarily to you were taught in school). Re-written code can do with one instruction what 8 bit CPUs needed many more instructions for.
* You know exactly what of the hardware the game needs for operation.
I can't imagine how tough it would be to try to copy the game's mechanics exactly, without the source.
Very very tough. I've fully copied a very simple game's mechanics (FlaschBier - a boulderdash clone) but for another game (Cauldron 2) I've excluded the enemies and then use the solver mainly for finding routes than for solving the game itself.
It might be possible with SMB1 (still provided there's someone with enough skill, time and patience) but I doubt anyone will succeed in doing this with later SMB or MegaMan games.
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
... that checkers is solved it got me wondering whether it would be a harder task for a computer ... to find the fastest route through SMB1...
Some techniques for this:
(1) You can use a modified emulator to take a snapshot every frame and use them as states. But these will contain information you'll never need for a speed run e.g. your score, number of lives or number of bonuses.
(2) You can also reverser engineer the game's internal algorithms and rewrite them in a modern language such as C++ which will then run much faster than any emulation (and also allows you to cut away anything you don't need, e.g. your score).
(3) As a compromise you can emulate a simplified version of the game that doesn't contain stuff you don't need. Don't forget to set traps (or assertions) just for the cause that the information you've just cut away is still accessed from somewhere.
I don't think (1) works for any real game.
I've already done (2) but be warned: it's very, very complicated.
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
I've TAS'd 3 Commodore 64 games so far
* Cauldron 2
* FlaschBier
* The Great Giana Sisters
Timing is a bit difficult - there's no counterpiece for ROM images for most games so I've traced the "entry point" where control goes from the loader or intro to the game itself and used that one to start timing.
Take a look if you're interested http://www.youtube.com/profile?user=taskabuto
Experienced Forum User, Published Author, Player
(104)
Joined: 5/22/2007
Posts: 22
One of the old C64 games I remember well is Cauldron 2, a game where you control a bouncing pumpkin through a witch's castle in order to defeat the witch. (There's also a predecessor, named just Cauldron (or Hexenküche in the german version), where things are opposite: you play the witch and need to defeat the pumpkin. Just for reference - this post is about Cauldron 2).
Using VICE and some selfmade tools I've begun making a TAS for that game. I've chosen Cauldron 2 as this is a good example for using helper tools for doing things that would be really difficult to do manually.
You have little control about the pumpkin: only whenever it bounces on the floor you have the choice of jumping left, middle or right and jumping lower or higher, giving up to 6 choices in general. Also in some places you need to be pixel exact to achieve a given goal as quickly as possible. Reaching that pixel is one of the biggest problems.
To achieve that I've made a kind of route planner (which has little in common with BisqBot). I've reverse engineered the game physics and created a model from that; together with Dijkstra's algorithm this can find quickest paths from A to B - the time it takes for computing differs, it's roughly one hour for 2000 frames. Also aspects like whether death abuse is beneficial can be incorporated. The result can be watched directly in the route planner (it has a built-in game graphics renderer which is very useful for tuning the physics model directly), furthermore it generates textual instructions about which button to press when.
The second tool is a text-to-"Event History File" converter that takes a game state, a list of instructions (such as "press fire button for 10 frames" and "wait 30 frames") and generates a pair of "Event History Files" for playback in VICE.
Probably the biggest problem with Cauldron 2 is its sloppy collision detection code which can miss player-world collisions, in a few rooms (those with a platform) about every fourth is missed. This has to be compensated for, usually by shooting without reason, just to "distract" the timing a bit.
Let me know if you want to see the run (will take some time if it ever gets finished) or anything else mentioned above.