D/A5 port: Current status, 2016-01-18

[Simon]

Hi folks,



Current status of D/A5 Lix

I'm 90 % feature-complete for singleplayer, and 80 % done with the singleplayer-relevant menus. In the upcoming days/weeks, I'd like to compile another test release for Windows.

Physics are similar to C++ 2015-09-02 plus geoo's physics fixes: miner cancelling prevention, refined lem order when updating physics.

Playing singleplayer levels is supported, replay saving/loading is supported. Automatic replay checking is not yet supported. Reasoning: Physics change somewhat anyway, and must be refined for a while. Manual testing of physics might be most interesting. Fewer features allow me to get the test release out sooner.

Or would someone like automated replay testing right away? Anything else that I forgot, that would be helpful for the smoke test? Bug tracker of D Lix.

Benchmarking in 2015-08

In August, I have asked people to send in their benchmarking results. As it turns out, I have the slowest machine of everybody. Therefore, I haven't analyzed the benchmark results more deeply, and instead wrote code that made myself happy. If I'm content with the performance here, probably most people will, too.

If anyone wants to make nice graphs or tables, you can download the bundled raw benchmark logs from 2015-08.

If anybody want to get entrenched and optimize drawing, they're encouraged to nag me in IRC.

geoo:

I have implemented drawing to terrain with correct semantics now. In particular, these two bugs are fixed: removers overwrote steel, adders overwrote terrain.

Drawing a miner swing takes 0.1 ms when it doesn't have to check for steel, and 7 ms (= half of a frame at 60 FPS) when the mask is copied pixel-by-pixel in a manual loop. Since in that case, it would cancel, this kind of drawing is comparatively rare. Exploders not overwriting steel are more expensive. The nuke explodes one lem a time, so it's again leveraged.

I am planning some experiments with holding the bitmap drawing. I expect this to speed up the pixel-by-pixel copying. I haven't looked into that again since you wrote the benchmark code. (Explanation of benchmark modes, and benchmark code on github before I eventually removed it from the master branch.)

Once this thread has settled, towards the weekend maybe, I'd like you to build for Windows.

-- Simon

[RubiX]

Loving that quality of the bottom panel, really exciting to see this port coming along.

[ccexplore]

Do you currently use the same bitmap both for displaying and for game mechanics?  If different bitmaps are used, is the performance hit around steel handling mostly applying to the displayed bitmap?

I'm asking because for the display bitmap anyway, I don't think you have to do special rendering to handle steel:  since everything steel is immutable for the entire duration of the level, just capture the bitmaps of all steel areas at start of level, and draw them over the top of regular terrain on each frame.  They'd cover up any removed terrain so they don't look removed.  Obviously you can't apply this to the bitmap used for game mechanics (well if you do, you'd need to change how you read terrain pixels for game mechanics), but I'm assuming that is less of a performance issue (well I can be totally wrong, but this is the best I can do without knowing any implementation details off top of my head at the moment).

[ccexplore]

On second thought, that suggestion as stated was kinda dumb, since I'm guessing terrain currently aren't being redrawn every single frame, so doing it for steel would be extra work, probably.

Still, the general point is that maybe it's possible to handle the steel situation as two normal blits (normal terrain followed by steel) instead of one special blit that has to account for steel.  If normal blits are much more optimized relative to the special blit, then having to do two may still be faster.  Granted, there's then also a memory cost since you'd end up with separate bitmaps for steel versus normal terrain.

All that being said, "blitting with a mask" seems common enough a task that I'm guessing there'd probably be a way to do it as efficiently as normal blits on most video cards.  Maybe worth an "ask the experts at the support forum of Allegro 5" kind of thing?

[Simon]

Rubix: Thanks! :-)

ccx/geoo: I've beefed up the implementation with bitmap holding. (Make hardware queue drawings instead of draw right away, queue many blits onto the same target bitmap, unhold => hardware can draw faster.) This brought down measurements for the per-pixel drawing from 7 ms to 1.2 ms. I can't tell whether this is accurate, or whether gfx-work differs from this code's execution time. From watching the FPS, these numbers are in the correct ballpark.

Current implementation: There is a separate matrix for physics in RAM. Updating physics changes the matrix, and checks whether the blit can be done later in one go, or if it must happen per-pixel. Later, when updating graphics, I hold bitmap drawing, draw all masks either in-one-go or per-pixel, then unhold.

The newest versions of Allegro 5.1 don't compile on my old Debian 6 anymore. >_> A5.1 comes with hardware shaders, those look like they could simplify and speed up (drawing only on transparent pixels of the target area). The A5 folks have suggested shaders for per-pixel before, when I asked in 2011. So, that's where expert knowledge of my domain points to.

Saving the steel at start of level: That would help for terrain removers, but terrain adders still have to draw behind the terrain. Since steel-saving incurs an extra cost at start of level, but doesn't solve all questions, I haven't tried it yet. Maybe steel-saving for terrain removers, and shaders for terrain adders, would be most interesting.

However, I believe the current implementation is OK, performance-wise. If someone sends in a patch to improve it, I'd happily merge it in. :-) As a single developer, because I'm content for now, I'd like to focus on other parts of the program.

In particular, I'd like feedback from other people about bugs and performance. That's why I encourage geoo to build for Windows in the upcoming days.

-- Simon

[Simon]

I've managed to cross-compile from Linux to Windows, by installing and running the entire Windows toolchain through Wine. Works similar to the Windows build instructions, but I'll have to document this extensively nonetheless.

The resulting build runs for Clam pretty well. Apart from a crash during replays that doesn't generate a full stacktrace, things seem to work.

I'll upload a test release in the upcoming days.

How you feel when your build runs on other people's computers:



How you feel when they report a crash in al_get_joystick_state(), which you never call in your program:



-- Simon

[RubiX]

Good job!