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 beforesubmitto 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.