Try singleplayer in the D/A5 port! v0.2.42

[Nepster]

Solid off by 1: Test case (replay with included level) would be nice. I want to get this right at all costs. Let's make it work like in C++ Lix, or come up with a good reason for such a change.

As the replays are for not yet released levels, I will send them via PM.

Miner & steel: I haven't been able to reproduce this. Test case please -- can you provide a replay?

Sorry, my bad. I checked the original level with C++ again, and the problem was with the missing no-overwrite handling: The steel piece was set to no-overwrite and placed above usual terrain. So the miner removed only usual terrain in D-Lix (as it should), even though parts were displayed as steel.

[Simon]

Okay, thanks for checking back with miner & steel, and for the PM.

Yes, no-overwrite is a huge mess right now, if presentation and physics differ. I have to invest time and energy into drawing next.

-- Simon

[Simon]

Here are hands-on profiling results from my 9-year-old laptop. This is from a build with profiling, but without other debugging instrumentation. Dark drawing (eraser piece drawing) sucks. The testing map was geoo's playground, a huge map with about 10 % dark pieces.

Lix version 0.2.16 profiling results from 2016-02-09 17:49:01.
Unit of time: 1 us == 1 microsecond == 1/1000 of a millisecond.
At 60 frames per second, 1 frame takes 16666 us.
                                       avg/us   min/us   max/us   amount
Level.drawPos to RAM DARK                 269       25     3407      123
Level.drawPos to RAM NOOW                 610      418      803        2
Level.drawPos to RAM NORMAL               428       10    10693     2789
Level.drawPos to VRAM DARK              47191    39122   131871      246
Level.drawPos to VRAM NOOW               2615     2431     2742        4
Level.drawPos to VRAM NORMAL              156      142     1190     5578

The averages are average times per piece, not average times of rendering the level.

Drawing no-overwrite pieces is also slower. But the sampling rate is too little, geoo's playground uses only 2 no-overwrite pieces.

Good suggestion by namida from IRC:
<namida42> wouldn't it make more sense to test with *several* real life maps, since that's going to give a more reasonable picture of how ti performs in actual usage, rather than unlikely test scenarios?
<SimonN> yeah, I should set up some kind of automated test >_>

-- Simon

[Simon]

Version 0.2.17 uploaded, with faster dark drawing.

To improve the performance of turbo-fast-forward, I'd like to try savestating less frequently during turbo. Right now, performance is mediocre, and Nepster is right that it should be faster.

-- Simon

[ccexplore]

So is dark drawing to VRAM now at least comparable perf-wise to NOOW?  I'm actually quite surprise at the performance reported before 0.2.17--conceptually an eraser and a normal draw seem almost identical, just that instead of overwriting with the terrain's pixel value, you overwrite with a black (or the background color) pixel instead.  Feels like I must be missing something there conceptually.

[Simon]

Before 0.2.17, I looped manually over the image, and for each opaque pixel, I drew a transparent pixel to the target. That was a naïve implementation, mostly copied from A4 Lix. While I used calls to the video hardware, they were many, many calls per tile.

In 0.2.17, I have a fully white, fully opaque copy of the tile in VRAM. For drawing dark, I blit the white piece with a blender that deducts from the target pixels (colors and alpha) the source pixels (colors and alpha).

Now, dark drawing has about the same VRAM performance as a normal blit.

-- Simon

[Simon]

Version 0.2.18 uploaded, with more performant turbo-fast-forward.

• Preview renders much faster than in 0.2.16 or before.
• How fast is the transition from menu to game? In addition to rendering the VRAM bitmap, as I do for the preview, I also generate the RAM physics map. That's still implemented a bit naively. I don't know whether I should work on faster physics map creation, so feedback would be cool.
• Clam: Is that bug fixed? Misalignment of physics/graphics in Leaky Building Syndrome
• Nepster: What's the performance of turbo-fast-forward now? A rough estimate is OK.
• Nepster: I've tried something at random against stuck keys. Complain in case they get stuck again. :]

-- Simon

[Nepster]

How fast is the transition from menu to game? In addition to rendering the VRAM bitmap, as I do for the preview, I also generate the RAM physics map. That's still implemented a bit naively. I don't know whether I should work on faster physics map creation, so feedback would be cool.

Much better. Now it scales roughly with the total number of terrain pieces, without a great influence of erasing/no-owerwrite pieces. My computer manages approx. 2000-3000 terrain pieces per second.
I don't see much differences between the time to create the preview image and the actual map creation.

Nepster: What's the performance of turbo-fast-forward now? A rough estimate is OK.

Approx. three times as fast as in previous versions.
- In levels with ~10 Lix, the game runs smoothly in turbo-FF.
- With ~50 Lix, scrolling gets noticable slower, but is still workable.
- With ~100 Lix, the FPS go down to 16-18 and scrolling speed is greatly reduced.

Nepster: I've tried something at random against stuck keys. Complain in case they get stuck again. :]

Haven't had any stuck keys yet, but then I only did a quick check.

[Simon]

Thanks! Happy happy about the improved rendering.

It's interesting how the number of lix makes such an impact on speed. Will think about it more. They're not optimized in memory for fast copying. I haven't put detailed profiling for savestating/physics updating in.

-- Simon

[Simon]

Version 0.2.19 uploaded.

Only Ramond needs to update to this one.

The switch --hardfull=1600x900 forces hardware fullscreen at the given resolution. Hardware fullscreen can't be accessed by setting user options right now, it must be wanted via command-line switch. This enables the game to run on Ramond's computer. I advise Ramond to run the game via a Windows shortcut that calls lix.exe --hardfull=1600x900, until I make a proper user option for hardware fullscreen.

I don't believe that hardware fullscreen affects performance in any way. On my Linux machine, hardware fullscreen prevents alt-tabbing. >_>

Also, little bugfix, singleplayer browser crashed for new users.

-- Simon

[Clam]

• Clam: Is that bug fixed? Misalignment of physics/graphics in Leaky Building Syndrome

-- Simon

It's fixed . The level now looks exactly like it did before.

Previewing and loading levels is noticeably faster compared to 0.2.9 (the last one I downloaded). A reasonably large level took half a second to load, now it's less than half that (though it's hard to measure times on this scale).

[Simon]

I'm fixing one bug a day -- or, when only hard bugs remain, trying to write enough code for a meaningful commit each day. Can't interrupt a 2-month streak. >_>

No need  to update, because the changes aren't that big. Summary of recent changes up to 0.2.22:

- Fixed #44: We sort dirs and levels according to the listing _order.X.txt.
- In singleplayer, lix start spawning 1 second after level start, not 4 seconds.
- Fixed #48: Assertion failure of climber on torus maps.
- Fixed sprite positioning of the climber.
- The panel displays elapsed minutes and seconds since level start.

But there's always need for your guidance. Is there something urgent to fix or implement? Issue list on github. Without good targets among the issues, I'd continue on the editor.

-- Simon

[Simon]

Screenshots from the early editor development. Hidden in a spoiler because of large image dimensions.

Spoiler

-- Simon

[Simon]

Nothing exciting to test yet.

I've been working on bugfixes and editor tile hovering. The editor understands that terrain has solid and transparent pixels. When hovering over multiple tiles, the editor chooses the topmost tile that's still solid at the mouse position. Priority invert selects the bottommost tile.

I'd like to have a mostly-functional editor before our next large test.



Update 2016-03-02: Attacking the joystick bug in separate topic.

-- Simon