thoughts/questions on the spazer+plasma combo

bob-e:

registered on 2004-12-18 06:14:47 pm.

view all posts by bob-e

bob-e

2005-02-21 03:03:42 pm

from what i understand, the reason the game crashes when a spazer+plasma combo is used is because it generates to many sprites and fills the ram, is this correct? why does the size of the room affect the functionality of the spazer+plasma combo? if the reason for the game crashing is lack of ram, then would it be possible to make an emulator with enough emulated ram to allow you to normally fire a spazer+plasma combo in any room?

Thread title:

Skreemaster:

registered on 2004-05-25 10:53:03 am.

Location: Cambridge, UK

view all posts by Skreemaster

Skreemaster

2005-02-21 03:25:57 pm

I'll be back. Maybe...

I don't think it is that, personally. The murder beam creates vast numbers of sprites, as does the Plasma Beam v. Crocomire, but these don't crash the game; they just cause other sprites to disappear. I think it is because the game is trying to find a sprite that doesn't exist that it crashes, though why it works in some circumstances and not others is beyond me.

Kejardon:

registered on 2004-12-07 07:21:36 pm.

Gender: male

view all posts by Kejardon

Kejardon

2005-02-21 04:19:56 pm

Embarrasing Fact: Power suit made by lowest bidder

The game crashes because the space/time beam fills a lot of the ram with a bunch of random data from the rom. It's not at all surprising that it crashes the game, what *is* surprising is that it *won't* crash the game under certain circumstances.
When you're in a large enough room, you'll be below the part of the room that gets filled up with random junk. If the room is too small, you'll be somewhere inside that junk, and you'll need to know a path to get out of it (or more likely, Samus comes in contact with a glitched block and the game crashes)

Roxinos:

registered on 2004-12-27 03:39:19 pm.

Location: Miami, FL

view all posts by Roxinos

Roxinos

2005-02-21 08:24:31 pm

*points to Kej* What he said...

But if you do, do it in a room that is too small and you get mixed in with the jumbled crap and the game doesn't crash...not only the room you fire the space/time beam gets jumbled with all the nonsense...I managed to get out of a room once....the next room was just as bad...but why don't the graphics get messed up...like the sprites on screen...or when you do manage to preform the space/time beam glitch in the proper room...why is no other sprites..images...whatever you want to call it...messed up other then the menu bar at the top of the screen...and an even harder question that I don't think you can answer...unless you programmed the game...is why does the reset glitch occur in the first place...why are all the flags set to zero when doing the glitch...*grumbles* I've been rambling...

Kejardon:

registered on 2004-12-07 07:21:36 pm.

Gender: male

view all posts by Kejardon

Kejardon

2005-02-21 09:05:49 pm

Embarrasing Fact: Power suit made by lowest bidder

The next room should be fine. You might wind up inside a wall or something, but the room itself should be loaded directly from rom and untouched by the space/time beam, unless you fired it in the new room as well.
The current blocks on screen don't reflect the corruption because there isn't any constantly-running code to update on-screen block graphics if they're changed. The graphics are created when a block moves on-screen, and then moved around as the screen moves.
Don't know how the glitch manages to mess the status bar up, and I don't know directly why the glitch sets almost all the flags to 0, but not even one of the Super Metroid programmers would probably be able to tell you how the glitch works. It's pretty much a random fluke that it does what it does.

I've considered looking into the code, but there'll be a mess of things doing stuff they aren't supposed to be doing, and I wouldn't be able to say 'This is what it's supposed to do, how is this code doing it?'. I understand most of the basics about assembly, but figuring out what a serious bug like this is doing is far beyond me.

The next room should be fine. You might wind up inside a wall or something, but the room itself should be loaded directly from rom and untouched by the space/time beam, unless you fired it in the new room as well.
The current blocks on screen don't reflect the corruption because there isn't any constantly-running code to update on-screen block graphics if they're changed. The graphics are created when a block moves on-screen, and then moved around as the screen moves.
Don't know how the glitch manages to mess the status bar up, and I don't know directly why the glitch sets almost all the flags to 0, but not even one of the Super Metroid programmers would probably be able to tell you how the glitch works. It's pretty much a random fluke that it does what it does.

I've considered looking into the code, but there'll be a mess of things doing stuff they aren't supposed to be doing, and I wouldn't be able to say 'This is what it's supposed to do, how is this code doing it?'. I understand most of the basics about assembly, but figuring out what a serious bug like this is doing is far beyond me.

Roxinos:

registered on 2004-12-27 03:39:19 pm.

Location: Miami, FL

view all posts by Roxinos

Roxinos

2005-02-22 07:18:19 pm

*shrugs* That certainly does explain some...