When you land a big combo, sometimes it will take a long time to tally up the points. When you start a new combo, it immediately applies the points from the old combo instead of counting down. It takes less time to count down a lower score combo.
My thoughts:
- This run should be accepted.
- This run should obsolete the current glitched run.
- This run should be published right alongside the 4+ hour run.
Similar runs should obsolete one another, and dissimilar runs should be considered as a separate publication if there is a significant entertainment difference.
I don't consider this to be terribly entertaining other than the fact that the game becomes horrifyingly broken. But it is a fascinating technical demonstration, so it should be published.
Thanks! I am using the video link you posted earlier as a reference (the routes are very well planned). Without a source input file for that video it's hard to tell if I am saving any frames, or if there are techniques that I am not aware of that were being used. So far, I have found a few places to save a few frames based on what I can observe.
Goliath's hitbox is tiny compared to his sprite :)
Got hitboxes and enemy health.
Here's the Lua script for the HUD if anyone wants:
http://pastebin.com/ckBCNGGG
It does everything I need it to, so I will probably be starting the actual run soon.
Some progress. I picked up Lua last night to help with the run. Unsure if the sprite hitboxes are correct, but I'm just using the addresses found in the actor data and they seem to match well. I don't know if there is additional 'origin' data that I am missing (see #5 in the image).
Studying RAM patterns. I haven't found hitboxes just yet.
00FF0106 - Player X (16bit unsigned)
00FF0108 - Player Y (16bit unsigned)
00FF010C - Camera X (16bit unsigned)
00FF010E - Camera Y (16bit unsigned)
00FF0802 - Camera X in blocks (16bit unsigned)
00FF0804 - Camera Y in blocks (16bit unsigned)
00FF2C76 - start of actor data (0x80 bytes in size, first one is the player)
+00 X location (16bit unsigned)
+02 Y location (16bit unsigned)
+50 health (16bit unsigned)
00FF3FFB - number of actors to process (8bit)
Does it mean it's acceptable to submit a TAS with TaoTao's version instead of the new FCEUX 2.1.5?
I only ask this because my first TAS I'm working on (Indiana Jones and the Temple of Doom Thread #11250: Indiana Jones and the Temple of Doom) is also suffers from this (enemy position, hidden exit and an unnamed glitch depends on CPU clock, that's why my WIP shows different result on 2.1.5 and TaoTao's patch) and I would like to take benefit of higher accuracy instead of "reworking" the same for a "possibly not accurate" version of FCEUX.
I dunno, that is a sucky situation and would like to not worry about it.
Considering that it is an accuracy fix I would like to eventually see this in FCEUX. The change would break some runs for sure. NES runs are being console verified. On NES I would rather side with the real hardware and hold on to my TAS for FCEUX to implement this.
I'd have to go with Genesis. But that's based on the sound alone, because Tommy Tallarico can freakin' wail on FM.
"Off The Wall" is a pretty good benchmark for comparing the two versions (it is a pretty tight level), and I think a test would help determine which version to use speed-wise.
The WIP looks good, I did notice some backtracking in the bonus levels, decent routes otherwise. Do you happen to have large maps for this game?
I just watched the NES Boy and His Blob video and thought about this sequel. I know this thread is a few years old but I think what we've got here already is important. Are there any further plans for this game? Does it have the same bugs?
I was once able to get the catapults in the first level to chain so that a jump wasn't necessary, however I haven't been able to replicate it. I don't recall if there is a difference between normal and hard mode other than the number of lives you get. This game also has a ridiculous amount of lag.
Voting yes because the game is terrible is the same as voting no because the game is terrible. Who cares about the game? Rate the video.
This TAS, while executed well, isn't that fun to watch. Given the style of gameplay it's probably about as good as it'll ever get though. Meh vote.
If this doesn't get published, then we should revert a few super mario bros (nes and N64) runs cause many of them improved prior runs by a few mere frames. Some of them actually had bad camera angles and bad "style" but still were accepted. I definitely vote yes because it improves the current published run. Yeah, the camera handling was a bit annoying but not to the extent for me to vote no.
I agree. Why should those be published and not this one? If someone gets a world record time in a 100m race by just a tiny fraction of a second, they don't get denied the record because the judge didn't like the way the runner moved his arms.
Would love to see something like that.. though it's hard to pinpoint an exact point where the game is "complete," but that can be figured out.
Depends on if you define it as using the expected route, or just As Fast As Possible. Expected route means no Lavos fighting until after the Undersea Palace, AFAP means as soon as you're ready, use the bucket. Or just 100%, meaning go through Undersea Palace, plus the optional quests after that.
I thought something like this might be kind of neat. But everyone's definition of 100% isn't necessarily the same. I think once you can't go any further with any NPC item trades or extra boss battles it's considered 100% complete QUEST-wise. That'd be my favorite kind, eliminate that rare item grind-fest. But once again, it's subjective.
VICE has rerecording for Commodore 64 but it's definitely not smooth. Still I think it's really the only open-source C64 emulator that could be considered accurate - and even then, they are still patching up a lot of newly discovered quirks in the hardware.
As much as I'd love to do one for that system, even if the emulator was perfect... load times would still probably kill interest in the end :\
One of the sound generators seems to be using a sine wave instead of a square wave - most notably in the Sonic games, using 11a's default settings. Any way to change this back as it was in earlier versions?
v15.3 did work on Win98, but v16 from the GoogleCode page does not. Keeps saying it is expecting a newer version of Windows.
No big deal, that was tried on my oldschool win98 rig and not my primary. But I thought I'd like to bring this to your attention.
Very entertaining. I have never seen nor heard of this game before but having watched its gameplay it's definitely an excellent blend of 2D and 3D elements. As for the movie, you've got slick maneuvering through the levels and complete annihilation of everything in your path. Quite short for a PSX game but the action just doesn't stop. I dig it.
Sega should do the next Sonic game like this.
Got hitboxes and enemy health.
Here's the Lua script for the HUD if anyone wants:
http://pastebin.com/ckBCNGGG
It does everything I need it to, so I will probably be starting the actual run soon.
Found the hitbox stuff. Added more info like invulnerability counter, exact HP amount, and run counter (need 12 for a dash move)
Some progress. I picked up Lua last night to help with the run. Unsure if the sprite hitboxes are correct, but I'm just using the addresses found in the actor data and they seem to match well. I don't know if there is additional 'origin' data that I am missing (see #5 in the image).
