YesNoOk
avatar

Lag problem! (Read 1291 times)

Started by Seravy, January 25, 2009, 04:21:52 am
Share this topic:
Lag problem!
#1  January 25, 2009, 04:21:52 am
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
I'm finally done with adding all attacks to my new character(s), and when I wanted to start testing, I noticed that it lags now. However, the lagging stuff is not what I would expect, but those quite simple attacks I added first and were working before perfectly (I didn't change anything in them either and they cause more lag than many more complicated attacks, while they didn't lag at all before).
The current sff is a bit more than 12 MB, the previous, lag free version is 11. I tried disabling the sound but the lag continued, so there should be no problems with the snd I think.
This however poses an interesting question, can a 10% increase in the sff file cause such noticeable lag? Could it be that the engine looks for the sprites to display in backwards order, so stuff in the beginning of the sff lags more? Or should I look elsewhere like in the increased air or cns file sizes?

If anyone has similar experiences, please do tell, I'll try reordering the sprites to see if it changes what lags and what doesn't.
Re: Lag problem!
#2  January 25, 2009, 04:26:14 am
  • ******
    • Portugal
    • network.mugenguild.com/pots/
Does it lag all the time or only in particular states?  Is the sff cropped and sharing palettes where due?

If you have persistent helpers try gradually disabling them one at a time and see if any of them's causing it.
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Re: Lag problem!
#3  January 25, 2009, 04:57:40 am
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
After some testing, it seems that anything creating new helpers makes the lag. On the other hand however, no matter what's already on the screen, there is no problem, as long as nothing new is created. (Sometimes also when destroyed like fireball hits).
As much as I can tell only helpers do it,and only when created, explods have no problem (The Snow makes 500+explods and no lag there).

I think this could be memory allocation speed problems? Not reasonable with 512MB of ram...
Or some other engine problems in the helper creation part of mugen?
Graphics are out as a problem source I think as no matter how many explods, or already existing helpers are there there is no problem.
What's interesting in it is, no such lag happened while the sff/snd/air/cns were 10-20% smaller. How does that relate to creating new helpers?

sff has no problems, most everything worth cropping is cropped. (I didn't bother with sprites where only 1-2 pixels would be the extra)
Palettes are also ok.
Re: Lag problem!
#4  January 25, 2009, 05:07:18 am
  • ******
    • Portugal
    • network.mugenguild.com/pots/
Can you post the sctrl and state for one of those helpers?
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Re: Lag problem!
#5  January 25, 2009, 05:18:11 am
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
This is the simplest one (the Wind attack). Unlike the fireball this doesn't always cause noticable lag, but sometimes does. (The fireball makes 3 helpers, so it also lags more)

Code:
[Statedef 500] 
Type     = S
MoveType = A
Physics  = S
Anim     = 310
Ctrl     = 0
Facep2   = 1
PowerAdd = 30

[State 500]
Type=VarAdd
Trigger1=animelem=2
v=16
value=30

[State 4000]
Type=VarSet
Trigger1= AnimElem=2
v=56
value=50

[State 240]
Type = Helper
Trigger1 = AnimElem=2
StateNo = 3999
ID = 3999
Name = "Circle"
Pos = 0,0
PosType = P1
Ownpal = 1
IgnoreHitPause = 1
Size.xscale=0.1
Size.yscale=0.1
PauseMoveTime=9999999

[State 220]
Type= PlaySnd
Trigger1= AnimElem=2
value=7000,2

[State 220]
Type= PlaySnd
Trigger1= Time=0
Value=310,0

[State 220]
Type = Helper
Trigger1 = AnimElem=2
StateNo = 501
ID = 501
Name = "Windy"
Pos = 40,0
PosType = P1
Ownpal = 1
IgnoreHitPause = 1
Persistent = 1
Size.XScale = 0.6
Size.YScale = 0.6

[State 220]
Type = ChangeState
Trigger1 = AnimTime=0
Value = 0
Ctrl = 1

[Statedef 501]
type = A
MoveType = A
Physics  = N
Anim     = 10010
SprPriority = 4

[State 221]
Type = HitDef
Trigger1 = time=0
Attr              = A, NP
Damage            = 85,1
GetPower          = 50,10
AnimType          = Hard
HitFlag           = MA
GuardFlag         = MA
Priority          = 4,Hit
PauseTime         = 0,0
SparkNo           = -1
Guard.SparkNo     = -1
SparkXY           = -25,-25
HitSound          = -1
GuardSound        = -1
Ground.Type       = High
Air.Type          = Low
Ground.SlideTime  = 16
Ground.HitTime    = 16
Air.HitTime       = 16
Ground.Velocity   = -12
Air.Velocity      = 0,-4
AirGuard.Velocity = -3,-3
Air.Fall = 1
Fall.Recover = 1
ID = 501


[State 221]
Type = VarSet
Trigger1 = Time = 0
fvar(0) = 8

[State 221]
Type = VarAdd
Trigger1 = Time = [1,21]
fvar(0) = -.325

[State 221]
Type = VelSet
Trigger1 = 1
X = (fvar(0)*Cos(30*(Pi/180.0)))
Y = -fvar(0)*Sin(30*(Pi/180.0))

[State 221]
Type = DestroySelf
Trigger1 = AnimTime=0

[State 221]
Type = AssertSpecial
Trigger1 = 1
Flag = Noshadow
IgnoreHitPause = 1

[State 221]
Type = Trans
Trigger1 = 1
Trans = AddAlpha
Alpha = 136,256

I'll try cutting down on sff size (I think there are some sprites that could be resized/removed), as I had no problem with an 1MB smaller one. (I used this wind attack code on two other characters with no problems before, some to the fireball even with a version that creates 7 of them, so it must be some kind of a memory issue caused by that additional few MBs I think...)

ok...sff is now only 500k larger than before, snd is about 2mb larger. Still lags. However, out of two attacks that throw out 10+ helpers per second, one has no lag at all, while the other has a lot. It seems that helpers getting created with size.xscale and/or trans lag more, so this is the next to investigate.

Also tried removing all of state -1 and -2 only to see if those sctrls might cause it but they didn't.
Last Edit: January 25, 2009, 06:27:40 am by Seravy
Re: Lag problem!
#6  January 25, 2009, 06:48:33 am
  • avatar
  • ******
    • Thailand
the problem is the summoning of the helpers at same exact time using animelem,


try summoning them like:

animelemtime(2)=0

animelemtime(2)=1


that worked for me.  :P
Re: Lag problem!
#7  January 25, 2009, 07:15:35 am
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
I already tried that, the fireballs had time=4, 5 and 6 as triggers for each one.
Also, the Circle helper was removed for this attack, so it has one helper only. (Basic attacks don't need a spellcasting circle anyway)

On the other hand, I got rid of the lag an unexpected way :
I removed 80 small sprites of about 2kbyte each (about 200k total size reduction from 11.5MB to 11.3), and all the lag went away the way it suddenly came.
My three primary suspects for the case :
1. The number of sprites matter, not the size of the sff.  (highly unlikely, most characters with 1500+ sprites work fine for me and this was around 1000)
2. The number of Palettes matter (all of these were set as individual, they were the text for attack names and each had a different color)
3. The order of sprites matter somehow (also unlikely, I tried placing those spites I just removed to two different places already)

Next thing to try is putting all those back but now with a shared palette setting.
Re: Lag problem!
#8  January 25, 2009, 07:48:47 am
  • avatar
  • ******
    • Thailand
Coincidentally, adding shared pallets does decrease lag, i just tested it out, Now i must go make some adjustments.  :-X
Re: Lag problem!
#9  January 25, 2009, 07:56:39 am
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
Yes, it solved my problem completely, even if they were back in with shared palettes, I had no more lag.
Time to check all the sprites if they are shared or not, I already found a big group of about 100 sprites which I though were shared but they weren't. This also explains why Yu-Toharus latest version of Hatsune Miku is lagging soo much, that group of sprites came from her sff.
It also gives me an answer to the question why shared palettes are better, when most stuff work with individual as well.
Re: Lag problem!
#10  January 25, 2009, 07:58:58 am
  • avatar
  • ******
    • Thailand
yeah, this explains a lot for me as well, it solves a load of problems, thanks for suggesting that. somewhat ;P
Re: Lag problem!
#11  January 25, 2009, 10:28:40 pm
  • ******
    • Portugal
    • network.mugenguild.com/pots/
You can help with Ikemen GO's development by trying out the latest development build and reporting any bugs on GitHub.
My Mugen and Ikemen content can also be found here.
Re: Lag problem!
#12  January 25, 2009, 10:43:58 pm
  • ******
  • [E]
    • Mexico
the size of the sff does not directly indicate how much ram the character is going to take, the sprites are decompressed to memory so even a smaller sff might use more ram than a bigger one.
Re: Lag problem!
#13  January 25, 2009, 11:34:16 pm
  • avatar
  • ******
    • Thailand
but why exactly does adding shared pallets reduce lag/eliminate it. Is it because MUGEN loads a bunch of mini pallets for the helpers or something?
Re: Lag problem!
#14  January 26, 2009, 01:24:34 am
  • avatar
  • ******
Well yes, if it's shared, there's less palette to load, so less data (the helper can have its own palette but all the helper spirtes can just share palette between each other while still not being shared with the character). But I dunno if the difference should matter that much considering the size of one palette, even multiplied by 500...
If I struggled to the end of my determination, to the end of my way of life with my followers, if the result is ruin, then this ruin is inevitable. Grieve. Shed tears. But you cannot regret.
Re: Lag problem!
#15  January 26, 2009, 09:38:14 am
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
I also think it shouldn't matter, but it does. And the difference was only about 80 palettes. It's probably some coding problem in the engine that only comes out if a certain number of palettes is exceeded.
Re: Lag problem!
#16  January 26, 2009, 06:47:19 pm
  • ******
  • [E]
    • Mexico
I think that this possible scenario (give me mugen's soruce code to prove me wrong) is this.

mugen creates a helper, if the palette is not shared then it has to apply a certain palette to the sprites as opossed to reusing the char's sprites.
Re: Lag problem!
#17  January 26, 2009, 09:48:06 pm
  • avatar
  • ******
    • Thailand
That's what i imagined MUGEN does, that makes the most sense to me.