Sometimes the game hangs loading with a black screen

[franciscod]

The log reads this:

DBG0  inserting new chunk at (00,00)
DBG0  neighbor 0 not found.
DBG0  neighbor 1 not found.
DBG0  neighbor 2 not found.
DBG0  neighbor 3 not found.
DBG0  neighbor 4 not found.
DBG0  neighbor 5 not found.
DBG0  neighbor 6 not found.
DBG0  neighbor 7 not found. 

It usually happens to me on a cold boot. It fixes by itself, I don't know what's the cause. When it fixes for the first time, it keeps working afterwards.

I'm on Arch Linux x86_64, currently running GNOME3.

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

[mic-e]

Can anybody else reproduce this issue?

When you encounter it again, please check the stack trace in gdb. This is a very basic method that allows you to get an idea of where the offending code/infinite loop might be (example from my working game):

mic@mic-nb ~ $ ps aux | grep openage
mic      12544 37.4  1.0 580244 43448 pts/0    Sl+  05:15   1:02 ./openage --data=assets
mic      13433  0.0  0.0  12888  2324 pts/2    S+   05:18   0:00 grep openage
mic@mic-nb ~ $ sudo gdb -p 12544
GNU gdb (GDB) 7.8

    (removed clutter)

Attaching to process 12544

    (removed clutter)

[New LWP 12587]
[New LWP 12546]
[Thread debugging using libthread_db enabled]

    (removed clutter)

(gdb) where
#0  0x00007fc6785cd972 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#1  0x00007fc6785af08e in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#2  0x00007fc678569ba0 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#3  0x00007fc6783c0dae in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#4  0x00000000004324ec in openage::Texture::draw(int, int, bool, int, unsigned int, openage::Texture*, int) ()
#5  0x0000000000432812 in openage::Texture::draw(openage::coord::tile, int, openage::Texture*, int) ()
#6  0x0000000000430edf in openage::Terrain::draw(openage::Engine*) ()
#7  0x00000000004228d5 in openage::GameMain::on_draw() ()
#8  0x000000000042c939 in openage::Engine::loop() ()
#9  0x000000000042c9dc in openage::Engine::run() ()
#10 0x0000000000425714 in openage::run_game(openage::Arguments*) ()
#11 0x0000000000421d0e in main ()
(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00007fc6866e1300 in glBindTextureEXT () from /usr/lib/libGL.so.1
(gdb) where
#0  0x00007fc6866e1300 in glBindTextureEXT () from /usr/lib/libGL.so.1
#1  0x00000000004322ba in openage::Texture::draw(int, int, bool, int, unsigned int, openage::Texture*, int) ()
#2  0x0000000000432812 in openage::Texture::draw(openage::coord::tile, int, openage::Texture*, int) ()
#3  0x0000000000430edf in openage::Terrain::draw(openage::Engine*) ()
#4  0x00000000004228d5 in openage::GameMain::on_draw() ()
#5  0x000000000042c939 in openage::Engine::loop() ()
#6  0x000000000042c9dc in openage::Engine::run() ()
#7  0x0000000000425714 in openage::run_game(openage::Arguments*) ()
#8  0x0000000000421d0e in main ()

[svkurowski]

This happens for me at every start of the program. It doesn't fix itself. The program stays a long time in the openage::util::read_whole_file function. So far I have encountered two parameters that cause the program to stay so long in that function. The first is 0x0 i.e. an nullptr. This should be fixed by adding a null check (which we should do anyways). More interestingly however would be why this function does even get called with nullptr as parameter.
The second parameter that causes the function to take a long time is "#struct unit_dead_or_fish\n#adds walking graphics, rotations and tracking properties to units.\n#int16_t,uint16_t,uint16_t,enum unit_classes,int16_t,int16_t,int16_t,int16_t,int16_t,float,float,int16_t,i". Again, why is the function called with this parameter?
I guess his is related to the game assets (different original game versions maybe).
I will try to find out more.

[TheJJ]

This is probably caued by the long loading time of the few thousand files. Loading them the second run or after conversion is faster as Linux will have cached the requested files.

It will be fixed, once #28 is finished. We could stuff all files in a tar archive or something to improve the access time i think.

[lilezek]

Does the game process something with the loaded data? If so, you can dump the structures directly to the drive, so you can load them and save some processing. That might be useful.

[franciscod]

hey structure dumping is a nice idea for fast loading!

[zuntrax]

We shouldn't put too much emphasis on speeding this up, since the data loading process will work differently once we use nyan.

[TheJJ]

The amout of work I need for converting the csvs to a relational database is minimal. The development workflow has to be as optimized as possible, long startup times are not feasible. See #124.

[lilezek]

Anyway, structure dumping of loaded data is always a fast way to avoid recalculating information, with or without nyan (btw I don't know what nyan means). The main disadvantage is that you need to check the structures aren't older than the assets.

[mic-e]

@jprashanth fixed this with PR #137. Now the game window is responsive and displays a "loading" message.

[franciscod]

nice!!