Page 2 of 2

Posted: Wed Dec 24, 2008 11:23 am
by SimoneB
Sorry for the lateness.
Yes, i'm using the proprietary/restricted driver.
Other 3d games I can think of are Warsow, Tremulous, Urban Terror, all of which worked fine.

On the machine besides this one, with 32bit Ubuntu, nvidia proprietary drivers, and (iirc) a geforce 440something graphics card, the game compiled and works fine...
edit: Whoops! This other machine has ubuntu 8.04 instead of 8.10. I'll update it and check if something changes.
edit2: Ubuntu 8.10 does not support the GeForce MX 440 card this other computer has, so I'm not upgrading it for now :/

Posted: Wed Dec 24, 2008 4:26 pm
by penguinflyer5234
SimoneB wrote:edit2: Ubuntu 8.10 does not support the GeForce MX 440 card this other computer has, so I'm not upgrading it for now :/
Yeah, I had to upgrade my GeForce 2 before upgrading to Ubuntu 8.10... :/

Posted: Wed Dec 24, 2008 11:18 pm
by SimoneB
In a short PM discussion I had with bgbirdsey he seems quite sure that I have a driver issue.
It may or may not help, but this is the result of the installed packages I can find with "aptitude search nvidia":
i A nvidia-173-modaliases - Modaliases for the NVIDIA binary X.Org dri
i A nvidia-177-kernel-source - NVIDIA binary kernel module source
i A nvidia-177-modaliases - Modaliases for the NVIDIA binary X.Org dri
i A nvidia-71-modaliases - Modaliases for the NVIDIA binary X.Org dri
i A nvidia-96-modaliases - Modaliases for the NVIDIA binary X.Org dri
i A nvidia-common - Find obsolete NVIDIA drivers
i nvidia-glx-177 - NVIDIA binary Xorg driver
i nvidia-glx-177-dev - NVIDIA binary Xorg driver development file
i A nvidia-kernel-common - NVIDIA binary kernel module common files
i A nvidia-settings - Tool of configuring the NVIDIA graphics dr

in two words, I seem to be using the 177 driver.

Posted: Sun Dec 28, 2008 4:18 pm
by SimoneB
I've been tinkering around a little with the egoboo sources, trying to spot this "black screen" bug.
I've tried putting a "draw_map(50,50);" instruction at line 2538 in game.c, just before "ui_endFrame(); SDL_GL_SwapBuffers();".
This instruction causes the drawing of a white square on the screen at the main menu, which means, the screen is no longer completely black! :)
In another machine where egoboo works well, in the main egoboo menu, I have this white square on the screen and the regular menu. On my laptop (where I have the black screen), everything is black except for this white square on the same position.

This leads me to think that OpenGL and drivers are fine. I think I have an SDL issue instead, maybe texture and font related, but i'm not very skilled in SDL ... so I was hoping in some advice before investigating further :roll:

I've also seen there are some references to a test_sdl in the makefiles but i couldn't find the sources for that. Maybe that could come handy, where can I get it?

Maybe this thread should be moved to the bug report forum?

Posted: Sun Dec 28, 2008 5:45 pm
by Zefz
The whole graphical drawing system has been revised in the latest revision of the 2.6.x SVN. We are now using SDL_image to load textures and improved the image loading and binding system. Maybe 2.7.0 will fix this bug.

Posted: Sun Dec 28, 2008 6:09 pm
by SimoneB
Well... ok. I got the latest version from the SVN and it behaves exactly like 2.6.8. So ... maybe i'll give 2.7.0 a try.

p.s: version 2.22, the one in ubuntu repositories, works fine :?

Posted: Sun Dec 28, 2008 8:21 pm
by SimoneB
Fixed!! :D

The problem is, the computer does more than one thousand cycles per second (sounds like a lot but ...) a little bug kicks in and the "delta time" between frames isn't measured correctly and always equals zero.
This causes various animations to freeze including the menu effects (transparency, sliding buttons, etc) which leads to the black screen!

Solution:
in sys_linux.c, around line 22, in sys_getTime(), there's a line that looks like this
return now.tv_sec + now.tv_usec / 1000000.0f - startuptime;
change it to:
return ((double)now.tv_sec) + now.tv_usec / 1000000.0f - startuptime;
so that the time is correctly measured also below the milliseconds.

I think there's the same bug in sys_mac.c!

Posted: Sun Dec 28, 2008 8:27 pm
by penguinflyer5234
SimoneB wrote:Fixed!! :D

The problem is, the computer does more than one thousand cycles per second (sounds like a lot but ...) a little bug kicks in and the "delta time" between frames isn't measured correctly and always equals zero.
This causes various animations to freeze including the menu effects (transparency, sliding buttons, etc) which leads to the black screen!

Solution:
in sys_linux.c, around line 22, in sys_getTime(), there's a line that looks like this
return now.tv_sec + now.tv_usec / 1000000.0f - startuptime;
change it to:
return ((double)now.tv_sec) + now.tv_usec / 1000000.0f - startuptime;
so that the time is correctly measured also below the milliseconds.

I think there's the same bug in sys_mac.c!
That's probably the bug I encountered in 2.7.7, where the menu was very slow...

Posted: Sun Dec 28, 2008 8:34 pm
by SimoneB
That's possible. If your machine did "exactly" 1000 cycles a second, then it would notice the time passed 50% of the times (assuming the computing time is distributed like a bell curve...), and thus go 2x slower.

Well perhaps I wasn't very clear, but you could give it a try, it's very easy to check!

Posted: Sun Dec 28, 2008 9:14 pm
by Zefz
Excellent! I have patched your fix into Egoboo 2.7.0, for both mac and linux.