??????
You are not logged in.
Pages: 1
I don't know if this is worth fixing, but I thought I'd report it anyway.
Annoyed with CM taking a non-trivial amount of CPU power, I put '3' in
settings/halfFrameRate.ini. The result was a perfectly playable 7.5fps, as
expected, but with an unfortunate side-effect: the pickers oscillate when
they're moved, and normally quickly settle down, but with this frame rate they
don't fully stop oscillating and end up in perpetual simple harmonic motion.
Worse, mousing over squares doesn't have the usual effect - I assume this is
because the pick isn't assumed properly picked until the picker is stationary.
With '2' in the file, it works fine.
Offline
Yeah, they're overshooting and then moving back to correct. I'll fix this.
In terms of CPU, there are simply a lot of sprites being drawn each frame. I would think that would be GPU-intensive instead of CPU-intensive (because each sprite is already loaded into GPU texture memory), but maybe there's enough code around each draw call to load down the CPU as well (and I have seen CPU being used quite a bit by the game too). I'll look into it.
Offline
Thanks.
I do have hardware acceleration on this machine - although it's just crappy
intel integrated graphics with Mesa drivers, so I don't know how much ends up
being software emulated.
I suppose it seems a bit strange to me to have a constant frame rate with the
whole screen being redrawn each frame, when there isn't actually much
animation in the game. I guess you'd make huge savings just by not redrawing
when nothing's changed. But perhaps this would require painful architectural
reworking, so I'm not necessarily really suggesting it!
Offline
Okay, so I fixed it so the pickers don't jump around when halfFrameRate is high.
Also if you pull minorGems, there's a fix in there so that you can push halfFrameRate as high as you want, and the frame rate will bottom out at 1 fps instead of hitting 0 and crashing.
I'm using a standard update draw game loop that I've used in all my games. Yeah, it doesn't make as much sense here when nothing is changing so much of the time. But you're right that deep architectural changes would be needed to fix it.
Essentially, it's easy enough to just not draw the screen. The problem is detecting when it's okay to skip drawing. There are so many distinct parts of the game that draw to the screen that the "need to redraw" framework would need to communicate with all of them (for example, when waiting for your opponent's move, the little waiting icon is changing, when mousing around, you can mouse over a picker or button and it should change---each of these things would trigger a full frame redraw).
Offline
More data here:
On my old slow laptop from 2000, I see my framerate dropping as the round progresses (as more pixel-heavy brush strokes are added). Probably exceeding the fill rate of my integrated graphics card.
HOWEVER, I also see the CPU usage dropping. It's cut by more than half by the end of a round. This is because far fewer sprites are drawn at the end when the graph has cleared out.
At the start of the game, that graph has 300 sprites in it, making it CPU heavy to draw. By the end, the number of draw calls drops, reducing CPU load, but increasing GPU load because the sprites being drawn contain a lot more pixels to fill.
Offline
OK. If there's no abstract representation of the UI state you can check for
equality between frames, I guess it's too late to insert one now. Supporting
low frame rates is good enough.
There's an obvious optimisation you could make for the assist graphs, though,
to deal with drawing so many sprites each time - blit the graphs from a buffer
which is redrawn only when they change.
Offline
You mean draw all the graph pips into their own texture, and then just draw that texture if the graph hasn't changed? Yeah, that's possible.... but since I'm using the OpenGL drawing routines to draw sprites, I'd have to either write my own drawing routines to draw to a texture OR draw to the screen once and then read that bit of the screen to make the texture.
Offline
Right... maybe not so simple with opengl. I'm used to bare SDL. And depending on what's causing the slowdown when drawing the pips directly, I guess it might not help anyway. Never mind!
Offline
I assume there isn't just a way to setup a drawScreen boolean flag global that can just be set to true by any part of the code that actually changes something on the screen and just clear the flag after any draws?
Offline
Anyway, thanks for fixing the bug with low framerates. It works nicely at 7.5 fps now.
Offline
Yeah, mzo, that's possible, but it would require quite a bit of digging to get everything setting that flag correctly.
Really, there are only a few moments that would be CPU-reduced by this. While you're dragging a slider, it would go back to 60 draws/sec. While you're waiting for your opp's move, it would be doing 60 draws/sec (smooth waiting icon). When moves/bets come through, back to 60 draws/sec. Waiting for a game to start, same thing (though that screen uses a lot less CPU as it is). It's really just those rare moments where you're staring at the screen, not mousing over anything, that would save some CPU. So... is it worth it?
It's also just not what I'm used to doing, because most games have no static moments at all.
Offline
I haven't had much issue with it being too slow on my tablet pc thankfully except for oddly enough on the Waiting for Opponent screen.
Offline
How is it slow on that screen? It chews CPU?
Offline
Yeah it seemed a bit higher on CPU, but take that as anecdotal as I don't have any data on it at the moment.
Offline
Well, it shouldn't be higher on that screen. Should be the lowest CPU screen in the game (fewest fonts drawn). Let me know what you unearth there.
Offline
Pages: 1