Need help reducing/removing lag for Falcao's Interactive System Lite

[KingHazeel]

I'm currently using Falcao's Interactive System Lite v2:

https://falcaorgss.wordpress.com/2012/11/22/falcao-interactive-system-lite/

And I've noticed that placing pushable events on larger maps cause significant lag. By commenting out lines 695 to 726, I removed the ability to let events fall, and this significantly reduced the lag. However, pushable events still cause noticable lag. This is more noticable the more events there are. To test this out, I scattered 20 pushable boulders in my 100 by 100 city. The choppiness was unacceptable and if I can't get away with it here, there's no way I could scatter these types of events in the overworld.

I'm willing to give up some features if necessary, but I do want to at least maintain the ability for the player to fall and for switches to be activated by pushable events.

Also, this is somewhat unrelated, but to avoid spamming topics, does anyone know a good way to create invisible walls?

https://i.imgur.com/fa0yy7p.png

The beach is meant to be a lower area than the stone wall, and I don't want the player to simply be able to "walk down to it", so I have a bunch of events lined up as an invisible barrier. Right now it's not causing issues, but it doesn't seem like a good habit to get into in the long run. Is there a better way to handle it?

 

[bgillisp]

I've moved this thread to RGSSx Script support. Please be sure to post your threads in the correct forum next time. Thank you.

100 x 100 tiles can often cause lag anyways, without this script. You might want to see if you can break up the map into smaller maps, as my tester hit 8 FPS on one of my big maps until I broke them up and added an anti-lag script.

 

[KingHazeel]

Dang, really? I thought 100 x 100 was pretty small...I mean the overworld has gotta be bigger than that, even if you try to break it up.

 

[bgillisp]

Not really, many games have much smaller overlands than you think. For example, FF6 has an overworld of around 127 x 127. My game did it with 83 x 72. Remember the player sees a much smaller view than you do in the editor.

 

[KingHazeel]

Took me a moment to realize you were talking about the world map setting. XD I was honestly thinking of nixing that in favor of a on-scale overworld that you would see in games like Pokemon or Zelda...but if 100 x 100 is stretching it, I suppose a seamless huge overworld is less realistic than I had hoped.

EDIT: Also doesn't this belong in VX Ace support? From what I can tell, this is a VX Ace script and is meant to be run in conjunction with another VX Ace script (Pearl ABS).

 

[bgillisp]

Anything involving scripts goes in script support. Ace support is for how to use the default engine.

As for the ?, it does depend on what is on the map too. I did manage to pull off a 140 x 140 map that worked with very few events, as it is both the size and the # of events that matter. You can get a 20 x 20 map to lag if you put an event on every tile and some are parallel processes.

 

[KingHazeel]

OK! I discovered something interesting. I was testing what conditions the script would lag in, so I started small with a 20 x 20 room with a few pushable objects...and it was already lagging. I realized something was off and thought maybe there was another script causing conflict with this one. So I started deleting things until I noticed an improvement....and of all the scripts to cause problems, it was this one:

https://area91.multiverseworks.com/rmvxa/scripts/dev/inpex

Somehow, a script focused on changing the control scheme was causing issues for this. I found the "area" of the code that's causing the problem.

#----------------------------------------------------------------------
# * Alias: Direction (Up, Down, Left, Right)
#----------------------------------------------------------------------
alias input_dir4_cxj_inpex dir4
def dir4
shortest = -1
if CXJ::INPEX::HOOK_GAMEPAD_TO_INPUT
if CXJ::INPEX::INCLUDE_CORE
shortest = Gamepad.dir_shortest_time
val = Gamepad.dir4
else
shortest = CXJ::INPEX::Gamepad.dir_shortest_time
val = CXJ::INPEX::Keyboard.dir4
end
end
#if CXJ::INPEX::HOOK_KEYBOARD_TO_INPUT
# if CXJ::INPEX::INCLUDE_CORE
# s_key = Keyboard.dir_shortest_time
# val = Keyboard.dir4 if val == 0 || (shortest > -1 && s_key > -1 && s_key <= shortest)
# else
# s_key = CXJ::INPEX::Keyboard.dir_shortest_time
# val = CXJ::INPEX::Keyboard.dir4 if val == 0 || (shortest > -1 && s_key > -1 && s_key <= shortest)
# end
#end
val = input_dir4_cxj_inpex if val == 0 && CXJ::INPEX::ENABLE_COMPATIBILITY
return 0 unless(get_dir_enabled(val))
return val
end

 

[KingHazeel]

OK I've (crudely) changed the dir4 definition based on Helladen's WASD movement:

alias input_dir4_cxj_inpex dir4
def dir4
return 2 if Input.press?DOWN)
return 4 if Input.press?LEFT)
return 6 if Input.press?RIGHT)
return 8 if Input.press?UP)
input_dir4_cxj_inpex
end

This has significantly reduce the lag, but it's still present. I notice that its at its worst if I'm moving up...however if I change dir4 to be this:

alias input_dir4_cxj_inpex dir4
def dir4
return 8 if Input.press?UP)
return 2 if Input.press?DOWN)
return 4 if Input.press?LEFT)
return 6 if Input.press?RIGHT)
input_dir4_cxj_inpex
end

UP is the most "lag free" direction, but moving right causes the most issues...