@grazer after months of struggling to figure out why games like Starblast 2 and Vortex lag so badly, I realised now that the games don’t lag at all, in fact, they run perfectly in embed mode. The lag issue has something to do with flowlab itself. However, I did notice that while holding S to shoot, sounds of enemies being shot or bullet streams just cut off or stop playing, leaving silence or only music playing for brief periods. I’ve noticed this in a few other games, but it’s not common unless there are more than 3 sounds playing at once. I did some testing in the bug editor and could not find the cause of the sounds cutting off, but I did notice that when in the lag pong tester, in /play the game will freeze up around 60-65 balls and you won’t be able to move without the game seizing up. However, in /embed I was actually able to go well over 200 pong balls and still move without any lag spikes at all. There was just a noticeable slowdown, but no loss of controls, and I was able to erase all the lag balls and resume the game at full speed. The lag seems to only present itself in flowlab itself. I never needed to make a December buglist, but these may be two bugs I could suggest looking into, besides flip/back making the sprite rotate.
Sounds cut each other off
Lag in /play but not /embed
Flip/back doesn’t work correctly with filtered extracted x velocity
Hey @“Mhx Ar” - thanks for the feedback, I’ll do some measurements to try and sort out why embed mode might have better performance.
I just tested Vortex, and it does seem to run a bit better in embed mode, but I haven’t measured it yet to see if the framerate is actually higher. I’ve spent quite a bit of time profiling Vortex, and I’m pretty confident I know what’s going on with the framerate:
Proximity checks are slow, relatively speaking. I spent a little bit of time making them a bit faster, but so far it hasn’t been enough to make a huge difference in Vortex.
Here’s a trick to try: Open up “New Type 10” (the background) and change the exhaust Proximity trigger to a Collision instead. The framerate will be tons better. Also, make sure that the emit lifespan is as low as possible for the exhaust and the bullets (i.e., make sure that the objects get destroyed as soon as they become invisible or fade out) These two changes should make Vortex pretty playable.
Thanks again for reporting these issues and keeping an eye out for bugs
I’ll probably rebuild Vortex from scratch with an improved engine. It’s outdated now and too unorganized, plus the proximity checks are completely broken now. I have a few ideas for workarounds now that there are so many improvements to flowlab. Still, Starblast 2 also lags, but not in embed mode, and not on Newgrounds. The lag seems to only exist when on flowlab, and it might be because you can’t access the editor in embed mode. Like I said, in bug tester, flowlab freezes at 60 objects on screen. In embed, you can have well over 200 objects and it just goes a bit slower but never freezes up.
As for sounds cutting each other off and flip/back not working right, I’ll do more testing after Christmas.
That’s an interesting result in your bug tester, @“Mhx Ar”. I just tried it here, and I get the same behavior in embed mode or play mode. In both cases, it gets pretty laggy after about 60 or ping pong balls. I haven’t done any profiling, but I suspect that the majority of the time is being spent in collision checks.
I use Google Chrome on the laptop. Normally, when I play on play mode or View mode, around 60 to 65 it will lag, but pressing any key on the keyboard at all, even keys that are not registered to flowlab like shift or something, the screen, game, and browser will freeze up for a few frames and will not register a button press, for example, if I want to erase all of the balls, I will have to hold the F button, because it will not register the F button for a few frames from the lag.
This bug was present on every computer and laptop I borrowed or tested including my old laptop that I used to have that I borrowed from my brother. Now that is why I assumed the problem lies in flowlab itself, because as I said, in embed mode, I can have 200 or more balls and the game will slow down but will never freeze or lag spike. It just significantly drops frames, because it is having a hard time processing 200 objects on the screen at the same time bouncing around, so it just looks like jittering balls. That’s to be expected, however this new laptop has twice as many cores and I believe 8 gigs of RAM, Which is far better than the last few computers I tested on. It might be an issue of computer speed for embed mode, but I never really got around to testing in embed mode.
This also leads me to believe that games may run even smoother when they are exported, since they do not rely on being online. That being said, all of the slowdowns I have had in many of the games I tested seem to only present themselves on flowlab, but not when embedded.
You can look into this further if you like. I just feel better knowing that I can build more complicated games and they will run perfectly fine on any other site.
Actually, you could try removing the editor in /play, and only have the editor in /view. Maybe this would make the games run as smoothly as when they are embedded. Nobody else needs to edit your game anyway, and if they did, they could go to /view, since the games are locked to others anyway.
In Flowlab, embed mode uses “opaque”, but other modes use “direct”. Direct is supposed to provide the best performance, and the other modes seemed to make the mouse laggy. This is interesting though, I’m not sure why the key handlers would be effected this way.
Glad I’ve been able to help you track down some bugs that you haven’t previously noticed before. I’m actually very curious myself why these things happen. What browser were you using? Opera? Firefox? Firefox still occasionally gave me problems, but I’ve heard that Opera is apparently the best browser. I’ve just used chrome for years, and never really tried anything other than other chromium type browsers.
I switch between Chrome and Firefox (and sometime Safari), but mostly Firefox for testing and development. The wmode thing is tricky, since there doesn’t seem to be one “best” setting. The one that the embed mode is using (“opaque”), which apparently is fixing the keypress lag, actually causes mousemove drag and makes the editor to perform poorly. Anyway, maybe I can try to figure out a workaround for this keypress issue.
