11 November 2017, 12:39 | #41 |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
Ex GBA dev like myself then? It was a very powerful 2d machine indeed.
|
11 November 2017, 13:01 | #42 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,503
|
Quote:
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. Last edited by ross; 14 November 2017 at 22:56. |
|
11 November 2017, 14:39 | #43 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 526
|
Quote:
The OCS A500 only has 512 kb of Chip RAM. 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. |
|
11 November 2017, 15:12 | #44 |
Banned
Join Date: Aug 2005
Location: London / Sydney
Age: 47
Posts: 20,420
|
|
11 November 2017, 19:04 | #45 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 526
|
Quote:
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. |
|
11 November 2017, 19:59 | #46 |
Banned
Join Date: Aug 2005
Location: London / Sydney
Age: 47
Posts: 20,420
|
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) Again, I'll eat my shorts if this ever happens, promise (and will take videos)!!! |
11 November 2017, 20:31 | #47 |
Global Moderator
Join Date: Nov 2001
Location: Derby, UK
Age: 48
Posts: 9,355
|
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! |
11 November 2017, 23:58 | #48 | |
Registered User
Join Date: Dec 2015
Location: Poland
Posts: 189
|
Quote:
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. Last edited by Trachu; 12 November 2017 at 00:07. |
|
12 November 2017, 09:30 | #49 |
Registered User
Join Date: Dec 2013
Location: GR
Age: 47
Posts: 1,416
|
This looks closer to what an Amiga 500 can do (with better graphics)
[ Show youtube player ] |
12 November 2017, 11:27 | #50 | |||
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 526
|
Quote:
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. Quote:
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. Quote:
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. |
|||
12 November 2017, 11:45 | #51 |
Zone Friend
Join Date: Apr 2005
Location: London
Posts: 1,179
|
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?
|
12 November 2017, 13:48 | #52 | |
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 526
|
Quote:
--- 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. 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). |
|
12 November 2017, 14:06 | #53 |
Warhasneverbeensomuchfun
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 41
Posts: 3,450
|
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 |
12 November 2017, 14:28 | #54 |
Amigan
Join Date: Feb 2012
Location: London
Posts: 1,321
|
|
12 November 2017, 14:57 | #55 |
Registered User
Join Date: Jan 2010
Location: >
Posts: 2,977
|
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.
|
12 November 2017, 15:23 | #56 | |
Registered User
Join Date: Dec 2016
Location: Finland
Posts: 168
|
Quote:
|
|
12 November 2017, 17:37 | #57 | ||
Registered User
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 526
|
Quote:
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. Quote:
--- @coder76 Thanks for clarifying the double buffering info. |
||
12 November 2017, 19:10 | #58 | |||
Registered User
Join Date: May 2014
Location: inside the emulator
Posts: 377
|
Quote:
Making n smaller projects where each solves m problems with the big ones means the big projects move forward too. Quote:
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. Quote:
|
|||
12 November 2017, 21:18 | #59 |
Registered User
Join Date: Jan 2010
Location: >
Posts: 2,977
|
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.
|
12 November 2017, 22:44 | #60 |
Registered User
Join Date: May 2014
Location: inside the emulator
Posts: 377
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Amiga 500 Rev.6A VS Amiga 500 Plus with 2MB chip and ACA 500 | turrican9 | support.Hardware | 0 | 24 December 2016 02:16 |
Amiga 500 + slow to chip conversion green screen | Nekoniaow | support.Hardware | 8 | 06 February 2015 06:04 |
NOT AMIGA (but 68k!) Art of Fighting Source Code for Neogeo [044] | jimmy2x2x | Coders. Asm / Hardware | 1 | 24 January 2014 15:34 |
EAB Multi Platform League - Round 10 - Metal Slug (NeoGeo) | TCD | EAB's competition | 33 | 26 July 2009 20:57 |
Steg the slug HOL error | dlfrsilver | HOL data problems | 8 | 12 February 2008 06:41 |
|
|