> Unlike in an NES emulator where you can just map an RGB value to each of the 64
> colors in the palette. Which is actually manually doable. But I doubt this was done
> in a game with 16 bit graphics.
(Fair warning I don't know the specific details of CPS-1 and I haven't bothered to check before writing this, but I'm confident it works how I say here)
Actually, 16 bit systems all work pretty much identically to the NES. Except when you set one of the 64 (256 on SNES) palette entries it's not a reference to a color predefined by the hardware, it's the actual RGB values of the color.
Since the sprites and tiles are still 4 or 16 colors each in most cases, there's an additional attribute that says where in the palette the 4 or 16 colors to use are located.
> yeah, the individual sprites are processed in cps1.c, line so and so. If you insert
> an if-else-condition with the indices of all the sprites that you don't want to show,
> they can be made invisible." Or something like that.
For the record, this is the specific part where I stopped feeling sorry for you and decided you wanted us to do your homework. If you can throw around terminology that specific, either you're capable of finding where to do it yourself, or you don't know anything and got once-in-a-lifetime lucky on word choice.
> And no, I don't have any interest in asking the MUGEN community. I'm not looking for
> individual sprite or background sheets.
The MUGEN community creates those sprite sheets with emulators that have layer disables where possible (often hacked versions of MAME), and with manual cutting-out where it's not (e.g. Mortal Kombat, which has no hardware layers). That community was already well up and running when the object test was discovered. Thus, it was exactly the right place to send you, as you have the same goals as them and they've already invented all the necessary wheels.
|
Index 
Flat 
Re: Disable sprite and background layers
Reply
Re: Disable sprite and background layers
