LÖVE

Posted: **Fri Feb 02, 2018 5:37 pm**

Added some improvements.
1. no text in saves, only doubles
2. no individual files for chunks, dump them together in 32x32 regions (obviously inspired by minecraft wiki)
3. gen in threads, separate thread for layer. still old code in those threads, however making doubles instead of blocks
4. pools for blocks, chunks, regions. And no string info on screen (which allocates lots of new strings?). All previous steps were not capable of eliminating lag spikes on crossing chunk border. Surprisingly, lag spikes on chunk borders still happened when strings were drawn. Probably that's somehow related to the rule that gc steps are 'generated at predictable places (when allocation happens)'.
5. drawing blocks at int positions on canvas, then drawing the canvas at fractional part of desired position. That eliminates 1px jumps caused by flooring and at the same time causes much smaller distortion compared to drawing individual blocks at float coords. Also added gammacorrect=true since somebody claims that it's better for subpixel drawing.
6. utilizing the chunk-as-cached-spritebatch drawing method advised by @MadByte. That probably freed around 1/120th of second for more chunk loading and garbage making/collecting.
7. drawing frame times at the top of the screen(lot of draw calls==screen width, but probably that doesn't matter?). That makes clear when frames are taking too much time, much more obvious than putting text on screen or in stdout.

That all makes the performance slightly better, allowing movement up to 10k pixels/second (less for generating, more for loading).
However not sure it's acceptable result. Every small frame time increase is clearly visible and irritating. Sometimes it's even visible without noticeable dt change (those small random lags replicated in empty test project with just 1 circle moving, not sure what that means).

Also that all is a bad sign for estimates. If improving small part of functionality from 'awful' to 'bad' takes 20 days, how many forevers it will take to improve it from 'bad' to 'playable'?

Posted: **Fri Feb 02, 2018 6:12 pm**

The one above is segfaulting for me. The backtrace is meaningless, but it appears to be accessing a null pointer, possibly via FFI:

Code: Select all

(gdb) disas $eip,$eip+10
Dump of assembler code from 0xb37d9c3e to 0xb37d9c48:
=> 0xb37d9c3e:	movsd  xmm0,QWORD PTR [ebp+ebx*8+0x0]
   0xb37d9c44:	cmp    DWORD PTR [edx+0xa8],0xb37d0d80
End of assembler dump.
(gdb) p $ebp
$1 = (void *) 0x0
(gdb) p $ebx
$2 = 0

One interesting thing to note is that when I take the game1.love in your first post, and *only move horizontally*, I see no lag spikes. I only get them when moving vertically. EDIT: Also, while moving horizontally I see no disk activity, but I do when moving vertically.

EDIT2: On a different computer I get no segfault, but Lua crashes with this backtrace:

Code: Select all

Error: utils/fileutils.lua:163: threads/rwFileThread.lua:112: bad argument #1 to 'push' (boolean, number, string, love type, or flat table expected)
stack traceback:
        [C]: in function 'error'
        utils/fileutils.lua:163: in function 'doRwTask'
        utils/fileutils.lua:195: in function 'writeFileAsync'
        game/Region.lua:133: in function 'saveChunk'
        game/BlockLayer.lua:233: in function 'clearChunk'
        game/BlockLayer.lua:167: in function 'handleChunkLoaders'
        game/BlockLayer.lua:341: in function 'update'
        game/GameArea.lua:148: in function 'handleBlocks'
        game/GameArea.lua:81: in function 'handleDt'
        main.lua:297: in function 'update'
        [string "boot.lua"]:464: in function <[string "boot.lua"]:436>
        [C]: in function 'xpcall'

Posted: **Fri Feb 02, 2018 8:51 pm**

Is it happening immediately? If it's not win 7 64, then probably my ffi declarations don't fit. Or it can be fs difference.

Posted: **Fri Feb 02, 2018 9:33 pm**

Both are Debian, one 32 and one 64. In the 32 bit machine, it seems to show a screen with some stuff in it and die immediately after. It looks like it's a thread that crashes, because the progress before the crash varies. One of the times it managed to load and run properly. I suspect a race condition of some kind.

In the 64 bit machine, it loads and shows the screen; it crashes when I move a bit (not immediately but shortly after I start moving).

Posted: **Fri Feb 02, 2018 11:13 pm**

no_login_found wrote: ↑Fri Feb 02, 2018 5:37 pm ...
Also that all is a bad sign for estimates. If improving small part of functionality from 'awful' to 'bad' takes 20 days, how many forevers it will take to improve it from 'bad' to 'playable'?

I still insist on bad/broken code like doing way to many load/save calls (possibly saving/loading every frame from/to HDD) or other stuff like way to many created (maybe not drawn but already generated) chunks at once or doing way to many table iterations.. I don't believe your low fps is coming from framework limitations or anything like that. Off loading tasks to other threads i.e shouldn't be necessary with what you got in your game at the moment. Multiply threads can imho help in specific situations like when your game already does a ton of collision checks which can't be optimized further or other demanding tasks, but they won't magically improve performance if there is something wrong with the code itself.
I can be wrong though.

edit: Runs on my Windows 10 64Bit system.

Posted: **Sat Feb 03, 2018 7:24 am**

pgimeno wrote: ↑Fri Feb 02, 2018 9:33 pm In the 64 bit machine, it loads and shows the screen; it crashes when I move a bit (not immediately but shortly after I start moving).

Same behavior on my Linux machine, same error, same stacktrace.

Code: Select all

$ uname -a
Linux deb9 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux

No errors on Win10 x64

Posted: **Sat Feb 03, 2018 8:03 am**

Had no crashes or errors on Win7 x64.

Posted: **Sat Feb 03, 2018 9:40 am**

Replaced one line which probably caused the error in rwFileThread. However it's just theoretical guess, when I try it on fresh debian vm it just segfaults, so I can't check now.

Posted: **Sat Feb 03, 2018 10:10 am**

Does not crash anymore, Debian x64 and Win10 x64.

Posted: **Sat Feb 03, 2018 11:34 am**

Works fine now in the 64bit machine, but it keeps segfaulting in the 32bit one.

I tried invoking Löve with MALLOC_CHECK_=2 to see if there was a double free, but then it no longer segfaults.

LÖVE

Garbage collector stops the game[or probably disk access]

Re: Garbage collector stops the game[or probably disk access]

Re: Garbage collector stops the game[or probably disk access]

Re: Garbage collector stops the game[or probably disk access]

Re: Garbage collector stops the game[or probably disk access]

Re: Garbage collector stops the game[or probably disk access]

Re: Garbage collector stops the game[or probably disk access]

Re: Garbage collector stops the game[or probably disk access]

Re: Garbage collector stops the game[or probably disk access]

Re: Garbage collector stops the game[or probably disk access]

Re: Garbage collector stops the game[or probably disk access]