[MARIO] Mario
Moderator: MaxCoderz Staff
[MARIO] Mario
Take a look:
More realistic framerates on this AVI video (needs DivX decoder):
http://www.maxcoderz.net/mario/mario1.avi
(Framerates on VTI and especially calc are of course much higher)
Do you like it? My first goal is Mario Bros 1 functionality. As you can see, basic functionality and gameplay is there!!
Work to do for SMB1'ish functionality:
- Edge detection for Koopa Troopa
- the Fire Flower upgrade and the Starman
- Moving platforms
- Pipe warp
- Level system
- More monsters
- multi-object monsters (master-slave relationships)
I'll be a happy man if i could achieve that.
EDIT: If you look at the shell->questionbox collision detection, you'll see a bug: the qbox doesnt always open. That bug is very recent...
EDIT2: I almost forgot: Thanks DWedit for your wonderfull 8-way scrolling routine! I used my own scrolling routine earlier, but yours seemed to be faster, so thats what i implemented
More realistic framerates on this AVI video (needs DivX decoder):
http://www.maxcoderz.net/mario/mario1.avi
(Framerates on VTI and especially calc are of course much higher)
Do you like it? My first goal is Mario Bros 1 functionality. As you can see, basic functionality and gameplay is there!!
Work to do for SMB1'ish functionality:
- Edge detection for Koopa Troopa
- the Fire Flower upgrade and the Starman
- Moving platforms
- Pipe warp
- Level system
- More monsters
- multi-object monsters (master-slave relationships)
I'll be a happy man if i could achieve that.
EDIT: If you look at the shell->questionbox collision detection, you'll see a bug: the qbox doesnt always open. That bug is very recent...
EDIT2: I almost forgot: Thanks DWedit for your wonderfull 8-way scrolling routine! I used my own scrolling routine earlier, but yours seemed to be faster, so thats what i implemented
Last edited by Duck on Sun 16 Jan, 2005 6:10 pm, edited 3 times in total.
I'm not sure yet. Because this will be an original Mario game, it would be nice to get unique functionality (special powers for mario, enemies) and thus a unique levelset.So whats your goal, replicating the original games or external levels or both
The original SMB1 levels were compressed in a very efficient way. It only took a few bytes to describe a level. These levels are extremely redundant so I would need to study this compression method.
The SMB3 sprites are my source of inspiration. Some tiles and one sprite (the Magic Mushroom) just looked so good, i re-used them. I'll ask permission to Sam and Bill Nagel before release.kv83 wrote:at the moment it does look more like SMB3 than 1
Yes, this is what I hinted at earlier. SMB1 functionality is a start. Without the SMB1 features, everyone will complain its not a complete mario After that, I may implement more. SMB3 features or original features. And it still runs very smooth on hardware. Current code size is 4.2k. The rest is 8k of sprites, tilemaps and extra buffers for both of these.tr1p1ea wrote: Whoa! (this is waht you were hinting at earlier?!). Will you be staying at SMB1 functionality? ... or will you go for SMB3 ? Also it looks like it will run extremely smooth on hardware
I alerady thought you would like it Kozak Your paratrooper game was also a nice surprise back then!Kozak wrote:I can't believe you've already done so much and kept it hidden! Nice suprise for the new year.
- GuillaumeH
- Regular Member
- Posts: 143
- Joined: Fri 17 Dec, 2004 8:30 pm
- Contact:
Yes, variable size maps. Camera position can simply be changed by changing paramters (cameraX) and (cameraY). So shifting 1 bit to right is be done by doing
Code: Select all
ld hl,cameraX
inc (hl)
Well, that functionality is not implemented by 1 piece of code, but by many more general functionalities. For example, a routine for object decision, a routine for object speed update, a routine for moving and tile-collision checking, and a routine for mario<->object collisions. All of these have a piece of the [/quote]p.s. i might ask you for youre turtle shell routine (how you make it move around and bounce off the blocks and such)!
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
Wait, hold on. Your shifting the screen just by inc cameraX. So then is the entire buffer for the map redrawn or is just modified(intelligently), becuase that looks like pretty good speed to be redrawn every frame.
Another question, are the tiles Animated (? box, coins) or are the objects.
Man, I'm even more impressed now that i'm seeing it agian, how about another screen shot or better yet a demo of the game, beta testing is always a good idea .
Another question, are the tiles Animated (? box, coins) or are the objects.
Man, I'm even more impressed now that i'm seeing it agian, how about another screen shot or better yet a demo of the game, beta testing is always a good idea .
Yes, you guessed correct, the screen is completely redrawn every frame. Animation of tiles (indeed the coins and boxes) is 'free': done by simply changing the tilemap.
As soon as there's more functionality, there'll be more eyecandy. I may make an AVI with higher FPS, because these gifs are pretty bad.
As soon as there's more functionality, there'll be more eyecandy. I may make an AVI with higher FPS, because these gifs are pretty bad.
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
Wow fast reply. I guess I've been playing with greyscale to long, I foregot how fast cpu can be with just black and white, done very well might I add.
I've been working 8way mapper myself, the bw version Im making only shifts the screen twice no matter how many bits need to be shifted by using:
RR (hl)
RL (hl)
RLD
RRD
In theory, It should run very fast, though it's not even running yet at all.
Is this a method similar to what your using or do you have something else going.
Sorry for so many Questions on your code, but Looks way to awesome not to ask how your doing it.
I've been working 8way mapper myself, the bw version Im making only shifts the screen twice no matter how many bits need to be shifted by using:
RR (hl)
RL (hl)
RLD
RRD
In theory, It should run very fast, though it's not even running yet at all.
Is this a method similar to what your using or do you have something else going.
Sorry for so many Questions on your code, but Looks way to awesome not to ask how your doing it.
I think you should switch to Crashman's tilemap renderer. It's what my tilemap routine was attemping to be, and crashman's runs about twice as fast as mine.
The only issue is that you need page aligned graphmem and page aligned sprite buffers, the 'tilemap' in memory is actually the high byte of each tile (which limits the total # of tiles to 32), and the tilemap and graphmem are vertical instead of horizontal.
The only issue is that you need page aligned graphmem and page aligned sprite buffers, the 'tilemap' in memory is actually the high byte of each tile (which limits the total # of tiles to 32), and the tilemap and graphmem are vertical instead of horizontal.
You know your hexadecimal output routine is broken when it displays the character 'G'.