NotAGoodName

Gee, I don't know. Maybe that I get some credit for my work which is obviously still on display in this version? Or that Drachir and Mayar get some credit. Or that things like "Edit and do whatever you want just credit me for the original base I guess. :]" are interpreted for what they are which is credit theft. Again, this is not in the edits section and in no way is it acknowledged that this or his previous version is an edit. I don't know what more proof you want that this is credit theft. I have proven that I created and released my screenpack in September 2011. Taybear has proven that he is unwilling to give me credit for my work. It doesn't matter that he edited my work and then edited it again. It's still my work that he edited and didn't give me credit for.

Seriously? I'm not sure what more you can possibly need than the fact that my YouTube video from mid 2011 demonstrates a super early version of my screenpack that this was obviously based on. Welp, ok. Here's my You've already seen that the original thread posted from the old forum. Here's an image from it. If you check the properties for this image, it has a timestamp of September 2011. Yes, it's hosted on MySpace. I used MySpace for hosting images back then. Not sure if I can even upload to MySpace anymore. Quite a bit of pixel art went into to making this screen look right. Here's an image from Taybear's earlier MFG thread. This is timestamped June 02, 2012. It's just a recolor of my work. Do I need to post a slideshow of his SFF vs my old one that I just uploaded or are we done here? *edit* And yes, I am Tim Markworth. All of my characters are released under my real name.

I am entitled to ask for credit for my work. He did not ask me concerning this edit nor did he credit me (or the previous authors that I did credit). If he wants to release it as an edit, he can post it in the edits section. Here is the oldest version that I still have on my computer. Feel free to check file dates and compare system.def and system.sff. You will see that my SFF is from 12-15-2012 (almost a year's worth of work at that point) and basically sprite for sprite matches his.

Stolen as hell. How about crediting me for doing like 75% of the work or so? *edit* Well you packed it wrong. You kept my old directory structure for directory "MillionaireFighting" on your end and in the system.def, but the download uses "MillionaireFighters" so that's a bad start. I guess this is built on an pretty old version that I released because the SFF includes a bunch of old stuff that I think I've since removed. But whatever. *another edit* Just in case anyone thinks I'm full of it, here's a video where you can see a super early version from 2011 (!!).

Just use the pixel ratio setting on the remote.

The character should come with another DEF file (like sf2'ryu2.def). Use that one as it disables the pause menu. Alternatively, if the character is for Mugen 1.x (not winmugen), you can add triggerall != AILevel to the CMD file for whatever state uses the start command.

Oh joy. CNS transparency combined with AIR transparency. Basically the ultimate way to have problems like this and it's totally unnecessary. 1.1b1 patch 1 was released basically for this reason, but this guy found a way to make the glitch happen anyways. There's probably a way to fix it by unraping the effects in CNS, but with so much going on, I'm not sure it would be worth the effort.

Never fear guys. My Mugen 1.1 patches are still up.

Well, I hope you're prepared to be disappointed when all your buggy old characters are still buggy.

[state 1000, spawning helper] triggerall = anim = 1000 This does nothing. It has no state type or anything. Remove it. If you really need that anim = 1000 trigger, add it to the next state.

This is a super early beta, but man these sprites look pretty good.

Just try using FF3's palette editor and import sprite features. If you get lucky with it, you might be able to import the sprite and use the right indexes using the adapt sprite/image functions. It's less effective if there's more redundant colors in the palette.

Is your walk.back velocity positive? It needs to be negative.

He's modifying the portrait to fit for his character that is using localcoord to be resized. Obviously, localcoord is the best way to adjust a character to suit your scale preference.

I think this is correct 320 / 250 = 1.28 (character is 1.28 times larger) [99,50] / 1.28 = [77,39] ?

You could modify the code and do some stuff, but let's not do that. Easiest way is to just abuse pal.defaults and [palette keymap]. So let's say you've got regular Ryu. Copy that def and rename the copy EvilRyu.def Now edit the displayname to be "Evil Ryu" (or whatever you want) At pal.defaults, you want it to list only the palettes that are Evil Ryu mode and the first one should be his default color. So maybe pal.defaults = 10,11,12,7,8,9 This basically makes sure that when the CPU picks this character, it's always Evil Ryu. And now, to make sure that YOU always get Evil Ryu mode put something like this between the [Files] and [Arcade] sections. Modify it to suit your needs and palette conditions. The point being that you want every button to pick a color that only selects Evil Ryu. [Palette Keymap] a = 7 b = 8 c = 9 x = 10 y = 11 z = 12 a2 = 7 b2 = 8 c2 = 9 x2 = 10 y2 = 11 z2 = 12

Import a single sprite. Make and save a palette with the palette editor. Hopefully that palette is good. Then delete that sprite. Import your palette as 1,1. Now when you import sprites, tell FF3 to adapt the image using palette 1,1

Open the BAT file with notepad. Add -r whateverscreenpack to the command line set p1=02 set p2=Ryu set st=RyuStage "mugen.exe" "%p1%" "%p2%" -s "%st%" -p2.color 4 -p2.ai 0 -r mugen1 So in this example, I set some variables for players and a stage. Then I have a line to run mugen with all the variables set. The last part, -r mugen1, tells mugen to use the crappy old default mugen 1.0 screenpack located in directory [mugen]\data\mugen1

Yes. From the help prompt. -r <sysfile> Loads motif <sysfile>. eg. -r motifdir or -r motifdir/system.def

Let's clear this up with actual information. Mugen 1.1's OpenGL mode requires support for OpenGL 2.1 (and appropriate shaders) which was released in 2006. I've never had the opportunity to test it, but Mugen 1.1 should run on hardware as old as the X1950s. Maybe X1800. It does not run on the Intel i945g (and possibly newer Intel GPUs) because it lacks the appropriate shader support. This "glitch" is a result of older Mugen versions rendering stage sprites improperly. The mask setting was basically ignored. Mugen 1.1 no longer renders it improperly, so stages that are coded with mask = 0 will do this. What you're seeing is the mask color (usually magic pink) being displayed.

https://www.youtube.com/watch?v=pS8SybZWZns

Welp, that was easy. It has nothing to do with OpenGL support or some nonsense. The stage is programmed wrong! Look for this block and change mask to 1 as shown. [BG resplandor] type = normal spriteno = 0,3 layerno = 0 start = -550,170 trans = add mask = 1 ;<--- NEEDS TO BE 1 NOT 0 delta = 3,0 ID = 1

Do you have a link to that stage? I'd like to examine the problem. Changing to system renderer is not a particularly good solution given the staggering loss of performance.

Well, you're not playing fullscreen so you've got stuff being cutoff. Also, you might be using the wrong resolution for that screenpack.