FEMultiPlayer-V2
FEMultiPlayer-V2 copied to clipboard
HamaIndustries
FEMP has excessive CPU utilization percent
Issue type: problem
Description:
FEMP thrashes CPU with over 50% utilization, this shouldn't be for a turn-based game with 16-bit (possibly 32-bit) 2d graphics. Code needs to run more efficiently and require less system resources.
EDIT: Updated system specs with new findings.
System Specs:
E-Machines ET1352-53 (Upgraded) AMD Athlon II X2 250 64-bit Dual-Core Processor NVIDIA GeForce 6150SE onboard GPU 1 GB Shared Video RAM (i.e. Reserves System RAM as Video RAM) Latest Supported OpenGL Version: 2.1 Max Supported Texture Size: 4096x4096 Display Resolution: 1600x900 8 GB DDR3 RAM OS1: Debian Linux 8 (Jessie) 64-bit OS2: Windows 7 Home Premium 64-bit
Examples:
Screenshot show CPU usage
The run games in an unconstrained single-threaded game loop. In effect, the frame rate is exactly as fast as a single CPU core will let it run. Like, my machine has 4 CPU cores and a FEMP instance always takes 25% cpu, and yours is dual core, hence one core is 50%.
When I run a server, I add a System.sleep(1ms) to the game loop. The client would probably want something slightly more sophisticated than that. The server definitely probably wants something more sophisticated than that.
Perhaps it would be good to add the frame rate in the display somewhere, as an option at least. Just to indicate whether the CPU is inefficiency or an ungated thread being ungated.
I just ran a slightly modified testFightStage, and the frame rate was usually 115±30 FPS, where 60 FPS is usually the highest anyone will demand.
Does the animation and such even require 60 frames? As in, did the native GBA titles even run at 60? We probably could get away with 30 for even less of a workload.
I don't know about the GBA, but the GB and GBC run at 59.6 FPS and I'd think the GBA would be the same. The two animations https://www.reddit.com/user/Cardalilyn gave us are intended to run at 60 FPS, but - if what I'm looking at is what I think I'm looking at - it looks like the majority of animations we have are intended for 20 FPS.
Changing the framerate would massively impact animations, particularly fight animations. we would need to cut out some frames automatically, or edit them by hand. Plus many animations are frame perfect and have unique timings/speed, which could put them out of sync with the other animations or their own sounds. Besides all that, not to downplay what you said, but FEMP's code base is far more than a simple "small game with 2d graphics." There's a ton of overhead that goes on, with a lot of memory used at once to store & keep all units loaded into memory at the same time.
Besides all that, not to downplay what you said, but FEMP's code base is far more than a simple "small game with 2d graphics."
I meant no offense by that statement (and have thus revised it), forgive my poor wording, rather what I meant to say is that in comparison to other games, especially 3D ones, it should be lightweight by modern standards as I doubt even 3D games are this taxing on the average PC (unless it have next gen graphics, or a crazy number of polygons and textures).
As Rayrobdod mentioned, it's probably the game loop not knowing when to wait / sleep resulting in a framerate probably far higher than even 60 fps. There should be no reason why this is hogging an entire core.
When I run a server, I add a System.sleep(1ms) to the game loop. The client would probably want something slightly more sophisticated than that. The server definitely probably wants something more sophisticated than that.
If we don't have the blue / red background behind the interface scrolling (as in we make it still), the game won't need to redraw the screen as often, am I right? Would introducing a sleep in the game loop be easier then?
Actually, the game redraws everything regardless of what's happening, and the background is constantly loaded, meaning that keeping it from scrolling wouldn't impact the memory usage, imo. A sleep that lowers fps (would need to be in the animation engine, not main loop or calculations) would likely work.
Can we test this? I'll compile and build it on my end if you have something ready for me. Furthermore, do I need to issue any special command or options to javac in order to compile this as x86_64 instead of just x86? Or does it just compile it automatically as whatever architecture I'm using?
No, I just realized how dumb I am. its not x86, its fastdl, I was just being not smart. its in the lowmem branch, but I need to update it first. its just a version of the game which downloads fast, but loads slow, and may crash some low memory comps when the game decompresses audio. its really uninmportant, and I haven't updated it yet. there's really only 1 version of the game.
I think you're misunderstanding me. I'm asking if a 64-bit version exists, or if there's a way to compile it as 64-bit that I don't know about. When I say x86_64 aka x64, I'm talking about a 64-bit version optimized to take advantage of 64-bit processors and can only be used on them. x86 aka i586 is 32-bit and while it can be used on on both 32-bit and 64-bit processors (as long as the 64-bit PC has 32-bit support libraries and plugins), it's not optimized. By you divining new names for these (such as non-x86), you're just confusing all of us, including yourself it seems. In fact, I'm horribly confused right now.
Or are you saying that a 64-bit version doesn't exist and that there's only a 32-bit version and a 32-bit lowmem version, making both x86? It'd probably run better if you made a 64-bit version.
Either way, did you add the sleep to lower the fps? It'd be nice if I can have some of my core's resources back.
I know, I made a mistake because I was tired. it never was x86_64, its just a 32 bit compatible version, and a fast downloading one. Ray's working on the sleep issue in one of his branches.
Actually, the game redraws everything regardless of what's happening
Shouldn't the game only be redrawing non-static tiles and sprites such as water, units, the cursor, etc. and not static tiles that would only need to be redrawn when something else overlaps or otherwise is moving from / onto it such as the cursor, units, movement grid, etc.? Or am I being stupid?
Also, from doing my own (most likely flawed) research, what about if we implemented "blitting" instead of layering overlapping sprites / images? It looks promising to me on paper when I read things like:
Because the computer is directly changing the individual pixels of the bitmap, rather than attempting to keep track of several different layers, this method is incredibly fast.
I could be horribly wrong, but it seems promising on paper. Opinion?
I knew about blitting, but I don't know if its possible in lwjgl, but I'm confident it would improve cpu usage. However, from Ray's comments, it looks like the real problem is that the game is using a higher fps than it needs, which we may be able to implement. He's working on the issue now in one of his branches.
I knew about blitting, but I don't know if its possible in lwjgl
This was the first result on Google when searching for "blitting lwjgl" No idea how well, or if, it works. Worth looking into though.
On closer inspection, it appears that it's been here since the beginning.
// draw quad
glBegin(GL_QUADS);
glTexCoord2f(txi, tyi);
glVertex3f(x0, y0, depth);
glTexCoord2f(txf, tyi);
glVertex3f(x1, y0, depth);
glTexCoord2f(txf, tyf);
glVertex3f(x1, y1, depth);
glTexCoord2f(txi, tyf);
glVertex3f(x0, y1, depth);
glEnd();
it also looks like Power of 2 has been accounted for automatically as well.