consumes too much CPU when it should be idle

[Feanor.81]

@DG: Read my updated post above, I found a workaround
Ok, then I'll collect the data enabling again desktop composition in the compatibility options, and monitoring before and after the slowdown occurs.

[darkgod]

Code: Select all

griffon:/usr/local/src/t-engine4-src-1.0.0beta10b$ grep 'handling sdl even' logs/Urist | sort | uniq -c
      1 handling sdl event 17
     87 handling sdl event 2
   2086 handling sdl event 24
     86 handling sdl event 3
    383 handling sdl event 4
      3 handling sdl event 5
      3 handling sdl event 6

If the game is really calling an SDL routine dozens of times every second, even when it's just sitting idle, that might also account for the CPU use....

It calls the display 33 times per seconds which should not even make a dent in a celeron that just can not be that.
Please use the display() method i posted above and geet me the log

I'd have to figure out what that means first.... "premake4 --help" says there's a --lua=VM_Type option, and its choices are "default" or "jitx86". I've been typing "premake4 gmake" and then "gmake" to compile, so I'm apparently using the "Default Lua Virtual Machine", whatever that means.

Ah yes you are using the default already.

[darkgod]

BIG UPDATE: Found a workaround to prevent the slowdown issue, by starting t-engine process with "Disable visual themes", "Disable desktop composition" and "Disable display scaling on high DPI settings" compatibility options enabled (but I think only the second matters, I will be trying enabling again the other two). This way I've been able to play my archer for 15 minutes without any slowdown, and CPU usage never went higher then 30%. This makes me think that probably there is some graphic compatibility issue with Win7 Aero theme, since:

Ahh .. windows ..

Anyway it still means we can get better, and greycat example proves there is still a problem deep within

[Feanor.81]

Here are my logs, collected with default application settings (no compatibility option enabled), the first is at game load, the second experiencing slowdown.

[darkgod]

Ah yes this seems to confirm what I thought.

Now try with this: http://pastebin.com/8Q8MrLW8
(This will only display the map not UI)

[Feanor.81]

Tested it. I made my way to Trollshaws(5) and back to Bree, killing anything in my way. (Thanks gods found no OOD, without GUI it would have just meant insta-death ) About 15 minutes of play, and not a single frame dropped, everything was perfectly smooth.

I guess you got it

[greycat]

Please try to replace the display() method in game/modules/tome/class/Game.lua with this one: http://pastebin.com/SPAYHB6G

Then post here the output when it runs fine and when it runs slow please.

Alchemist, one and a half levels of the Trollshaws: (attached, I hope)

[greycat]

Ah yes this seems to confirm what I thought.

Now try with this: http://pastebin.com/8Q8MrLW8
(This will only display the map not UI)

Attached. Didn't play very long, though.

CPU use with that version is virtually nil.

[darkgod]

yeah that confirms it, the UI code is horribly unoptimized while the map code is optimized to the teeth.
I'll change them to be much faster

[darkgod]

I did, next beta should run quite faster, hopefully

[marvalis]

Some of the problems I have been experiencing seem to be related to the UI too. At one point, mouse movement worked wile keyboard lagged.

[greycat]

Well, 11b is definitely faster on my home box (the one with the old Radeon card). The load-average-ometer is no longer pegged at 1+ the whole time. It even feels faster when I'm walking around in the Trollshaws, at least, which is definitely more important than the actual CPU use.

On the work box, unfortunately, it's still rather sluggish. The work box has a built-in Intel chipset, rather than a graphics card of any kind. Not sure if there's anything that can or should be done about that....

[Zop]

No more stuttering, nor is there thousands of pagefaults per second any more. Good job!

[Final Master]

While overall game play is the fastest it's ever been, saving still takes way longer than I think it should, continuously reaching minutes. What could be making the saves for T4 be so much longer than saves of T2? I remember less than a second saves back then...

Oh, I do still run into random slow downs, but it is probably due to leaning on a direction to tear through 30+ ants at a time.

[darkgod]

Savefiles are large (tens of MB uncompressed) because they save most of the world, this has the cost of being longer to save but the HUGE advantage of not having module makers think about savefiles at all and making everything absolutly dynamic. The game can change every single variable of every single object in the world and it will be saved.

As for over a minute saves it is still not normal, it should take maybe tens of seconds at most.
Is it while saving & exiting or while saving while playing ?