Stephen Rao


view:  full / summary

Roses are orange, my name is Steve, I can't rhyme, potato!

Posted on July 24, 2020 at 7:00 PM Comments comments (56)

A crack in the curtain, through a silvery line, on the bed by the wall

a person peeps down, at the folks dressed so fine, doing nothing at all.

The excitible cock, is retired for the day, and it's bed time for all,

but, you can hear uncle Albert's voice drift up the stairs, from where he stands in the hall.


He's saying Big Fat Billy get out of your bed,

you've got to work for your keeping.

You've got nothing to show for your life,

but Big Fat Billy goes on sleeping


Out in the streets, it's the time of the day.  Can't afford to be late!

Rap-a-tap-tap, with typewriter on lap, waiting for a tea break.

 Back in his bed, with no thoughts in his head, of doing nothing till date

A shattering sound fills the peaceful sorround - the voice of aunt Kate!


She's saying Big Fat Billy get out of your bed,

you've got to work for your keeping!

You've got nothing to show for your life,

but Big Fat Billy goes on sleeping.

Big Fat Billy goes on sleeping.

Poem #2

Posted on July 24, 2020 at 6:55 PM Comments comments (35)

Cool was the sand, and so warm was the sun,

But wild is the wind, since my baby has gone

Too late to wonder, where she can be

Wild is the wind, my friend

As wild as her love for me


Danced to the music, as seas rushed to shore,

Now, warm breezes don't sing our song anymore

Too late to wonder, where she can be

Wild is the wind, my friend

As wild as her love for me


Stand here forever and hold her memory

Still wandering; years of wandering -

I'll hold her close to me.

Too late to wonder, where she can be

Wild is the wind, my friend

As wild as her love for me

wild as her love for me

Additional Stuff

Posted on April 18, 2020 at 10:40 AM Comments comments (27)

7.1 - Avoiding colorloss

Sometimes, you want to use an image which has (much) more than 256 colors. Hence, when you convert it to indexed colors, the quality of the image goes down proportionally to the number of colors it had at the beginning. There are 3 methods to avoid colorloss.


Jiggsaw Method :

It consist in cutting the original image in many little pieces, then display all the pieces at the correct place in the stage. Each small piece having less colors than the original image, you lose less colors when you convert it to indexed colors. The optimal size for the tiles using this method is 16x16 pixels, since 16^2=256, hence a tile will contain 256 colors maximum, and you're sure to avoid colorloss. However, cutting an image into tiles of this size is insane and results in too many tiles. Using 25x25 or even 50x50 tiles if the image doesn't have too many gradients is often enough.


Here is a quote by XGargoyle about handling the Jiggsaw method with Photoshop :

XGargoyle said, 11 years ago

- Your psd file contains all the tiles arranged correctly, but each tile is a different layer

- Export each layer as a different 8-bit indexed pcx. Use photoshop's excellent tools such as batch automation, actions and scripts

- Each resulting pcx will have the same size (i.e. 800x1200) and they will consist on a tile placed somewhere and the rest is just the magenta background

- Now create the text file for sffmaker. Placing the axis is easy because you don't have to do any calculation at all. All the sprites will have the same axis

- Finally build the SFF and make sure the crop option is enabled in the command line (so your sprites are optimized and reduce filesize)


RGB Method :

It's the most common method nowadays, even though it has its flaws. It consists in separating the image into its 3 channels : red, green and blue (RGB), with a graphical software. Then, in Mugen, you can reconstitute the image by placing the images one over the other with transparency.

While this method ensure no colorloss and is very quick to use, it results in a white screen when characters use alpha ctrls.


For more information about this method, reffer to this topic by Jango : The RGB Method.


ImageSplitter :


A method using a tool developed by AokManiac13, after [E] told him about the algorithm.

To get the tool, go here : -> Download Tools -> General Purpose Tools -> ImageSplitter.


Using this command-line tool, you will get many uncropped layers, which you will just have to insert in the SFF, all with the same axes. Then, you just have to write the code for one layer and do some copy-pasting job to display the others.


The only problem with this method is that it may generate a high number of layers (something like 50), and Mugen may not be able to handle that properly without having your framerate go down drastically.



7.2 - Other Animation Codes

While we have learned how to code simple animations, there are other parameters you can add to achieve different kind of effects. Here's a short list of these parameters.


- Infinite time :


You may want an animation to stop on a particular sprite and display it indefinitely, until the end of the fight. To do this, you just have to set the time (number of ticks) of the sprite to -1, as such :


[Begin Action 123]






Sprite 123,4 will be displayed for an infinite time.


- Turning the sprites :


If you have sprites you need to turn horizontally or vertically, you don't have to include them several times in the SFF after having modified them with Photoshop. You can do this simple rotation effect in the definition of your animation. Using "H" at the end of the line will turn the sprite horizontally, and using "V" will turn it vertically. You can use "HV" to do both :


[Begin Action WTF Flip]

10,2,0,0,5 ;Normal sprite

10,2,0,0,5,H ;Sprite with horizontal symmetry

10,2,0,0,5,V ;Sprite with vertical symmetry

10,2,0,0,5,HV ;Sprite with horizontal and vertical symmetry.



- Adding transparency :


We previously used the "trans" parameter in normal sprites to make the clouds transparent. However, when defining an animation, you may want to define the transparency within the animation itself. This is done by adding some other code at the end of the line :


[Begin Action WTF Trans]

10,2,0,0,5 ;Normal sprite

10,2,0,0,5,,A ;Additive transparency (identical to trans=add)

10,2,0,0,5,,A1 ;Additive transparency with background dimmed to 50% brightness (identical to trans=add1)

10,2,0,0,5,,S ;Substractive transparency (identical to trans=sub)

notice the two ",,". These are made because the code between the commas is made to flip the sprites, as we have seen in the precedent paragraph.


If you're using WinMugen or Linux Mugen (but not DOS Mugen), you can also define the transparency better as if you were using "trans = AddAlpha". This is done by using ASxxxDyyy, with "xxx" being the source, and "yyy" the destination, both values being between 0 and 256. If you want to make an animation fade out, you would use a code like this :


[Begin Action 16];Fading Out

16,0, 0,0, 4,,A


16,13, 0,0, 4,,A

16,14, 0,0, 4,,A

16,15, 0,0, 4,,AS200D256

16,16, 0,0, 4,,AS160D256

16,17, 0,0, 4,,AS120D256

16,18, 0,0, 4,,AS80D256

16,19, 0,0, 4,,AS40D256

16,-1, 0,0, 40,,AS40D256

The last line means that you're using and empty sprite.


- LoopStart :


This parameters allows you to define a point from which the animation will loop. An example being better than hundreds of explanations :


[begin Action 10]












The LoopStart is defined for sprite 10,5, which means the animation will loop from there. Hence, the animation will display the sprites from group 10 in this order :

0 1 2 3 4 5 6 7 8 9 5 6 7 8 9 5 6 7 8 9 ...



7.3 - Foreground Images - The BlackJack Method


You may have noticed in the tutorial a line of code concerning the number of the layer :


layerno = 0


This code was present in the sky or the moving mushroom for example.


Most sprites use this layer number of 0, which means that they appear behind the characters. However, you may sometimes want to include some elements in front of the characters. It may be a layers of snow as it can be an element on the ground closer to the screen than the characters. To do this, you just have to change the layerno to 1 :


layerno = 1

Sprites with layerno=1 follow the same rules as the sprites with layerno=0, which means that they appear in the same order as the order you've coded them in the DEF file. Hence, you should be careful if you have several items with layerno=1. However, these sprites will always appear in front of sprites with layerno=0, whatever the place where you code them in the DEF file.


Using a foreground element of this type, you can achieve effects of this type :

However, while this effect can be neat, it may sometimes clutter the fight and make the fighters disappear behind a huge foreground element, which is not suitable. A simple solution to this is to make the foreground element transparent. However, if you limit yourself to this, the foreground element will appear entirely transparent, and background elements will be seen through it, which is not very nice.


The good method is called the BlackJack method (the name of the guy who found this method) : you just copy-paste the code for your foreground element. You set the first one to layerno=0, and you give to the one with layerno=1 some transparency. Your code should go from :


[BG foreground]

type = normal

spriteno = 10, 0

layerno = 1

start = 0,0

delta = 1,1

trans = none

mask = 1

to this :

[BG foreground 1]

type = normal

spriteno = 10, 0

layerno = 0

start = 0,0

delta = 1,1

trans = none

mask = 1

[BG foreground 2 trans]

type = normal

spriteno = 10, 0

layerno = 1

start = 0,0

delta = 1,1

trans = add1

mask = 1

I used "add1", but you can use "add" or "addalpha" if you want. By doing this, the same stage now looks like this :

The sprite will appear as normally as before, but will be transparent when a character passes behind it.


Nono used an alternative version of this code by using "add" and "sub" at the same time, you can check it by looking at this topic.



7.4 - BG Controllers

These are very powerful tools I won't be explaining here. You should report to the Mugen Docs for more information. Look at here, Part IV for more information about Background Controllers.


Tamez also wrote in-depth tutorials about Background Controllers, explaining Animation Change, VelSet and VelAdd, click here for the link to the tutorial videos.


However, as pointed out by Mike Werewolf in his French translation of the Mugen Docs, there's a mistake in the simple example given at the end of the file. Here's a corrected version, just for you :


-- Simple Example -


Suppose we want to make a person walk back and forth from (-300,0) to (300,0), right behind the main characters. We'll use background controllers to accomplish this task.

First, define the walking animations. Say that the character's walking sprites are 10,0 through 10,3 and that they face to the right.


; Walk right

[Begin Action 10]





; Walk left

[Begin Action 11]





Now start the character off at the far left edge of his range.



[BG Peregrinator]

type = anim

actionno = 10

id = 10

start = -300, 0

delta = 1,1


Let's give Peregrinator a comfortable ambling speed of 2 pixels per tick. The one-way distance for his walk is 600 pixels, which will take 300 ticks. In total, it'll take him 600 ticks to make the round trip. Using this knowledge, set up the background controllers appropriately: since the entire situation repeats every 600 ticks, we can set the global looptime to 600.



[BGCtrlDef Peregrinator]

; reset the whole deal every 600 ticks.

looptime = 600

ctrlID = 10

; Set velocity of 2 pixels/sec rightward at time 0.

[BGCtrl Walk Right]

type = VelSet

time = 0

x = 2

; Set velocity of 2 pixels/sec leftward at time 300.

[BGCtrl Walk Left]

type = VelSet

time = 300

x = -2


NB from Mike Werewolf : Elecbyte forgot a part of the code. As it is now, the code makes the peregrinator go from left to right and vice-versa, but the anim always stays the same, with the peregrinator facing right. Hence, in the secind phase of the BGCtrl (walk to the left), the peregrinator will be doing a moonwalk. To correct this, we will add a BGCtrl to change the animation in the middle of the walk :


[BGCtrl Turn to the Left]

type = Anim

time = 300

value = 11


However, following the same idea, with the previous code, the peregrinator will indeed use anim 11 from time=300, but when the BGCtrlDef womes back to the beginning of the loop, it didn't receive any other indication, hence it will continue using anim 11, and we will start getting the moonwalk at the second loop. We just have to add a new BGCtrl. The whole code for this part becomes this :


[BGCtrlDef Peregrinator]

; reset the whole deal every 600 ticks.

looptime = 600

ctrlID = 10

; Set velocity of 2 pixels/sec rightward at time 0.

[BGCtrl Walk Right]

type = VelSet

time = 0

x = 2

[BGCtrl Turn to the Right]

type = Anim

time = 0

value = 10

; Set velocity of 2 pixels/sec leftward at time 300.

[BGCtrl Walk Left]

type = VelSet

time = 300

x = -2

[BGCtrl Turn to the Left]

type = Anim

time = 300

value = 11


And that's it! You can make the walk look better by having Peregrinator slow down and display a turning animation at each end of his walk. This would entail use of the VelAdd and Anim controllers. If you want Peregrinator to stop and start at regular intervals as he goes from one end to the other, you could create more VelSet and Anim controllers with their own individual looptimes (to get the behavior to repeat at regular intervals).


Finally, there is another mistake in the Mugen Docs. They specify that the syntax is :



type = Enabled

However, having the "d" on the end will make mugen crash. It needs to be:



type = Enable



7.5 - Misc. Stuff - Parallax

This is an effect you can apply to the floor, to make it move as the characters move. If you do it correctly, it can achieve nice effects, but is horrible if done badly. You can't go by eye with this method, and will have to use some Maths to code it properly.

Animating the stage

Posted on April 18, 2020 at 10:30 AM Comments comments (36)

Okay, so the stage is nice and all, but how about we add some animated elements, which will be moving all around the stage and give an impression of life to the stage. We will start simple by adding a moving sprite, then we will focus on creating animations and applying more complicated effects.


5.1 - Adding a moving mushroom - Velocity

As said, we're going to start simple. You can see that mario012.pcx is a little mushroom. We will add him to the floor, just behind the characters, and make it move horizontally.


- Start by adding mario012.pcx to the SFF file and save. I added it as sprite 2,0, with axis = 0,0.

- Now, open the DEF file and add the mushroom so that it's placed perfectly on the ground. Place him wherever you want on the X axis, it doesn't matter so much.

- At this point, you shouldn't have to look at my code, but just in case :

Spoiler, click to toggle visibilty

- When done, you should obtain something like this, with a static mushroom on the ground :

We are now going to make the mushroom move horizontally with some simple velocity. If you look at the code for the floor BG, you should see these lines :


velocity = 0, 0

tile = 0, 0

tilespacing = 0, 0

Setting these values to zero makes the element static and appear only once, which is what we wanted for the floor. Copy paste these 3 lines to the mushroom BG.


Let's analyze these 3 lines of code, and understand what they're meant for :

- velocity is what allows you to make a sprite or animation move. The first value is the X velocity, the second one is the Y velocity. If you want to make an element move diagonally, you'll have to set both values to something different from zero. In our case, we will only change the X velocity.

- tile can be whatever integer value. If set to 0, the sprite won't repeat itself throughout the stage. If set to 1, it will have infinite tiling on the axis you have set it to 1. The first value is the X tiling, the second one is the Y tiling. In our case, we will only tile it on the X axis. If you don't use tiling, the animation will just be displayed once with velocity on the stage, and never appear again. That is not what we want in our case. When tile is set to anything over 1, it will cease to be infinite. Tile = 2,0 will show the stage item in the original location, and will place one more time, horizontally in this case. Hence, tile = 2,0 is showing the item two times. You can use tile this way to place something on the screen a limited number of times.

- tilespacing sets the space between the tiles. If you want to create a motif for example, you wouldn't put any spacing. However, in the case of our moving mushroom, we wouldn't want 10 mushrooms on the screen at the same time, and we don't want the mushroom to appear too often too. We will have to find/guess a good value to achieve this.


You should now start playing with these values, and try making the moving mushroom acceptable. Here is the code I have written for it, feel free to use whatever suits you :


velocity = 2, 0

tile = 1, 0

tilespacing = 1500, 0

- There's velocity only on the X axis. Value was made positive to make the mushroom move from left to right. You can make it negative if you wish to have it move from right to left.

- Tiling was done only for the X axis, with a tilespacing of 1500, which ensures it won't appear too often.

- I set the X start value to -270 too, so that it's not on the screen at the beginning of the fight, but appears a few moments after the fight starts.


5.2 - Adding clouds - Transparency

We will now be adding moving clouds in the sky. You won't learn many new things concerning animation. The goal of this part will be to :

- Train by adding several clouds at various speeds and heights. Some will pass in front of the mountains, some behind.

- Add some transparency to a sprite.


Once again, I won't be holding your hand, as you should have enough experience to add sprites in the SFF and code the clouds on your own.

- I added mario003.pcx, mario004.pcx and mario005.pcx in the SFF in group 3, number 0, 1 and 2, all with axis = 0,0.

- I added the medium sized one twice. It passes in front and behind the mountains. Big one passes in front of the mountains, small one behind. As said, you have white card to do the effect you want to, place the clouds at a height that suits you, etc. I made them move from right to left.

- Here is the code I use, if you want to look at it :

Spoiler, click to toggle visibilty

- Here's an image of what I get after writing this code :

We are now gong to make the clouds a little transparent, as real clouds. Note that I usually wouldn't make clouds of this type transparent, as it doesn't necessarily match with the sprite style, but the goal of this tutorial being to show you a maximum of stuff, this is the best way I found to introduce transparency.


There are two ways of applying transparency. One of them is by defining it in the sprites when creating an animation, which is a process we will see later on. We will now focus on applying transparency in the BG code itself, while introducing you to various types of transparency.

- Add the line "trans = " to the code of a cloud passing in front of a mountain.

- You can set the "trans" parameter with different values.

+ "none" for normal drawing. It's the usual behaviour and the default one if you omit this parameter (as it was done from the beginning of this tutorial).

+ "add" for color addition (like a spotlight effect).

+ "add1" for color addition with background dimmed to 50% brightness.

+ "sub" for color subtraction (like a shadow effect).

+ "addalpha" for colors with additive transparency (alpha must be specified).

Best is to test this parameter on your clouds sprite, and see for yourself what effect you get. In order, you have the cloud with "add", "add1" and finally "sub".

- As you can see, the "sub" effect is definitely not the one we are looking for, while both "add" and "add1" give very few transparency to the sprite.

- Let's now use "addalpha", and add a "alpha = " line in the code.

- The code for alpha is : "alpha = int, int", the first number being the source, while the second is the destination. Both values go from 0 to 256.

- Test values for alpha. Here are some examples :

+ First image is with alpha=256,128. Sprite is much brighter and a little bit transparent.

+ Second image is with alpha=128,128. Sprite has the same brightness, but with the transparency appears darker.

+ Third image is with alpha=128,256. Sprite has the same brightness, but appears more transparent.

- After some tests, I added these lines too all the cloud related code :


trans = addalpha

alpha = 200,255

- Here's an image of what I get with this code. In my opinion, it has enough transparency while not being too bright :

5.3 - Adding Princess Peach - Creating Animations

Until now, the elements we've added to make the stage more lively are just single sprites which we moved with the velocity controller. In this chapter, we are going to learn how to create an animation and display it on the stage.


- Let's start by adding the various Peach sprites in the SFF. They are the sprites mario006.pcx to mario009.pcx.

- While we could be adding them one after the other, as you used to do, it will be more convenient to add them all at the same time.

- Press the "Add" button, as usual, but instead of selecting one sprite to add, select all of Peach's sprites by maintaining Ctrl and clicking on the 4 sprites. Set the group to 4, and make sure the number is set to "0,1,2,3,4..." (look at where my mouse points) :

- Once this is done, press "OK". You've just added 4 sprites to the SFF, which is handy when you need to add dozens of sprites, depending on the stage you're creating.

- Luckily, your sprites are aligned. If you look at all the sprites, you'll see the sprites don't move all over the place each time. If it happens in your future creations with sprites of a same animation, align them by hand in the SFF, it's much easier than doing it by code, and much cleaner.

- Save your SFF file. We're now going to code the animation.


The code for using animations is almost the same as the one we've used before. Here is the "minimal" code for it to work correctly :


[BG Princess Peach]

type = anim

actionno = 1

start = 0,20

- You can see the "type" is not "normal" anymore, but "anim".

- Instead of defining which sprite to use for this BG Controller, you define which animation you're going to display, with "actionno". Here, Princess Peach will be defined in animation number 1.

- You may have noticed there is no "mask=1" line. As a matter of fact, using an animation automatically sets the transparency for the sprites.


Obviously, we now have to write the code for animation number 1. Here is how to write it :


[Begin Action 1] ;Peach on cloud







- To define an animation, you have to write in brackets [Begin Action XXX], with XXX being the number of your animation.

- The structure of each line is as follow : "group, number, X axis, Y axis, time". There are other optional parameters, which we'll see later. Let's focus on the basics for now.

- "X axis" and "Y axis" are way to modify the position of a sprite if you need to. They can help create animations by displaying sprites at various positions.

- "time" is the number of ticks the sprite is displayed before displaying the next one. There are 60 ticks per second.

- Mugen reads the code from top to bottom, and automatically loops the animation when it reaches the end of it. Hence, the animation will display in order sprites : 0 1 0 2 3 2 0 1 0 2 3 2 ...

- The odd tick numbers and order of the sprites was just to make the animation do things in the good order. You can see Peach looking elsewhere, then looking at you before winking, etc.


Write down this code at the end of the DEF file, and save before launching Mugen :

- You can now appreciate how the animation looks like, and if it suits you or not. Peach is obviously static in the air. You can apply some velocity to her to make her move (don't forget the tiling). In the next part, we will add some code to make the movement nicer.


IMPORTANT NOTE : The tilespacing parameter works differently for "normal" and "anim" elements. --;

- With "normal" elements (non-animated) when tilespacing = 0, 0, tiling will occur as one would expect where the element is duplicated with no spaces in between the images. A 100 x 100 image tiled once in the x direction will result in a total of 200 x 100 pixels of space covered.

- With animated elements, when tilespacing = 0, 0, tiling will not occur the same way but instead the tile will be created at the same coordinates as the original image. A 100 x 100 animation tiled once in the x direction will cover 100 x 100 pixels. To achieve a similar effect for normal elements, tilespacing should be the actual width of the image; in this case : tilespacing = 100, 0.


5.4 - Adding Sinusoidal Movement - The Grand Finale

We have nearly finished creating the stage !!! Congratulations if you've followed every step up to this point. ;) In this short chapter, we will just add some sinusoidal movement to Peach, and you will be able to train by writing the animation and code for Flying Mario.


First of all, here is the code I used to make Peach move :

Spoiler, click to toggle visibilty


With this code, Peach slowly moves from right to left on the screen, appearing every few seconds. However, the movement doesn't look very natural in my opinion, and doesn't give an impression of her floating in the air with her cloud. To this mean, we are going to apply some sinusoidal movement on Peach, by affecting the way she moves Y-wise (not X-wise).

To do this, I added this code :


sin.y = 7.5,96,0

- The 3 parameters are, in order of appearance, the magnitude, the time and the phase.

- "Magnitude" is the number of pixels it will go up and down (or left and right if you use sin.x).

- "time" is the number of ticks necessary to accomplish one cycle.

- "phase" should be used if you have several sinusoidal movements you want to differenciate a little. Learn some Maths to know what it is exactly.


You now have all the elements to do the final part of the tutorial : adding Mario sprites (mario010.pcx and mario011.pcx) and coding the animation and motion for him.

- Just one thing to be careful with : his sprites won't be aligned if you insert them both with "axis = 0,0".

- The rest of the coding is merely the same as Peach's one. You have to create an animation using another animation number. It would be nicer to make Mario move from left to right, etc.


Here is how the stage looks like after adding all the images included in the first file you've downloaded :

Congratulations, you have finished this tutorial !!!

Adding depth - Deltas

Posted on April 18, 2020 at 10:25 AM Comments comments (0)

Needless to say, the stage might be functional, but it lacks more elements. That's what we are going to add now, with different deltas, in order to add depth to the stage.


First of all, we are going to start organizing our work. Until now, with two images, there was no confusion possible in the DEF file, but as you add more and more stuff, in random order, it becomes convenient to label your work. I personally name all my BG stuff with comments. In the stage we currently have, I changed :

- [BG 0] to [BG sky]

- [BG 1] to [BG Floor]

It helps organizing your stuff easily. Only rule you have to respect is that it needs the word "BG" in brackets. Then, add the name or comment you want.


We will first add the mario002.pcx sprite, the one with a lot of fancy Mario related stuff on it. Let's start by inserting the sprite in the SFF.

- In FF, go on the last sprite of the SFF (sprite 0,1) and click on the "Add" button.

- You should see a new window called "Add image" appear. Browse to the mario002.pcx sprite. Don't add it yet, we have to set some values first. Set the number of the sprite to 2, since sprite 0,2 is not used yet, and it's a static background element, justifying group 0. You can leave the X axis to 384, since the sprite is 384 pixels wide too (yeah, life is easy with you). Don't check "Shared Palette" nor "Auto Crop". Your screen should look like this :

- Click on "OK". FF will tell you one sprite was added. Then, it will tell you that the sprite may have not been added correctly, since no palette is applied to the SFF. This is not a problem whatsoever for a stage.


We will now add the piece of code relative to this background element.

- Open the DEF file, and copy paste the code relative to the sky. Paste it between the sky and the floor code, and name it [BG Big Mushrooms, Plants, etc.] or however you want.

- You have to set the various values to match your sprite, as such :


[BG Big Mushrooms, Plants, etc.]

type = normal

spriteno = 0, 2

layerno = 0

start = 0, 47

delta = 0.9, 1

- spriteno = 0,2 corresponds to the sprite in the SFF.

- the start value (Y-wise) can be found by testing random values, or with some calculation : 47 = 240 - 156 - 37. I'll let you figure out this one.

- The delta allows the sprite to move a bit X-wise, compared to the floor and the sky. I kept the Y-delta at 1 because I don't want it to go "through" the ground when a character jumps.


However, if we launch the stage in Mugen, we get this horrible thing :

This comes from the fact that I didn't tell Mugen to consider the last colour of the palette as the transparent one. This is done by adding the code


mask = 1

Each time you use a sprite with transparency involved, you should add the code "mask = 1". You should use "mask = 0" (or ommit to write the code) only if the sprite is square and doesn't involve transparency, as the 2 precedent sprites we added, or when you're using the jiggsaw technique and want your 256 colors to be displayed correctly (cf. chapter "Avoiding colorloss")


This line being added, we now have a correct display :

The next part step will be easy, since we are just going to repeat the same process to add more mountains in the background. Hence, we are going to add mario013.pcx and mario014.pcx to our stage.

- I won't be explaining the process at all on this one. You have a white card to produce whatever you want, and you can place the mountains how you wish.

- THE ONLY RULE TO REMEMBER : the further the element, the nearest to the beginning of the code it must be. And the further the element, the smaller the X delta must be.

- I inserted both sprites using group 1.

- I placed mario014 behind mario013. Smalest mountains and lighter colors indicate further background mountains IMO. Both mountain sprites are obviously placed behind the [BG Big Mushrooms, Plants, etc.] stuff.

- I placed the mario013 mountains twice in the stage. Obviously, they were only inserted once in the SFF, but the code was doubled in the DEF file, with only the position changing.

- If you want to see the code I have written, just open the spoiler. However, I'd advice you to try to code it yourself first. You have all the explanations and knowledge to do so. It's just about reproducing what you have just done with the [BG Big Mushrooms, Plants, etc.] sprite :

Spoiler, click to toggle visibilty

- Here are two screenshots of what I have with my code :


We now have a very cool stage, with deltas giving depth to it. At this point, what differenciates a good stage from a bad/average one is the originality you put in the stage, and how you mix various elements. It's often a bad idea to mix different sprite styles (be it for a character or a stage).

Creating a stage for MUGEN

Posted on April 18, 2020 at 9:05 AM Comments comments (37)

- Start by installing stage0 in your Mugen (full or clean version, as you wish. Note that I will quote only the clean version later on), if it has not been done already.

- Open the DEF file with Notepad, and set debugbg to 1. Save the file.

- Launch Fighter Factory, and open the SFF file of the stage by clicking on "Sprites -> Open" :

- Browse to the correct path, and load the SFF :

- You can now see that the sprites are launched. I will now explain various buttons you can see in Fighter Factory, in order for you to add or remove sprites, align them, etc.


Here are the most important buttons we'll be using during the stage creation process. There are many other buttons, which you'll have to discover yourself, by playing with them.

1. The button defining which file you're working on. The sprites in our case. Other buttons concern AIR file, SND, DEF, CNS, etc. We won't take care of them.

2. The zone in which you can see your sprites. The cross in the middle defines the 0,0 axis (the origin). You can move the cross in the zone for better visibility, and you can interactively move sprites around the cross to change the axes of a sprite.

3. This button allows you to add sprites to the SFF, it adds the sprite just after the sprite you are on.

4. This button allows you to change the sprite you're currently on by another sprite of your choice.

5. Press this button to save your progress in a new file. You can use it to make backups.

6. Press this button to save your progress.

7. This button allows you to duplicate sprites. We won't be using it here. It's mainly for characters.

8. and 9. These buttons allow you to delete a sprite or a group of sprites.

10. This bar allows you to browse through all the sprites, you can see under it your position and the number of sprites in the SFF.

11. These blocks define the Group and Image parameters of the current image. You can use whatever group and number you want, but be careful to never have two (or more) sprites having the same group and same number. The convention is to put all sprites of the same type in a single group, and number them from 0 to the number of sprites. For example, mario006 to mario009 are sprites of Peach. We could place them at Group number 3, and number them from 0 to 3. During the tutorial, when I write "sprite 123,45", it means that it's the sprite which is placed in group 123, with the number 45.

12. These blocks define the X-axis and Y-axis of the current sprite. You can see their position in zone 2, compared to the central cross.

13. You can see the size of the image here. It comes handy when you have to do some calculations for alignment.

14. These magnifying glasses allow you to zoom in and out of zone 2, in order to get a better view of the sprites.


We will now start modifying the stage's SFF and DEF file to build our own stage.


3.1 - Setting the floor


- Go on the second sprite of the SFF (sprite 0,1), and press the "Change" button (button 4 on the screenshot).

- Browse to find sprite mario000.pcx, which is the floor of our stage, and click on "Open".

- You now see that the sprite was exchanged, and that our floor is the sprite 0,1, with axis=0,0. I personally prefer aligning my sprites in the SFF rather than in the DEF file, at least concerning the X axis. At the bottom left of FF, you can see the size of the sprite : 768x37 pixels. What I want to do is center the sprite on the cross X-wise, so that I will just have to use an axis of 0 in the DEF file later on. The calculation is very simple, we just have to divide the width of the sprite by 2 to get the center : 768/2 = 384. We just have to change the X-axis of the sprite to 384 and we will have centered it. You can either move it with the mouse in zone 2, or just write down the correct axis in the right box. By doing so, you won't see the sprite move in zone 2. Don't worry, it's just a little glitch. Go to sprite 0,0 with the bar, and go back to sprite 0,1. You can see your sprite is well placed now :

- Press the save button (button 6 on the screenshot) and launch Mugen to see how it looks like now :

- As you can see, there are several problems. There is magenta at the bottom of the screen (from DebugBG), so we will have to align the floor Y-wise. The characters are not standing perfectly on the ground either. We will have to change this value too, once the floor is aligned. Therefore, it's time to open the DEF file to start recoding some things.


For now, we will act on the floor's sprite. Search for this piece of code in the stage


[BG 1]

type = normal

spriteno = 0, 1

start = 0, 185

delta = 1, 1

mask = 0

velocity = 0, 0

tile = 1, 0

tilespacing = 0, 0

Let's analyze the code a little bit.

- type = normal is the usual parameter. We'll get back to this later.

- spriteno is the sprite number : group and number. 0,1 corresponds to our floor.

- start defines the position of the sprite at the beginning of the fight. The first value (0 in our case) is the X-axis, second value (185 here) is the Y-axis.

- delta allows you to create depth in the stage, by making the elements move one between the others, as some elements our closer to the fight while other are very far. For the floor, the delta should ALWAYS be 1,1 for low-res stages, and 2,2 for high-res stages. If you fail to comply with this, the characters will appear to slide on the floor, which is not suitable at all. The further the element is in the background, the lower its delta must be, in order for it to look natural and realistic.

- Velocity is what allows you to make the element move, tile and tilespacing allow you to tile your sprite. I will come back on these parameters later. For now, just change the tile to 0,0 :


tile = 0, 0


- We now have to align the floor Y-wise. To do this, just change the second value of the start parameter until you find something that suits you. After several tries, it turns out the best value is Y=203. If it's lower than 203, you will see pink, if it's higher than 203, part of the sprite will be lost out of the screen. Hence, I just changed the code to :


start = 0, 203

- However, even though the floor is well placed, the characters are now floating in the air :

- As said in chapter 2, the value relative to the position of the players on the ground is the zoffset parameter in the [StageInfo] part of the DEF file. Change the value until you find something that suits you. I personally set it to (open the spoiler if you want to see my value) ...

Spoiler, click to toggle visibilty

- I also set the shadow intensity to 0, as this stage won't have any shadows. We obtain something like this

3.2 - Setting the sky


We will now follow the same process to change the background of the training stage into the sky. I won't explain everything again, just refer to what you did on the floor sprite :

- In FF, go on sprite 0,0.

- Press the "Change" button.

- Browse to mario001.pcx (the sky sprite) and click on "Open".

- The sprite has its axis at 0,25. We will once again center it X-wise. The sprite's width being 768 pixels once again, the center is 384. Just for convenience, I used 0 for the Y axis. If everything was done correctly, you should have something like this in FF :

- Save your SFF file and launch Mugen, and you'll see something like this :

While it looks okay and proves everything is correct for now, it's not quite what we want. You can see that the top of the screen corresponds to Y axis = 0. We are going to change the sky's Y axis in order to get a full portion of it.


Open the DEF file once again and search for the code relative to the sky, which means sprite 0,0 :



  • [BG 0]
  • type = normal
  • spriteno = 0, 0
  • layerno = 0
  • start = 0, 0
  • delta = 1, 1
  • trans = none
  • mask = 0
  • tile = 1, 0
  • tilespacing = 0,0
  • window = 0,0, 319, 239


- Start by cleaning the code of the unnecessary stuff (I'll come back to it later) : remove trans, tile, tilespacing and window lines.

- We are now going to change the Y axis of the sky sprite. Try random values and look at what it does. Note that the Y axis is going from top to bottom, so if you want the sprite to go up, you have to input negative values. For example, if I set it to -220 like this : "start = 0, -220", it will result in something like this :

- As you can see, I put the sky too high, so there's a zone which doesn't contain any pixels, hence it appears in magenta due to debugbg. The value I set it too is -190. With this value, some portion of the sky is hidden by the floor, but I think it's high enough anyway.


IMPORTANT : As you may have noticed, the code relative to the sky is placed before the code relative to the floor. It was done on purpose. Mugen parses code from the top to the bottom of the file, so the first sprites to be displayed are those written at the beginning of the file, and the last ones to be displayed are those at the end of the code. To resume : arrange your code -> further elements are at the beginning of the file, close elements are at the end.


3.3 - Setting the bounds

Now you're asking "Damn, I have a huge floor and very wide sky, but my stage is small, how's that ?!" This is what we are going to correct now, which means setting correctly the bounds : the left, the right and the heigth one. We will set the left/right bounds, before setting boundhigh.


- In the DEF file, go in the [Camera] part of the code, and change the values of boundleft and boundright to high values (but always keeping their absolute value the same). In this example, I set them to +/- 300.

- Then, after saving, launch Mugen and go to one corner (the one you want) of the stage. As you can see, the stage is much wider, or rather, too wide :

- That's why it's important to always check the corners, as it's easy to miss a one pixel wide vertical line, especially if you didn't set debugbg to 1. Of course, I overdid it in the example, but it was just to make a point. Set the boundleft and boundright values to a value you feel is okay for the width of the stage. I used +/- 220.


Now we are going to set the boundhigh parameter following a similar process. However, usual characters can't go very high in the sky to allow you to check boundhigh. There are two ways of testing it, use the one you prefer :

1) Activate Debug mode by pressing Ctrl+D ingame. Jump with a character and quickly press Ctrl+I when the character is in the air. He will then stand in the air. Repeat the process as much as you need until the character reaches the top of the stage.

2) Choose one character of your choice which will always be your test character (it's better if you use this method only in a Test Mugen). Open the CNS file of the character, and look for the [Movement] section at the beginning of the file. Set the number of air jumps you can perform to a very high number, as such :



airjump.num = 999 ;Number of air jumps allowed (opt)

You character can now jump like crazy, allowing you to reach very high portions of stages.


Once you have chosen the method you prefer, set the boundhigh to a high value, and repeat the same process as for boundleft and boundright. For example, setting the boundhigh to -220 will lead you to something like this :

- After some tests, I set the boundhigh value to -185. Finally, we have a [camera] section with these values :


boundleft = -220

boundright = 220

boundhigh = -185


With all the work accomplished till now, we have a very basic functionnal stage. It has a floor and a background. All the bounds are set correctly, the camera doesn't move all over the place when characters jump, etc.

In fact, we've already gone further than most beginners. If you want, you can start creating basic one layer stages with this process, that's what many beginners do anyway. :P


To finish this part, let's just change the name of the stage and add an author name, because it's not a "Training Stage" anymore. I called it "Mario Tutorial - Basic Stage" and added my name as author. Of course, you call it as you wish.

Why Dragon Ball Minus is a terrible story

Posted on May 19, 2017 at 12:50 AM Comments comments (28)

Dragon Ball Minus is mainly looked down upon because of how it contradicts the already established history of a character - Goku's father. What really makes Dragon Ball Minus such a disgrace in my eyes, is because of this particular exchange from the Saiyan Arc:-

Before they start fighting, Vegeta tries to rattle Goku by comparing their statuses in Saiyan society, saying that Goku should feel privileged to fight an elite - that the whole reason Goku was sent to Earth in the first place, is because Saiyans are tested for combat aptitude at birth and those with no promise are sent to subjugate weak planets like Earth.

However, Goku is unfazed by this insult. In fact, he says he's glad to have been considered trash, because that was what had allowed him to escape those very limitations society had placed upon him. It taught him that hard work is more important than social status, or faith placed on him while he's still an infant.

Goku's journey throughout the Saiyan arc is finding out who he is - and it's nothing good. His native species are terrible people. His brother kidnaps his son, his other remaining kinsmen kill his friends. He has saved the world, when he was actually sent there to destroy it, and it was only through a lucky chance that that wasn't what ended up happening.

However, that's exactly who Goku is - he's one of them. Except that he's not. Even as far back as his birth, his people rejected him; labelled him as nearly worthless and shipped him off to do the only thing they judged him capable of doing and that's the beautiful irony of it all.

If they hadn't judged him to be inferior, he probably would have met the same fate as the rest of them and died. He certainly wouldn't have saved Earth and proven himself to be worthy to have trained under gods (Kami, Kaioh).

Only because his fellow Saiyans concluded he had no potential, did he manage to achieve it and now he is face to face with the personification of that bigotry (Vegeta) and he's about to show him what a low born cast-off can do and just how wrong they were about him. That, despite their aspersions on him, he can be better than all of them.

Unless, of course you believe Dragon Ball Minus, where his parents love him so much, they send him to Earth to thrive, which is exactly what he ends up doing anyway. YAWN!

 - MistareFusion

Samsung Corby Android 1.5-1.7 Skins

Posted on August 31, 2011 at 8:55 AM Comments comments (527)

Here are some skins/themes for Samsung Corby. Install S3650XEIJ2 firmware and then upgrade. 

Instructions and download on the forum.

Dragonball Z and DC vs Marvel MUGEN Screenpacks

Posted on December 19, 2010 at 4:14 PM Comments comments (156)

Whoever is wondering about these screenpacks:

You need Adobe Flash Player to view this content.


You need Adobe Flash Player to view this content.

Here is how you make the Dragonball Z screenpack and get the DC Mugen screenpack.

Check out the post here.

You must register to see the links. Please don't mind. :roll: It takes barely a minute.

Pok?mon HG / SS USA 100 % Working Freeze solution for R4 and lots of others!

Posted on March 22, 2010 at 2:50 AM Comments comments (22)

You need Adobe Flash Player to view this content.



No$GBA 2.6: Works, but freezes in-game so save a lot!

R4 SDHC: Works! There is 1 report freezing after 3 hours (with YSmenu)

R4i-Gold v.1.31b: Works!

N5: Works!

DSTT inofficial 1.17.12a: Works!

DSTT official: Don't use YSmenu on the DSTT. then it should be fine (EDIT)

R4 (1st edition): Works! (EDIT)

EZ-Flash: Works!

M3-DS Real: Works when running M3 Sukra!

YSmenu (Latest version): Works!

TTDSmenu: There are some reports it works, and also some that it doen't work

Pre-Patched Roms Download:

link removed. Patch no longer required as the U.S.A version has been released and works perfectly.

Please take a minute out of your time to register at the members area for free to access the download. :)