[Suggestion] 60+ FPS

[Zakhep]

Currently, the game seems to run at 30 fps, although most games run at 60 fps. This means movement won't be as smooth as it could be.
This can be fixed by doubling the number of steps per second and halving the speed of the game, but this could cause lag on slower machines and bigger maps, while also being a lot of work.
Instead, I propose rendering additional frames in-between steps. This would make the game look smoother and can easily be disabled to reduce lag. This can also work for 120 fps.
I'm not sure how feasible this is, but it should definitely be considered.

[Ninja]

I'm curious how you've deduced how many FPS the game runs at. Videos don't show that, as they record independently of the game's frames per second (at least the one I use does). For example, if I'm playing a game which is ACTUALLY running at 30 frames per second, I can technically record the video at 90 frames per second, or even more. That just means that 2 in 3 frames won't have anything moving on my game screen, but if you're using a FPS displayer while watching the video, it'd show up as 90 frames per second.

Therefore, Virgil could be running the game at really infinite frames per second, but only recording it at 30 frames per second.

Or maybe the game really does run capped at 30 frames per second and I just ranted about nothing, who knows.

[Karsten75]

I just ranted about nothing, who knows.

^^^ This

[Zakhep]

I'm curious how you've deduced how many FPS the game runs at.

In the top left corner of the game play videos I saw the number 30, implying the game runs at 30 fps.

[knucracker]

The game's simulation runs at 30fps (if your machine can keep up).  Since CW3 is intentionally simulation-locked, there is no movement or anything outside of the simulation update speed.  So rendering frames twice per simulation update would just double the draw calls with no visual impact.  That's the case when running at 1x.  When running at 2x game speed, two game updates happen per frame (and the frames still tick by at 30fps).

[Zakhep]

The game's simulation runs at 30fps (if your machine can keep up).  Since CW3 is intentionally simulation-locked, there is no movement or anything outside of the simulation update speed.  So rendering frames twice per simulation update would just double the draw calls with no visual impact.  That's the case when running at 1x.  When running at 2x game speed, two game updates happen per frame (and the frames still tick by at 30fps).

My intention is that particles will visually move half the actual distance each frame, while it's actual position is calculated every other frame. Sorry if that wasn't clear.
I made an image to show you what I mean (In MS paint because I can).

[planetfall]

That would still cause problems. Basically the particle calculation would still have to take place between positions 1-2 and then only the GPU would have anything to do between 2-3, essentially doubling the required efficiency for the physics calculation. I suppose it could work as an option players with older machines could disable, but it's questionable how much benefit there would be for the difficulty of implementation (I'm by no means an expert but I would imagine that this would require the computer equivalent of black magic.) There is also the question of what to do when the player issues commands on an in-between frame. Also, the advance-one-frame-button would look very odd when it looks like it's advancing by two.

[SuperTerminator]

In the specific case of the CW3/PF engine, the game runs in very specific time intervals. The passage of the computer's clock time is called "delta T," or change in time. At the end of every game update, if the amount of passed time from start of the update cycle to the end is LESS than 1/30th of a second, then the game engine just waits/sleeps for the remaining time.

In addition to this, the game has the ability to speed up time. There are several ways of doing so, but in my mind the best way to speed up the game is to add a multiplier to all positional and operational math that the game must do. For all operations controlled DIRECTLY by dT, you could add a multiplier (or a divider in certain cases) that corresponds to the time enhancement, and that will effectively calculate the game's operations faster. So, when calculating the position of a particle, instead of performing the math "x = x + velocityX * dT", you'd perform "x = x + velocityX * dT * timeMultiplier."

The other option is to increase the total calculation calls the game must do. This is generally going to be easier, but has several major drawbacks. First, due to the increase in update calls, the developer would have to tell some updates to not call their rendering functions, in order to maintain FPS and decrease the extra processing load. Second, speeding up time can cause major performance issues depending on the complexity and difficulty of the update calls. For a 2x speed, your cpu/gpu would get an extra 50-90% load (depending on how taxing the graphics components are.) Who knows how terrible things would get once you hit 4x. You'd have to update the game four times just to render one frame.

Here's a little story to demonstrate why extra processing cycles are bad. About two months back, me and my friend were doing some work implementing new mechanics into a game sideproject of ours. What I was doing was adding some multithreading functions into the game as groundwork for a special mechanic (this was using the LOVE, or LOVE2D game engine which has SUCKY threading functions). I made the mistake of not adding in a timer for limiting processing calls, and when I finally got my code to run, my laptop lagged out horribly then locked up due to 100% cpu usage and complete RAM maxing (I later found out that it was doing each of its calls in like .0000000001th of a second, and each iteration it stored something in memory that wasn't getting cleaned out later.  :3

Anyway, it's all about performance. To be honest, it probably wouldn't be too hard to set the game speed to 60 fps, but would it be worth it for everyone playing is virgil's question. Potatoes burn very easily if not watched closely :P

[Michionlion]

Since this is based in unity, threading is quite difficult, since everything else is in the Main thread. This means that in order to make the game machine-independent, V needed to either implement a completely new thread-based logic system (which, while possible, probably isn't his expertise) which was machine-independent, or have all logic directly depend on frame-rate and limit fps. There is theoretically no trouble from what I know of changing the limit to 60 from 30, besides the fact that everything in the game would run twice as fast, as if on 2X. There would probably at this point be a lot of unintended side-effects, as V has been running with this assumption of 30 fps for a long time, and there could be any number of weird dependant things on it.

[Karsten75]

I know that Virgil has looked at implementing multi-threading in Particle Fleet. Same problem as with the majority of games out there. The amount of processing that can be offloaded to a separate thread is not sufficient to warrant the additional processing since there are quite sever costs in the signalling and making sure the processes are not blocked. Alternatively, multiple processes block one another, impacting throughput and performance.

[Shockblast DX]

Currently, the game seems to run at 30 fps, although most games run at 60 fps.

You can easily tell this if you're a mapmaker, because getting one second is 30 frames.
Also, I'm sure that 30 fps is good for those who don't have great computers (A.K.A. me) that want to play games like this.

[strigvir]

There is no point in 60 fps when you spend most of the game paused.

[DanDaMan]

The game's simulation runs at 30fps (if your machine can keep up).  [...]

Can you already specify the system requirements (minimum and recommended) for PF?

[Fireball14]

The game's simulation runs at 30fps (if your machine can keep up).  [...]

Can you already specify the system requirements (minimum and recommended) for PF?

PF system requirements should be somewhat similar to CW3 requirements. Unity dose not allow devs to crank up requirements too much.(Well aside of bad optimization)

[J]

Can you already specify the system requirements (minimum and recommended) for PF?

http://knucklecracker.com/forums/index.php?topic=18363.0