How well can Metal Slug backgrounds be recreated with tiles?

Discussion of development of software for any "obsolete" computer or video game system.
psycopathicteen
Posts: 2952
Joined: Wed May 19, 2010 6:12 pm

Re: How well can Metal Slug backgrounds be recreated with ti

Post by psycopathicteen » Sun Jun 17, 2018 8:17 am

I don't have the tools to build a custom cartridge, let alone test it on one. That's why it's at $a0 instead of $80 or $00. It's funny how Nintendo never placed SRAM in the most optimal places.

It only takes approximately 30 lines because once it hits the max amount of DMA size, it ignores everything after it.

lidnariq
Posts: 9708
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: How well can Metal Slug backgrounds be recreated with ti

Post by lidnariq » Sun Jun 17, 2018 9:48 am

Unlike on the NES, where there would have been a clear advantage to overflowing regular code into save RAM, on the SNES it's most often exclusively for save data.

Also, decoding both $3xxx and $5xxx should have required another pin on the MAD-1, and couldn't be done with the 74'139 at all.

tepples
Posts: 22057
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: How well can Metal Slug backgrounds be recreated with ti

Post by tepples » Sun Jun 17, 2018 9:50 am

Perhaps Nintendo put SRAM on Super NES PCBs in out-of-the-way address spaces because it didn't expect SRAM to be used for anything but battery save. The less time the save chip spends enabled, the less likely it is to suffer data loss when losing power or otherwise running out of voltage spec.

psycopathicteen
Posts: 2952
Joined: Wed May 19, 2010 6:12 pm

Re: How well can Metal Slug backgrounds be recreated with ti

Post by psycopathicteen » Sun Jun 17, 2018 10:06 am

Weren't there games that used non-battery SRAM?

lidnariq
Posts: 9708
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: How well can Metal Slug backgrounds be recreated with ti

Post by lidnariq » Sun Jun 17, 2018 10:16 am

Not significantly. Only GSU carts.

psycopathicteen
Posts: 2952
Joined: Wed May 19, 2010 6:12 pm

Re: How well can Metal Slug backgrounds be recreated with ti

Post by psycopathicteen » Sun Jun 17, 2018 10:29 am

So you're telling me that if back in the day, if I tried publishing my game for Nintendo, they would put a lousy battery in the cart that will cause the game to malfunction after a while?

lidnariq
Posts: 9708
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: How well can Metal Slug backgrounds be recreated with ti

Post by lidnariq » Sun Jun 17, 2018 10:42 am

wtf?

No, what they would have told you was "You don't want to waste your money buying a small amount of extra RAM on top of the 128 KiB that are already in the console".

Historical production costs were huge, probably $10-$20 per unit, even in volume. Adding several more dollars on top of that wouldn't have been something you could have gotten anyone sane to finance.

Also, the battery's presence wouldn't cause the game to malfunction, it would just mean that if you were using cart SRAM for something other than just save data, the save data was more likely to get destroyed.

psycopathicteen
Posts: 2952
Joined: Wed May 19, 2010 6:12 pm

Re: How well can Metal Slug backgrounds be recreated with ti

Post by psycopathicteen » Sun Jun 17, 2018 10:49 am

The primary reason for the SRAM, is for software sprite rotation, and not having to pad out levels to avoid software rotating sprites clashing with each other.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: How well can Metal Slug backgrounds be recreated with ti

Post by Drew Sebastino » Sun Jun 17, 2018 11:04 am

So Alisha's Adventure uses the same 8KB of sram? If you ever wanted to have something tested on real hardware, I have an SD2SNES I can use.

psycopathicteen
Posts: 2952
Joined: Wed May 19, 2010 6:12 pm

Re: How well can Metal Slug backgrounds be recreated with ti

Post by psycopathicteen » Sun Jun 17, 2018 12:51 pm

It uses 128kB of SRAM, but it's split up into 8kB banks because it is using an existing cartridge memory layout. If you look carefully at the above code, I implemented an "animation mode" that is specifically for jumping across SRAM banks for rotating sprites.

Code: Select all

sram_bank_crossing:
lda {animation_index}
xba
and #$ff00
-;
cmp #$2000
bcc +
sbc #$2000
inc {temp2}
clc
bra -

single_sprite:
lda $0002,y
bmi sram_bank_crossing
lda {animation_index}
xba
and #$ff00
clc
+;

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: How well can Metal Slug backgrounds be recreated with ti

Post by Drew Sebastino » Sun Jun 17, 2018 2:53 pm

BSNES would have allowed you to put SRAM wherever you would have wanted, wouldn't it? I thought the roms had headers that define how much SRAM they need and where it is.

What did you need 128KB of SRAM for?

tepples
Posts: 22057
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: How well can Metal Slug backgrounds be recreated with ti

Post by tepples » Sun Jun 17, 2018 3:06 pm

Caching software-rotated sprite cels, as an alternative to putting a GSU on the board to rotate them in real time like Yoshi's Island does.

93143
Posts: 1231
Joined: Fri Jul 04, 2014 9:31 pm

Re: How well can Metal Slug backgrounds be recreated with ti

Post by 93143 » Sun Jun 17, 2018 3:43 pm

lidnariq wrote:Unlike on the NES, where there would have been a clear advantage to overflowing regular code into save RAM, on the SNES it's most often exclusively for save data.
I have a reason. Speed.

My game uses an H-IRQ to pull off an elaborate raster effect, and it needs to run at 6 master cycles per byte to get everything done within the available window. Right now I use a trampoline in shadow RAM to get into a FastROM bank, but the IRQ plus a full slate of HDMA eats the bulk of the CPU time available during active display, and saving a JML per line plus two master clocks on every byte accessed on the stack might actually be worth it, even aside from the small speedup to regular code.

This is obviously an edge case, but it may actually be topical because there's a section in Mission 1 of Metal Slug that seems to want three 4bpp BG layers. And with the way it's arranged, it may be possible to use a combination of sprites and window masking to cover a scroll split executed with an H-IRQ. You might say it's overkill to add a custom SRAM configuration just to avoid having to reduce the bit depth of a BG layer, and you may be right. This particular section isn't even that busy, so it may very well not even be helpful (other than the small general speedup from having fast work RAM and a fast stack, and when porting Metal Slug to the SNES, any advantage is worth looking at).

...it may be possible to use sprites for the waterfall once the beam is below the HUD. There's not much else going on in that section, and the destructible part of the wooden structure is offscreen before the bulk of the waterfall comes into view. The ship and cliffs look like they'd reduce to multipalette 2bpp pretty well if you gave them a bit of HDMA and maybe some bridging sprites. This could be a good candidate for an OBSEL split, particularly if we decide to try to use real colour blending on the near-field waterfalls instead of checkerboard dither... it looks to me like the cliff on the left is out of view before the near waterfalls overlap any part of the far waterfalls, so the latter could be switched back to a 4bpp BG to permit layer blending.

I fear the water is going to have to slow down a bit. Even with tile reuse (and there are repeated elements in that far waterfall), there's just not enough bandwidth, or VRAM, to do 60 fps without butchering the graphics... wait, could it be possible to use colour math to combine a static 4bpp cliff+water background with mostly 2bpp animation? With enough tile reuse, the whole animation might fit into a useful amount of VRAM, or at least enough could be cached to leave the bulk of the bandwidth for the foreground. Still not hitting 60 fps, but might be faster than trying to use 4bpp for everything... One could also exploit the VRAM gate settings to overwrite half the bitplanes in a 4bpp tile set, but while that does reduce the bandwidth requirements, it also prevents compact tile caching/switching (which there may not be room for). Also, arranging tiles so they can be replaced selectively without a ton of overhead is harder when using 16x16 BG tiles. Using 8x8 tiles allows finer colour control but wastes VRAM on map data. Lots of work to figure out the best way to do this...

lidnariq
Posts: 9708
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: How well can Metal Slug backgrounds be recreated with ti

Post by lidnariq » Sun Jun 17, 2018 4:05 pm

Sure. With 16-bit M/X, the effects of fast B bank seem to be very approximately equal to fast K bank. And with a standard LoROM cart, you can even use cart RAM with fast timings.

But with 8-bit M/X, the benefits of fast B bank are only roughly 1/3 ish of fast K bank. It's not clear whether that difference is big enough to matter.

User avatar
Drew Sebastino
Formerly Espozo
Posts: 3503
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: How well can Metal Slug backgrounds be recreated with ti

Post by Drew Sebastino » Sun Jun 17, 2018 4:11 pm

I thought I had shown in a picture that you can use BG3 for the middle layer in that scene in conjunction to a window layer, and you'd have enough color for everything but the rocky edge of the BG layer and a few highlights on the tree trunks that you could use a few 16x16 sprites for. By some stroke of luck, the layer doesn't actually extend up to where the status bar is.

Something that's a real pain though is that the wooden fortress is really two layers in of itself. Luckily, you can get by a lot of it by messing with tile priorities, but there are some parts you are going to need sprites for. I think both front and back parts use the same palette, so you might be able to get away with an Equinox style sprite masking system so sprites don't need to be there all the time (so you could potentially save vram space). There is so much layering in this scene that even the Neo Geo even displays sprite pixel per line dropout with the last explosion, but that's also because they weren't smart about lowering it. (The waterfall layer is presumably loaded in its entirety even while most of it is occluded).

Post Reply