Lemmings Forums
Lix => Lix Main => Topic started by: Simon on August 24, 2015, 09:42:39 PM
-
Update March 2016: Try D-Lix 0.2.x (http://www.lemmingsforums.net/index.php?topic=2413.0) 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 (http://asdfasdf.ethz.ch/~simon/etc/lix-d-port-2015-08-23.zip). 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 (https://github.com/SimonN/LixD) 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
-
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.
-
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
-
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?
-
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]
-
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.
-
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?
-
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
-
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. ;-)
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
-
Great job. Excited for the future of the game :)
-
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...
-
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
-
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.
-
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.
-
Here's data from an older, crappier Windows laptop (4-5 years old? maybe even older, not sure) that I don't use much except for testing on slower hardware. ;P (Note: it's probably not the oldest I have access to, stay tuned. ;P)
At least the fullscreen mouse problem didn't happen on this cmoputer, no surprise since it's using default system DPI settings unlike the other one. The inability to regain mouse capture in windowed mode after focus lost does repro though.
One other thing: potentially consider avoiding mode 5 altogether. During the benchmark in both fullscreen and windowed modes, Lix consistently crashed the graphics driver on this computer whenever the benchmark gets to mode 5. It seems Windows has gotten better over the years and instead of Bluescreen-and-reboot, in this case display just flashes black a few times followed by a "your display driver has crash and recover" error message, and then back to normal. If I'm lucky sometimes Lix even manages to continue running after all that, though most of the time the program dies with it. Ah, the joys of dealing with graphics-driver-specific bugs. (To be fair, it may also be possible that Lix itself is doing something wrong that it shouldn't be doing in the first place; that said, the driver is supposed to be resilient and not crash.)
-
ccx: Thanks for the extensive feedback and log/profiling files.
Mouse not captured on reentry: I can reproduce this here. It's a general bug, seems be solvable with the correct Allegro calls. Issue tracking for the D port is on github (https://github.com/SimonN/LixD/issues), I've added it.
Mouse doesn't leave small rectangle: Will look into this.
Ichotolot's machine is a few years old, but was top-class when he bought it. He hits 60 FPS on the 3500 gadget map too, and I have the log/profile results.
I'll make a table from the various results at some time.
-- Simon
-
One other thing: potentially consider avoiding mode 5 altogether. During the benchmark in both fullscreen and windowed modes, Lix consistently crashed the graphics driver on this computer whenever the benchmark gets to mode 5. It seems Windows has gotten better over the years and instead of Bluescreen-and-reboot, in this case display just flashes black a few times followed by a "your display driver has crash and recover" error message, and then back to normal. If I'm lucky sometimes Lix even manages to continue running after all that, though most of the time the program dies with it. Ah, the joys of dealing with graphics-driver-specific bugs. (To be fair, it may also be possible that Lix itself is doing something wrong that it shouldn't be doing in the first place; that said, the driver is supposed to be resilient and not crash.)
Mode 5 is actually the exact same as mode 4, just applied to a bigger bitmap. It uses ./images/matt/oriental/bonsaitree.png (227x207) instead of ./images/matt/earth/07b.png (16x16). I recall using the even huger dragon instead of the bonsai tree at some point. I encountered a crash but I didn't output the modes yet back then so I didn't find what caused it. I wonder if it's due to the size, or due to the weird dimensions. Maybe you can try replacing the bonsai tree with a 256x256 bitmap and see if you encounter the same crash, or change the size of the small bitmap to something weird. Mode 4 and 5 really just blit bitmaps onto the bitmap of the level map (al_draw_bitmap), while the other modes use textured triangles (al_draw_prim). Or at least that's what I think they do, I don't know what exactly those functions do internally.
-
I wonder if it's due to the size, or due to the weird dimensions. Maybe you can try replacing the bonsai tree with a 256x256 bitmap and see if you encounter the same crash, or change the size of the small bitmap to something weird.
It seems to be mostly due to the size. After testing it out with various different sizes of bonsai (note: the benchmark desperately needs the ability to skip ahead to the next thing via keypress or similar, for testing out this sort of thing), it seems that the cutoff might be somewhere around 192x192. Sizes much smaller are fine (ie. no crashes) even with odd non-power-of-2/non-multiple-of-8 sizes, like 127x127 and what-not. Around 192x192 are where the crash seems to start happening, with weird sizes seemingly to more likely to trigger the crash than non-weird ones. At that boundary point the crash may not always repro with 100% consistency but still quite often. Once you go sufficiently beyond 192 (like maybe 200x200), the crash seems to be triggered all the time regardless of weirdness of the size.
For now I think I'm more inclined to chalk the fault up to the graphics driver, though it also suggest there may be a need for a user-configurable parameter to place a size limit on bitmaps (which gets handled by Lix by essentially splitting one blit into multiple blits that conforms to the limit), as a potential mitigation against faulty drivers like what we have here.
Mode 4 and 5 really just blit bitmaps onto the bitmap of the level map (al_draw_bitmap), while the other modes use textured triangles (al_draw_prim). Or at least that's what I think they do, I don't know what exactly those functions do internally.
Hmm, are you sure you have the mode numbers correct in the statements above? After reducing the bonsai to 127x127 so mode 5 works, I'm seeing significant performance differences between 4 and 5, with 5 being extremely slow (probably 1 frame per second if not worse), while 4 is more acceptable (at least it doesn't look like framestepping like mode 5 ;P). On the other hand, mode 3 is almost as slow as mode 5 though still better (looks something like maybe 2 frames per second versus mode 5's 1 per second).
It does make sense to me that textured polygons are more efficient, after all they are the workhorses of 3D graphics which most graphics cards have to support in this day and age. That being said, I have to suspect you may still not be doing certain things the right way, if blitting is getting you framerates that look like framestepping. Perhaps time to browse some sort of forum on A5 for technical expertise?
-
Hmm, are you sure you have the mode numbers correct in the statements above?
Yes, they are correct. You can check perform_geoo_benchmarks() in https://github.com/SimonN/LixD/blob/master/src/basics/demo.d for details (don't mind Simon's weird variable names). The modes are as outlined:
- Write all triangle vertices in an array, then use a single al_draw_prim call. 16x16 bitmap, 20000 triangles.
- Write all triangle vertices in an array, then use a single al_draw_prim call. 16x16 bitmap, 80000 triangles.
- Write all triangle vertices in an array, then use a single al_draw_prim call. 227x207 bitmap, 20000 triangles.
- Hold target bitmap. Call al_draw_bitmap for each bitmap. Unhold target bitmap. 16x16 bitmap, 10000 calls.
- Hold target bitmap. Call al_draw_bitmap for each bitmap. Unhold target bitmap. 227x207 bitmap, 10000 calls.
- Write the vertices for each pair of triangles forming a rectangle into an array, then call al_draw_prim for each. 16x16 bitmap, 20000 triangles.
What all modes do is draw some stuff in the top left corner. All the other stuff floating around is just fluff Simon was testing, and tbh it shouldn't actually be drawn during the tests.
We checked A5 forums for similar questions, and the results seems reasonably consistent with benchmarks other people made. If the allegro layer is too slow, the alternative is doing everything directly via OpenGL. E.g. OpenGL natively supports quads instead of triangles, which would shrink the required size of a vertex array for modes 1-3, for instance. Though afaik allegro doesn't always use OpenGL in the backend, I think it depends on the graphics card what it uses.
-
Interesting, so it sounds like the slowness seen in 3 and 5 are due to the much larger bitmap size. You would have 183.55 times more bitmap data to deal with even when keeping everything else equal. Perhaps it would be interesting to have a mode that uses 16x16 bitmap but have 3671000 triangles or 1835500 calls (ie. scaled by that 183.55 factor) to compare against.
Do 3 and 5 actually reflect realistic situations that may be encountered in real lix levels, or is it more like a stress test for benchmarking only?
I don't pretend to be anywhere close to an expert on this stuff, but regarding 1-3 vs 6, I think I've heard/read that you basically want to batch GPU calls as much as possible. That way the driver can work out the most efficient way to schedule the given work across the GPU's pipeline taking as much advantage of parallelism as it can. So I would expect (but haven't look at the actual data to confirm) 6 to be less efficient than 1.
Regarding OpenGL, my main worry would be that I think for Windows, even though most graphics drivers support it I don't think it's really required, at least not to the degree that DirectX support is. DirectX is first-class citizen in Windows world compare to OpenGL. You can bet that nothing Microsoft writes for Windows would be using OpenGL, and many games written for Windows also will likely use DirectX because it's where Microsoft and graphics card vendors will spend most of their efforts in terms of enhancements, improvements, etc., such that when performance is paramount it will make more sense for them to target DirectX. As a result given this business climate, if nothing else I'd expect that for the same Windows graphics driver, the DirectX aspects will likely be much more well tested and maintained, compare with the OpenGL aspects. The situation is such that for example, Chrome apparently uses a OpenGL->DirectX translation layer in Windows to handle WebGL content (https://code.google.com/p/angleproject/), rather than directly targeting OpenGL.
So if Allegro 5 can intelligently choose between OpenGL vs DirectX for its Windows implementation, that may be advantageous compare with always sticking to OpenGL. Linux is of course different since it's just OpenGL in that world.
Triangles vs quads may not be that good a reason to jump to OpenGL anyway, in terms of performance. At least the given data on this test computer would indicate the texture size can be much more of a bottleneck. It would not surprise me that at least for some lower-end drivers, their quad support may well be handled by the driver internally by turning the quads back into triangles especially by the time things get to the GPU.
-
(Note: it's probably not the oldest I have access to, stay tuned. ;P)
Continuing the trend, here's data from an older laptop with an even crappier graphics card, in fact likely the crappiest brand in existence* (SiS). The laptop is running Win7 but has a label that says Windows Vista, so that should give you a good idea how old it is. :XD: And in case you're wondering, I still have yet an older one running XP, though it might not turn on anymore since I haven't powered or even charged it for months ever since Microsoft stops providing security patches for it. :XD:
Bad news on this Vista-era laptop: the game only lasts up to the first level of the benchmark, it crashes (the game this time, not the driver) on the second level for both fullscreen and windowed. The logs seems to have captured the crash details successfully so I'll leave it for Simon/geoo to sort out.
And yes, the laptop does run C++ Lix just fine, as does Clones, so maybe it's a sort of worst case scenario but still a valid setup for testing this.
*actually I wonder if they're even still in business
-
Crash on the Vista-era laptop in level 2: The level has #SIZE_X 3200, and the crash is upon creating a VRAM bitmap, but getting a null pointer back from A5. It's possible that the gfx card's max VRAM bitmap size is 2048x2048. The card in my 9-year-old laptop can't make any VRAM bitmaps larger than 4096x4096 either.
Things like this are the reason why I've opted for the debugging build. It may run slower, but will dutifully log all the assertion failures and other things flying out of the main loop. Thanks for testing this!
The Clones developers are good hustlers when it comes to speeding up things. They use many 128x128 (IIRC) bitmaps instead of one large bitmap for the land. They have to draw on these pieces eventually with terrain-altering skills. I have to experiment how fast it is to blit this land at some time.
A5 should select either OpenGL or DirectX, yes. It probably defaults to DirectX on Windows, but I don't know much about the internals.
-- Simon
-
Does Clones attempt to keep the entire level's terrain bitmap in VRAM no matter the size of the level, potentially just failing to run the level if it's too large? Or does it do something like dynamically swap parts of the level in and out of VRAM as needed when it can't all fit? I seem to recall some fairly large singleplayer levels (though perhaps not 3200x3200 or even 2048x2048).
-
My results attached.
OS: Windows 8.1
CPU: Intel Core i3-3110M 2.4GHz
RAM: 8GB
GPU: Intel HD 4000
Age of hardware: 3 years
Screen resolution: 1366 x 768
Fullscreen works fine, which is an improvement from the current C++ Lix. I haven't noticed any other issues :lix-smile:
-
I deleted my old post and I'm creating a new one to bump the topic as I tested it on my XP machine now.
I ran it on my primary machine in both Windows and Ubuntu. Same machine, same hardware specs, but the performance on Ubuntu is notably better.
On my XP machine the benchmark does at least run, but only the first level runs at 60 fps. The 3500 gadget level takes almost 10 seconds to load, so the benchmark only has two or three frames there.