Hands-On Rust: Wrong multiplier for 8x8 console in main.rs

[mikecargal]

Title: Hands-On Rust (Chap 8 (Adding a Heads Up Display)

It looks like

    ​.with_simple_console_no_bg​(SCREEN_WIDTH*2, SCREEN_HEIGHT*2,
​	        ​"terminal8x8.png"​)”

should be:

    ​.with_simple_console_no_bg​(SCREEN_WIDTH*4, SCREEN_HEIGHT*4,
​	        ​"terminal8x8.png"​)”

I had thought that my HUD seemed a bit bigger than the screen shots, but it really showed up when I added the tooltips and they were way off (being multiplied by 4)

Also… another Mac/Big Sur terminal rendering artifact:

It looks like the top row (or 2??) of pixels are being occluded.

[herbert]

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.

[herbert]

I’m having troubles replicating this one locally. On Windows/Linux (the systems I have ready access to), everything lines up nicely:

That’s with the layer initialized as it in the book’s code:

.with_simple_console_no_bg(SCREEN_WIDTH*2, SCREEN_HEIGHT*2, "terminal8x8.png")

The constants haven’t changed:

pub const SCREEN_WIDTH: i32 = 80;
pub const SCREEN_HEIGHT: i32 = 50;
pub const DISPLAY_WIDTH: i32 = SCREEN_WIDTH / 2;
pub const DISPLAY_HEIGHT: i32 = SCREEN_HEIGHT / 2;

And in tooltips.rs:

let screen_pos = *mouse_pos * 4

I thought it might be a library bug with display scaling, but at 125%, 150% and 200% display scaling it still lines up on my systems! (200% is hard to test because I only have 1080p monitors)

Removing the scaling altogether (so set the new layer to DISPLAY_WIDTH x DISPLAY_HEIGHT and remove the multiplier in tooltips.rs) looks terrible, but also lines up:

Which did get me thinking. The mouse_pos() function in bracket-lib retrieves the character position from the current layer. Could you double-check that when you insert the mouse position into your resources you are setting the console?

The correct code (in tick, main.rs) is:

ctx.set_active_console(0);
self.resources.insert(Point::from_tuple(ctx.mouse_pos()));

Some questions to try and nail this one down:

• Do you have the same problem running the bundled code?
• How are the tooltips offset? Are they rendering in the wrong place, but activating correctly based on mouse position over a monster?
• What resolution are you running?
• In tooltips.rs, try adding a line of code before submit to draw the current mouse position - translated to the tooltips layer from the monster layer:

draw_batch.print(*mouse_pos * 4, format!("{:?}", *mouse_pos)); // <-- New line
draw_batch.submit(10100).expect("Batch error");

This will show you the current monster-layer position of the mouse cursor, and should move with it (it’ll be jumpy because of the layer resolution difference):

My gut feeling is that this is going to turn out to be an oddity with display scaling.

[mikecargal]

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)

[herbert]

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!)

[tilo9000]

I ran into exactly the same thing and didn’t see it in the first place. Thanks for sharing. I also went to derive the size from the DISPLAY and not SCREEN just to be consistent with the other consoles.