This game has ruined way too many childhoods, including mine at times. Too many cryptic puzzles (throwing monkeys, caves, lava pits), difficult platforming and very few HP / lives. It's great to see it destroyed like this.
Great job, guys. Yes vote.
Alright, I added the instructions for creating the image and the contents of the cfg file.
Since I now created a new image (using those linux commands), here is the resync'd movie:
User movie #637891445280063924
Just in case, always remember to delete rom/pb570/flash.bin before running the movie
I'm torn on this one.
On one hand, I love chess, and I love the fact you used unconventional means to create a TAS (namely, a freaking chess engine). I also used to love battle chess when I was a kid and all the quirky animations.
However, as I watch it today I cannot derive much joy. At least in this port, animations are slow, tedious, and not that much fun anymore. I cannot sustain 10 mins of this. To be honest, I had much more fun running the PGN on lichess at my own pace.
All of this diatribe, just to say I'll abstain to vote (even a Meh is unfair here).
Ok guys, so I fixed QuickNES to halt on bad opcodes and disabled the Up+B bad inputs from the bot. So far I made some good progress. However today, just for the fun of it, I tried what would happen if I allow the bot to make glitchy inputs. And to my surprise, I have just observed the first 'glitch' that works in all emulators. See Frame 13685, where our hero glitches through the floor, saving a considerable amount of frames:
User movie #637851337516198347
The bot has also detected other 'tricks' on the patched QuickNES that so far haven't worked in NesHawk. Which brings me to the following dilemma:
A) Keep working on the 'glitchless' version + this glitch I just found.
B) DO WHAT I MUST, and try to find all glitches that work on NesHawk.
If I follow (A), then I'll be done with this damn game in 2-3 weeks. If I follow (B), it will be a rabbit hole: I will need to connect my bot to NesHawk or an emulator that behaves similarly.
The question is: @Alyosha do you think we can use your C++ version of NesHawk for this task?
Ahh finally the treatment this game deserved. GMP had hoarded a bunch of route and execution improvements to the (now obsoleted) movie since last year and refused to publish it until there was an emulation platform that allowed for this game to show it's true colors. Well, today is the day where libTAS+PCem finally overtook JPC-rr for us, and boy it was worth the wait.
Remark: The movie time is actually around 14:10, if you discount the booting times, which makes it faster than my (and +GMP +Challenger) submission
Movie highlights:
0:38 - Can't touch this
1:50 - What are walls?
3:35 - No, really, what are walls?
4:30 - W-A-L-L-S? Nope, never heard of him
5:15 - Bye, bonehead!
5:35 - ktnxbye
5:45 - No walls for you!
6:00 - Parsing error: 'walls' command does not exist
6:45 - Walls are just, like, a social construct, man
7:05 - sllaw
7:20 - Doors ain't a thing either
7:38 - The pain section -- hours lost routing this part
8:20 - Who turned off the light?
9:40 - Just a s(k)ip
10:00 - swordturn
10:30 - the legendary birdskip
11:00 - whoopsie
11:45 - walls. not even once.
12:20 - no, really, how many wall skips does this movie have?
12:35 - another wall bites the dust
13:10 - Great bird avoidance
13:45 - Hey, you dropped your wallet! -really? *BAM*
14:10 -Buggy supersaiyan
14:45 - Kamehameha
This is an obvious YES for me.
Great research. I feared that could have been the case, what a bummer :(
I'll have to patch QuickNES to halt on this opcode and re-run the bot. The result won't be as spectacular, but hey, that's life.
Can we delay this movie until then?
Thanks Challenger and Alyosha for your kind comments and feedback!
You guys raise some valid points about reproducibility and accuracy. Unfortunately, I don't have a good answer for them, given the tools I've used. I tried the trick on FCEUX and it did produce the characteristic flicker you see in this movie (I assume PPU corruption) and didn't crash, but it didn't produce the skip either. I would have to try again with more accurate timing synchronization. On the other hand, I'm thinking of replacing QuickNES by Mesen (another C++-based emu) for the botbut then again, there are no guarantees of cross-compatibility and it might be painfully slow. Perhaps I can also use your C++ version of NesHawk since the routing is mostly done?
Besides that, there are so many things I want to do with the bot like solving other simpler NES games I really like (cough cough Castlevania cough Ninja Gaiden) and even SNES and Genesis (Flashback), that I don't feel like spending too much more time on analyzing what exactly is going on with this movie. I'll be fine with whatever decision the judges make.
Regardless, this is indeed a hairy topic, and perhaps this movie can serve as catalyst for a wider discussion.
Thanks Nymx :)
Exactly. Sometimes the bot used variants to UB, such as DUB and DUBA. Don't ask me why.
Hahaha I can sense the irony. Thanks for the vote :)
I know, right? It's amazing.
Wow!! Thanks so much for the comparison video, it really helps to see the difference the new tricks made to the route!
Yes, SNDDRVRS contained additional drivers provided by Broderbund for that era's sound cards. Since we use only PC-Speaker, we have no use for this additional folder.
MIDI and DIGI.DRV are the specific drivers for Sound Blaster and MIDI music copied from the drivers folder by the game's setup. Again, since we use PC Speaker, these files are also not needed.
Hope that answers your question!
Sorry, dumb question.
Why wasn't the equally bad SNES port used?
The SNES port is, from what I recall, considered the worst version of the game, being glitchier, having several missing elements, and most notably completely lacking the Escher-esque final level.
Edit: Oh, I forgot this version was never actually released. So I don't know if anything besides the final level that was missing from the SNES version is actually in this one.
This version was chosen for being very close to the DOS version. Many of the mechanics/tricks that work here, also work on DOS and vice versa (with some notable exceptions mentioned in the description). Memory analysis also confirms that game-specific variables behave largely equally in both versions.
Level layout is also equal on both versions. Again, with some exceptions: e.g., the beach level has one tile less in Genesis than in DOS. Also there are no health potions in the last screen of Jaffar's labyrinth.
Therefore, this version was the best proxy to the DOS version when applying the bot (applying the bot to the DOS version is just not feasible with the current state of DOS emulation, and we don't have its source code as we did with PoP1).
Hi all,
This is to let you know I'm working on a bot-driven TAS for the genesis Prince of Persia 2 (1996) cart. This is an almost complete game has never been released and it only surfaced/leaked relatively recently. I cannot post the link to the information page because it also contains a link to the rom and goes against forum rules, but a quick google search would suffice but I quote:
The unreleased Mega Drive port of Prince of Persia 2. It was dumped by Jurai and released by drx on August 11, 2006. [...] This game was canned for unknown reasons.
The game is almost complete because there is a bug that prevents you to get onto the horse that takes you to the last few levels of the game. To overcome this, a fix patch has been released: http://www.romhacking.net/hacks/3755/
As of now, I've linked the BlastEm! emulator to my route generating bot, Jaffar2 (https://github.com/SergioMartin86/jaffar2) and I'm working with the PoP speedrunning community to bring the full TAS to life. I estimate to to take 6-12 more months to complete.
The purpose of making the TAS is to satisfy our own curiosity and lust for TAS, but also to eventually port the movements to the DOS version of PoP2. Early tests indicate that the ports are mostly similar and tricks work equally in both ports. We work on genesis because a bot-driven TAS for DOS games is still very much in the horizon.
THAT being said, my question would be: would this genesis version be acceptable for publication here once it's done? I know it's very far fetched from the ground rules (it's a non-published game and it needs a patch), but then again I know judges have some degree of freedom to take discretional decisions.
Don't worry, it's ok if it doesn't quality. We won't can the project if it isn't and we'll probably come back later on with the DOS version of the TAS. But for now I'm curious to know whether this particular port could work it out here.
Why was this created/chosen?
How was this created?
Also, I'm trying to import this image, however JPC-RR says it doesn't recognize it.
Edit:
Okay, I see the file just needs to be copied directly to the drive library.
Hi Nach,
For most of JPC-RR's configuration, I followed this page verbatim:
http://tasvideos.org/EmulatorResources/JPC.html
The FreeDOS image is a build shared by CoolHandMike in that page. It used to point to the google drive link but it seems that someone replaced it with a link to a static file in this server. FreeDOS is the DOS of choice since it's GPL and is, allegedly, perfectly compatible to the licensed MS-DOS.