English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 14 November 2017, 15:39   #101
coder76
Registered User

 
Join Date: Dec 2016
Location: Finland
Posts: 69
Quote:
Originally Posted by Master484 View Post
But the Neo Geo has 900 sprites, and everything that moves in the screen, including the backgrounds, are sprites. So in all likelyhood it's totally impossible to make an Amiga sprite engine that would be capable of directly replicating all Neo Geo sprites by just multiplexing the 8 Amiga sprites.
Look up Neo Geo specs somewhere:
https://wiki.neogeodev.org/index.php?title=Sprites

Neo Geo has a limit of 381 sprites per frame and 96 per scanline. Neo Geo sprites are all 16 pixels wide and maximally 512 pixels high and have each a 4-bit color palette. In terms of needed graphics bandwidth in visible screen, this is 96*2*4*224*50 = 8,6 MB/sec @50 Hz.

Amiga AGA sprites have a comparable bandwidth of 8*8*2*224*50 = 1,4 MB/sec. In addition to those onecan use blitter (max copy speed 3,3 MB/sec) and CPU (max 7 MB/sec) e.g. on a 68030/50 MHz, dataregister to chip ram. Blitter and CPU copy speeds are of course not comparable to sprite bandwidth, as they need to do more operations to get sprite-like objects (bandwidth is lowered by a factor of 3, for blitter objects, and similar for CPU objects).
coder76 is offline  
Old 14 November 2017, 16:29   #102
DamienD
Global Moderator

DamienD's Avatar
 
Join Date: Aug 2005
Location: London / Sydney
Age: 42
Posts: 12,778
Guys, besides coder76's post above mine, we are getting way off topic discussing CPC / C64 etc...

Move along please.
DamienD is online now  
Old 14 November 2017, 18:24   #103
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 330
Quote:
Look up Neo Geo specs somewhere:
https://wiki.neogeodev.org/index.php?title=Sprites

Neo Geo has a limit of 381 sprites per frame and 96 per scanline. Neo Geo sprites are all 16 pixels wide and maximally 512 pixels high and have each a 4-bit color palette. In terms of needed graphics bandwidth in visible screen, this is 96*2*4*224*50 = 8,6 MB/sec @50 Hz.
Ok thanks for the info, until now I have believed that Neo Geo has 900 sprites...this info I originally read from Wikipedia I think, but now Wikipedia too says it has only 380. Oh well.
Master484 is offline  
Old 14 November 2017, 18:56   #104
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 347
Have anyone ever tried to decompress graphics data with the blitter?

Doubt that it would be worth the effort but had to ask.
Megol is offline  
Old 14 November 2017, 19:38   #105
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 44
Posts: 1,131
Send a message via Yahoo to Samurai_Crow
The blitter and copper can render structured graphics as long as it's not realtime.
Samurai_Crow is offline  
Old 15 November 2017, 01:32   #106
saimon69
J.M.D - Bedroom Musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 869
Quote:
Originally Posted by Master484 View Post
That's right, on AGA sprites maximum horizontal size was increased to 64 pixels. The older OCS / ECS sprites could only be 16 pixels wide. But both on AGA and OCS we still have only 8 sprite channels.

But the Neo Geo has 900 sprites, and everything that moves in the screen, including the backgrounds, are sprites. So in all likelyhood it's totally impossible to make an Amiga sprite engine that would be capable of directly replicating all Neo Geo sprites by just multiplexing the 8 Amiga sprites.

---

I made an updated memory plan for A500 8 + 8 Dual Playfield:

50 kb = two 288*224 8 color "game area" bitmaps (front playfield)
125 kb = five 288*224 8 color level "background" bitmaps (back playfield)
80 kb = music and sound (although the demo most likely has none)
30 kb = reserve
220 kb = graphics

Game code goes to Slow RAM.

With this plan, in a "real game" there would need a loading break only every 5 screens.

One tank frame is 2,6 kb in 8 colors. So we can have 84 "tank frames"...This is equal to five standard 320*256 Amiga screens full of graphics.

So 220 kb should be able to hold a good amount of frames for the following: Player, enemy soldier, two tank types, helicopter and some bullets and explosions.

So RAM wise a short 5 screen infinitely looping demo level would be 100% possible on the 512K A500, and speed wise I think it would be 17 FPS + player and scroll at 50 FPS.
Some animations can be achieved by splitting elements, like tank and turret and using tweening; you could even make separated wheel animations so to save more space
saimon69 is offline  
Old 15 November 2017, 12:57   #107
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,678
Quote:
Originally Posted by Galahad/FLT View Post
Having seen modern efforts, I think the Amstrad CPC464 got REALLY and properly short changed during its lifetime, more so than the Amiga and its ST ports.
I think one obstacle was the 464, actually. The 6128 has a lot more RAM to dedicate to the quite heavy graphics and all the tricks needed to work around certain hardware limitations.
idrougge is offline  
Old 15 November 2017, 17:23   #108
LongLifeA1200
Registered User

 
Join Date: Nov 2017
Location: Amiga Kingdom
Posts: 56
The key to what makes Metal Slug "Metal Slug" is the action. I think that is partly what makes it so memorable.

While I can't think of any AGA game that ever matched Metal Slug's level of intensity (That's not to say there isn't one, I don't know every game.) at least a project like this generates interest from programmers to try.

If you design the levels so that the player is constantly engaged, and provide the illusion that multiple things are happening at once, it will feel like you are playing a Metal Slug game, in my opinion.

Though, I can't shake the feeling that since it's mainly programmers who are interested in this project as opposed to artists, there may be a few missed opportunities here.
LongLifeA1200 is offline  
Old 16 November 2017, 00:11   #109
rare_j
Zone Friend

rare_j's Avatar
 
Join Date: Apr 2005
Location: London
Posts: 862
Thanks to this thread I went back and played Metal Slug properly. Not like last time, when I yawned my way through it spamming the insert credit button and dying every 2 seconds.
Playing it properly is hard at first but mind bendingly awesome. I got to the bit where you roll over a line of fiat 500s in the tank and was grinning like an idiot.
This just can't happen on ocs. You might as well say you're going to port it to the zx spectrum.
rare_j is offline  
Old 16 November 2017, 00:52   #110
Shatterhand
Warhasneverbeensomuchfun

Shatterhand's Avatar
 
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 35
Posts: 2,967
Metal Slug is awesome, but from 3 upwards IMO the games got too hard in a stupid way, while the level design never matched the previous games. The best games on series are the first 3 imo (1, 2 and X).

I like 6 because they finally tried to do something different with it, with new characters and a few minor new stuffs, but it's nowhere as good as X
Shatterhand is offline  
Old 16 November 2017, 12:04   #111
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 330


Here is a quick A500 Metal Slug graphics stress test demo that I put together by copy pasting code from my earlier demos.

ADF download is in the attachment of this post. Just boot the disk and it'll autoload. Disk also includes Blitz source code.

Instructions: press numbers 1-9 to make stuff appear, move the robot with joystick, and press space to delete objects.

---

This demo is for the 512K A500, and it's optimized for low RAM usage.

Because RAM in the "real game" would be so tight, I made the front playfield bitmap 288*224, without any "bob zones" around it. The "bob zones" are usually needed so that we can draw objects whose images are partially outside of the visible screen. But the BOB zones increase the size of the bitmap, and therefore I left them out.

Also, there are no "Queues" or bitmap repair buffers.

Instead, this system is used: Every frame I use a CLS to clean to whole front PF bitmap. This is relatively fast thanks to the small 8 color bitmap. And after this objects are drawn either with "Blit" or "ClipBlit" command, depending on their position on screen; usually Blit is used, but when object goes to the border zone, it switches to the somewhat slower ClipBlit.

But despite the full screen CLS and ClipBlits, speed is comparable to "QBlits" when we draw lots of GFX. Only at low object amounts QBlit is faster (the 50 FPS zone), but at medium object amounts (25 FPS zone) this method is equally fast, and at extreme object amounts I think this method is actually faster.

---

The demo also has an auto-scrolling level loop, some copper effects, and uses all 8 sprite channels to make that 16 color Turrican robot sprite.

I put the sprite in to demonstrate how sprites can always move at 50 FPS, no matter how much slowdown. Also the sprite shows how large objects can be made "for free" with sprites. It uses all 8 channels to make this one 64pix wide sprite. But on AGA this same sprite would cost only 2 channels. So on AGA we could have four 64pix wide sprites like this. ( Just imagine an AGA Street Fighter 2 conversion using big sprites like this )

But so, how does it run?

Well, the FPS for the bobs is locked to 25, and this is what it can draw without slowdown:

15 soldiers
8 normal tanks
1 super tank
7 explosions
25 shots
22 rockets

That means one of those things, not all at once, hehe.

But it's not totally hopeless, and maybe the real game could indeed run at 25 FPS "with slowdowns".

I watched a Neo Geo longplay that used "real hardware", and there were frequent slowdowns in it, triggered by common events like big explosions, lots of bullets, etc. So frequent slowdowns on A500 too would be acceptable.

---

You can run this demo on A1200 too, but the difference won't be that big: basic A1200 can draw some 21 soldiers, 10 tanks, and so on, so the speed increase is some 20 %.

And if we used the AGA 16+16 dual playfield, then I estimate speed to be about the same as 8+8 on OCS.

But on AGA, there are two things that can be done to boost speed, but it's a choice between two things: Firstly, we can use the four 64pix sprites to put some big stuff to screen at almost no cost. Or secondly, we can use the bigger AGA display fetch modes. The fastest fmode boosts drawing speed by some 30 %, but doing this reduces the available sprite channels to just 1. So it's a hard choice, but in most 2D games I would probably go for the sprites. The fmodes are probably most useful in 3D and in isometric games like Syndicate, Populous and stuff like that.

And of course both on A500 and A1200 we can add fast RAM, and this too gives some 30% boost. But if we are trying to prove that Metal Slug "could have been done", then Fast RAM is a no-no, because only a few A500/A1200 owners back then had Fast RAM. And the same goes for adding faster processors and GFX cards.
Attached Thumbnails
Click image for larger version

Name:	MetalSlugDemo.png
Views:	587
Size:	34.6 KB
ID:	55450  
Attached Files
File Type: zip MetalSlugV2.zip (75.9 KB, 59 views)
Master484 is offline  
Old 16 November 2017, 13:15   #112
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,328
Quote:
Originally Posted by Master484 View Post
The fastest fmode boosts drawing speed by some 30 %, but doing this reduces the available sprite channels to just 1. So it's a hard choice, but in most 2D games I would probably go for the sprites.
Compromises are possible.
Your screen is 288 so 32*9 single CAS DMA. For scroll you need 2 further, so a slice of 352.
Setup FMODE=$D, DDFSTRT=$38 to DDFSTOP=$D0 (11 single CAS DMA fetch), a view from DIWSTRT=$xxA1 to DIWSTOP=$xxC1.
Drawback? Screen shifted 16 pixel to the right, we can live with it.
Profit? We have all 8 sprite available and plenty of more blitter DMA slots available

Another 2 cents.
ross is offline  
Old 16 November 2017, 18:02   #113
zero
Registered User

 
Join Date: Jun 2016
Location: UK
Posts: 189
How are you going to scroll a 352 pixel wide bitmap? You need one that is at least twice as wide as the display area to low overhead scrolling.
zero is offline  
Old 16 November 2017, 18:15   #114
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 44
Posts: 1,131
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by zero View Post
How are you going to scroll a 352 pixel wide bitmap? You need one that is at least twice as wide as the display area to low overhead scrolling.
...or use a tube scroller. That only needs a few tile widths extra on all but one row of pixels.
Samurai_Crow is offline  
Old 16 November 2017, 18:54   #115
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 330
Quote:
Compromises are possible.
Your screen is 288 so 32*9 single CAS DMA. For scroll you need 2 further, so a slice of 352.
Setup FMODE=$D, DDFSTRT=$38 to DDFSTOP=$D0 (11 single CAS DMA fetch), a view from DIWSTRT=$xxA1 to DIWSTOP=$xxC1.
Drawback? Screen shifted 16 pixel to the right, we can live with it.
Profit? We have all 8 sprite available and plenty of more blitter DMA slots available
Thanks, I'll try to test those values with the Blitz "DisplayAdjust" command, and see if I can get both the AGA fmodes and 8 sprites working at the same time.

Quote:
How are you going to scroll a 352 pixel wide bitmap? You need one that is at least twice as wide as the display area to low overhead scrolling.
About the scrolling method, in the actual "real game" I would scroll a 5 screen long 8 color bitmap. This demo uses the same method, but the bitmap is only 2 screens long. And this is a 8+8 dual playfield, and only the back playfield bitmap is used for scrolling. The front playfield is a 288*224 single screen bitmap that never scrolls, and is only used to draw the objects.

And a 5 screen wide scrolling bitmap means loading brakes every five screens, on the 512K A500.
Master484 is offline  
Old 16 November 2017, 19:22   #116
Akira
Registered User

Akira's Avatar
 
Join Date: May 2001
Location: New York
Posts: 19,265
The demo is great for static objects, but there needs to be animation in there.
The toll to RAM when you introduce more frames per object will quickly get impossible to maintain on an Amiga.

Also these graphics are thrown in as-is, perhaps reducing their size would improve performance. Yes, a daunting task, but no one said this should be easy.
Quote:
Originally Posted by LongLifeA1200 View Post
The key to what makes Metal Slug "Metal Slug" is the action.
[...]
If you design the levels so that the player is constantly engaged, and provide the illusion that multiple things are happening at once, it will feel like you are playing a Metal Slug game, in my opinion.
This, 100%. This is one of the key elements one could extract from the game design of Metal Slug that would make a "clone" feel like Metal Slug.
This ultimately allows you to take a lot of compromises on graphics size, amount, animation frames, objects at once on screen, colors and more.
Akira is offline  
Old 18 November 2017, 05:41   #117
LongLifeA1200
Registered User

 
Join Date: Nov 2017
Location: Amiga Kingdom
Posts: 56
Good show, Master484. Just seeing Metal Slug sprites move about on a stock A500 makes a person think "it could happen" .

Trachu, did you get the sound files, too?
And do you still have the sprite sheets in their original colours?
LongLifeA1200 is offline  
Old 18 November 2017, 08:43   #118
turrican3
Moon 1969 = amiga 1985

turrican3's Avatar
 
Join Date: Apr 2007
Location: belgium
Age: 42
Posts: 3,334
just to say it , if i was a coder i would choose good games to convert but more realistic to port... I have 2 in mind :

1) penguin adventure from msx :
[ Show youtube player ]
that amiga 500 should easily handle it and even improve it.Everybody loves this little game, it's a gem.

2) vigilante arcade or pcengine :
[ Show youtube player ]
the amiga should be able to handle it. and the stages are just 5, shouldn't be so long for a good coder.
the amiga 500 version was a real crap, i should say a shame :
[ Show youtube player ]
by the way could it avoid the copyright problem if the new version ask you to insert the original amiga disk of vigilante to work ??
turrican3 is offline  
Old 18 November 2017, 11:20   #119
OmegaMax
Knight Of The Kingdom

OmegaMax's Avatar
 
Join Date: Feb 2016
Location: Mordroc's Castle
Posts: 135
Speaking of games like Vigilante,I started these for pc engine(Kung Fu Master)their 32x64 pixels each.It also has five stages,not many colors onscreen.


OmegaMax is offline  
Old 18 November 2017, 14:18   #120
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 41
Posts: 7,853
Send a message via MSN to dlfrsilver
Quote:
Originally Posted by turrican3 View Post
just to say it , if i was a coder i would choose good games to convert but more realistic to port... I have 2 in mind :

1) penguin adventure from msx :
[ Show youtube player ]
that amiga 500 should easily handle it and even improve it.Everybody loves this little game, it's a gem.

2) vigilante arcade or pcengine :
[ Show youtube player ]
the amiga should be able to handle it. and the stages are just 5, shouldn't be so long for a good coder.
the amiga 500 version was a real crap, i should say a shame :
[ Show youtube player ]
by the way could it avoid the copyright problem if the new version ask you to insert the original amiga disk of vigilante to work ??
Vigilante Arcade use a double 256 colors palette. This explains how poor in colors the graphics are.
dlfrsilver is online now  
 


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 03:16
Amiga 500 + slow to chip conversion green screen Nekoniaow support.Hardware 8 06 February 2015 07:04
NOT AMIGA (but 68k!) Art of Fighting Source Code for Neogeo [044] jimmy2x2x Coders. Asm / Hardware 1 24 January 2014 16:34
EAB Multi Platform League - Round 10 - Metal Slug (NeoGeo) TCD EAB's competition 33 26 July 2009 21:57
Steg the slug HOL error dlfrsilver HOL data problems 8 12 February 2008 07:41

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 23:57.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.15140 seconds with 16 queries