Not embarrassing - happens to all of us. I once replaced every news article on a production server with the word “quilting” because of an SQL typo…

I think you’re right about renaming the constants and making the multiply/scaling more obvious. I’ll see if I can clean that up for the next beta. Thanks!

That’s a good point about magic numbers. You could include

const MAP_LAYER : usize = 0;`
const DISPLAY_LAYER : usize = 1;`
const HUD_LAYER : usize = 2;

in your prelude, and use those. That would definitely be easier to read - I’ll see if putting that in won’t blow up my page count too badly (the eternal author struggle: fitting everything into a size the publisher wants to print!)

This is embarrassing…

I used DISPLAY_* (instead of SCREEN_) when I set up the simple_console (since the others used DISPLAY_. It appears that, when reporting my “issue” I copied/pasted from the book, instead of my code.

In whatever of my defense I might mount, I think that DISPLAY_WIDTH4 and DISPLAY_HEIGHT4 make a bit more sense, because you’re using DISPLAY* constants on the other consoles and 32/8 = 4. SCREEN_* works (with 2) because there’s already a divide my 2.). And… and… the HUD is more of a DISPLAY thing played over the window into the full screen (THat’s my defense, and I’m sticking to it )

Of course, all said, your code is correct, and my “issue” was my typo. Deeply sorry about wasting your time.

Arbitrary code critique… I’m at the point now that I bring when I see “magic numbers” in code. (examples are the layer console IDs, the z_order, etc. I’ve been playing a bit with trying to find good ways toggle them names in my version)

Thanks again! There’s a Big Sur update in the works for bracket-lib. I’m waiting on a couple of M1 chip fixes to come downstream, but the warnings are fixed. Adding a gutter is in-progress, requires a surprising amount of testing.

I’ll check the multiplier. I’ve added the issue to the tracker, and it should be in beta 3.