Main Menu
  • Welcome to The RPG Maker Resource Kit.

[RESOLVED] event lag?

Started by da good king, August 03, 2007, 01:33:00 AM

0 Members and 1 Guest are viewing this topic.

da good king

okay, In my game, the first town has a bazaar, right? well, that means LOTS of people, right? :(
so, that also means am @$$ load of lag. :tpg:..I used ABSEAL and verything, but it still lags to death! >:(

Anyone know how I can reduce this damn lag? :-\

xeph

If its xp use an antilag script if its 2003 at the begining make and event that makes things faster

da good king

thanx
but ABSEAL is the BEST anti-lag script.

xeph

ANOTHER SULOTION ok use the speed up thing in the beging of the game (it will be a little bit laggy but..)

da good king

speed up...thing? what do u mean?

i made less characters move at random, and stay fixed. That reduced it a ton, but only a few move now and it still lags a but...i don't want no one to move, i mean, it's a freakin bazaar!

xeph

Ohmygosh lol the speed up thing is in your move event thing =)

da good king

That just speeds up walk speed...the lag I'm suffering from doesn't slow me down, it glitches and slows the whole screen down.......hmm...

I might have to get rid of a few people...I guess bustling cities filled with wild crowds are just a little too much for the old RMXP...huh, wonder why I never thought of this before....all the people that aren't doing anything, are as good as a tiles, right?

Well, tiles don't slow the stupid thing up!!!

modern algebra

http://rmrk.net/index.php/topic,1121.0.html

landofshadows made a few crowd graphics. That should give the impression of a lot of people bustling about, but it only uses one event.

da good king

#8
true...well, I have also used the idea of replacing most events with tiles, and has improved lag greatly! this crwod thing'll help, too.

wow, i must be tired, my grammar is suffering......well, thanx for the crowds! they didn't solve the lag problem, but they made my bazaar like time square!

also, after copying the map on a new project w/o any events at all, i have discovered it is probably my laptop. My character as moving almost full speed, but the screen was stll laging and glitching. Adding events really actually didn't change ANYTHING. Very minor changes, that is.

Well, tomorrow i'll send a link for my map, and I ask that someone test it for me for lag, to see if it really is just my crappy laptop.

Zeriab

If you have too many events on the visible part of the map it'll lag pretty much regardlessly of the anti event lag script used.
I am afraid the reason is due to bad engine design. If it is this, then there is nothing you can do. We might be able to speed other things up though.
I do have an idea for anti event lag script btw. You would need a scripter to do it ^_^

[spoiler=Idea]The principle in my idea is not to optimize the current design, but instead to alter the design.
I would instead map the events accordingly to their coordinates.
We could for example do something like this:

$game_map.map_events = {}
$game_map.map_events[[x,y]] = event
# or
$game_map.map_events[[x,y]] = [event1, event2]   #so there can be more than 1 event on that tile

Naturally I would implement it in the Game_Map class; it is just to give the idea.
I am not saying that using a hash in that way is the most efficient way, but it is conceptually easy to understand.
Perhaps it would be better to encapsulate the map of events in a class, I am not sure.

Think about how fast collision detection becomes.
If a event moves to the left it is simple just to check what is in $game_map.map_events[[x-1,y]]
This is much much faster than the naive collision detection that is in the original scripts

Another bonus is which events to update.
Just check for events in the visible part of the map and a buffer (a tile or two outside the screen) in the hash-map. Update the found events.
You won't event process outside events.
An added bonus of this is that the size of the map is irrelevant when updating the events.
The cost is simple just more ram usages.
The speed is dependent on how many events are visible.

We can take this and go even more advanced. Why should events outside of the screen have sprites?
Sprites will slow down the game significantly even if they are outside the screen.
1 or 2 sprites make no difference, but what if you have a 500x500 map with loads of events?
500 sprites outside the screen... I think you get my point.

We can do some tricks to make the adding and removing of sprites faster.
We only have to consider which events move into the buffer and out of the buffer. This is why I wanted a buffer previously. Otherwise the player might notice the events blink in and out.
If the player moves to the right then we should consider the new 17 or 19 tiles that comes into the buffer and create the sprites for the events there, while removing the sprites for the tiles going out of the buffer.
Naturally we will also have to check when events move whether or not the go inside or outside of the buffer/visible area.

~ Zeriab[/spoiler]

modern algebra

That's a great idea for an anti-lag

da good king

those are very good ideas Zeriab. I must say I was thinking of things similar myself a while back. Perhaps we should post ur idea as a script request?
Events outside the screen was the first thing that came to mind, since my city IS 61x90, (not TOO big) and even when I'm on the outskirts of town where there is little more than one person, the screen still lags just as much.

unfortunately, in my case, as I have said, the same map, with NO events (and even some demos I've tried) lag incredibly on my laptop. So I'm not sure I'll ever be able to banish lag from my laptop.

Also, could someone test for and tell me if it lags on their computer?
the map
the tileset

just to save time, I didn't upload the the tileset data or scripts for messages, so...too bad.

I'd really appreciate if someone could tell me if this works.

Kokowam

Quote from: Zeriab on August 03, 2007, 06:25:40 AM
[spoiler=Idea]The principle in my idea is not to optimize the current design, but instead to alter the design.
I would instead map the events accordingly to their coordinates.
We could for example do something like this:

$game_map.map_events = {}
$game_map.map_events[[x,y]] = event
# or
$game_map.map_events[[x,y]] = [event1, event2]   #so there can be more than 1 event on that tile

Naturally I would implement it in the Game_Map class; it is just to give the idea.
I am not saying that using a hash in that way is the most efficient way, but it is conceptually easy to understand.
Perhaps it would be better to encapsulate the map of events in a class, I am not sure.

Think about how fast collision detection becomes.
If a event moves to the left it is simple just to check what is in $game_map.map_events[[x-1,y]]
This is much much faster than the naive collision detection that is in the original scripts

Another bonus is which events to update.
Just check for events in the visible part of the map and a buffer (a tile or two outside the screen) in the hash-map. Update the found events.
You won't event process outside events.
An added bonus of this is that the size of the map is irrelevant when updating the events.
The cost is simple just more ram usages.
The speed is dependent on how many events are visible.

We can take this and go even more advanced. Why should events outside of the screen have sprites?
Sprites will slow down the game significantly even if they are outside the screen.
1 or 2 sprites make no difference, but what if you have a 500x500 map with loads of events?
500 sprites outside the screen... I think you get my point.

We can do some tricks to make the adding and removing of sprites faster.
We only have to consider which events move into the buffer and out of the buffer. This is why I wanted a buffer previously. Otherwise the player might notice the events blink in and out.
If the player moves to the right then we should consider the new 17 or 19 tiles that comes into the buffer and create the sprites for the events there, while removing the sprites for the tiles going out of the buffer.
Naturally we will also have to check when events move whether or not the go inside or outside of the buffer/visible area.

~ Zeriab[/spoiler]
Tl;dr. Anyone mind summing it up for me? I read a bit but I was overwhelmed.

da good king

he's saying to correct a few stupid mistakes the program has, such as keeping track of events you can't even see.

Well, just tested my again, and.......it's fine. laptop must have been fried yesterday from all the work I've been doing. Even with all the crowd events, it's working!
thanx all! think I'll call this one resolved.

Zeriab

Lol, I'm glad that it works now, whatever the reason was for it lagging before.

I am too lazy to do the script myself  ;9
Maybe I'll try to get Blizzy to do it. He is not as lazy as I am.

da good king

laziness is a mental illness, i swear to god

i suffer from a ba case of it...