Is it possible to disable the various sprite and background layers in MAME?
If this is game-dependent, I'm talking about "Street Fighter II", i.e. CPS-1.
I would like to be able to do screenshots without the energy bar and the score at the top of the screen.
I've seen this in the emulator Nebula: You can either turn off a specific layer (unfortunately, the fighters and the energy bar are in the same layer). Or you can turn off individual sprites (The energy bar for example consist of many single sprites.)
Unfortunately, Nebula uses slightly different colors for the game. So, since I always do all my screenshots with MAME, I cannot switch to Nebula for these specific pictures because the colors wouldn't be the same.
That's why I'm asking you if something like this is possible in MAME. I didn't find anything in the MAME documentation, but maybe it's possible by editing the CPS-1 source code?
Repeating the same question just because you didn't get the answer you dreamed of the first time is annoying. You were pointed toward asking for help in the Mugen community before so...
I forgot: If for some reasons the thread gets forgotten even though it was not resolved and the people just suddenly stopped answering*, the question is forever off-limits.
* Which seems to be an issue here. I've never seen a forum where the chance that a thread is answered is so random as in this forum:
My thread about input lag was one of the longest threads on the first page. Then it was locked because of some stupid flaming moron. When I opened a second one to continue the conversation: Zero replies.
Or a question that should be relatively easy to answer for someone who knows a bit about the source code: How does MAME detect which colors to display in games that use more than 10000 of it? Surely, they are not hard-coded, are they? 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. But do you think anybody gave even the most basic answer or the slightest hint on how the colors are produced? Nope, not a single reply, even though the question was in no way obscure.
So, yeah, I did a second thread about the same topic. Because the last one died right in the middle of the conversation. And with this forum's randomness, maybe I would have had success. I mean, I even included new findings, like the fact that Nebula can disable individual sprites. So, again, maybe a code expert could have told me: "Oh 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.
And no, I don't have any interest in asking the MUGEN community. I'm not looking for individual sprite or background sheets. Even for that, a savvy user could have directed me to the game's hidden object test instead of simply telling me to grab pictures from da interwebs. (As if I wouldn't have thought of it myself if it had been an option. "Oh really, you can find pictures of the fighters if you search the net? Thanks a lot. You helped me very much. I would have never thought that the internet can be used to find cryptic stuff like pictures.") So, no, sprite sheets don't do it. I'm looking for a way to clean an actual game scene of its status data. A game scene with the correct position of all the visible objects from this particular camera perspective. Because, as you might know, you cannot just paste the background of "Street Fighter II" together as if it were freaking "Super Mario Bros." If I let a fighter take two steps to the right when the breakable statue in Bison's stage is visible, the perspective might put the statue yet in another position. You cannot just take a panorama view of the stage from a PNG file, put two fighter sprites somewhere, cut out a rectangle of 384 x 224 pixels and expect this to look like the scene would actually look in the game.
The thread where you asked about this was a different one that didn't get locked but anyway... Here you would be lucky to find 1% of the crowd having tried something like this, where at Mugen where you were directed, more like 99% have tried stuff like this and someone could more likely help you. Like your supergun questions, you want an answer here were at most .1% of the members have ever even seen a supergun when you could be asking at byoac where 99% of the members have used or built them.
> Here you would be lucky to find 1% of the crowd having tried something like > this, where at Mugen where you were directed, more like 99% have tried stuff like > this and someone could more likely help you.
MUGEN developers need the sprites as general, separated images. There's no need for a MUGEN developer to edit a single frame of a single random scene of the game, so why should they do something like disabling stuff in a live play? If I want to know how to disable layers in emulation, I need to ask on the forum where the developers of the emulator are. In how far is it logical to assume that a MUGEN developer, a programmer who works on a PC fighting game engine written in C, knows more about the reengineering and inner workings of an arcade board than the developer of an arcade emulator? You wouldn't go to the website of a "Super Mario" fangame to ask how to do the variable color brightness of the NES palette, do you?
Like your supergun questions, you want > an answer here were at most .1% of the members have ever even seen a supergun when > you could be asking at byoac where 99% of the members have used or built them.
Besides, even if that totally random assumption of a hacked MAME version in the MUGEN community was true (which would be totally unnecessary even if there wasn't such an object test because in this case they would probably just use WinKawaks or Nebula that can disable layers and show sprite tiles natively), do you think it's wise to ask for some dubious mame.exe on a MAME-unrelated forum? Don't you think in this case it's better to ask, you know, the people of the MAME forum who might be able to provide a source code patch for such a hack and who can even explain how it works while finding someone like that on a MUGEN forum is a complete game of luck?
Do you understand now why "Ask on a MUGEN forum. This one here is not the right place for your question" is not an advice that sounds very logical?
> Do you understand now why "Ask on a MUGEN forum. This one here is not the right place > for your question" is not an advice that sounds very logical?
It's not very logical to ask in a community who doesn't care about ripping/hacking graphics either. Emulators only control tile/background layers, not specific tiles per layer (WinKawaks used to do I think, but it's a laborious task per frame). If you feel like disappearing the energy bar, feel free to grab a tile editor and set the bar tiles as transparent in a hacked ROM.
Don't ask about tile editors here, there's a bigger chance someone at MUGEN forums know more about them.
I don't think so. I bet if I go to nesdev and ask for some information about disabling the sprite layers and the background layer in an NES emulator, it will take less than an hour until I get a concrete answer. And this answer will not contain the advice to ask the people at Spriter's Resource for a hacked version of FCE Ultra. Which should pretty much prove that it's not me who talks bullshit here.
I'm sure you could. I'm also sure that if people who work on cps1 in mame were here they would be capable of figuring it out and telling you. But they apparently aren't here and if they are they obviously don't care to put the time in to help you out. Because you've already asked about it. You don't seem to want to put in any leg work at all beyond emuchat and when you get advice you don't like, that isn't the absolute perfect solution you want you disregard it and try to find logic to disprove it and then continue with being annoying. So like I said, good luck.
> It's not very logical to ask in a community who doesn't care about ripping/hacking > graphics either.
Strictly speaking, this is not a question about hacking graphics. It's a question about the way sprites and layers are processed in the CPS1 code. Just like a question about the signal values when cetain button presses are emulated isn't a question about joysticks.
> Emulators only control tile/background layers, not specific tiles > per layer
Which would already be enough. As long as the fighters aren't inside the energy bar, I could take a screenshot of the unaltered scene, then a screenshot of the same scene with the sprite layer disabled and then cut them together: The upper part of the edited screenshot (without the bar) and the lower half of the unaltered screenshot (with the fighters). Additionally, every fighter and every score and every energy bar is made up of a number of various 16x16 sprites. So, it would be possible (as demonstrated in Nebula) just to skip the output function of certain sprites. Like this: for (int i = 0; i < sprite_count; i++) { if (i != 5) // This line is new. process_sprite(sprite); }
> If you > feel like disappearing the energy bar, feel free to grab a tile editor and set the > bar tiles as transparent in a hacked ROM.
Yeah, sure. I will edit the ROM files that change every second version of MAME anyway even though the emulator's source code could be able to switch off certain screen elements on the fly, without having to fiddle with actual game data.
> Yeah, sure. I will edit the ROM files that change every second version of MAME anyway > even though the emulator's source code could be able to switch off certain screen > elements on the fly, without having to fiddle with actual game data.
It's pretty simple logic actually. If disabling layers won't do what you want to see, the only solution here is either messing with the graphics or the program code from every single game you want it to work. Both involve ROM hacking on a custom version of MAME.
So you don't want to edit ROM files that change every version of MAME, but you want to change every version of MAME for every specific custom change you want to see? Here's what it could be a great discovery to you: Why not stick to a specific MAME version and ROM hack something that no one cares about except you? It involves touching MAME source code to alter the game specific ROM CRC32/SHA1 it asks too.
> 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.
> 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.
But when the actual RGB values are accessible somewhere in the game or in the hardware's code, how come that different emulators use different colors? For "Street Fighter II", MAME has other colors as WinKawaks. If the RGB values are fixed, why is this the case?
> 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.
Yes, I know what I'm talking about. Yes, I can program myself. But no, I've never done this kind of programming. I never wrote an emulator or recreated hardware workings in software. So, yes, while I do know that this:
READ16_MEMBER(cps_state::cps1_hack_dsw_r) { static const char *const dswname[] = { "IN0", "DSWA", "DSWB", "DSWC" }; int in = ioport(dswname[offset])->read(); return (in << | in; }
is a function that declares an array, then gets a specific entry of that array, calls functions and does some bit shifting and OR-arithmetic, I have no idea what the function actually really does. So, while I could probably manage to find the sprite drawing function in a game written in GDI or maybe even DirectX, I have no idea at all how a CPS-1 board or any game consoles work. I could look into this code forever and not figure out what it does unless I debug through the whole program many, many times from start to end. So, I can program, but just because I can program doesn't mean that I'm capable of quickly finding anything in a code that I never had contact with. That's why my question has nothing to do with other people doing my homework. I mean, if you are in a huge company building with an architect and that architect asks you where the bathroom is, would you tell him: "Hey, you are an architect. You design buildings. We are in a building. You should be able to figure out where the bathroom is." Would you tell this to him? No, of course not. Just because he designs buildings doesn't mean he immediately has to know how this building is designed. So, unless you expect me to spend the next six months reading and understanding the MAME source code for eight hours a day, you shouldn't talk about me wanting others to do my "homework". Just because I have an imagination how sprite handling could work in general doesn't mean that I will quickly find the actual sprite handling function in a source code that's completely foreign to me and that uses techniques that I never ever used in my whole life. That's the typical misconception: "Hey, you know about computers, right? So, you have to be able to solve every computer-related problem in the world." "Why do you ask how the program works? Shouldn't you be able to figure it out yourself?" Yeah, right.
> 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.
Even if that's true, it's something that was pointed out to me just today, after I was called out on the fact that I have been directed to the MUGEN community before. Yeah, the problem is just: You never told me that they have customized emulators. Originally, you just sent me there for sprite sheets and stuff. You didn't mention those kind of tools until after you criticised me for not going there.
> It's pretty simple logic actually. If disabling layers won't do what you want to see, > the only solution here is either messing with the graphics or the program code from > every single game you want it to work.
Disabling layers would do what I want to see. The problem is just: MAME doesn't offer the option to disable layers. Or did I miss something?
> Disabling layers would do what I want to see. The problem is just: MAME doesn't offer > the option to disable layers. Or did I miss something?
No it wouldn't. The energy bars are drawn with sprites, so you'd have to intercept specific sprite ranges and stop them from being drawn. However disabling all sprites would hide the player characters, too.
> No it wouldn't. The energy bars are drawn with sprites, so you'd have to intercept > specific sprite ranges and stop them from being drawn. However disabling all sprites > would hide the player characters, too.
What I find strange is why is he using and outdated emulator (Nebula) as example? Yet he's conscious WinKawaks exists. Last WinKawaks version is v1.63 in January this year. It gets the work perfectly done with the ScreenShot factory tool.
> But when the actual RGB values are accessible somewhere in the game or in the > hardware's code, how come that different emulators use different colors? For "Street > Fighter II", MAME has other colors as WinKawaks. If the RGB values are fixed, why is > this the case?
It's not exactly rgb, there is some interpretation. Even if it was solely rgb, the colours might not be linear which also opens them up for interpretation.
> So, I can program, but just because I can program doesn't mean that I'm capable of > quickly finding anything in a code that I never had contact with. That's why my > question has nothing to do with other people doing my homework.
You want to do something, but you don't want to invest any time into learning how to gain the information yourself. If we help you too much, then you might keep coming back for more information. If we tell you to figure it out yourself then you will either give up, or actually bother to learn. I don't care which of those you do.
> No it wouldn't. The energy bars are drawn with sprites, so you'd have to intercept > specific sprite ranges and stop them from being drawn. However disabling all sprites > would hide the player characters, too.
As I already said: As long as the fighters aren't behind the energy bar, I could do a screenshot with the sprites disabled. Then I could do a screenshot of the same scene with the sprites enabled. And then I could paste them together: The upper part with the disabled energy bar and the lower part with the enabled fighters. Even for the rare part where the fighters are behind the energy bar, I could do the same two screenshots, then take the corresponding frames of the fighters from the object test and put them into the picture.
> What I find strange is why is he using and outdated emulator (Nebula) as example?
The fact that I want this to be done in MAME shows that I do not use the Nebula emulator. It's just a program that I stumbled across and used as an example.
> Yet > he's conscious WinKawaks exists. Last WinKawaks version is v1.63 in January this > year. It gets the work perfectly done with the ScreenShot factory tool.
WinKawaks has a slightly different color palette than MAME. One and the same scene does not look identical in both emulators. (For example, the blue background color in the character selection screen is #000066 in MAME and #000060 in WinKawaks.) And since I do all my screenshots for "Street Fighter II" with MAME, switching to WinKawaks for those specific kind of pictures would create a discrepancy. That's why I need this to be done in MAME. Or, alternately, if there's a way for WinKawaks to use MAME's colors, that would be fine too.
> It's not exactly rgb, there is some interpretation. Even if it was solely rgb, the > colours might not be linear which also opens them up for interpretation. > > src/mame/video/cps1.c
O.k., thank you. That's finally something to work with. But when you get literally zero answers and your post dies down without a single reply, well, it can be kind of frustrating.
> You want to do something, but you don't want to invest any time into learning how to > gain the information yourself.
How do you want to know this? In this thread and in the last one there was not a single answer that refers to the source code. So, how do you want to know if I'd invest some work myself or if I would just wait until someone gives me the answer? It's not that anybody directed me to the function in the source code and I ignored it. Nobody even attempted to put me in the right direction. They talked about sprite sheets, the MUGEN community and the screenshot factory in WinKawaks. But none of the answers referred to my suggestion to disable those things in source code. So, unless you count "Not wanting to browse the entire source code as long as I have literally no knowledge about anything of it and not the slightest hint where to start watching" as "Too lazy to invest anything myslef", you cannot even know how much work I'd actually invest into it because nobody even tried to help me with altering MAME. (The fact that I refused the offer to take a hacked MAME version from another community should show you that I don't just want some pre-made solution and that I'm indeed interested to learn how to do it myself. Taking such a compiled exe would equal your "Others doing my homework" complaint. But as you see, I'd rather get some help with the code myself instead of relying on somebody sending me an altered mameexe.)
I don't know if you'd be willing to use cheats and an older version of MAME (where cheats were open to users to the standard version of MAME). I should probably presume you won't given how easily you could use WinKawaks, but it's immediately disqualified if the tones of the colors are ever so slightly off. I'm not sure if you know this for a fact or if you're making presuppositions. And FYI/reminder, the contrast, and brightness can be adjusted in MAME, usually used to 'erase' the gray boxes that appear in some of the CPS1 games. As much as I hate to say it (IMO) - nitpicking over minor color values kinda makes you look a tad anal/OCD about all this.
But anyway... It would be a bit of work to find the address/es that affect the sprite layers, maybe even the palettes. From my experience in the past (way back in 2006) if you can find an address for one thing, then addresses for other things are usually nearby, if not then in a similar region of another rom. But I could be wrong.
This is just my .02˘, probably doesn't help... But I don't think anything can help.
> How do you want to know this? In this thread and in the last one there was not a > single answer that refers to the source code. So, how do you want to know if I'd > invest some work myself or if I would just wait until someone gives me the answer? > It's not that anybody directed me to the function in the source code and I ignored > it. Nobody even attempted to put me in the right direction.
They probably assumed that if you had a chance of making changes yourself then you'd have at least found the right source file.
> I don't know if you'd be willing to use cheats and an older version of MAME (where > cheats were open to users to the standard version of MAME).
Yes, I would use an older version if the game looks the same there. Which, fortunately, it does. "Street Fighter II"'s palette was never changed, at least not for the past few years.
> I'm not sure if you know this > for a fact or if you're making presuppositions.
I know this for a fact. Have a look:
Left half is MAME, right is WinKawaks. Open the file and use the fill option to change the blue color. It will only change on one side because the other one is another color.
> And FYI/reminder, the contrast, and > brightness can be adjusted in MAME, usually used to 'erase' the gray boxes that > appear in some of the CPS1 games.
I said all my screenshots were made in MAME and I want to keep new ones consistent with the screenshots I already made. In how far would adjusting MAME's color now help me with this task? I don't want to change MAME's color, I would want to change WinKawak's color be be exactly like MAME's.
> As much as I hate to say it (IMO) - nitpicking over > minor color values kinda makes you look a tad anal/OCD about all this.
So what? Yes, I'm quite nitpicky. I want everything to look neat and fine. If I do my whole "Street Fighter II" sprite comics with MAME because it's the most common emulator and it can also be used for making screenshots of all the other arcade games, why should I switch over to WinKawaks for a bunch of screenshots where I need a specific feature? The scenes made with this emulator will have a different color, resulting in a sleazy result if one scene in the comic suddenly looks different from the others.
> But I don't think anything can help.
Why do you think so? I already said: All I need is the ability to disable layers or individual sprites. Almost every major emulator can disable the layers and WinKawaks can disable individual sprites. So there should be a way to implement this in MAME as well.
> They probably assumed that if you had a chance of making changes yourself then you'd > have at least found the right source file.
Yeah, and that's the typical cliche: The project consists of hundreds of cryptic source code files that I have literally zero knowledge about, nor of the general techniques used in this project. After all, these are not just some WinAPI commands. It's not like finding certain features of a simple 2D DirectDraw game written by a 13 year old boy. These are byte-exact simulations of the low-level workings of old arcade boards whose data were originally written in Assembler. And now people call me lazy for the fact that I don't find the right function? Yeah, next time we want to kill a specific mole that lives in Central Park, we will call a gardener lazy if he doesn't immediately know where the mole is. After all, he is a gardener and knows about moles, he should figure it out, right?
> Yeah, next time we want to > kill a specific mole that lives in Central Park, we will call a gardener lazy if he > doesn't immediately know where the mole is. After all, he is a gardener and knows > about moles, he should figure it out, right?
For the analogy to fit, it would have to be the gardener that wants to kill a specific mole but the gardener doesn't know how to find or kill a mole.
> As I already said: As long as the fighters aren't behind the energy bar, I could do a > screenshot with the sprites disabled. Then I could do a screenshot of the same scene > with the sprites enabled. And then I could paste them together: The upper part with > the disabled energy bar and the lower part with the enabled fighters. > Even for the rare part where the fighters are behind the energy bar, I could do the > same two screenshots, then take the corresponding frames of the fighters from the > object test and put them into the picture.
So you want to be able to enable and disable sprites while the emulation is running/paused? You're very ambitious, considering you can't even find the right source file, despite it having a very obvious name. For your trouble you'd be better off using a tile editor to make the energy bar sprites transparent. That won't require you to actually learn any skills.
> For the analogy to fit, it would have to be the gardener that wants to kill a > specific mole but the gardener doesn't know how to find or kill a mole.
Irrelevant. I was talking about expectations towards programmers and people who know a bit about computers. It doesn't matter whose desire it is to find a specific solution. My argument stands: Every noob expects a computer geek to know everything about computers and to be able to handle every single computer-related problem just because he's a computer geek. On the other hand, those people would never expect a gardener to know every spot in every park in this world just because he's a gardener.
And by the way, don't bother anymore. I found it myself:
2726 case 0: 2727 cps1_render_sprites(bitmap, cliprect); 2728 break;
And no, it was not because of understanding the program or anything like that which includes actual useful learning. It was just by stupidly searching for the word "layer" in the whole source file. So, I didn't gain any actual knowledge from doing the search myself, it was nothing more but CTRL+F and some dumb luck because the word "layer" was actually used as a function name. Somebody just telling me the code line would still have been much more efficient. But let me still say: Thanks a lot for not helping me at all.
> My argument stands: Every noob expects a computer geek to know everything > about computers and to be able to handle every single computer-related problem just > because he's a computer geek.
You're a noob, I'm a computer geek. You expect us geeks to know where to find what you're looking for. That isn't going to happen, just stop being a noob.
> Somebody just telling me the code line > would still have been much more efficient.
Not for us, we'd have had to use dumb luck to do exactly what you did. You learnt something, stop pretending you didn't.
> Irrelevant. I was talking about expectations towards programmers and people who know > a bit about computers. It doesn't matter whose desire it is to find a specific > solution. My argument stands: Every noob expects a computer geek to know everything > about computers and to be able to handle every single computer-related problem just > because he's a computer geek. On the other hand, those people would never expect a > gardener to know every spot in every park in this world just because he's a gardener.
Under that logic you're a programmer and hence a computer geek, we expect from you to find the solution yourself. But as you expect we know everything about computers and to be able to handle every single computer related problem (if we care) then you're definitely a noob. That, or you are a gardener expecting to catch a mole under a full moon in May with a pair of tweezers at midnight.
> And by the way, don't bother anymore. I found it myself: > > 2726 case 0: > 2727 cps1_render_sprites(bitmap, cliprect); > 2728 break; > > And no, it was not because of understanding the program or anything like that which > includes actual useful learning. It was just by stupidly searching for the word > "layer" in the whole source file. So, I didn't gain any actual knowledge from doing > the search myself, it was nothing more but CTRL+F and some dumb luck because the word > "layer" was actually used as a function name. Somebody just telling me the code line > would still have been much more efficient. But let me still say: Thanks a lot for not > helping me at all.
See how easy it is to do it yourself instead of writing long essays in forums asking for help about something you only benefit and care? It's not like you had to disassemble code, the source functions are in plain english for everyone to look for.
On a positive side you've raised a good question: Why do emulators output different colors? I though Nebula and WinKawaks developers shared knowledge between MAME in both ways.
Index 
Threaded 
Disable sprite and background layers
Reply
[Re: 
| in;
