Bugs in GAE 0.2.8

[titi]

Please list all bugs for GAE 0.2.8 in this thread
-------------------------------------------------------

the bugs:
( I had some compile problems see here: viewtopic.php?f=15&t=3901)

1- When you play indians you cannot see the bees / norsemen cannot see the arrows of the crossbow / magic cannot see stones of the golem.
  So projectile models are currently not visible.

2- freezing when playing
  If you have lots of units and you start selecting multiple of them( with a rectangle ) the game suddenly freezes for 1 second. This gets more worse with more units.

3- when game ends( you have lost ) game stops ( bug or feature? )

4- performance problems: GAE is much slower than glest but this can be for the same reason as number one. I think this has somethig to do with each other.

[daniel.santos]

Thanks for the report.  I can confirm #1, I don't see any models showing up in projection particle systems (which is what those are).  This is also true of the archers.

I had lots of problems with #2 and I'm not sure what specifically caused it.  I did put a tweak in to counteract some of the effects of it, but I need to figure out the root cause.  I don't recall it existing (at all) in 0.2.7, but I'll probably double check so I know I'm looking in the right place.

I can't confirm #3 right now, but I have the 0.3 branch checked out and it isn't doing it there (I just destroyed all my buildings and it gave me the option to continue).  However, I'm thinking that the standard loss condition should be the loss of all buildings (excluding walls, as it already is) AND the loss of all builders.  Just a thought.

And #4, I don't think I noticed anything beyond the problems when drag-drop selecting units.  I'll worry about the other 3 1st and maybe I'll find something that causes this (I'm also on a faster computer, so I may not notice it as much).

[titi]

3: The game doesn't doesn't stop, it freezes wihle the "you win"-message is shown. When you click "no", the game continues without problems.#

2: this must have something to do with rectangle select and I#m quite shure now, that it is the reason for the performance problems.
Computer: Athlon x64 3400+(no X2!) Geforce 6600GT 2GB Ram. And I saw performance issues in an one-on-one game with a ultra-cpu-player.( both sides had about 50 units when it starts ). So its not a big lag but its something noticable and at this moment the rectangle problems start too.

[titi]

Multiplayer, should this work in 0.2.8?
- if you connect to a server and have typed the wrong IP, the game crashes.
- I tried to play multiplayer(2 player vs CPU), but the game crashes after about 2 minutes.....



What about the lua system? are there any plans to integrate this in the first stable version?
If yes, you can probabaly fix the bug I posted,....
viewtopic.php?f=7&t=3671#p18629

[titi]

more bugs:

1.- The CPU player seems to be completely corrupted:
I played a game versus 2 cp players(simple indian cpu players).
They build nothing!!??!! and didn't attack me for 15 minutes.
Another thing I see, is that the ultra cpu player is much much better in original glest.
Has this something to do with these automatic function for idle workers (auto repair/auto build)?
You should try to disable this for the cpu players! The workers probably don't get commands, because they already have commands( from this auto function)?
These auto-functions are really a nice thing, but they really make it a lot easier for human players.
But thats also a problem, because humans get better by this and the balance in games versus CPU is not the same as before.
Nevertheless, I like this feature a lot.

2.- If you select a worker and tell him to go to another unit ( with the right mouse button ) the red position arrow is shown in a wrong place

[daniel.santos]

3: The game doesn't doesn't stop, it freezes wihle the "you win"-message is shown. When you click "no", the game continues without problems.#

Ahh, that makes sense.  This is by design and started a few releases back I believe.  All dialogs will pause the game now unless you are in a multiplayer game where at least one other live player is connected.  Even if you are in a multiplayer game and all of your opponents disconnect, it's supposed to pause the game when a dialog comes up (the you win/loose dialog, save game, etc.)

Multiplayer, should this work in 0.2.8?
- if you connect to a server and have typed the wrong IP, the game crashes.
- I tried to play multiplayer(2 player vs CPU), but the game crashes after about 2 minutes.....

My initial playing around with selection rectangle is working ok in 0.2.8, but I did find another minor bug in something else (setting MaxFPS=2000 in the .ini causes a crash .  I need to try this on windows too.

Thanks for your help on this titi!

[titi]

I tested some more:
how to reproduce the rectangle select bug:

open the indian.xml
and set stickfighters amount to 100
<unit name="stickfighter" amount="100"/>

now start the game. first selection works fine, but when you select several diffrent groups after another and give them attack commands, you will (hopefully) quickly see the bug )

Thanks for your help on this titi!

And I want to thank you for your work!

[daniel.santos]

Ok, I'll test this now, but it sounds like problems with the pathfinder code, which I did change.  I made one change that should have increased performance of the pathfinder AI in 0.2.8, reducing work in some areas by as much as half, but that doesn't mean that it did.  Also, please make sure that this is a release build.  How did you run the "./configure" script?

[daniel.santos]

hmm, I can't reproduce it.  Are you sure you're running an optimized version? You can force jam to show you the compile command with jam -n (maybe you can do that and post the output for one of the object files?).  Like this:

Code: [Select]

$ jam clean
$ jam -n|lessThis is the 1st part of my output when I run this:

Code: [Select]

...found 535 target(s)...
...updating 127 target(s)...
C++ ./build/x86_64-unknown-linux-gnu/optimize/shared_lib/sources/platform/window_gl.o

    g++ -c -o ./build/x86_64-unknown-linux-gnu/optimize/shared_lib/sources/platform/window_gl.o  -I/usr/include -DPACKAGE_NAME="gae" -DPACKAGE_TARNAME="gae" -DPACKAGE_VERSION="0.2.8" -DPACKAGE_STRING="gae 0.2.8" -DPACKAGE_BUGREPORT="daniel.santos@pobox.com" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DUSE_POSIX_SOCKETS=/**/ -DX11_AVAILABLE=1 -DHAVE_GLOB_H=1 -DHAVE_SYS_IOCTL_H=1 -DUSE_SDL=/**/ -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -I. -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -pthread -pthread  -I/usr/include -I/usr/include  -Ishared_lib/include -Ishared_lib/include/platform -Ishared_lib/include/platform/sdl -Ishared_lib/include/platform/posix -Ishared_lib/include/util -Ishared_lib/include/graphics -Ishared_lib/include/graphics/gl -Ishared_lib/include/sound -Ishared_lib/include/sound/openal -Ishared_lib/include/xml   -Wall -W -Wno-unused -Wno-sign-compare -fno-strict-aliasing -O3 -g -DNDEBUG -ffast-math -ftree-vectorize shared_lib/sources/platform/window_gl.cpp


[titi]

I didn't give any options to configure.
I just did
./configure

Hm, how to create a release build? I didn't give any options...
But I stripped the binary after building ( to remove debuginfo ). But I had the same problems with debuginfo before.


here is my "jam -n"

Code: [Select]

...found 536 target(s)...
...updating 152 target(s)...
MkDir1 ./build/i686-pc-linux-gnu/optimize/shared_lib

        mkdir -p "./build/i686-pc-linux-gnu/optimize/shared_lib"

MkDir1 ./build/i686-pc-linux-gnu/optimize/shared_lib/sources/platform

        mkdir -p "./build/i686-pc-linux-gnu/optimize/shared_lib/sources/platform"

C++ ./build/i686-pc-linux-gnu/optimize/shared_lib/sources/platform/window_gl.o

    g++ -c -o ./build/i686-pc-linux-gnu/optimize/shared_lib/sources/platform/window_gl.o  -I/usr/include -DPACKAGE_NAME="gae" -DPACKAGE_TARNAME="gae" -DPACKAGE_VERSION="0.2.8" -DPACKAGE_STRING="gae 0.2.8" -DPACKAGE_BUGREPORT="daniel.santos@pobox.com" -DUSE_POSIX_SOCKETS= -DX11_AVAILABLE=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GLOB_H=1 -DHAVE_SYS_IOCTL_H=1 -DUSE_SDL= -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1  -I. -I/usr/include/SDL -D_REENTRANT -pthread -pthread     -Ishared_lib/include -Ishared_lib/include/platform -Ishared_lib/include/platform/sdl -Ishared_lib/include/platform/posix -Ishared_lib/include/util
-Ishared_lib/include/graphics -Ishared_lib/include/graphics/gl -Ishared_lib/include/sound -Ishared_lib/include/sound/openal -Ishared_lib/include/xml   -Wall -W -Wno-unused -Wno-sign-compare -fno-strict-aliasing -O3 -g -DNDEBUG -ffast-math -ftree-vectorize shared_lib/sources/platform/window_gl.cpp

MkDir1 ./build/i686-pc-linux-gnu/optimize/shared_lib/sources/platform/sdl

        mkdir -p "./build/i686-pc-linux-gnu/optimize/shared_lib/sources/platform/sdl"
....


OK, I try to compile it on a newer Linux too....
And I will also run the windows version to find the bug now.

[titi]

build and tested it on another computer now ( ubuntu 8.04 )
same problem with this build.  and now for windows .....

[titi]

No problems in windows!
But is this windows binary really build on the same base ? ( 0.2.8 source package?)
Or is this probably a slightly other version ?
If not, it might have something to do with SDL and these things.

By the way, glest is much much much slower in windows-xp on the same machine!!! ( I tried both binaries )
Its nearly impossible there to play with startup settings of 100 vs 100 Stickfighters! ( 10 fps or something like this )
Probably one day someone should try a SDL version for windows too. Its probabaly faster ( but I cannot believe this )

[daniel.santos]

I didn't give any options to configure.
I just did
./configure

Ok, I noticed that optimize is enabled by default, so that should be ok then.

here is my "jam -n"...

Yea, it looks fine, this is the main thing I was looking for: "-O3" that's the flag that tells gcc to optimize.

I think I'm going to leave focus on a few more aspects of 0.2.8 and work on a minor revision, but something is definitely screwy.  Maybe you can try the 0.2.7 sources or earlier and see if you have the same performance problems?  Once, after doing some upgrades, I ended up with the xorg opengl drivers in use instead of the nvidia drivers and I was getting about 1 frame every 2.5 seconds or so.  Also, do you know what version of libsdl you are using?  You might be able to find out by looking at the file /usr/include/SDL/SDL_version.h, but that depends on how Ubuntu installs everything.  It's in these 3 lines:

Code: [Select]

#define SDL_MAJOR_VERSION   1
#define SDL_MINOR_VERSION   2
#define SDL_PATCHLEVEL      13Thanks for the help on this.  It would be really nice to figure this problem out.  I know that something definately changed because when I was doing a mouse drag before I added some tweaks (in 0.2.8-wip) I was able to hang the frame rate (keep the game frozen) for as long as I continued to drag the mouse around.  When I did some debugging and tracing, I discovered that it was servicing the mouseMoveLeft() event so often that it didn't have a chance to do anything else.  Part of the problem with the drag-drop select is that it calls renderUnitsFast(), which actually does most of the work it takes to render the units!

[titi]

ok gae 0.2.7 doesn't have these problems!
Here are my sdl versions:

Ubuntu 6.06:

Code: [Select]

#define SDL_MAJOR_VERSION       1
#define SDL_MINOR_VERSION       2
#define SDL_PATCHLEVEL          9

Ubuntu 8.04:

Code: [Select]

#define SDL_MAJOR_VERSION       1
#define SDL_MINOR_VERSION       2
#define SDL_PATCHLEVEL          12

( I'm going to bed now its  4 a clock in the morning here  :-/  and I have to work tomorrow ...... )

[daniel.santos]

( I'm going to bed now its  4 a clock in the morning here  :-/  and I have to work tomorrow ......  Also, if you select a unit and right click on the mini-map, the red arrow appears in various bazaar places.

[daniel.santos]

Ok, I fixed the bug where models weren't showing up in attack particle systems (arrows from archers, rocks from golems, etc).  Also, I fixed an annoyance bug, when drag-dropping to select units, if you happen to mouse over the minimap, it wont change your camera anymore (that was annoying).  Now, you have to mouse down on the minimap before dragging around on it will have any effect.

[titi]

Is it in the version control system?
I think i will start to checkout the source from there to help you testing.

[daniel.santos]

not yet, but I'll check in some time this weekend, maybe tomorrow.  I would like to try to isolate the performance problem, but I also want to make sure I have the particle system code cleaned up correctly (and not buggy).

[daniel.santos]

Ok, titi, I checked the fixes into the 0.2.x branch.  I don't think this will fix any of your performance problems though.

Do you think that things are starting to slow down once you have units moving around?  I'm wondering if it's something I've done to the path finding code (I did make what I thought to be a minor optimization to it in 0.2..  I also touched the code for rain particle system to clean up some stuff, but I don't think it's been negatively affected.

[titi]

ok I checked it out and tried it ( I checked out https://glest.codemonger.org/svn/repos/gae/      :oops:  :oops: )

And now for the BUG:
I have 3 computers here, the fastest (4600 x2 2 GB ram Geforce 8600 ) only gets problems with 200 stickfighters.
The slowes computer ( AMD Athlon(tm) 64 Processor 3400+ 1GB ram Geforce 6600) gets problem with 100 stickfighters.
These select problems aren't there immidiatly! You have to select different groups and then after 5-10 times it happens.
So I hope you can reproduce it now.  Try it with 400 stickfighter ( and a big map!! )if you have a fast computer.
I'm shure it will happen at you too. Its a CPU problem not a memory problem from what I see from the system monitor.
There must be some very cpu intensive operations now ( pathfinder ?)  (An athlon 64  3400+ should really be able to handle 100 units !!)
The problems also occurs if I only select onw group after another with the rectangle! After 3-5 group selects ( all groups have different units )
the game gets stuck.


And one new bug?:
I don't have any more minimap on one compter!?! I saw a switch in glestadv.ini but it had no effect. Is there a key to toggle it ingame?
I'm quite shure I saw a minimap there before! All other computers have a minimap !?! ( problem is there with 0.2.8 and current cvs version)
But I can click on the unvisible minimap and it has effect!

[titi]

I tested some more!!!
It's very interisting to watch the cpu load while glest is active ( with 100 units ).
Here is what see on my computer: ( evergreen tileset / I play indians with 100 stickfighter / cpu plays magic with default setup. )
If I start the game and I do nothing, cpuload is at about 40%.
1.:
If I zoom out cpuload immidiatly rises to 100%.
If I zoom in again, after a while the cpuload goes donw to normal.

2:
I zoom out ( and have 100 % CPU load then)
If I now select units via rectangle, the game stops and hangs for 1 second or in worse cases for several seconds ( sound too!!).

3:
If I don't zoom, but select groups ( like described before ), I have to move around to select more new units. With every new selection the CPU load rises more and more. If I reach 100% , game stops for one second and so on.... . I have to wait 20 seconds then ( without doing anything!) and suddenly the cpuload starts to fall. But not to 40% to a much higher level of about 70-80 % .

I hope this helps you to find this bug!
By the way, windows gae 0.2.8 is also much much slower than original glest, especially with lots of units ( 100 ) its really slow on my computer
( AMD 64 X2 Dual Geforce 7600GS  2GB ram )

[titi]

more info, please read all my posts above too:

RAIN!!!
Looks like rain is a serious problem for CPU-load ( in windows too ).

In windows I see the rising cpu load too( as described for linux, but if I reach 100% there I get no selection bug, it just have very slow framerates.
So probably this bug is something not new, but the high cpu load is something new ( or both bugs are new   )

UPDATE: In windows I see no rising CPU-load when zooming out when it rains!! So I think rain is a big problem.


OK, I stop testing now, I have no more ideas..., I hope you'll find it!

[modman]

I shut off the rain for the beginning menu.  It got really annoying, not its effect on my computer, but I just didn't like it.  I also shut off rain in tilesets.

[daniel.santos]

titi, I got the performance bug to happen!!!  I'll let you know when I find something out.

[daniel.santos]

Ok, I found and fixed the problem.  Please do an update from svn and give it a go.  As for the low performance when zooming out, that's just a limitation of the game engine at current.  My rain seemed to behave correctly, so let me know if you find anything else.

Thanks