Amiga Super Mario Bros. ?

[Retro1234]

I just always wonder why people go on about tiles and of course the amiga just like any games machine uses tiles.
Yes any parallax on Amiga seems week from my laymans point of view either use the basic dual playfield modes or raw power and redraw everthing when needed with something like the vampire that should work.

[idrougge]

http://www.msx.org/forum/development...ario-world-msx
MSX users are successfully porting Super Mario World from the SNES to a much lesser 8-bit computers. The number of MSX users are but a fraction of Amiga users, yet you lot are making a slow-as-molasses clone of the first 8-bit game in Backbone.

But never mind me, go on with your efforts, while the MSX people run circles around you.

[ReadOnlyCat]

Originally Posted by Boo Boo

I just always wonder why people go on about tiles and of course the amiga just like any games machine uses tiles.
Yes any parallax on Amiga seems week from my laymans point of view either use the basic dual playfield modes or raw power and redraw everthing when needed with something like the vampire that should work.

It always seems simpler when you don't know the constraints.
It's up to you to not be a layman anymore, ignorance is a temporary thing and you just need to learn how to make a DMA budget to go from:
"any parallax on Amiga seems weak [...] either use dual playfield or raw power"
to:
"ah, crap, forget it, dual playfield has eaten half of the blitter cycles and there's not enough to blit all bobs and the third parallax layer, we need to find a very smart technique or we will not be able to make it".

I never said it was not possible, just that it is hard. Tile based graphic modes provide an enormous advantage. If you do not understand why, you should start your quest toward un-layman-ness with that.

[saimon69]

@idrougge

Any movement is better than a slow standstill death which else this platform seems to come to...

[Asman]

Originally Posted by oRBIT

I am still waiting for someone to make some kind of "framework" for porting NES-games to Amiga, that would have been cool.
But still a very difficult task:
1) The graphics on the NES works very different compared to the Amiga. It's bitplanes-based, yes, but the graphics are tilebased. The NES could animate the entire screen within just a few CPU-cycles, this would require lots of more work on the Amiga.
2) The CPU. How would you translate the 6502 to 68k? Manual conversion would take alot of time. There are conversiontools but the one I've seen still requires a disassembled ROM, not the ROM itself.
Perhaps somekind of JIT-"emulation" would do the trick. But at the same time you'd loose alot of speed, because something the 680x0 can do with a single instruction, might require a few more on the 6502. The 68k code generated would be very inefficient unless there are some clever optimizations builtin.

Anyway, a very interesting subject to discuss. Anyone with some bright ideas?

What do you expect from such "framework" ?

[ReadOnlyCat]

Originally Posted by idrougge

http://www.msx.org/forum/development...ario-world-msx
MSX users are successfully porting Super Mario World from the SNES to a much lesser 8-bit computers. The number of MSX users are but a fraction of Amiga users, yet you lot are making a slow-as-molasses clone of the first 8-bit game in Backbone.

But never mind me, go on with your efforts, while the MSX people run circles around you.

Everyone moves at their own speed. You may be capable of writing assembly or C but these kittens aren't (yet) and they try with something that does not scare them. There is nothing wrong with that.

Although I concur that Backbone is a dead end I would rather encourage people to try something, even if ill fated, rather than do nothing.
One cannot learn programming overnight nor game design but practice is essential for progress even if it's accompanied by failure. As long as one learns from their mistakes and is willing to listen to knowledgeable advice, nothing is impossible, it just takes time.

[idrougge]

Originally Posted by saimon69

@idrougge

Any movement is better than a slow standstill death which else this platform seems to come to...

My post was intended to demonstrate the slow standstill death of the Amiga scene. Making a "port" of Super Mario or Sonic so slow that it seems to run in an emulator is indeed a sign of what a standstill the Amiga has come to. It doesn't do the Amiga, Backbone or Mario any justice.

[Mrs Beanbag]

i read an article once about how to write a copper list that implemented a text-based screen mode (with copper controlling the blitter), which is basically a tile-based mode in 1 bitplane i guess, i don't know if it could be extended to 4 bitplanes and still be fast enough.

[idrougge]

If you need to blit, it's still not tile-based.

[Mrs Beanbag]

Originally Posted by idrougge

If you need to blit, it's still not tile-based.

well of course it doesn't actually modify the hardware... what do you want, magic?

it IS tile-based, though; the screen mode might not be tile-based, but there is a tile-based buffer that is rendered to the screen transparently in the background without hassling the CPU, and that's all we need, right?

[idrougge]

A real tile-based mode would work like a copperlist where each "screen" is 16x16 pixels. That way, you'd only have to update the copperlist to rearrange the screen, and the blitter would have to blit anything as long as you don't try to update the bitmap of any specific 16x16 "screen".

[ReadOnlyCat]

Originally Posted by idrougge

A real tile-based mode would work like a copperlist where each "screen" is 16x16 pixels. That way, you'd only have to update the copperlist to rearrange the screen, and the blitter would have to blit anything as long as you don't try to update the bitmap of any specific 16x16 "screen".

If I understand Mrs Beanbag correctly that is exactly what she was talking about.

The copperlist is essentially a WxH table of pre-baked blits and the only thing the programmer needs to do to modify which tile is displayed at a given (x,y) position on screen is to poke at the corresponding 16 bit word which selects the blit source and point it to a different place in the tile map.

Since all tiles have the same dimensions, the setup can be much reused and the copperlist probably consists only of sequences of (set-source, set-dest, set-size, wait-blitter) tuples.

This is a super neat technique.

Also, I am a bit surprised it can only handle one bitplane. With interleaved bitplanes, the bitplanes of each character would be blit(ted?) at once thus saving much setup time, especially for these small blits. It seems the blitter could probably do two bitplanes but I might be wrong.

[Mrs Beanbag]

Originally Posted by ReadOnlyCat

Also, I am a bit surprised it can only handle one bitplane. With interleaved bitplanes, the bitplanes of each character would be blit(ted?) at once thus saving much setup time, especially for these small blits. It seems the blitter could probably do two bitplanes but I might be wrong.

I don't know how many bitplanes it can handle, but the original code was for one bitplane (IIRC) because it was to simulate a "text mode", which is a monochrome problem (EDIT3: also it might have been hi-res). I would be surprised if 3 bitplanes were not possible, maybe even 4. Most Blitter registers could be set up at the beginning of the display, since all the tiles would be the same size, the only ones that need to change are source and destination addresses, plus final write to Bltsize for each blit. Interleaving the bitplanes would be sensible.

The copperlist itself could even be prepared by a small vbl interrupt routine, so the coder only need to see a 2D matrix of byte or word tile IDs, and it could effectively "NOP" tiles that didn't change since the last frame.

NES tiles are 8x8 though i think, but that is still possible, two tiles can be blit at once, not sure how that would affect the timing. Also i believe each tile can be flipped in X and Y directions and can have different colours.

EDIT: looking it up it's even better, i don't think it can flip tiles, but it can select only four different palettes of four colours for each 2x2 "block" of 8x8 tiles, so really we only have to blit 2 bitplanes, and if those two are both even planes, we can use the odd planes to "select" the palette, and use bitplane modulo to stretch it out so each bitplane row covers 16 scanlines in the image.

EDIT2: also the NES screen is only 256x240

[ReadOnlyCat]

Originally Posted by Mrs Beanbag

EDIT: looking it up it's even better, i don't think it can flip tiles, but it can select only four different palettes of four colours for each 2x2 "block" of 8x8 tiles, so really we only have to blit 2 bitplanes, and if those two are both even planes, we can use the odd planes to "select" the palette, and use bitplane modulo to stretch it out so each bitplane row covers 16 scanlines in the image.

EDIT2: also the NES screen is only 256x240

Yeah! Extra DMA slots. although aspect ratio might be an issue especially on NTSC monitors.

This last palette selection technique is brilliant.
Moreover NES games often tend to group tiles of the same palette together so with a good algorithm these palette planes would not have to be modified very often.

[Leffmann]

Originally Posted by Mrs Beanbag

i read an article once about how to write a copper list that implemented a text-based screen mode (with copper controlling the blitter), which is basically a tile-based mode in 1 bitplane i guess, i don't know if it could be extended to 4 bitplanes and still be fast enough.

Originally Posted by ReadOnlyCat

If I understand Mrs Beanbag correctly that is exactly what she was talking about.

The copperlist is essentially a WxH table of pre-baked blits and the only thing the programmer needs to do to modify which tile is displayed at a given (x,y) position on screen is to poke at the corresponding 16 bit word which selects the blit source and point it to a different place in the tile map.

Since all tiles have the same dimensions, the setup can be much reused and the copperlist probably consists only of sequences of (set-source, set-dest, set-size, wait-blitter) tuples.

This is a super neat technique.

Also, I am a bit surprised it can only handle one bitplane. With interleaved bitplanes, the bitplanes of each character would be blit(ted?) at once thus saving much setup time, especially for these small blits. It seems the blitter could probably do two bitplanes but I might be wrong.

I've written one of these, and it works fine. You can even have the Blitter do the updating of the Copper program every frame, so everything becomes fully automatic and you only have to touch the tile-map to change the screen.

You can have a 320*256 screen in 8 colors in 50 FPS, but you only have maybe 1-2 miliseconds worth of time left for game logic, so it's a neat way of doing things but not very efficient.

[Lonewolf10]

Originally Posted by idrougge

A real tile-based mode would work like a copperlist where each "screen" is 16x16 pixels. That way, you'd only have to update the copperlist to rearrange the screen, and the blitter would have to blit anything as long as you don't try to update the bitmap of any specific 16x16 "screen".

That's an interesting idea, but wouldn't that be a large copperlist that eat's up alot of DMA each frame?

[frank_b]

Originally Posted by ReadOnlyCat

Things like that simply cannot be done easily on the Amiga: reproducing the same visual result can require copying entire regions of the screen using the blitter and sometimes it is simply not fast enough for to do it under one frame. This issue surfaces at times during the "Conversion Capers" threads initiated by CodeTapper: even a C64 game can be really tough to port on the Amiga because of the advantages brought forth by cell-based graphic modes.

[ Show youtube player ] look at this main menu demo from the ST. The parallax affect is done via an animation over several frames. You could do this on the Amiga too. That's 50 fps and full overscan on the ST!

[ReadOnlyCat]

Originally Posted by Leffmann

I've written one of these, and it works fine. You can even have the Blitter do the updating of the Copper program every frame, so everything becomes fully automatic and you only have to touch the tile-map to change the screen.

You can have a 320*256 screen in 8 colors in 50 FPS, but you only have maybe 1-2 miliseconds worth of time left for game logic, so it's a neat way of doing things but not very efficient.

Cool!
Indeed, there must be precious little time if it is redrawing the whole tile set every frame. This said, 1ms of 68000 is worth many more of NES 6502.

I suppose there would be much more time available if there was a way for it to do partial updates, that would certainly make it less transparent since extra logic would have to be added to detect changed tiles but would probably be worth it.

Originally Posted by frank_b

[ Show youtube player ] look at this main menu demo from the ST. The parallax affect is done via an animation over several frames. You could do this on the Amiga too. That's 50 fps and full overscan on the ST!

Absolutely, there are tricks which allow to simulate tile animation.

And what they are doing in this ST demo is precisely a trick: I would bet a few coffees that they are using at least quadruple buffering here (possibly more but it is hard to guess with the horrible compression), taking advantage of the fact that the tiled texture repeats very frequently to simulate the fact that it scrolls.

This works well but takes a pretty hefty toll on the graphics budget given the amount of Chip RAM this requires. This said, for NES games this should not be too much of an issue.

[Amiga1992]

So, who's gonna try making SMB on the Amiga with the source code available and this neat tile trick?

[Retro1234]

Some off you may know I started work on my own version of Mario, I dont care about parallax etc If I want ill add ecs parallax for some turbo card like vampire or convert in to blitz AGA and add Dual playfield.

Mario is a very intresting test subject You have Maps you have collision you have enemy map collision and firinig and scrolling and warping - so in terms of learning this is probably one of the main reasons people choose mario.