Tom wrote:

I tried your game and didn't detect this problem, but I suppose it's machine-dependent. Could you make a version that starts at a high level with lots of particles moving? I will see where it's getting bogged down. I suspect it is due to garbage collection due to the object limit rather than the drawing itself, but we can likely change the way that works. I need a reliable way of seeing the issue though.

Here you go.

I've made it so balls will spawn infinitely (so you can see the deterioration of responsiveness). You also have infinite clicks here. You can right click to place an inert large ball, so nothing will collide with it; it'll just demonstrate the lack of responsiveness with clicking. Left will still place an active ball. Press R to restart.

I suggest waiting until the red marker in the top right corner is at -50 or so. Try to move the window around while the particles are spawning, you'll see a gradual decrease in responsiveness. The map and display will stay virtually flawless for the movement of small balls.

If you left (active ball) or right (inert ball) click with a lot of balls on the screen, it'll take awhile to respond, mouse responsiveness is awful with a lot of balls. Left click will eventually start a reaction, balls will collide and often freeze for a moment when the "sparkles" shoot out from reactions. (There is an S macro to toggle the spawning of collision sparkles, I think sparkles are a separate issue, so.)

I can provide the entire source (it's pretty small), if you want to see the whole thing.

Thanks. I'm seeing the delay now.

I'm quite certain the issue is due to the client/server both being on the same thread, where the server is sending so many updates that the client's message queue is backlogged. You'll notice that if you run this as an external server on your machine, it works fine (I tested up to 500 balls). We plan on multithreading the client/server so that should resolve the problem, but I'll see if there is a way to improve that beforehand.

To be clear, all I mean is that we'll put the client on one thread and the server on another. Supporting multithreading on the server itself is far more difficult and probably unrealistic, but we could investigate to see if it could at least be used for things like resource transfer.

It means I won't have to use DreamDaemon to test fancy mouse controls solo without it being completely unresponsive.

Tom wrote:

Thanks. I'm seeing the delay now.

I'm quite certain the issue is due to the client/server both being on the same thread, where the server is sending so many updates that the client's message queue is backlogged. You'll notice that if you run this as an external server on your machine, it works fine (I tested up to 500 balls). We plan on multithreading the client/server so that should resolve the problem, but I'll see if there is a way to improve that beforehand.

Wow. I've been busting my butt trying to speed up the display in my game, cutting things out, trying to optimize anywhere I can, using alternative methods just to keep things playable. Running in DD made a HUGE difference. I couldn't figure out how to fix it since the cpu was always pretty low, but the display was occasionally grinding nearly to a halt.

Thanks, and looking forward to the update :)

yeh i think a particle system like a precoded obj that you can put on people or place would be great cause atm if you even try to do particles in byodn you get massive lag and its unplayable

Could use that never used miiiiieisssqass\sleee proc if the effect is purely visual.

Fixed, thanks.

HAHA