It is currently Sat Oct 20, 2018 9:42 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 114 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Author Message
PostPosted: Thu May 31, 2018 7:40 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3377
Location: Richmond, Virginia
Oh yeah, Metal Slug is programmed like shit. I haven't done anything sort of disassembly, because it's obvious. The people at Irem that went to form Nazca must have favored x86 because both the M72 and M92 used x86 processors when no other arcade machine did, (unless they signed some sort of contract with NEC) and their games were still pretty badly programmed then.

psycopathicteen wrote:
Alisha's Adventure already has a pretty advance dynamic animation engine, so I can probably reuse that for Metal Slug, if I'm making a port.

How complex is it? You won't be able to afford any unused space or redundant tiles.

93143 wrote:
I see nothing that's obviously impossible, given the 30 fps game speed and the abundant slowdown (a blessing in disguise when you're DMA-bound; drop one frame and you can basically replace all of OBJ RAM between engine updates),

I'd first just try and shoot for 60fps for the hell of it. :lol: I'd be funny to give people a reason to legitimately play this over the Neo Geo original. The 30fps honestly hampers my enjoyment of the game a bit (especially with the slowdown where it starts to look terrible)...

93143 wrote:
A good bit of it, though, is amenable to workarounds with BG layers and such (especially some of the bosses)

You could easily make all but the last boss a BG layer; the first boss is obviously just going to be the foreground layer, the second boss flies fully above the train and would use an IRQ or HDMA, the third boss only has the foreground, the fourth boss has a background, but it's fully above both tanks, and each tank is fully above the other, and the fifth boss also only has the foreground. The last boss is small enough though that I think I remember taking it apart and it fitting in about 3 64x64 sized sprites.

93143 wrote:
That's always the question. It can't be 100%, because the SNES can't output 320x224, and the Mega Drive can't handle enough colours

8 pixels on either side are blacked out, so you're only dealing with 48 less pixels in width; whatever you're missing on the sides of the screen should be negligible. The aspect ratio is going to off, but not enough to care. A Mega Drive port probably would not look good at all; 9 bit color won't look good for this game, and four palettes for the BG layers and 4 palettes for the sprites would be difficult enough, but I don't think you'd be able to share them with sprites and would have to somehow condense all the BG and sprite graphics down to two unique palettes... Not to mention you don't get an extra layer for the scoreboard so you'd probably have to black out behind that, and things like the background in front of the waterfall would pretty much be impossible.

93143 wrote:
I suspect the most dubious bit may be the explosions; they're big and plentiful and they animate fast. There are a couple of potential shortcuts that were discussed back when Espozo was attempting this... and maybe the big circular flashes could be done with windowing, but that only helps so much, and you'd run out of windows pretty quickly...

The explosions are 80x80 at their largest; I don't remember how fast they animate though. Luckily, explosions are pretty coordinated with each other, so you can use the same graphics. It'd be pointless to use windowing for the flashes when there's going to be a large sprite the same size later anyway; all this would be is a waste of HDMA channels. Windows would be more useful for other things, like the background over the waterfall.

You're going to have to use HDMA like crazy; you have the background palettes that need to be swapped out, you have the 2bpp scoreboard that you'd change a few colors to recreate the gradients, and if you want as many unique sprite palettes as the original, you're going to have to dynamically change the palettes down the screen, especially for 2 player. Can you use an IRQ to change the HDMA registers? That's the only way you're doing all this.

93143 wrote:
Obviously you'd be looking at extensive flicker/cheesegrater effect due to tile-per-line limits...

Yeah, that's innevitable. You can even make the original game drop sprite pixels if you keep spamming grenades and/or rockets; you'd want to drop old player created explosions if too many appear for this reason and that it'll shit all over your VRAM space and DMA bandwidth.


Top
 Profile  
 
PostPosted: Thu May 31, 2018 1:35 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 966
Espozo wrote:
I'd first just try and shoot for 60fps for the hell of it. :lol:

If it came to a choice between 30 fps with an S-DD1 and 60 fps with an SA-1 and an MSU1, I'd probably choose the former just for the authenticity factor, never mind that it's a stronger proof of claim.

Also, I can't see one frame being enough for animation updates in all cases, so those would probably lag. Though without double buffering (which you'd probably want to avoid as much as possible to save VRAM, as psycopathicteen points out), there'd be a similar visual effect even with the engine at 30 fps...

I agree it would be great if you could hit 60 fps just with the S-CPU, but I'm not sure it's possible outside the lightest action segments (the beginning of Mission 1, some of Mission 3, the final boss, stuff like that). Also, slowdown is more pronounced at 60 because going from 60 to 30 is a bigger drop than going from 30 to 20, leaving aside the fact that it will happen more.

Quote:
8 pixels on either side are blacked out, so you're only dealing with 48 less pixels in width; whatever you're missing on the sides of the screen should be negligible. The aspect ratio is going to off, but not enough to care.

I don't know about that. It seems like narrowing the effective visible area that much (~16%) would negatively affect the gameplay, and it would certainly look wrong. There are a lot of graphics to convert, but if you were really going to the trouble of producing a faithful port of Metal Slug I would imagine you wouldn't want to cut corners where it's not necessary.

Besides, you can save PPU sprite bandwidth and DMA bandwidth (and ROM) by rescaling the graphics, at least on large or partly blank sprites. The Mega Drive gets ~25% more DMA speed and 25% more sprite overdraw in H40 mode as compared with H32 mode, and all of it is eaten up by the extra resolution.

If you wanted to be a cheeseball and cut six or seven pixels from each side of the screen (or, honestly, even if you didn't), you could scale the graphics from 320 to 256, and that 80x80 explosion would be 64x80.

Quote:
Can you use an IRQ to change the HDMA registers? That's the only way you're doing all this.

Yes, you can (though it's kinda tricky to repurpose an HDMA channel mid-frame)...

...but you're just describing palette work. One HDMA channel can address one CGRAM entry per line regardless of where it is or why you're changing it. If all you're doing is changing colours, you can combine a bunch of unrelated palette changes into one HDMA channel; if they overlap, just spill to the next channel until you run out, and then spill to the next line. Or something like that.

You might be able to save compute time by using indirect tables, since you could then simply stick a pointer to the desired data in the HDMA table and use repeat mode, instead of having to copy the whole thing (you'd have to store interleaved index/index/colour data in ROM for every combination of subpalette index and sprite colour list, but they're just 60 bytes each, and how many could there possibly be?).


Top
 Profile  
 
PostPosted: Thu May 31, 2018 2:47 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3377
Location: Richmond, Virginia
Quote:
If it came to a choice between 30 fps with an S-DD1 and 60 fps with an SA-1 and an MSU1, I'd probably choose the former just for the authenticity factor.

I'm not entirely convinced it couldn't run at 60fps just on the 5A22 though; you can always point to Rendering Ranger R2 and how it runs on a SlowROM cart. I don't know how well the extra speed of a FastROM cart is going to cover the dynamic vram engine, palette sorting, but I figure it wouldn't have more slowdown at 60fps than the original at 30fps...

Quote:
Also, I can't see one frame being enough for animation updates in all cases, so those would probably lag. Though without double buffering (which you'd probably want to avoid as much as possible to save VRAM, as psycopathicteen points out), there'd be a similar visual effect even with the engine at 30 fps...

Yeah, 30fps really isn't going to give you an advantage for this reason. The largest, most animated common things are the 80x80 explosions, and they're like 3KB at largest; you basically have to double buffer these. Luckily though, they pretty much always go off at the same time, so you only need to store and update graphics for one. Smaller explosions often don't go off at the same time, but slightly after one another, so you couls still only need to animate the first one.

Quote:
but if you were really going to the trouble of producing a faithful port of Metal Slug I would imagine you wouldn't want to cut corners where it's not necessary.

But palettes are not going to align perfectly like they did, so you won't be able to just automate converting the graphics, which means it's going to take forever and a half. This is my opinion, but unless the person converting the graphics has a lot of experience (and even more time), it's probably going to look worse than the stretched original anyway. Most games that I've seen that were on the Genesis and the SNES ran at 320 pixels wide on the Genesis and used the exact same artwork (minus the difference in color) for both versions. You can tell that even SNES exclusive games often have artwork that assumes square pixels.


Top
 Profile  
 
PostPosted: Thu May 31, 2018 3:57 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2760
Espozo wrote:
Oh yeah, Metal Slug is programmed like shit. I haven't done anything sort of disassembly, because it's obvious. The people at Irem that went to form Nazca must have favored x86 because both the M72 and M92 used x86 processors when no other arcade machine did, (unless they signed some sort of contract with NEC) and their games were still pretty badly programmed then.

psycopathicteen wrote:
Alisha's Adventure already has a pretty advance dynamic animation engine, so I can probably reuse that for Metal Slug, if I'm making a port.

How complex is it? You won't be able to afford any unused space or redundant tiles.


What my animation engine can do:
- Display up to 24 unique 32x32 sprite patterns and 32 unique 16x16 sprites patterns at once
- Update 4kB of sprite patterns in one frame
- Automatic animation delay to prevent DMA overflow
- Automatic duplicate frame checking
- Metasprites are allowed to have several copies of the same sprite pattern within itself

Shortcomings:
- Doesn't do any predictive double buffering
- Can't reactivate left over dead sprite patterns
- Activates newest vacant sprite slot, instead of oldest vacant sprite slot
- Can't animate metasprites larger than 4kB without breaking it into smaller parts
- Non-identical metasprites can't share a duplicate sprite pattern in VRAM
- Can't split a 32x32 sprite slot into 4 16x16 sprite slots, and vise versa
- Doesn't have any split screen page-switching (this would be rocket science)


Top
 Profile  
 
PostPosted: Thu May 31, 2018 4:26 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20679
Location: NE Indiana, USA (NTSC)
Pinocchio and Pac-Attack run at 256 on both platforms.


Top
 Profile  
 
PostPosted: Thu May 31, 2018 4:35 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 966
Espozo wrote:
Quote:
If it came to a choice between 30 fps with an S-DD1 and 60 fps with an SA-1 and an MSU1, I'd probably choose the former just for the authenticity factor.

I'm not entirely convinced it couldn't run at 60fps just on the 5A22 though; you can always point to Rendering Ranger R2 and how it runs on a SlowROM cart. I don't know how well the extra speed of a FastROM cart is going to cover the dynamic vram engine, palette sorting, but I figure it wouldn't have more slowdown at 60fps than the original at 30fps...

I dunno. Rendering Ranger has a lot less going on in the run&gun segments, and feels more scripted. People have done neat stuff on the SNES, but there's really an awful lot going on in Metal Slug at times.

Quote:
Quote:
Also, I can't see one frame being enough for animation updates in all cases, so those would probably lag. Though without double buffering (which you'd probably want to avoid as much as possible to save VRAM, as psycopathicteen points out), there'd be a similar visual effect even with the engine at 30 fps...

Yeah, 30fps really isn't going to give you an advantage for this reason.

No, I'm pretty sure it'd still be a big advantage. You'd only need to run the game logic half as fast, including everything from physics and collisions to HDMA palette swap scheduling. About the only thing that wouldn't have its compute time requirements cut in half would be the animation engine. A good load-leveling DMA engine might give you broadly similar performance between 30 and 60 fps, but everything else would be immensely eased and you'd spend a lot less time with the gameplay speed cut to half or one-third.

Actually, it occurs to me that even DMA might be easier at 30 fps, because you only have to update OAM and CGRAM once every engine cycle.

Quote:
The largest, most animated common things are the 80x80 explosions, and they're like 3KB at largest; you basically have to double buffer these.

Do you? Even 3 KB fits into VBlank quite nicely, and if you have to delay updating something anyway, you might as well delay something else. And if you scaled it from a 320-wide starting point, it would only be 2.5 KB (though it could be more fiddly to transfer).

Quote:
But palettes are not going to align perfectly like they did, so you won't be able to just automate converting the graphics, which means it's going to take forever and a half. This is my opinion, but unless the person converting the graphics has a lot of experience (and even more time), it's probably going to look worse than the stretched original anyway.

That's true, but you don't have to redraw it completely. With an appropriate tool (and what are you doing converting Metal Slug backgrounds if you haven't set yourself up with appropriate tools), you could automate the initial conversion and then manually re-palettize any collisions, and if necessary rejigger the palettes to ensure there are only 8. If you got desperate you could even patch it up with sprites, though I doubt you'd want to...

Sprites typically only use one palette anyway, so converting them is easy.

I really think you're underestimating the gameplay impact of changing the aspect ratio that much. And I still think the size reduction could be important.

I've attached the large explosion, converted from 320-wide to 256-wide (so, 64x80) by sinc rescaling in GIMP and repasting over a 16-colour indexed version of the original. No touch-ups have been made. And this is a very simple method; unfortunately RotSprite doesn't support anisotropic scaling like this, but their method pretty clearly generalizes to it...

Attachment:
ms_explarge_rescale0.png
ms_explarge_rescale0.png [ 54.91 KiB | Viewed 1462 times ]

psycopathicteen wrote:
- Update 4kB of sprite patterns in one frame

Was this just intended to leave space for OAM, CGRAM and BG map and tile updates, or is a significant chunk of it CPU time for dispatching the transfers?

Quote:
- Doesn't have any split screen page-switching (this would be rocket science)

Yeah, in the general case it seems like it'd be extraordinarily difficult. Maybe impossible.

In a specific case where a lot of things are happening on two separate levels without crossing between them, while some other things can cross over, it might be possible to reserve 8 KB for full-screen action and 8 KB each for the upper and lower levels, switch at a fixed V-position, and just special-case the engine to deal with it.

No?


Top
 Profile  
 
PostPosted: Thu May 31, 2018 4:55 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20679
Location: NE Indiana, USA (NTSC)
I cloned RotSprite in Python as Rotpixels. If I remember correctly, it supports this sort of aniso scaling. (It probably needs to be updated for Pillow 4's changes to nearest neighbor resampling offset.)


Top
 Profile  
 
PostPosted: Thu May 31, 2018 5:07 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2760
93143 wrote:
psycopathicteen wrote:
- Update 4kB of sprite patterns in one frame

Was this just intended to leave space for OAM, CGRAM and BG map and tile updates, or is a significant chunk of it CPU time for dispatching the transfers?


OAM, yes.
CGRAM, no.
BG map updates, yes.


Top
 Profile  
 
PostPosted: Thu May 31, 2018 9:19 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3377
Location: Richmond, Virginia
Quote:
I dunno. Rendering Ranger has a lot less going on in the run&gun segments, and feels more scripted. People have done neat stuff on the SNES, but there's really an awful lot going on in Metal Slug at times.

And there's an awful lot of slowdown when there is. :lol: Other than the final stage (which pushes 12 enemies at once in the begining) I don't think the load is too much different; Rendering Ranger R2 actually pushes more player bullets (even when taking into account two players) for one thing.

Quote:
No, I'm pretty sure it'd still be a big advantage.

I meant in the context of animation.

Quote:
Actually, it occurs to me that even DMA might be easier at 30 fps, because you only have to update [...] CGRAM once every engine cycle.

Not necessarily; if you're using HDMA to change colors down the screen, you're going to have to reset them every frame.

Quote:
I really think you're underestimating the gameplay impact of changing the aspect ratio that much.

Well, as a rudimentary test, view the game, but cover everything to the left of the second pow icon and everything to the right of the the number of credits at the bottom of the screen. As is, I didn't find it that jarring, but you'd probably still want to move the camera around a bit to better capture everything.

Quote:
Was this just intended to leave space for OAM, CGRAM and BG map and tile updates, or is a significant chunk of it CPU time for dispatching the transfers?

I've got to ask, why designate different amounts of time for everything?

Quote:
Yeah, in the general case it seems like it'd be extraordinarily difficult. Maybe impossible.

Not to mention all the BG graphics probably won't allow sprites to use more than 16KB anyway. With the space efficient method psychopathicteen is using, I don't think it is as much of a problem as the VBLANK DMA limit.

Quote:
What my animation engine can do:

The one thing I'd try and push for for space concern is removing the distinction between 16x16 and 32x32 sprites and just let them fight for the same space. I have no idea what sort of repercussions there would be though. Still the most advance VRAM engine for the SNES by a wide margin.


Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 1:12 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 966
Espozo wrote:
I've got to ask, why designate different amounts of time for everything?

Huh? Am I understanding your question correctly?

It's just a matter of budgeting your VBlank time. Make sure you've accounted for everything that MUST get done to avoid glitching, such as updating OAM and refreshing the tilemap, and then see how much time you've got left for tasks that can be delayed a bit, like sprite animation. Remembering of course that you can't just DMA chunks all over VRAM back to back; you need to stop and change the destination address, which starts eating into your bandwidth if you have to do it too often.

This calculation could perhaps be automated in a truly general method. My shmup port doesn't really need a general method, so I've done a fair bit of cycle-counting to make sure everything fits in the worst-case scenario. 9 KB sounds like a lot, but when the Super FX is feeding you nearly 7 KB per frame you've got to be thrifty with the remaining bandwidth...

I did manage to rig my CGRAM HDMA so it restores the colours to their top-of-frame values before the end of the frame. Very useful; saved at least one DMA transfer. This may not be possible with Metal Slug - with five HDMA channels (setting aside one for audio streaming and two for other stuff), it would take 24 lines just to reset the sprite palettes, assuming you'd changed all of them - though perhaps there's a smart way to handle this that happens to not break in the actual game... The HUD would be pretty easy to reset in the top few lines. Other BG layers probably don't need HDMA in the first place...?


Oh hey - I just realized that setting a palette with all N HDMA channels (N being however many you end up reserving for CGRAM) gets done a lot faster than just piling all 15 colours into one channel. (Yes, I'm stupid today. We discussed this years ago.) And you can still get N palettes changed in 15 lines. The drawback is of course more CPU time; at minimum you now have to write N pointers per palette change rather than one... on the other hand, collision avoidance when scheduling could be simpler... on the other other hand, this method wouldn't work at all at the altitude of the HUD, but then perhaps it wouldn't need to all that often...


Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 4:03 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3377
Location: Richmond, Virginia
Yeah, I think the general thing with this project is that you can make the port as detailed and close to the original as possible, but it's a hell of a lot of trickery/work. With all the cartspace in the world, even an official port would have turned out to be shit. I don't think any developer would have made a dynamic, sprite palette changing engine just to avoid having to condense the bullet and explosion palettes together. :lol:


Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 4:30 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2760
I don't think Metal Slug would need a lot of palette switching.


Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 12:15 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3377
Location: Richmond, Virginia
It would; the backgrounds usually fit into 8 palettes, but not always, and then you've got the scoreboard that wants 2 additional palettes. Sprites really want more palettes; just about every object uses a unique palette. For example, there's player 1, player 2, the weapon pickup icon, the ammo crate, POWs, soldiers, the soldier shot shot/grenade, the sherman tank wannabe, the shotgun blast, the machine gun fire, shrapnel... I mean, even the grenade explosion and the standard explosion have different palettes... Most screens won't use more than 8 palettes, but you really can't count on it, especially with 2 players. I think I've counted 12 palettes on-screen with 2 players before, but they were stacked vertically enough to where it would work.


Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 1:41 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 966
The thing is, these palette changes aren't free. (Well, the HUD is - you just need to keep the HDMA in place, and it's such a tiny fraction of CPU time that you'll never miss it.) You'd have to spend a lot of time checking for palette usage and scheduling the changes. You could very well end up with significantly more slowdown simply because you refused to harmonize with . And it's not like the rest of the game is going to be 100%; there's going to be either a lower resolution or a narrower screen, a lot more sprite dropout, sprites animating out of sync with the frame rate - and it's probably not going to sound the same either. Merging a few palettes wouldn't be the end of the world.

...if it could be pulled off without exceeding the amount of slowdown in the original (and without single-handedly sinking the project into development hell), I think I might go for it. Might at least be worth a try...


Last edited by 93143 on Fri Jun 01, 2018 2:19 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri Jun 01, 2018 2:14 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3377
Location: Richmond, Virginia
93143 wrote:
...if it could be pulled off without exceeding the amount of slowdown in the original (and without single-handedly sinking the project into development hell), I think I might go for it. Might at least be worth a try...

It's more for authenticity / bragging rights / whatever than actual visuals; the majority of people probably wouldn't even notice the palettes were condensed. :lol:

Background updates should still mostly be free though, correct? The difficulty would be working the sprite palette updates around these, unless you're fine with potentially halving the color changing bandwidth by reserving some HDMA channels for background color updates and some HDMA channels for sprite color updates.

I really kind of wonder how you'd arrange this...I think I suggested that you'd start with something like virtual palettes that you'd have to find where their top and where there bottom is on the screen, and then sort them. The problem is, the only way it seems to find the area for each palette would be to compare the visual area of each object with the visual area of the palette it's requesting, so basically one dimensional collision. The palette area will grow if an objective using that palette is above or below it.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 114 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group