Posts for Dwedit

Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Technically, you already CAN do SMS rerecording by using VisualBoyAdvance in conjunction with SMSAdvance (SMS emulator for GBA).
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Shining Force 2 has counterattacks, if that game could be manipulated the same way, then the enemies would become suicidal.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
The sound is awful, and sounds nothing like the original game.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Which would save more time? The pipe glitch or the bubble glitch? Even though the pipe glitch works only on about 33% of the levels, it's still useful.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
I'm pretty sure this run would have gone to gruefood anyway regardless of whether the emulation bug was discovered or not.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
I haven't counted the number of levels which can be solved with the pipe bug in a correctly behaving emulator, but I'd estimate that still at least 33% of the levels that can be finished that way.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Dizzy the adventurer has one of the worst music engines of any NES game. It introduces a nasty 60Hz noise because the channels are updated every frame regardless of whether they need it or not, and every time you update the channel, you restart the waveform. Codemasters would later fix their music engine. It sounds significantly better in JNes, which does not correctly emulate the NES's audio and does not produce the artifacts.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
The more user-friendly version of Mencoder (not memcoder) is FFDSHOW. You might already have it if you've ever downloaded a codecs pack.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Wow, watch these characters fly around at super high speeds! This is what TAS's are all about.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
For the ram mirroring issues, back compatibility isn't that important. For the other small changes to the GB emulator that have been made since, that may be an issue. I'd like to just see a new version get out the door though. The sooner the new version gets out, the sooner new movies won't depend on an old buggy emulator. If you really need back compatibility, leave the old version up for download next to it with a caption like "May be necessary to play older files".
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
I think Kirby WAS named after the vacuum cleaner.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
This isn't your average small emulation quirk, this is an earth-shattering, showstopping emulation bug that never should have seen the light of day. Failing to get the basic GB memory map correct is completely inexcusable for any emulator. Every GB emulator other than old VBA has the basic GB memory map correct. It's not "my emulator" at all, I don't mean to take credit for any of it. I just identified that the run depended on an emulation bug, then I fixed that bug. The original VBA developers also independently caught and fixed the same bug a while ago too, but their changes just stayed in CVS. The people who forked VBA based their forks off the buggy 'latest official versions' that did not incorporate the bug fix. Unfortunately, vba-rerecording was one such fork. The real effects of the bug being resolved is that you don't get the exact same effects of falling through the floor. In some levels, you get a bunch of air in both subbasements to fall through until you can exit the level early. In other levels you fall to the bottom where solid tiles block your progress, and there is a wall to your right. Still in other levels, you get a floor at the bottom, but can still move far enough to the right to fall through it and exit the level that way. The main difference is that you no longer get the big wall of bricks consistently appearing in every level to use to get to the bottom.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Bug was already fixed in CVS version and the very very newest forks, still present in everything else.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Fixed Version of VBA (NOT a re-recording version!)
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
I was wrong about two things in my last post. First, the level is not stored in the SRAM area, it is stored in the RAM area. Second, correctly emulating Echo RAM means that there are far fewer levels in which you can do the through the ground cheat to beat the level. This really does invalidate the TAS completely. (Pumpkin Zone 1 does happen to be one of the levels in which you can cheat through.) Edit: And Here is the major bombshell: Fixed version of VBA (not a re-recording version) Because far fewer levels are now clearable using that technique, the TAS needs to be completely redone from scratch.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
http://www.work.de/nocash/pandocs.htm#memorymap Echo RAM is a mirror of regular RAM. Meaning if you change the byte at address E123, the same byte shows up at C123, and vice versa. VBA was treating Echo Ram as a separate memory that does not mirror main memory.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Without knowing anything about what's up, I'm guessing it's due to incorrect emulation of Echo Ram. I've already proposed a fix in the sticky topic.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
EDIT: FIXED MISTAKE in switch replacement gbCopyMemory function is not echo-ram aware. Needs a check to see if the source address is in Echo Ram area, then subtract 0x2000 from the source address. We don't need to validate the destination address, since it only DMAs to either OAM or VRAM. Replace it with:
void gbCopyMemory(u16 d, u16 s, int count)
{
	if (s>=0xE000 && s<0xFE00)
	{
		s-=0x2000;
	}
	while(count) 
	{
		gbMemoryMap[d>>12][d & 0x0fff] = gbMemoryMap[s>>12][s & 0x0fff];
		s++;
		d++;
		count--;
	}
}
gbWriteMemory needs this change: Replace this:
	if(address < 0xfe00)
	{
		gbMemoryMap[address>>12][address & 0x0fff] = value;
		return;
	}
with this:
	if (address<0xE000)
	{
		gbMemoryMap[address>>12][address & 0x0fff] = value;
		return;
	}
	if(address < 0xfe00) 
	{
		gbMemoryMap[(address-0x2000)>>12][address & 0x0fff] = value;
		return;
	}
gbReadOpcode is just really bad code, it has a major bug in that the switch statement doesn't do anything! Replace the switch:
	switch(address & 0xf000) 
with this:
	switch((address>>12) & 0x000f) 
(this was edited) Then right before the last return add this:
	if (address>=0xE000 && address<0xFE00)
	{
		return gbMemoryMap[(address-0x2000)>>12][address & 0x0fff];
	}
gbReadMemory needs this right before the last return:
	if (address>=0xE000 && address<0xFE00)
	{
		return gbMemoryMap[(address-0x2000)>>12][address & 0x0fff];
	}
This should fix the Echo Ram problem which plagued the SML2 run.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Edit: Revising this post... VisualBoyAdvance has many major bugs regarding Echo Ram (E000-FDFF) on the GB/GBC. It treats the echo ram as a separate block of memory instead of a mirror of (C000-DDFF). I'll be examining the VBA source code looking for all the instances that cause it to not behave correctly. I can't build the rerecording version on my system however.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
This TAS is invalid. It relies on a bug in VisualBoyAdvance. (and this bug actually slows you down!) Allow me to explain what's going on after you go downward through the bottom of the screen. The normal level is stored in memory at the SRAM area. The first 'basement' area is RAM at C000-DFFF, which happens to be filled with blank tiles for the area you fall through. The second 'subbasement' area is Echo Ram E000-FDFF. Finally, the first row of garbage is the OAM area (FE00-FFFF) (sprite table area in memory), and the exact behavior of each tile is determined entirely by which sprite of Mario is being displayed. (So that's why you'd see coins which behave continuously, since mario is touching a coin, then the game overwrites the tile with mario's sprites, so you get the coin once each frame...) The second row of garbage blocks is the IO area. Subsequent rows of garbage blocks are ROM addresses. The Echo Ram area (E000-FDFF) is a mirror of C000-DDFF. However, due to a bug in VisualBoyAdvance, it does not treat memory addresses E000-FDFF as a mirror of C000-DDFF, and instead treats them as unique memory having their own values. Initially, these values are zero-filled. You can see this in that you get a ton of destructible bricks for the second subbasement. But the bricks aren't supposed to exist at all! In a properly behaving emulator, the bricks will instead be the same tiles you just fell through. Fortunately, the block that skips you to the next level is either in the OAM or IO region, haven't exactly figured out which tile number does it. This should behave consistently among emulators, assuming of course the game is reading the tiles during VBlank.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
Watching this one, I'm just wondering where the memory block containing those destroyable bricks is, and how exactly the game initializes that memory. I'm wondering if the bricks are indeed initialized by the game filling up the memory, the GB Bios doing it, or the emulator filling it up. I think the memory block containing all that stuff may be in the SRAM area, and the bottom area with the Next Level tile might even be the Z80 stack! I bet predefined save games would mess all that stuff up. Or worse yet, Mario spin jumps on bricks that are actually your save data, and destroys it! Voted Meh, too much walking back to pumpkin zone.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
The SNES9x movie of Illusion of Gaia had really slow scenes walking from area to area, while ZSnes ran those at normal speed. What does hardware do?
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
FF6 Advance (aside from the music) wasn't that bad. FF4 on the other hand was that bad. Damn you TOSE!
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
LOL Micronics Those talentless asshats couldn't program a game decently under any circumstances. And I mean any circumstances. Use your imagination to think of any possible circumstances which could possibly motivate the development team to produce something of quality. And the answer is still No quality under any circumstances! Of course, they still lose the Worst Developer award to Active Enterprises, Color Dreams, Sachen, and several pirate companies. Geez, nobody's that bad, not even Micronics.
Dwedit
He/Him
Experienced Forum User
Joined: 3/24/2006
Posts: 692
Location: Chicago
I've watched the 120 Stars WIP video too much, and I guess that spoiled this one for me. This one was just boring, and too similar to the other movie. I turned it off halfway through the ghost level.