Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Heidman wrote:
Ok... I am sorry if I don't understand it properly or not, but this is what I get out of it. For this bug to happen, one of the tanks (for my rout it will be the right one) needs to be destroyed on a frame that happens every 105 frames. So kill the tank on that frame, get the bug? Is this right?
Right, but there are two lucky frames within every 105 frames (one when tank switches from 03 to 04, and another one when it switches from 04 to 03).
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Interesting, it seems like programming oversight.
Basically, this right tank is doing "death cleanup" twice, because left tank shoots at the moment. As far as I understand, this game is programmed so that only one tank can switch its status during single frame. This is probably made to avoid lag, because initialization of new objects (bullets) may take considerable amount of CPU cycles, so it's better to distribute them to different frames.
Details:
At 0x9F there's tank_counter that must be zeroed to allow scrolling again.
At 0x668-0x675 there's array of statuses (up to 14 objects on screen).
At 0x6E6-0x6F3 there's array of animation_timers (measured in frames).
Every tank enemy has following statuses:
01 - just created, increase tank_counter and switch status to 02
02 - intro, scroll screen closer, then switch status to 03
03 - wait for animation_timer to expire (btw, it's 96 frames), when it becomes 0 - then switch status to 04
04 - shoot -way projectiles, wait 9 frames, then switch status to 03 (so this is infinite loop)
When player nullifies tank's HP, the enemy is forced to switch status to 05 (making break from infinite loop).
05 - init explosions timer, switch status to 06
06 - show explosions for some time, then switch status to 07
07 - decrease tank_counter, then switch status to 08 (if possible)
08 - finish stuff, free memory
So, what it means for you, well, the only way to recreate this bug is to finish right tank at the very specific frame (using Memory Watch). This lucky frame repeats every 105 frames, so the probability is not 1/400 but 2/105.
Yes, and other enemies don't affect this bug.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
FODA wrote:
I was wondering how did they manage to do some of the apparently complex collision detection. Take Double Dragon 2 for example, how did they calculate where you can walk and where you can't? I mean, right on the first screen you can walk on a rectangular floor, but on the next screen the floor grows diagonally, and the collision there seems pixel perfect. I think the same goes for games like mac kids, super mario 3 or kirby's adventure where there are ramps. How do they calculate that?
Note that these games only use "45 degrees" ramps. Those 45-degrees slopes don't even need to have lookup tables because y(x+1) = y(x) + 1. It's easy to code such collisions with only addition/subtraction operations.
BTW, there's great article from the programmer of MC Kids: http://games.greggman.com/game/programming_m_c__kids/
The mapper does not really care about the lower bits of the address line used to program the mapper. It is merely a convention that it is often used in that manner, a convention that needn't be religiously followed.
Um... no, this convention has hardware roots. It's not about address, it's about bus conflicts. When we're writing 05 (101b) to ROM location that contains 06 (110b) as a result we may switch bank to 07 (111b), because UNROM mapper doesn't disable ROM's output signal.
You can read about it here:
http://wiki.nesdev.com/w/index.php/Bus_conflicthttp://wiki.nesdev.com/w/index.php/Programming_UNROMBisqwit wrote:
(Also, as for your code, did you make sure it fits in the allotted space?)
Nah, it'd obviously overwrite some original code, as well as FinalFighter's IPS did.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
feos wrote:
Also, this is probably the first run which abuses the LAG (and only then the game itself)?
Not exactly. There is SubstitutedScrolling trick in MM2. And I think there were some cases of enemy non-appearing in Rocking' Kats... But this Delay* trick is extreme case.
It was known long ago that lag could be useful, I even remember calling things "lag management" instead of simple "lag removal".
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Quibus wrote:
Just a check question: are we absolutely sure that none of these glitches are caused by emulator-inaccuracies?
Read more about the trick and you'll see that, while probability of getting NMI between two desired instructions is insanely low, it's still very natural behavior of such crappy code:
1. Change bank to value N
2. Make notification (to NMI) that bank was changed to N
If only the game saved CurrentBank (0x42) before actual switching, the trick wouldn't work:
1. Save N to 0x42
<--- suddenly NMI, but notification was already made
2. Switch mapper to bank N
It's perfect example of "Abuses program errors".
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
ALAKTORN wrote:
klmz wrote:
How many rerecords were done by the bot? In my opinion, you should either substract all bot-rerecord counts from the run, or include all of them in it, instead of only including some of them. I incline to the former choice because you don't give credit to the bot(s) who did 99.999999% of the whole job as a main author(s), though.
I'm all for crediting the bot and putting in over 4 million rerecords! I think it should show that a bot was used, and leaving out its rerecords is misleading
Agreed. When you think how improbable are all the conditions for pulling the trick, you expect some bots/bruteforcing, so put in those rerecords for great justice.
Yes vote. Good work, FinalFighter and Shinryuu!
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Wow, this trick is certainly hi-class achievement. And it's so rare occurrence, it's amazing someone stumbled upon such ingame condition.
Now I wonder if same technique could be used in another lag-heavy game. Because many NES games use similar bankswitching routine and bank changing/restoring in NMI, so it's only a matter of extreme coincidence to get NMI between two instructions (bank switching and variable storing). And for "coincidence" we have bots and pure luck...
finalfighter wrote:
I made HackROM with the same effect as delaytest.lua.
Because there's that racing condition between Read/Write, so 05 should be written to an address containing 05 (such as C005).
Of course this has nothing to do with accuracy of Inzults' hardware test, I'm just being nitpicky. :)
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Flygon wrote:
Weatherton wrote:
Flygon wrote:
Easy, make the final flagpole overflow the 999,999 counter.
Perhaps this was intended to be tongue-in-cheek. But this would obviously not be within the spirit of "lowest score." Any reasonable person would include the aggregation of points regardless of the number of times the score rolled over...
No, I was being serious.
Make the score counter overflow to zero. If it is zero, it is truly zero. It doesn't have to make sense.
The problem is, even after PlayerScore resets, TopScore remains being high, because the game updates TopScore each frame. Even if at the end you get 0000000 (yes, there's 7 digits, but highest digit is masked by space when it's zero), after returning to title screen you'll see 9999950 or whatever score you had before overflow. That doesn't count as "truly zero"!
Here's example movie:
http://shedevr.org.ru/temp/sound/smb-score.fm2
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Kuwaga wrote:
I don't think TASing becomes more fun if it's necessary to beat a game.
I think it's more about using complex algorithms for calculating f.e. speeds (so that it's hard/impossible to find the absolutely fastest solution) and to have lots of abusable glitches (that still can be explained somehow, but require frame-perfect input to be executed or RAM-watching to be abused in efficient ways) or game mechanics that can be abused by TASing such as cancel-able lag after attacks.
Also, if the main character has different forms or other restrictions on using particular moves, the TAS will get more diverse and thus more entertaining to watch and create.
So the best example of the game you're talking about is Super Metroid. But such game would be impossible for TAS-newbies to... oh, I think I misunderstood the purpose of the topic. I thought we were talking about a game that would be easy to TAS even for inexperienced players. My apologies.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Flash would be suitable even for SNES-like tile-based games (after all there's Flixel, although you might want to deliberately add some abusable physics features).
Dromiceius wrote:
Taking that further, how about a platformer where the level is constructed during play, by falling tetris pieces controlled by the player?
There's the Flash game called Tuper Tario Tros that's just about that. It's not very fun though.
Unfortunately, creating fun TAS-related gameplay is the most difficult task among any other. I tried it and kinda failed (well, few guys completed all the puzzles and learned basic stuff like frame advance and luck manipulation, but they didn't acquire any motivation for practical TASing). Because TASing is hard. Speaking relatively, it would be much easier for a casual gamer to become hardcore gamer than for any hardcore gamer to become TASer.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Thanks for C64 trivia. I've heard of some games detecting copiers by checking available RAM size, but solving the task of recognizing data patterns just for the sake of copy protection... wow.
zaphod77 wrote:
But an emulator CAN make uninitialized ram random. It can make the initial state of the DMC random. And such an emulation will be more accurate than one that does not (it's behavior will be closer to real hardware). And on such an emulator, the game would become unTASable, without provisions to store the initial state of ALL memory and write only registers when recording starts. (just because they are write only on the real hardware doesn't stop the emulator itself form reading them) But then we have the possibility of people manipulating that initial state by hex editing the file. Is that legit?
Here's how I see it. Every TAS starts from savestate, which is embedded into emulator instead of keypresses file, so that noone can manipulate that state. Thus there's no difference if emulator simulates random state of RAM/registers/etc at the moment of opening ROM file, or it doesn't. It still has to "load" the clean savestate after opening movie file. That seems quite legit if you ask me.
Advanced accuracy of emulation has nothing to do with the problem (problem of not being able to repeat TAS session on real hardware by feeding it with just keypresses file). I guess to solve the problem you have to be omnipotent entity - to control the state of real console and load "clean state" at will.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Awesome twist at the end! Although that auto-hold feature seems way too artificial. Answering Yes to "Did you like it" and No to "Should this movie be published".
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Admins' jokes aside, I'd like to latecomment.
zaphod77 wrote:
The theory of a TAS is that it should be possible to play back on real hardware.
...only if this hardware is capable of actually "playing back" (as in: being deterministic). This is closer to the real definition. But it sounds too long so it's gonna abridged anyway.
The flaw of current TASing lies in our method of storing session information in a keypresses file. If only every game had ingame replay mechanism, we wouldn't need all these imperfect emulators. Well, dreams.
Input file is only quick-and-dirty solution that was used in 2003, but didn't evolve too much. Does it have to evolve? It seems Tasvideos is fine with it. Although, honestly, from higher perspective, our "art" is similar to composing music with those "automated mario" levels. It's still great, but there will always be people who want it to be "more realistic"/less artificial. So I really hope there will be a day when consoles will have built-in recording mechanism, and then maybe some tools like hardware-powered quicksaves.
TASing as it is now - is still kinda proof of concept. It already highlighted some undexplored sides of human psychology (e.g. it appears that human mind is almost 100% capable of percepting time as full-fledged dimension, while still creating art from anything), but I beleive it can be much more.
zaphod77 wrote:
The fact that the DMCs registers are effectively random to start off with means the cpu stolen when it is first activated is unpredictable.
This makes it a source of entropy NOT CONTROLLED BY THE PLAYER.
Since the game has a source of entropy not depend on input from the player in any way, this INVALIDATES ANY TAS of said game.
This indeed undermines the concept of "keypresses files". At least this makes "frame-whoring" laughable. But this doesn't invalidate the concept of tool-assistance. And superplay.
zaphod77 wrote:
Any NES emulator that was truly accurate would emulate this behavior after all, and thus any attempted TAS of a game that does this would desynch. The fact that it doesn't means that the emulator is not accurate
What are you talking about? "truly accurate"? There cannot be truly accurate NES emulator. It's not even discussed among emudevs. For example, how can you emulate or simulate bus conflicts? These are common on old hardware, although emulators ignore those possibilities.
zaphod77 wrote:
The state of memory after power loss is RANDOM.
And this is the least problem. Even on NES majority of games DO clear RAM after power up. As for older consoles, it's common practice.
zaphod77 wrote:
Also a game could conceivably uses uninitialized RAM to get the first seed. This would cause the same problem again. In fact, games for certain other 8 bit systems count of the fact that the state of RAM is random when the system is powered on, and will not work al all if it's not!
Uh, can you provide real names of these games? I'm really interested. Because every RNG in NES games I checked didn't use random state of RAM, instead it initialized random seed by fixed value (even though this seed was previously zeroed by another subroutine at the powerup).
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
KNJZJ
In Bucky O'Hare this is the first password you get for completing Green Planet without any powerups.
It think it's been about 12 years since it stuck in my memory for no reason.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
IMO both music choices are good (maybe SSH is better because of lack of lyrics), I also think speedmetal is the only viable soundtrack for such type of videos.
But the lack of music sync is the biggest downside, it made the video feel less emphasizing than old promotional video. While old "God playing" video had some message in it, the new video is something like a kaleidoscope of random cool stuff + some pathos words at the beginning, they sound unrelated to the whole movie.
Still the video is good, but I just liked the old promo video more.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Oh, finally some replies, huh... -_-
alden wrote:
This sounded cool so I tried it out but couldn't get past the first level... probably just because I suck at video games. Are you just supposed to kill all the enemy tanks? Or something else?
Yeah, just kill all the tanks and also take that star up there. But some next levels will contain much less obvious subtasks, so I dunno how you're gonna like it.
juef wrote:
Sorry if I haven't replied earlier - I tried this and it is awesome! Quite a nice hack you've done there. I didn't get far so far (!), but I'm trying to respect the 'no savestate rule'.
Well, maybe I'm wrong, but from my experience I'm convinced that to be TASer one must be really hardcore nerd. Although I guess at some point using savestates is inevitable.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Hey guys. Since last year I'm not very prolific at TASes, but this year I was working on somewhat related thingy.
Binary City
It's a ROM hack which could be useful for people who wish to learn TASing. It doesn't directly show "how to TAS" (that's what video tutorials are for), but instead it's supposed to develop TAS-oriented thinking.
This is not a trivial task, so I'm not sure I did it right. So I hope to receive comments from everyone who feels he has mastered TASing enough to judge the game.
Here's the hack page on Romhacking.net: http://romhacking.net/hacks/569/If you want extra materials like NSF music from the game, you can also visit my own page (sorry, russian text only): http://shedevr.org.ru/cgi-bin/parse.cgi?id=BinaryCity
Here's cool but uninformative trailer: http://www.youtube.com/watch?v=fZe7q6Ki42gDon't expect the game to be THAT fun though. TASing is hard, after all.
Basically the hack is applying Binary Land's idea to action game Battle City. You're controlling 2 tanks by 1 gamepad, the goal of each level is to destroy all enemy tanks.
More important, each level slightly changes the rules, forcing player to:
* optimize movements
* optimize object positions
* abuse game engine
* discard solutions that were eligible before
* use solutions which previously led to losing
* manage time used for each operation
* manage 2 lifestocks
* make decisions based on lack of visual information
* manipulate enemies
All this can be done without savestates or other tools. In fact, using savestates will ruin the learning curve. So try not to use them as much as you can!
But this only applies to first part of the game. That's what I'd call "TASing theory", abstract experience.
Then at the end of the game there's also a bit of practice (Chapter 6):
* using several savestate slots
* manipulating luck
* using slowdown
* understanding frame advance
* managing several counters to find safe periods for actions
* frame-bitching to death
* abusing global game rule
This is it. I know I should have taken more popular game like SMB, but SMB just didn't motivate me enough.
Hope you'll like the game, and maybe someone finds it useful.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
The beginning was promising enough to watch about 5-7 minutes of this. But then I had to hold Turbo pretty much all the time. Your run is well-executed, but the game's just too simplistic and repetitive (also level design could be MUCH more creative). If the movie were twice shorter, I think I'd vote Yes, but now I'm voting Meh.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
I wonder what exactly happened in September 2008. Was someone brainwashed?
Sorry if this sounds rude, but hearing nazi ideas from the person I once admired, I'm feeling betrayed.
...
What the hell, Bisqwit? I thought that religion and critical thinking were compatible.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
That sudden Lavos shell appearance is startling indeed. Overall this movie has brought so many questions that I hope the submission won't be accepted until author adds more info. :) Well, anyway, voting Yes in advance.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Oh, at last there's an easy-to-follow movie at Workbench! (well, maybe that's because I actually played the game, although didn't like it as much as first Another World) Quite enjoyable run. Voting Yes.