ToME: the Tales of Maj'Eyal

Hello there. I have a number of different systems, mainly 2 Linux computers and 1 Windows 7, 64-bit.
It's my custom to try out programs on a Linux machine first, before trusting it to run under Windows.
Thus, I was disappointed to find that I could not even compile the source code, due to the unstated dependency on LuaJIT.
Or is there a way to turn the compile option off, to use LuaJIT, within premake4?
I'm based on lua5.1 BTW.

More importantly:

When I run the Linux 32 binary on my Linux laptop, the CPU usage goes to 100% and stays there. This laptop is a single-core, which is prone to overheat easily at continuous 100% CPU usage. On the other hand, my Windows 7 x64 is a quad-core, which is simply much too powerful to run at 100% CPU usage. It would be a waste, even if I do have 3 other real cores. I tend not to trust any software that exercises even one core at 100%.

Now the Beta-31 Linux binary does not produce a slowdown. Some slowdown was reported on anther thread, and the solution was suggested to add
to an earlier version. However, with version Beta-31, I see that this code has been added already to 'pre-init.lua' by the developer. So just as the other player was already posting, this was a different bug from the one addressed under "Massive slowdown".

I understand that it's an easy mistake to make in any programming environment, to put busy-wait loops, or to forget to put a Sleep() instruction.
But it's also just an easy mistake to make, just to hit another car when driving.

In any case, while this example of 100% CPU usage doesn't produce a slowdown under Linux, the same bug just might under Windows.

Dirk

dirkmitt wrote: I understand that it's an easy mistake to make in any programming environment, to put busy-wait loops, or to forget to put a Sleep() instruction.
But it's also just an easy mistake to make, just to hit another car when driving.

...uhhhhh, what?

I'll give you the benefit of the doubt and say it's possible I'm interpreting you incorrectly, but I have to say, this entire post sounds incredibly pompous.

Well I also find it a bit frustrating, that I've submitted a second bug report, because I believe that the second one is unrelated to this one. But this second bug report explains why it remains infeasible for me to play this game, even if the 100% CPU usage is resolved.

However, this second bug report was not admitted to the forum.

Well you see, as much as I'd like to work with you, to get this game to work, you should be placing some importance on whether other people are to have the privilege of playing your game.

Dirk

Helping fix a cpu lock would be a boon, yeah. Do you have any idea what's actually causing it for your system? I can't really parse what's going on beyond 'cpu is hitting 100%'. Does throttling the process's cpu consumption cause slowdown? I use Battle Encoder Shirase for that on my windows comp, but I'm not sure what a linux equivalent is. Terribly useful to have on comps with heating problems, though.

Is it actually chewing up a full core on your windows system, or is it just the linux? I'm not sure if T4 multi-threads by default, so it shouldn't chew up the whole core. I'm on winXP, and while it'll spike to 100% from time to time (usually when saving/loading), it doesn't stay there terribly long. Does it react the same on both linux machines, or just the laptop? Regardless of graphics mode?

That fix shown was for garbage collection, something to reduce the memory imprint during play, and it never caused constant 100% cpu utilization, just lengthy spikes to full and fairly massive slowdown. That would mean that whatever is going on, garbage collection issues are probably neither the cause nor solution.

Anyway, luck with getting it fixed. The fight makes the victory more worthy

I'm thankful to get a positive reply!

I'm not really sure what options exist under Linux, to throttle the CPU consumption for one process. Will the 'nice' command do that, with certain command-line parameters?

What happens to me, is that when I launch the game, there's an intro screen, which shows stylish game-play taking place in the background, But which is really just an an intro screen. So logically, I next clicked on "Start Game", hoping that this CPU usage only existed to allow the stylish background to play at full speed. But, since the CPU usage stays at 100% even when I have the 'Start Game' window open, I've concluded that this bug is not restricted to the intro screen.

What I was really trying to say, is that it can easily happen that a game developer writes a loop, which may generally test for some user input, test for conditions to be met and so forth, which could all be a part of the defined actions of an 'entity', although I think the current trend is to cal them 'actors' instead of 'entities'. And then it can be easy to miss putting one sleep() instruction, so that one actor's activity could consume the CPU to 100%.

So you are correct in suggesting that such a bug is hard to find. And I wasn't really trying to say that there's anything wrong with the game developers, just because they made an innocent mistake. It would be nice if such a mistake was found, because the game looks promising.

--------

But there's another reason fw I'm not experimenting with this game right now. When I run it on my Linux laptop, it disables the kde4 screen-saver, not just for during game-play, but also after I've exited the game itself. And what this effectively forces me to do, is to reboot my laptop, every time I'm finished running the game.

I find this frustrating, because I'd like to see bugs found and corrected as much as the next guy. But I'm not willing to reboot my laptop that often.
I've noticed that ?about 25%? of all the FOSS games I've tried, which specifically use SDL, seem to have this screen-saver issue. And it could easily just be due to another innocent mistake.

I've never programmed for SDL myself, and must admit that my own programming projects in the past have been much more minuscule (than this game). Therefore, I also don't know what the correct way is to disable the screen-saver temporarily. One way I've heard, is to send a timed signal to the X-session, to tell it that the user is still active.

But another possible way to disable a screen-saver might be built-in to SDL, and it might be necessary to undo this hypothetical SDL instruction when the game exits. If that's the case, then the game might be exiting incorrectly, so that the screen-aver remains disabled.

These are all things worth looking in to. But also, I wouldn't want to convey any sense of urgency about them.
Yet, I'm not yet willing to install this game under Windows 7 yet, because ironically, I regard Windows 7 to be less stable than Linux...

Dirk

That stylish background will jack your cpu through the roof, yes -- there's a disable button in the bottom left, which'll turn the background static and stop those processor chewing shenanigans. That's cross platform, I guess.

There is a significant amount of processor usage during the character creation process -- initially, this is due to it loading the module and getting things initialized, but I'm not really sure what causes it while you're actually choosing race/class, etc. It will, indeed, shoot straight to 100% for a bit, depending on the comp's specs, and probably maintain that until you're actually done making your character. This is normal and, apparently, cross platform. Once your critter's made and you're in game, the cpu should settle down. If it's still sticking to 100% when you're moving around and doing stuff in game -- not just spiking occasionally, which T4 can do when a lot of stuff's going down -- then there's another problem going down, heh.

CPU utilization during the actual character creation process is probably the actual bug, here, from what I can see. Wouldn't mind seeing that fixed, m'self -- it's a problem on windows, too, for all that the period which it's an issue is fairly small. The rest of it's just T4 being T4, heh. It's got a lot going on under the hood, so to speak, and LUA isn't the most efficient language under the sun, from what I understand. Some extraneous resource utilization's probably going to be par for course for a while. It's been worse in previous versions

Hi

The CPU can go to 100% during boot & birth yes, once you are ingame (after character creation) it should go down. If it does not you must check if your opengl drivers are correctly using hardware acceleration (glxinfo should do it). If it does not then that's your anwser right there, the CPU will have to render opengl calls and this is *SLOW*.

As for the screensaver, I have no idea, I have no experienced it here. Anyway next version switches to sdl 1.3 which has support for screensaver enabling/disabling, which I now use to enable it anyway.

As for the "unstated" dependency on luajit, UH ? It's included in the source, the only dependencies are very generic stuff like libvorbis, openal, opengl and sdl. Should be all you need to compile, the luajit2 core is the default now so it's autoselected.

First of all I do owe you guys an apology. I felt that it was worth putting my laptop through an added reboot, if doing so could avoid people hunting for a bug which wasn't there.

So I ran the game again on my laptop, and tried the button in the lower-lefthand corner of the intro screen, to stop the background animation. And guess what, doing so allowed the CPU to settle down!

Next, I went through the process of creating a character, and starting a game. And again, this allowed the CPU to settle down!

So I guess that 'simply using the program correctly' solved this (non-)bug.

Now I guess that the only issue which remains, is my KDE4 screen-saver. What some people do, is to disable KDE screen-savers entirely, and (under Linux) stick to using 'xscreensaver'. I, for one, would like my KDE screen-saver system to work.

But what this means, is that I feel free to use this program on my Windows machine next. And I will download the CPU-throttling program you guys suggested as well.

Dirk