Beta 564 - SUPER SLOWDOWN

But 560 works okay?

I'll check when I get home. I went right from 509 to 564. I'll try the intermediate versions to see where the problem lies.

I know my scripts arn't the most elegant (fuck, we don't even have switch statements or arrays) but they weren't causing this sort of slowdown back in 509.

Holy shit, 12 fp ****ing second in 564, are you kidding. I've never had that happen. C-, are you using a script to purposely slow down the player? 😛

I was extremely satisfied with the non-wavering 60 fps for the last 5-10 builds...untill now. What could cause that dramatic of a change since 509?

Anybody have a more precise idea of which build started the slowdown?

Yep, It works fine in 548 - Somewhere between then and 564.

Here's my 2 cents
I was playing around in 564 with the sideview gravity and the rocks feather and jumping and hitting the directional arrows would sometimes start dimming the screen as though it was pulling huge amounts of power.
Never saw that before. 😉

The last revision to be non-sluggish is 550. I'll investigate.

I've figured out what's causing the slowdown - you're writing to Link->Item[] every frame, aren't you? 😞

Changing Link's items is possibly the slowest of the ZScript commands, because of all of the overhead involved. When you change his items, ZC has to:
- Process the side-effects of gaining that item,
- Clear the cache of which item of each item class has the highest level (expensive)
- Compute if Link needs to change his A or B weapons, and do so if he does.
- Rebuild the subscreen using the new information above (expensive)

Pre-550 was faster than the current build because a bug prevented the last step from taking place; for obvious reasons I can't undo that change.

I have made some optimizations to improve performance, but changing Link's items every frame is probably still going to cause a performance hit. Please don't do that 😉, at least until 3.0 when we rewrite ZC from scratch with the item system in mind from the start instead of a tangled mass of hacks.

You gotta be fucking kidding me. Rebuilding the sub-screen causes THAT much slowdown?

Well, this is a problem. I can work around it, of course, but I was relying on the ability to manipulate the player's inventory every frame to:

(1) Change the player's sprite depending on circumstance; and
(2) Adjust arrows / bombs per special abilities to preset levels.

I guess I can rewrite the code to only change inventory when the player's state changes, that should help somewhat... but it'll lag the game when the player's state changes, like say, when they grab onto a wall and cling. Eek.

Have you tried the latest build? I have optimized it as much as I can without an extensive rewrite, and it does perform considerably faster than 564; I get 60 FPS on my middle-end laptop. I'm just letting you know where the bottleneck is, so you can design around it if you need to in the future.