HOW DO THEY DO THIS?.....
Anyone ever play the game for super nintendo "Mario Allstars"? If so, i have a question about how they did some things.
1. How do they have a huge scrolling background behind the main playing field. I know it couldn''t have been a big bitmap, because that would take up too much memory. Did they use tiles, or something else.
2. (this is a general Mario Bros. question not specifically for Mario Allstars...) How do they test for collisions between each of the enemies (i.e., when they bump into each other and stuff). Because there are so many enemies in a level, they cant possibly test for each enemy collision.
Thanks.
1. well, I''ve never played the game, but most of those games used tile engines.
2. they create an array for all of the enemies and just use a for() loop to test all of them at once.
JoeMont001@aol.com www.polarisoft.n3.net
2. they create an array for all of the enemies and just use a for() loop to test all of them at once.
JoeMont001@aol.com www.polarisoft.n3.net
My HomepageSome shoot to kill, others shoot to mame. I say clear the chamber and let the lord decide. - Reno 911
Well, some enemies can be ruled out. And collision detection (using bounding boxes) is pretty fast anyway.
lntakitopi@aol.com - http://www.geocities.com/guanajam
lntakitopi@aol.com - http://www.geocities.com/guanajam
Or... you could always determine which enemies are visible (on the screen, easy bounding box checks) and perform bounding box collision tests on them, or per-pixel collisions on them if you wanted to be a little fancier (via a true bitmap, which is monochrome and literally an array of bits), though it would be slower, and those games didn''t use that technique.
-----------------------------1. "Diplomacy is the art of saying 'Nice doggie!'... till you can find a rock." 2. "Always remember you're unique, just like everyone else." 3. "If we don't succeed, we run the risk of failure."-Dan Quayle4. If life gives you sour grapes, squash them and make wine!
Ah, remembering the action replay days again...
In mario (the old nes version anyway), there is a maximum of 5 enemies on screen. If there are less than 5, the game checks if an enemy should be on screen (in the viewport). You can save these 5 enemies in a struct like this:
The scrolling background can be a 320x200 bitmap, that will repeat itself.
"Now you will see time life music commercials for the rest of your life, no forever! Bwahaha!"
"Nooooooooo!!!!!!!!!!"
Sludge Software
www.sludgesoft.com
Developing a secret of mana style role-playing-game
In mario (the old nes version anyway), there is a maximum of 5 enemies on screen. If there are less than 5, the game checks if an enemy should be on screen (in the viewport). You can save these 5 enemies in a struct like this:
typedef struct{ unsigned char enemytype; unsigned short x,y; unsigned char aipattern; unsigned char *pixeldata;}ENEMY;
The scrolling background can be a 320x200 bitmap, that will repeat itself.
"Now you will see time life music commercials for the rest of your life, no forever! Bwahaha!"
"Nooooooooo!!!!!!!!!!"
Sludge Software
www.sludgesoft.com
Developing a secret of mana style role-playing-game
Sludge Softwarewww.sludgesoft.comDeveloping a secret of mana style role-playing-game
Hi all.
I am afraid I don''t know the game, but I can talk a bit about collision detection.
In most games hardware, and I think this is also the case in the super nintendo, the collision detection is harware assisted. I don''t know how it works on the SNES, but in the Commodore 64 there are 2 bits assigned to each sprite. One of those bits is set on all of the sprites for which a pixel collision (not enclosing rectangle) with another sprite has been detected, and the other bit is set for all sprites for which a pixel collision (not enclosing rectangle) with the background has been detected. Those bits are refreshed as each frame is drawn on the display.
So, to speed things up you only test for collision those sprites that have the apropiate bit set.
Topgoro
;You are not a real programmer until you start all your sentences with a semicolon
I am afraid I don''t know the game, but I can talk a bit about collision detection.
In most games hardware, and I think this is also the case in the super nintendo, the collision detection is harware assisted. I don''t know how it works on the SNES, but in the Commodore 64 there are 2 bits assigned to each sprite. One of those bits is set on all of the sprites for which a pixel collision (not enclosing rectangle) with another sprite has been detected, and the other bit is set for all sprites for which a pixel collision (not enclosing rectangle) with the background has been detected. Those bits are refreshed as each frame is drawn on the display.
So, to speed things up you only test for collision those sprites that have the apropiate bit set.
Topgoro
;You are not a real programmer until you start all your sentences with a semicolon
We emphasize "gotoless" programming in this company, so constructs like "goto hell" are strictly forbidden.
The SNES has about 5 hardware assisted background layers, and one sprite layer. I know this because if u download the ZSNES emulator, play a game, and press keys 1-5, they turn off the corresponding background layer. Pressing 6 toggles the sprite layer...cool. (helps in games where a layer of fog is degrading the view..hehe).
I guess the SNES had a blitlist for each background layer, in which the SNES video chip would copy the blits straight from the Cartridges ROM onto the backbuffer.
------------------------------------------------
DWOD Sonic = 0;
DGOD Mario = 65535;
DWORD GetRulerDomination()
{
DWORD Loser = GetLoser();
if(Loser == Sonic)
{
return Mario;
}
else
{
DebugOut("Compile Error!");
return Mario;
}
}
------------------------------------------------
I guess the SNES had a blitlist for each background layer, in which the SNES video chip would copy the blits straight from the Cartridges ROM onto the backbuffer.
------------------------------------------------
DWOD Sonic = 0;
DGOD Mario = 65535;
DWORD GetRulerDomination()
{
DWORD Loser = GetLoser();
if(Loser == Sonic)
{
return Mario;
}
else
{
DebugOut("Compile Error!");
return Mario;
}
}
------------------------------------------------
Downloads: ZeroOne Realm
September 11, 2000 01:56 AM
The SNES uses multiple tilebased hardware backgrounds(Up to four). The backgrounds, and the individulal tile graphics (usually 4 or 16 color planar, and very rarely 256 color planar) don''t take alot of the video memory (it''s a difficult task to use all of the SNES''s VRAM).
The sprite collision detection is handled in software. The 128 sprites the SNES can handle are placed by the x,y position, and range only to two times the width of the screen. The relativly uneventful SNES game loop has more than enough time calculate each of the spites against each other, usually as they are updated. Unless, of course, you try to use all 128 at once.
The sprite collision detection is handled in software. The 128 sprites the SNES can handle are placed by the x,y position, and range only to two times the width of the screen. The relativly uneventful SNES game loop has more than enough time calculate each of the spites against each other, usually as they are updated. Unless, of course, you try to use all 128 at once.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement