What benefits would the 9*17-frame countdown have over the 144-frame countdown?

The physics update should be the only unit of time for computations. Seconds are not interesting, they're a weird multiple of the main unit of time. There is cultural value in 5 seconds, the L1 exploder had that. There is hand-on value in 144 frames, because it matches the old NL radiation replays.

The only value in 9*17 is that you can keep the presentation, without the presentation lying about the mechanics. I accept that marking the radiated lems is good. But displaying the remaining physics updates rounded to seconds is too coarse to be useful.

-- Simon

AAXXAXX
XAAAA
AXXXX
AAAXXX
AAAAXXXX

-- Simon

Awesome, thanks for clarifying.

I want to support multiple binds of the same key wherever appropriate. I will retry this bug later at home.

The options menu should allow, but warn about same key bound to different functions. Excellent feature request for D Lix. I'm undecided about binding multiple keys to the same function. People love it for pause. MMB and RMB should be rebindable like keyboard keys.

-- Simon

C++/A4 stable 2016-01-09.

I cannot repro this:

1. If you use backwards frameksip one frame at a time, it erases any actions you've made once you go past them. On the other hand, if you were to go back one second, any actions that happen during that second are not erased.

I've attempted this repro that doesn't work:

• Linux, map back-one-frame to [2], map ahead-one-frame to [3]
• Assign stuff in frame B
• Go back from frame C > B to frame A < B by pressing [2] several times. This activates pause.
• Go back from frame A < B to frame C' > B by pressing [3] several times. The assignment is replayed as I expect.
  

If I hold [2], [3] instead of tapping them repeatedly, or LMB on the panel buttons instead of tapping [2] and [3], I get the same expected result.

namida: How do you trigger the bug?

-- Simon

The lingering fear of nuke solutions points to a game design problem. Nuke should live outside the solution space. Singleplayer should prevent saving after nuke, and show that clearly.

Yeah, Rubix's level doesn't need the nuke.

-- Simon

Great ideas!

I love the frame-dropping during ballpark-framestepping. The fastest method for backstepping goes back 15 steps per graphics frame, even when the FPS drop below 60. Instead, the feature should go back (15 * 60 / FPS) steps, to cancel performance hits.

Yeah, I haven't profiled enough for the question in part 8. I work on D Lix sporadically, mostly on the editor. When I get loose ideas for physics, they go on the backburner. Manual savestate RAM/VRAM management smell best to me. Still, I'll keep the alternatives in mind.

-- Simon

Part 8: Sucky performance of OO -- but is it the lion's share of my problem?

There's a performance downside to the state pattern in part 6.

Naively, with automatic memory management, we allocate a class instance for the lemming, then a class instance for the job. We don't estimate the maximum memory size to fit all jobs, but allocate dynamically per subclass. The lemmings go in a collection of pointer-to-lemming, and point themselves to their jobs. When we copy n Lemmings, we follow 2n pointers, and allocate 2n little chunks.

The tagged union is faster. All lemmings occupy the same amount of space: job-independent fields, plus the maximum length among all jobs. You can allocate naively n lemmings, or put them in an array that allocates once. Similarly, all-fields-in-base-class allows to allocate once.

In D/A5 Lix, I've implemented the naive strategy. In addition, I allocate entire savestates under the garbage collector, then run the garbage collection whenever savestates become superfluous. Savestates contain VRAM bitmaps of the land, in addition to the lixes and jobs. To preserve VRAM that's managed by the savestates, I run the RAM garbage collection multiple times per second during framestepping. But running the GC may hit performance much harder than a slow allocation strategy.

Related to my strategy:
Discussion with ccx about a crash due to exhausted VRAM
github issue: before running the GC often
github issue: performance of running the GC often

I would like faster savestating, aiming at faster framestepping. I should compare the performance gain of (D/A5 Lix now to D/A5 Lix with manual savestate management, without running the GC, but still 2n allocations each savestating) with the performance gain of (2n allocations to a single allocation for lixes).

I want to feel good. I want huge gains in VRAM management; I want negligible prospects in hacking up the job hierarchy. I wouldn't like my OO design responsible for my problem... at least this time.

-- Simon

QuoteMost of the arguments for culling them are "they can be used for unfair design".

No.

From 2 hours ago in IRC:
<SimonN> the point is not whether it allows bad design
<SimonN> the point is that fake & invis both flat-out invite bad design

-- Simon

Clam's Lix pack. >_>

Clam designs excellent levels. He hasn't yet received the due spotlighting.

-- Simon

I have this too, occasionally.

Guess: Many external graphics cause this. The forum cannot generate height tags for external images. When the images load after the page is rendered, the posts enlarge, while the scroll position remains unchanged.

Old Firefox 3.5, maybe it's better in a different browser.

-- Simon

Random idea: in dosbox.conf, try
output=opengl

...or one of the other output methods. Maybe that plays better with the recording software.

-- Simon

I favor the 4 pixels merely because it's a round number, unlike 3, and it partitions the blocker field in equally-sized areas. Any argument from comparing source code details should be stronger than mine.

Pass-through blockers are easier to set up at 3-5-3 at 3-6-3. Blockers on slopes work better at 4-4-4.

I've never noticed an inconsistency, because I've never tested walkers inside the blocker.

-- Simon

core=auto
cputype=auto

Cycles around 10,000. Doesn't matter whether set in the config file, or raised from 3,000 to 10,000 during play.

Runs smoothly on a 10-year-old laptop at 2x 1.6 GHz, 3 GB RAM.

-- Simon

4, 4, 4!

-- Simon

Graphics: The blocker doesn't have a single-pixel central column. Its center is 2 pixels wide. Therefore, it's sensible to have a blocker area with even witdh. We have a blocker area with an even width if it extends n pixels from the center in one direction, and n+1 pixels into the other.

Would you redraw the blocker sprites to match an odd-width field?

-- Simon