D/A5 port: Windows binaries to test

[Simon]

Update March 2016: Try D-Lix 0.2.x with singleplayer largely done, and the editor in development.

The topic here is outdated.



Hi folks,

I would like to know how well the Lix D port runs on your machines.

• Windows users: download this zip archive. This is not an update of the stable Lix release; it's completely independent. Extract to a new directory.
  
• Linux users: If you feel adventurous, you can look at the github repo and build yourself. There are instructions in doc/build/linux.txt. The instructions aren't 100 % complete necessarily, find me on IRC (irc.quakenet.org #lix).
  

How you can test:

• Start the game.
  
• In the main menu, click the big fat button "Benchmark! Takes 2 minutes to run."
  
• A couple of levels will be displayed, and some expensive graphics rendering will be tried. Something new happens every 10 seconds automatically. You can scroll around the level if you like.
  
• When you're back in the main menu, exit the game.
  
• Send/post the following 2 files: data/log.txt and data/profile.txt.
  
• Give some rough information about your computer: What's your operating system? Average age of your hardware? Screen resolution? In case you know it: what's your CPU and graphics card?
  

And that's it. :-)

If you had weird mouse behavior in the old Lix, maybe that has become better already in the D port.

Skippable background:

In February 2015, I have started a fundamental rewrite of Lix in the D Programming Language, using the newer library Allegro 5 instead of the 15-year-old Allegro 4.4. When geoo was visiting me a week ago, we got the D port to compile on his Windows machine. The choice of D over C++ aims at long-term productivity and convenience, without sacrificing efficiency.

The library upgrade is more important. I have great aspirations for the port. With Allegro 4.4, many different people have had issuses: Lix didn't run at all, it didn't display properly on their monitor, or the mouse behaved weirdly. I want the game to run fine for these users.

Finishing the port will take at least 6 more months. Depending my reallife work, expect it in 1 or 2 years. I will continue to maintain the C++/A4 version until then.

-- Simon

[namida]

First thought - all those DLL files in the main directory are a mess. Can they not be embedded into the EXE as resources (NeoLemmix does this with BASS.DLL, though it's certianly not practical in all cases - for example, I wouldn't be able to do this with any BASS addons if I were to use them), or at least placed in a subfolder?

During the test, typing UTF8 characters did not work - although I had Korean IME activated, it still took normal ASCII input. (eg. if I pushed the F key, it typed F, whereas if it was taking this input correctly, it should instead type ㄹ). The sound test worked perfectly fine; it played without delay. Scrolling in the levels also worked fine. Whenever it loaded something new, it appeared to freeze for about a second before displaying the new content and continuing to work.

Although I didn't watch it overly closely, I never noticed the FPS counter displaying anything other than 60, though the log files (which are probably more reliable) would disagree with me here.

I notice that as well as the main game window, a blank console-type window with a flashing _ mark also appears when running Lix. The title bar of it is just the full path of the Lix EXE.

Log files attached. Also attached is a screenshot of some weird behaviour if I moved the mouse outside the level area in the benchmark test; as well as these extra cursors appearing, they also flickered.


System
OS: Windows 10 Home
CPU: AMD A10-5745M Quad-Core 2.1GHz
RAM: 12GB
GPU: Radeon R7 M260, 2GB VRAM
Hardware age: Not very old; about 4 - 5 months I think?

The PC is a laptop with a dual-GPU setup, so I tested with the low power GPU as well.

GPU: Radeon HD 8610G, 768MB VRAM

The second set of log files is using this GPU. I notice the "log.txt" has two sets of prior logs as well, one being the first log, and the second was accidentally run with the same GPU as the first time.

[Simon]

First thought - all those DLL files in the main directory are a mess.

We don't even know which of the DLLs are necessary. :-) This is our first try shipping Windows binaries.

Cleaning this up is on the radar.

During the test, typing UTF8 characters did not work - although I had Korean IME activated, it still took normal ASCII input. (eg. if I pushed the F key, it typed F, whereas if it was taking this input correctly, it should instead type ㄹ).

Noted.

The sound test worked perfectly fine; it played without delay. Scrolling in the levels also worked fine.

Perfect, thanks for mentioning.

Whenever it loaded something new, it appeared to freeze for about a second before displaying the new content and continuing to work.

It's rendering the level. It's also fetching tiles from disk, but that shouldn't take too long. Everything is kept VRAM now. Blitting is fast, but load times can be noticeably longer now. I'll have to see how to deal with them.

I notice that as well as the main game window, a blank console-type window with a flashing _ mark also appears when running Lix. The title bar of it is just the full path of the Lix EXE.

Noted. The extra console can be suppressed with a linker setting, will see how to get that done with the build system here.

Log files attached.
System
OS: Windows 10 Home
CPU: AMD A10-5745M Quad-Core 2.1GHz
RAM: 12GB
GPU: Radeon HD 8610G *
Hardware age: Not very old; about 4 - 5 months I think?

Thanks. So you get full FPS on the map with 200 gadgets, and take a serious performance hit with 3500 gadgets. On my 9-year-old hardware, the 3500 gadgets run at 10 FPS.

The networking game should run with that many sprites, so there's some work to do here.

Also attached is a screenshot of some weird behaviour if I moved the mouse outside the level area in the benchmark test; as well as these extra cursors appearing, they also flickered.

This is expected. It's the space for the panel, I never draw there yet.

Thanks for the extensive report!

-- Simon

[namida]

I updated my post to reflect accurately determining which GPU was in use, as well as testing with the other one. Interestingly, the low-power GPU actually performed better on the 3500 gadgets level, but didn't perform as well on the "demo" tests.

I wouldn't call it a "serious" performance hit. 30 FPS is surely adequate for Lix?

[ccexplore]

I wonder if it'll be good to have an analogous C++ baseline benchmark program to compare against on the same computer?  Though I realize it may be more work than it's worth.

Give some rough information about your computer: What's your operating system? Average age of your hardware? Screen resolution? In case you know it: what's your CPU and graphics card?

For Windows:  if anyone is unsure, there is a "dxdiag" program you can run to gather this kind of information (except for "average age of your hardware").  You can launch it by pressing Windows key + R to bring up "Run", then type "dxdiag" (no quotes) and press ENTER.  [If that doesn't work for some reason, the EXE file of same name is found in the c:\windows\system32 directory (replace the initial "c" with the letter of your system drive, though in almost all cases it will be C).]

Find and click the "Save All Information" button at the bottom of dxdiag's window.  The information dump will be saved as plain text file, which you can attached here.

[edit: updated how to launch dxdiag based on namida's suggestion below]

[namida]

For Windows:  if anyone is unsure, there is a "dxdiag" program you can run to gather this kind of information (except for "average age of your hardware").  The EXE file is found in the c:\windows\system32 directory (replace the initial "c" with the letter of your system drive, though in almost all cases it will be C).  It is buried under the Start Menu in slightly different places depending on which version of Windows you are running, that's why I'm pointing you directly to where the file's at.  Run it, then click the "Save All Information" button at the bottom of its window.  The information dump will be saved as plain text file, which you can attached here.

You can run it quite easily without having to navigate to it like that, by bringing up the Run window (press Windows key + R) and typing "dxdiag".

However, in the case of laptops with dual-GPU setups, it may only report one of the GPUs; I've noticed this with both NVidia and AMD GPUs (my previous laptop also had a dual setup, but with an Intel low-power / NVidia high-power, unlike my current one which has AMD chips for both). Furthermore, it doesn't really offer a good indicator of which one is actually being used. You'll need to use Catalyst Control Center (for AMD; or the equivalent in the NVidia case) to find the full info, and work out which one is being used.

[ccexplore]

Thanks for the tip, I forgot about the Windows keyboard shortcuts which are thankfully more stable from version to version.

I don't have much experience with the dual-GPU cases.  Is there like a custom utility to switch the system between the two choices of GPUs?  If so, are you saying that even after you switch, rerunning dxdiag again might still not produce data that reflect the change in GPU being used?

[Simon]

I updated my post to reflect accurately determining which GPU was in use, as well as testing with the other one. Interestingly, the low-power GPU actually performed better on the 3500 gadgets level, but didn't perform as well on the "demo" tests.

Yep, interesting results. geoo has made all the different demo tests, to see how they fare against my current drawing code.

I wouldn't call it a "serious" performance hit. 30 FPS is surely adequate for Lix?

This is tricky to answer. It's mostly human perception. The physics run at 15 FPS, so fixing the framerate at 30 FPS would be enough. All that would mean is 16 ms of input lag and a slightly stiffer mouse cursor movement.

If the framerate is wobbling up and down, that might lead to noticeable skips in the physics, even though the physics speed is the same.

Right now, I want to see whether I can reap some low-hanging fruit to boost the graphics performance. If there is nothing much to improve, 30 FPS wobbling up and down is still playable, you're right.

I wonder if it'll be good to have an analogous C++ baseline benchmark program to compare against on the same computer?  Though I realize it may be more work than it's worth.

Currently, there are 3 brakes in the released Windows executable:

• It's a debugging build. It's got name symbols, contract checks, and asserts compiled in. Those are straightforward to remove with a different build command.
  
• It's also compiled with the reference compiler DMD, not with GDC, which is the compiler using the powerful and well-optimized GCC backend. Allegedly, on CPU-heavy programs, GDC produces binaries that run up to 30 % faster. The Allegro D bindings errored out when using GDC, but I can try to iron out the problems in the bindings myself some time.
  
• It's got the profiling code in (what writes to profile.txt). This is not zero-cost. I have profiling even in some inner loops. I could take that out of the inner loops, and only profile the outermost loop; or I could take it out entirely and log only the framerate (log.txt)

Removing brakes 1 and 3 (debugging and profiling), I get a 30 % speedup (10 FPS -> 13 FPS) in framerate on the 3,500 gadget map. On the other hand, I get much lower benefits in geoo's graphics testing, 24 FPS -> 25 FPS in demo mode 4.

We have opted to leave in all the brakes in this first test build, to get the most detailed data. It's possible that brakes 1 and 3 (debugging and profiling) amount to different speedups for other people; that would be left for another test.

-- Simon

[RubiX]

Looking nice.
typing A, the sound plays immediately.

64bit win7
corei7 930 @ 2.8ghz
8MB Ram
Radeon HD6770 1GB

[Simon]

Rubix wins, he achieves 60 FPS on the 3,500 gadget map. ;-)

All this aside: I'm super happy that this build runs at all for everybody.

For many users, old Lix had issues even before the first level came up: It wouldn't start, it wouldn't go to fullscreen, the scaled 640x480 image would look crappy, the mouse wouldn't move properly.

Seeing how pouring the last 5 months into the D/A5 port hasn't gone to waste -- this is encouraging.

-- Simon

[RubiX]

Great job.   Excited for the future of the game

[namida]

Thanks for the tip, I forgot about the Windows keyboard shortcuts which are thankfully more stable from version to version.

I don't have much experience with the dual-GPU cases.  Is there like a custom utility to switch the system between the two choices of GPUs?  If so, are you saying that even after you switch, rerunning dxdiag again might still not produce data that reflect the change in GPU being used?

It's generally switched on a per-application basis, not a global setting. Since I don't think I've ever found a way to get dxdiag to display the high-power one, it's possible that maybe data still goes through the low power one but is merely passed on to the high-power or something? Though really, I have no idea how the setup works behind-the-scenes.

Looking nice.
typing A, the sound plays immediately.

64bit win7
corei7 930 @ 2.8ghz
8MB Ram
Radeon HD6770 1GB

Rubix wins, he achieves 60 FPS on the 3,500 gadget map. ;-)

Hm... it'd appear that CPU affects this more than GPU does, then? Since as far as I can tell, Rubix has the superior CPU and got 60FPS, but I had the superior GPU (and for that matter, more RAM, though I don't know if Rubix maybe has faster RAM) and only got around 30...

[Simon]

Hm... it'd appear that CPU affects this more than GPU does, then? Since as far as I can tell, Rubix has the superior CPU and got 60FPS, but I had the superior GPU

Very much possible. I wondered about this too when I read about your very recent graphics card. In the benchmark, the 4 levels are bogged down much more by debugging/profiling than the 6 graphics demos.

Next time we build on Windows, I can try to get you an extra release build of this exact version instead of a debug build.

-- Simon

[ccexplore]

Results on one of the better laptops I currently have access to.  When I have time I can try it on older, slower computers too.  I believe the computer is relatively new model that came out within the last 2-3 years.

(yes, the logs show that I aborted one of the first benchmark runs, because it was clicked on by accident, partly due to the mouse issue noted immediately below.  The log does end with a completed benchmark run.)

But bad news:  with D lix, mouse actually has bugs for me on this computer in both windowed and fullscreen mode, that do not happen with the current C++ lix.  I suspect this may be due to the DPI settings I'm using.  I'll try to explain more on that in another post.  In fullscreen, lixd is not correctly handling mouse cursor movement, such that for example when I moved the mouse as far to the lower-right as I can, the cursor displayed in the program is nowhere close to the lower-right corner, as seen in the attached zipped screenshot.  Note that it's not just merely the game's cursor being displayed in the wrong position--where the game's cursor is displayed does actually correctly reflect the UI element in the game you will be able to click on--so this bug means there are areas of the game's display that I cannot reach to click on at all.

In windowed mode, the mouse is okay, but it fails to retain mouse capture once I switched out to another window via Alt+Tab.  And I kind of have to always do that at the start because for some reason, when launched lixd insists on positioning the window off to the lower-right corner of the screen instead of centering it like one would expect.  And since it starts off with working mouse capture, I can't move the window without using Alt+Tab first to switch out first (which turns off the mouse capture, allowing mouse to reach the title bar of the window to drag).  In C++ Lix when I do this sort of  thing, as soon as I switch focus back to the Lix window, mouse capture will work correctly again.  In D Lix, it seems to permanently lose mouse capture, so the system mouse cursor (ie. the arrow) remains visible at all times after the switch out, and mouse is no longer confined to the window when the window has focus.  The system-mouse-cursor remains visible actually also happens if I Alt+Tab in fullscreen mode.

One other fun side effect of the mouse problem in fullscreen is that, I discover the level selection UI currently does not seem to respond to ESC to go back to the main menu.  So in fullscreen mode I end up stuck if I go there, because due to the aforementioned bug, I can't position the mouse to reach either button.

[ccexplore]

During the test, typing UTF8 characters did not work - although I had Korean IME activated, it still took normal ASCII input. (eg. if I pushed the F key, it typed F, whereas if it was taking this input correctly, it should instead type ㄹ).

It's worth pointing out that from prior testing when I contributed code for Unicode support in C++ lix, I don't think IMEs will work with the current C++ lix either, even with the updates to support Unicode.  At least for Windows.  I seem to vaguely remember concluding after digging into A4's Windows source code that IME input most probably will never work with that implementation.  It remains to be seen what A5's like in that regard.  That being said, depending on how fonts are handled in the D port, it may be a moot point anyway as the game may still be unable to display the character even if it handles IME input correctly.

Instead, try testing with a different keyboard layout like German or similar; any that has dead-key support for entering letters decorated with various diacritical marks.