Ex GBA dev like myself then? :D It was a very powerful 2d machine indeed.

I'm indeed an ex in too too many things.. :(
My GBA experience was limited to a very short time span (beginning of this century was a period of major change for me).
I can say it was my shortest experience.

The biggest problem indeed is the memory available.

The OCS A500 only has 512 kb of Chip RAM. :great

And even if you add the half meg RAM expansion and increase the total RAM to 1 MB, the amount of Chip RAM still stays at 512 kb. The expanded RAM is so called "Slow RAM" that cant be directly used by the special chips. This means that all "currently active" graphics, bitmaps, music and sound, have to fit into that 512 Kb Chip RAM.

---

If I would be making this game for A500 with Blitz (No no, I won't do it ), then I would go for a 8 + 8 dual playfield, so that all graphics could be 8 colors and use less RAM. Player 1 would use 4 sprite channels, and Player 2 would use the other 4. So player sprites could have a separate 16 colors apart from the 8+8. If enough sprites aren't available, then its 1 Player only. And because the soldiers are the most common enemy type, with lots of animation frames, I would probably try to make them with 4 colors only (3 + transparent), to save RAM and to make them faster to draw. So they would look like C64 sprites sort of, but still acceptable. Tanks and other stuff would probably get the same treatment, but only if RAM was real tight.

And there would be lots of loading brakes, and everything that wouldn't fit in would simply be axed. Levels would be totally redesigned and all vertical scrolling parts mostly removed. You could choose between sounds and music, but maybe not have both at the same time. So in other words: it might end up as an another "classic" A500 arcade conversion; an OK game but far from the arcade.

---

If you want an accurate "available memory" estimate, then we could calculate that:

320*200 bitmap in eight colors uses 24 kb. But we need a 640*200 for scrolling (using my fast but RAM hungery Blitz scroll method). So its 48 kb. And then I would use double buffering, so double again, to 96 kb.

That was just the front playfield bitmap. The back playfield needs the same amount, but without double buffering. So it only needs 48 kb.

So the 512K Chip RAM would be used like this:

144 kb = bitmaps
32 kb = back bitmap tiles ( 320*200 screen full of tiles, includes transparency cost)
32 kb = front bitmap tiles
100 kb = music and sound effects at same time
50 kb = reserve ram for random things
150 kb = Graphics

(Note - If 16 color bitmap is used instead of 8+8, then bitmaps would use 128 kb, but all gfx then need one more bitplane and parallax is impossible)

The game code itself and some other stuff can go to the expansion Slow RAM.

That is one theoretical "memory plan" for the A500 using the 8+8 dual playfield method.

I counted that 57 tank frames in 8 colors would fit into that 150 kb. But the 150 kb has to hold all the following:

1. Player frames in 16 colors. (is sprite, and I think sprites dont need the transparency cost like BOBs do)
2. Explosions and bullets and score displays etc in 8 colors
3. Enemies in 8 colors. (notice that the soldiers at least need both left and right versions)
4. All destroyable foreground objects like the houses in 8 colors

The stuff in 1. and 2. would be hold in Chip RAM at all times, so you can count the costs for those first. Also the game is full of those soldiers, so they too would be in Chip RAM for most of the time. And then the remaining memory is for the "other stuff" that can be held in Chip RAM at one time. And when more is stuff needed, then there needs to be a loading break.

Possibly a reasonably working level could be built with this plan, if the level is divided into small sections.

But, just to be sure, I say again that I'm not going to do this game. I have my hands full in another secret project. :)

...another secret project?

You are still working on this though, I hope? Megaman X on the Amiga?

Unfortunately no, the secret project is not Megaman X. That project has been "on ice" for some time now. Originally the project stalled because of the massive RAM consumption, needing a 2 MB machine just to support the bitmaps, and then I lost interest, and started doing multiple smaller game demos instead.

And although now my skills have improved, and I now have a RAM friendly solution to the "unlimited maps" scrolling problem, and so theoretically I could re-launch the Megaman project and make it run on an 1 MB A500 again.

And maybe I'll actually do it one day. But before that I'm going to finish the secret project that I'm talking about, which is actually another Street Fighter 2 demo, but this time with assets ripped from the SNES; with the aim of having 2 or 3 layers of parallax, all background animations, and 64 pixel sprites as fighters, running at a solid 50 FPS. But I call it a "secret", because I won't be releasing any demos or other info until I have some real gameplay in place.

And after that demo is ready and released, then I'll decide on which game to concentrate. Those two games are also real mad man projects: Street Fighter 2 and Megaman X...So maybe it's better not to get myself involved with Metal Slug as well. :)

Ok, gotcha ;)

You say "Street Fighter 2" and "Megaman X" are real mad man projects...

...but nothing in comparison to someone believing that a *decent* "Metal Slug" port is even possible on an Amiga (let alone an A500) :crazy :crazy :crazy

Again, I'll eat my shorts if this ever happens, promise (and will take videos)!!! :agree

I have just watched the video above, and I think an AGA machine with some fast ram could possibly do a slim lined version. The biggest concern for me is the speed of the game, and the amount of large sprites needed. The general player sprites would be fine as they aren't too big. It's the tanks, helicopters, and boats etc that would be difficult to do.

If you can get the "feel" of the game, with similar gfx and sfx then I think that could be considered a success!

It is not a Tile drawn game. You need to store the whole level map which uses 976kB in 4 bitplanes...
This of course would have to be split so i there would have to be stops for replacing the graphics in chip memory. I believe we could allocate 200kB here.

Is it true that having 4 bitplane sprite drawn by blitter we need actually 5 bitplane?

Also using triple buffer makes the whole blitter thing faster as this is what i know from Ryggar.

I dont think dual playfield is requied in this game. Its hardly noticable and resource hungry, and 8colours would hurt the quality a lot.

Generally speaking porting this game to a1200 would be much easier thanx to 2MB of chip ram and additional power.

This looks closer to what an Amiga 500 can do (with better graphics)

https://www.youtube.com/watch?v=Nuvfvu6E8R4&t=490s

Yes. All blitter images need one extra bitplane for the "transparency mask". This mask is needed for the "no color" pixels; allowing the background graphics to be visible through these pixels.

And in the game palette "Color 0" is always the transparent color. And this counts as one of the 16 colors. So when drawing images, the actual images have to be in 15 colors, because the "no color" pixels use one of the palette colors.

And if 8 colors were used, then that too is actually 7 + transparent color.

That's right.

In Amiga games "Buffering" usually means this:

1. One Buffer only

Uses only 1 bitmap. All images are drawn to this bitmap. So drawing happens on the same bitmap that is currently shown on screen.

This only works in games that run fast at 50 FPS. If speed drops below 50 FPS images will start flashing like in some NES game.

2. Double Buffering

Uses 2 bitmaps. The bitmap shown on screen is constantly changed, and drawing always happens to the hidden bitmap. The images will never flash because the next frame is not shown until it has been 100% drawn. This method is also a little bit faster than one buffering.

3. Triple Buffering

Uses 3 bitmaps. Here we do the same thing than in Double Buffering, but also have a 3rd bitmap which contains a "clean copy" of the background graphics. Nothing is ever drawn to the 3rd bitmap. Instead we use it to speed up the "background repair" process. Every time when objects are drawn to the screen, the background GFX get overwritten and need to be repaired after every Blit. Having a clean background stored in the 3rd bitmap speeds up this repair process a lot.

The Triple Buffer speed increase in comparison to normal Double Buffering is about 30 %. But also bitmap RAM consumption increases by 30 %.

---

One reason why Dual Playfield is great is that the Front and Back bitmaps are on separate screens. So when you draw to the front bitmap you don't need to "repair" the GFX in the back playfield. This gives the same 30 % speed increase than Triple buffering would give, and also the 8 color objects are some 20 % faster to draw.

This is why I see 8+8 being the best solution for A500, although 16 colors could of course also work. And parallax would be nice, but not necessary.

Ok, in that case lets update the A500 memory consumption plan:

128 kb = 640*200 scrolling bitmap in 16 colors, double buffered
100 kb = music and sound effects at same time
50 kb = reserve ram for random things
230 kb = Graphics

( Note - With Triple buffering bitmaps would need 192 kb.)

With this plan there needs to be a loading break after every 320*200 screen. The new level bitmaps can be loaded directly to the Double Buffered bitmap. Also we could have a one screen longer 960*200 level bitmap which would mean less loading breaks, but then bitmaps need 192 kb.

---
---

On A1200 things look much better. We could have a 3 times longer bitmap, with triple buffering, and lots more everything.

Here is a RAM plan for A1200:

576 kb = 1920*200 scrolling bitmap in 16 colors, triple buffered
200 kb = better music and sound effects at same time
50 kb = reserve ram for random things
1200 kb = Graphics

( Note - A 16 + 16 dual playfield would use 768 kb )

Now there would be a loading break only once in every 3 screens.

And we can have triple buffering, 2x more music and sounds, and 6x more graphics.

A1200 is fast with 16 color graphics, blitter drawing is maybe 30% faster and we also have 64 pixel wide sprites. If screen X size is reduced to 288 pixels there can be four 16 color 64 pixel wide sprites on screen.

Although people might complain about the low color amount, because they expect an AGA game to be more than 16 colors. But the extra speed and animation frames would compensate for this.

And of course on A1200 a 16 + 16 dual playfield would also be possible, it would need some 200 kb more RAM and leave about 1000 kb for the graphics. Doing a 16+16 dual playfield is also an easy way to increase the total color amount on screen: 16 color Front PF + 16 color Back PF + 16 color sprites + copper effects = 64 color game or more.

That's really interesting. But the loading breaks sound bad for game play. How much A1200 fast ram might be needed to play an entire level ( say, level one) without loading breaks?

The loading breaks would indeed be bad on the A500 at least. But on A1200 they wouldn't be that frequent, and with careful planning only a few brakes might be required per level. About Fast Ram needed to store an entire level, I think the maximum amount of 8 megs would be needed. But just like the A500 slow RAM, Fast RAM is different from Chip RAM. So still only 2 MB worth of stuff can be shown on screen at one time. But the loading breaks would be mostly eliminated, because the loading would happen from the Fast RAM instead of floppy disk.

---

I just watched a Neo Geo longplay of this game, and I would now say that A1200 is the only sensible option here. Attempting a direct A500 conversion would be madness. :D

An A500 conversion, if it's ever done, should be based into the possible A1200 version. So first there needs to be an A1200 version, and then the A500 version could be made using the A1200 code as an example on how to do things.

Memory wise the standard A1200 should be able to handle this game with loading brakes. And when it comes to 2D drawing power, things aren't that bad as you might think...firstly at any time we can have four 16 color 64 pixel wide sprites on screen, that can be used to draw anything. You could for example have 4 helicopters flying on screen "for free". Or you could make a 256 pixel wide boss using all sprites. Also most of the bullets in the game are just player bullets. The enemies don't seem to shoot so much. There is action, but the amount of objects is far away from some arcade bullet hell. Also many enemies are big and well animated, but there aren't that many on screen at once. And the Blitter is better at drawing a few big objects rather than many small ones.

For example Banshee on the A1200 has quite a lot of stuff on screen, and I think it runs in 64 color mode (6 bitplanes). So in a 16 color game we can draw some 30 % more stuff than what Banshee draws, and I think the game could even run at a steady 25 FPS (with some slowdowns at explosions and bosses and so on).

I didn't realize you are the same guy who was making that Megaman X game.

Sorry for being so blunt here but... have you ever finished any of your projects? Don't you feel it would be better to try out things you could actually finish before going into more ambitious projects?


The Playstation 1 version also has loadings during gameplay and we lived with it :D

Why do you think that? Looking at some screenshots of Metal Slug it looks to me like it uses tiles.

Every NeoGeo game is purely sprite based, everything is sprites inc the backgrounds, immensely powerful sprite system, even the PS1 and Saturn had cuts in their ports, and the former had lots of slowdown too.

The single buffer method will not usually work even for games that run in one frame, unless you are able to race down before the beam when drawing. But screen drawing can't usually be done like that, and when beam goes past your drawing area you get flicker. Double buffers is needed to eliminate that, even for games running in e.g. 50 FPS. Otherwise double buffering will not speed up drawing, if you're able to complete drawing in less than a frame. Since you have to wait for next frame to switch buffers. Here triple buffering will help somewhat with performance, as you can swap to another draw buffer without needing to wait for anything, while one buffer is shown on screen. Triple buffers can be used in other ways as well (like you describe).

For the Amiga, no. Expect those small Blitz demos that I've made. :D

Maybe it would indeed be better to do smaller games that could be finished in a month or two, but that just wouldn't be so exciting as the bigger projects.

I like to play around with these theoretical game projects, and make small demos of them, although it's unlikely that I'll ever actually complete any of them. But I have learned a lot through them, and so little by little the chances that I actually might finish something get bigger.

The Megaman X project went well until I ran into the limitations of Blitz Basic. Street Fighter 2 is still a work in progress, and completely possible with Blitz, and so I haven't abandoned it yet. Metal Slug too would be theoretically possible with Blitz, thanks to it's simple one way scrolling levels, and this is why I have posted so much in this thread. :)

True, and also it's interesting to note that Playstation 1 has roughly the same amount of RAM than the A1200, and so the longplay videos of the PS1 version might give some idea on how often new stuff would need to loaded.

---

@coder76

Thanks for clarifying the double buffering info.

But the thing is doing smaller games would actually be training and writing code for bigger projects!
Making n smaller projects where each solves m problems with the big ones means the big projects move forward too.

Well it may be true if you only want to scroll the level without any action going on.

But why not try doing just that? Could be cool in its own way even if it doesn't result in a port. And it could be used for other projects too.

Perhaps. It depends on how things have to be stored.

Don’t forget the PS1 has a lot of animation frames cut from the NeoGeo version, and yet still loads mid level, so the same or more cuts will need to be made here too.

But isn't the PS1 using 256 colors?