MAMEWorld Forums - EmuChat - Re: Disable sprite and background layers

> 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.