I ran the demo for 4.13 and was surprised badly when I couldn't get the cheat menu to show up.
A quick look through the source code tells me the Backslash seems to be missing in https://github.com/thebracket/rltk_rs/blob/master/src/hal/wasm/events/keyboard.rs, the JS key code is 220

I am currently on rltk = "0.5.12" on Mac Os and I'm still experiencing this issue. Full stacktrace:

thread 'main' panicked at 'called Result::unwrap() on an Err value: NoAvailablePixelFormat', src/libcore/result.rs:1165:5
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
1: backtrace::backtrace::trace_unsynchronized
at /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:76
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:60
4: core::fmt::write
at src/libcore/fmt/mod.rs:1030
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1412
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:64
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:196
9: std::panicking::default_hook
at src/libstd/panicking.rs:210
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:473
11: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:380
12: rust_begin_unwind
at src/libstd/panicking.rs:307
13: core::panicking::panic_fmt
at src/libcore/panicking.rs:85
14: core::result::unwrap_failed
at src/libcore/result.rs:1165
15: core::result::Result<T,E>::unwrap
at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libcore/result.rs:933
16: rltk::hal::native::init::init_raw
at /Users/amedvedev/.cargo/registry/src/github.com-1ecc6299db9ec823/rltk-0.5.12/src/hal/native/init.rs:20
17: rltk::rltk::Rltk::init_raw
at /Users/amedvedev/.cargo/registry/src/github.com-1ecc6299db9ec823/rltk-0.5.12/src/rltk.rs:42
18: rltk::rltk::Rltk::init_simple8x8
at /Users/amedvedev/.cargo/registry/src/github.com-1ecc6299db9ec823/rltk-0.5.12/src/rltk.rs:53
19: rust_rogue_tutorial::main
at src/main.rs:39
20: std::rt::lang_start::{{closure}}
at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/rt.rs:64
21: std::rt::lang_start_internal::{{closure}}
at src/libstd/rt.rs:49
22: std::panicking::try::do_call
at src/libstd/panicking.rs:292
23: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:80
24: std::panicking::try
at src/libstd/panicking.rs:271
25: std::panic::catch_unwind
at src/libstd/panic.rs:394
26: std::rt::lang_start_internal
at src/libstd/rt.rs:48
27: std::rt::lang_start
at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/rt.rs:64
28: rust_rogue_tutorial::main
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.

Process finished with exit code 101

Originally posted by @amedviediev in #17 (comment)

Texel ( https://github.com/almindor/texel ) is similar to REX Paint, but written in Rust - and quite awesome. RLTK should support its output files.

Talking with various people using RLTK, it's become evident that there's quite the division between use-cases. Some just want the algorithms (the A* implementation in particular), some just want the console rendering, etc.

So I propose dividing RLTK into separate crates before 1.0:

• A master "RLTK" crate would gather and export everything that is already here, and be home to platform examples.
• A console crate (name TBD) would gather just the console/main loop. So you could import that if you just need a quick CP437 web-assembly friendly console (with all of the existing back-ends).
• An algorithms crate (name TBD) would offer all of the geometry and path-finding services, separated from needing to have RLTK subsume your main loop.
• Possibly one more crate would work with Amethyst, to offer RLTK's consoles as an Amethyst Component (probably wait until after the Legion migration is complete).

That would also make it a little easier to expand things in the future.

RLTK currently crashes when you draw to an invalid screen location; it shouldn't do that.

I was going through the RLTK Roguelike tutorial (and it's great; thanks so much for this). In the FOV section, I'm getting odd results in the field_of_view calculation, and I think the Bresenham's line algorithm may be broken. It's leaving holes in my results. If I have a flat wall, the wall is completely lit except for the two tiles one in from either side at the radius. In the poor example below, all the # are lit, but the four * aren't.

#*#############*#
        @
#*#############*#

I'm on a MacBook Pro with Catalina, so maybe it's something weird with the Retina resolution?

As an exercise, I created my own FOV function based on the shadowcasting one described on Roguebasin. I'm using the tutorial to learn Rust at the same time, so my code might not be the greatest. But I'm getting better results (for me at least) than I was with the baked algorithm.

https://gist.github.com/sbowman/eb277f162b4890346fe704653b4c2a53

The latest RLTK 0.6 has a rendering issue when using post scanlines.

Without context.with_post_scanlines(true)

With context.with_post_scanlines(true)

Not sure if related to the changes made in #46 ?

RLTK: 0.6

Hey there. I want to use this library, but it seems to have graphical artifacts on Linux. I have tried using it on both my laptop and desktop PCs, which have different graphics cards and all drivers installed. Just wondering if there's an easy fix for this before i try to jump into figuring it out myself

When I try using multiple layers the background stays black this problem occurs even when I try to build the examples 7 and 18.

I am on windows 10 with rust 1.43.0-nightly and using version 7.0.0 of rltk.

Hello,

I am experiencing a rendering bug with tiles (native, not wasm) where tiles seem to render repeated instead of scaling properly:

The rendering is working properly for me up until efee85c. The next commit, 9306f2c, just gives me a black screen. 48a997e and forward gives me this bug.

System:
Manjaro Linux 4.19.84
NVIDIA GeForce GTX 850M, drivers: 4.6.0 NVIDIA 430.64

On my Mac (which has a non-high-DPI monitor attached), if I run an rltk app from a terminal on the laptop screen, I get super-tiny font rendering in the wrong place. If I drag the terminal over to the external monitor and then launch the app, everything looks fine.

Laptop screen:

External monitor:

The code is chapter 1 of the book:

rltk::add_wasm_support!();
use rltk::{Rltk, GameState, Console};

struct State {}
impl GameState for State {
    fn tick(&mut self, ctx : &mut Rltk) {
        ctx.cls();
        ctx.print(1, 1, "Hello Rust World!");
    }
}

fn main() {
    let context = Rltk::init_simple8x8(80, 50, "Hello Rust World", "resources");
    let gs = State{ };
    rltk::main_loop(context, gs);
}

The field of view code is needlessly returning tiles more than once. See: amethyst/rustrogueliketutorial#34

The field-of-view algorithm traces out a circle and scans lines to the center point. The problem is that this can miss points adjacent to the boundary that should be within the field-of-view.

#55 provides an alternate version of the Bresenham circle that jumps either in x or y (not both) to include these interior points in the set of locations to scan from, and makes some corresponding changes to tests. I did not want to replace the classic Bresenham algorithm, but it doesn't appear to be used elsewhere in the library so it might make sense to remove it and only use the new version.

Since the demo is run as WASM, it is possible to trigger a panic eg. in the visibility code by running any of the demos before chapter 3.19. By default, WASM panics are less than helpful (RuntimeError: Unreachable executed).

However, there is a way to make them more informative - enter https://github.com/rustwasm/console_error_panic_hook

Step 1: Add console_error_panic_hook = "0.1.5" to the Cargo.toml
Step 2: Add extern crate console_error_panic_hook; use std::panic; at the top of main.rs
Step 3: Add panic::set_hook(Box::new(console_error_panic_hook::hook)); at the top of the main() function in main.rs (before you initialize RLTK console)

I'm using rltk on Ubuntu-18.04LTS.

I use the following GameState with rltk:

struct State {}
impl GameState for State {
    fn tick(&mut self, ctx: &mut Rltk) {
        if ctx.shift {
            println!("SHIFT {:?}", ctx.key);
        }
        if ctx.alt {
            println!("ALT {:?}", ctx.key);
        }
    }
}

With some previous 0.5 version it worked as expected, shift+key showed SHIFT and the key. With 0.5.15 I get "SHIFT Some(LShift)" and "SHIFT Some(RShift)", but no other key together with either shift print anything. If I instead press ALT+ some key, I get SHIFT and the key printed...

The ALT message comes with the ALT keys, but to get ALT + some key, I need to press CTRL and the key.

How do I go about accessing what modifier keys are pressed? I'm looking to detect the ">" keypress, so I assumed I need to detect simultaneous "." and shift presses. I followed the examples using VirtualKeyCode and traced the code back to the winit library which has a ModifiersState struct which appears to be what I'm looking for, but I'm not sure how to access it from an Rltk context.

Thanks!

Testing on OS X revealed that the WASM runs and correctly sends logs to the console, but the OpenGL render box itself is a black screen with nothing rendered! It's very odd, there were no shader compilation errors or panics - the GL layer thinks that it is running.

This may take some time to fix; I only have sporadic access to a Mac to test on.

See also: amethyst/rustrogueliketutorial#33

A scripting system allows game customization without recompile rust code, improving speed on the game testing.

It would be good if:

• A script runner that runs another language (Lua, Python, etc)
• Scripts can create ECS systems and use the ECS capabilities
• Scripts can create arbitrary data structures
• Close to no speed overhead

The entity go on target instead of fleeing.
In the #[cfg(not(feature = "threaded"))], a and b seem to be in the bad order.
But the #[cfg(feature = "threaded")] version it seem to be ok.

i can't reliably reproduce it, but it seems to happen when the mouse cursor is out of the window:

thread 'main' panicked at 'index out of bounds: the len is 512000 but the index is 512727', /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libcore/slice/mod.rs:2715:10
stack backtrace: 
.
  11: <usize as core::slice::SliceIndex<[T]>>::index                                                      
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libcore/slice/mod.rs:2715             
  12: core::slice::<impl core::ops::index::Index<I> for [T]>::index                                      
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/libcore/slice/mod.rs:2566            
  13: <alloc::vec::Vec<T> as core::ops::index::Index<I>>::index                                          
             at /rustc/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/liballoc/vec.rs:1791                 
  14: <ex14_dwarfmap::State as rltk::GameState>::tick
             at examples/ex14-dwarfmap.rs:217
  15: rltk::platform_specific::tock
             at ./src/platform_specific.rs:209
…

OS: linux, rustc rustc 1.38.0

I'm creating this issue to track work related to merging doryen_rs and bracket-lib.
Items that eventually require work in bracket-lib will have their dedicated issue.

WASM

• MISSING cargo-web not supported. To be investigated

Windowing

• MISSING easy way to save a screenshot, like BTerm::save_screenshot(file_path: &str)

Version 0.5.17.

When building a project with:

rltk = {version = "0.5.17", default-features = false, features = [“curses”]}

I get the error:

> cargo run
    Updating crates.io index
   Compiling rltk v0.5.17
error[E0308]: mismatched types
  --> /home/mitch/.cargo/registry/src/github.com-1ecc6299db9ec823/rltk-0.5.17/src/hal/curses/simple_console_backing.rs:46:54
   |
46 |                 window.attrset(pancurses::COLOR_PAIR(pair as u64));
   |                                                      ^^^^^^^^^^^ expected u32, found u64
help: you can convert an `u64` to `u32` and panic if the converted value wouldn't fit
   |
46 |                 window.attrset(pancurses::COLOR_PAIR((pair as u64).try_into().unwrap()));
   |                                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0308]: mismatched types
  --> /home/mitch/.cargo/registry/src/github.com-1ecc6299db9ec823/rltk-0.5.17/src/hal/curses/sparse_console_backing.rs:47:50
   |
47 |             window.attrset(pancurses::COLOR_PAIR(pair as u64));
   |                                                  ^^^^^^^^^^^ expected u32, found u64help: you can convert an `u64` to `u32` and panic if the converted value wouldn't fit
   |
47 |             window.attrset(pancurses::COLOR_PAIR((pair as u64).try_into().unwrap()));
   |                                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0308`.
error: could not compile `rltk`.

To learn more, run the command again with --verbose.

Also, the README section on using curses is out of date because the curses examples were removed.

I tried using context.backend.platform.context_wrapper.unwrap().wc.window().set_fullscreen(...) for the OpenGL version, but then I have a partial borrow out of the context, preventing me from calling main_loop later.

Is there a way to do this?

From Reddit: https://www.reddit.com/r/rust/comments/ene9mm/introduction_roguelike_tutorial/

This is really great!

I'm having some difficulty getting the "hello world" example running. After setting up the TOML / SRC / resources folders and files I just get a Windows error that says "The procedure entry point AdjustWindowRectExForDpi could not be located in the dynamic link library "My path to hellorust.exe""

I get a Rust error / panic that says "Exit code: 0xc0000139, STATUS_ENTRYPOINT_NOT_FOUND"

I've tried in both release and debug mode.

I'm on Windows 8, if that matters.

I've noticed some weird behavior with tick() on windows. You can see it with the the first example. If the mouse is over the window, everything works as you would expect and FPS counter shows 120 (on a 120hz display). If I move the mouse away from the window, so that it's no longer over the client area of the window, then when I stop moving the mouse you can see the game basically freeze. If you wait a second and move the mouse again then it starts processing tick() again. The FPS counter will then update and you can make it go arbitrarily low by waiting between when you move the mouse. I can post a video clip if that explanation is confusing.

I looked through the issue tracker for glutin and I didn't see any issues like this so I suspect the bug is in the Rltk code. I tried the example on linux (X11) and it behaved as I would have expected (full frame rate all the time, regardless of mouse movement or position).

Looking at the Rltk event loop, it looks like tick() is called after all the events have been cleared and the application is about to give control back to the OS. The only thing I can think is that perhaps on windows glutin only creates this EventsCleared event when there were events to process and that on linux this event is created more often.

Have you noticed this bug before? It's probably not a big deal for turn based simulations. I think for simulations that are not turn based that the current API might be restrictive in the sense that tick() appears to be tied to the framerate. (Unless I'm missing something, of course.) For instance, is it possible to have a simulation that runs at 20hz with animations and event processing that runs at 60hz?

main.rs:

use rltk::{Rltk, GameState, Console};

struct State {}
impl GameState for State {
    fn tick(&mut self, ctx : &mut Rltk) {
        ctx.cls();
        ctx.print(1, 1, "Hello Rust World");
    }
}

fn main() {
    let context = Rltk::init_simple8x8(80, 50, "Hello Rust World", "resources");
    let gs = State{ };
    rltk::main_loop(context, gs);
}

Dependencies:

[dependencies]
rltk = "0.5.12"

Rust version:

$ rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/ssilva/.rustup

stable-x86_64-unknown-linux-gnu (default)
rustc 1.39.0 (4560ea788 2019-11-04)

Full backtrace:

$ RUST_BACKTRACE=full cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.14s
thread 'main' panicked at 'Failed to initialize any backend! Wayland status: XdgRuntimeDirNotSet X11 status: XOpenDisplayFailed', /home/ssilva/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0-alpha5/src/platform_impl/linux/mod.rs:561:9
stack backtrace:
   0:     0x7f46c36f95e4 - backtrace::backtrace::libunwind::trace::hda41dbcdfba36aa0
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
   1:     0x7f46c36f95e4 - backtrace::backtrace::trace_unsynchronized::h1a8d6e1f8cb3f5d4
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/mod.rs:66
   2:     0x7f46c36f95e4 - std::sys_common::backtrace::_print_fmt::h610c4127487e10da
                               at src/libstd/sys_common/backtrace.rs:76
   3:     0x7f46c36f95e4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h0722dc552e01bd1d
                               at src/libstd/sys_common/backtrace.rs:60
   4:     0x7f46c371a50c - core::fmt::write::h01edf6dd68a42c9c
                               at src/libcore/fmt/mod.rs:1030
   5:     0x7f46c36f67d7 - std::io::Write::write_fmt::hf15985f193f03c04
                               at src/libstd/io/mod.rs:1412
   6:     0x7f46c36fbb15 - std::sys_common::backtrace::_print::hd8d5d08a1795e743
                               at src/libstd/sys_common/backtrace.rs:64
   7:     0x7f46c36fbb15 - std::sys_common::backtrace::print::hf89a79e3921a2366
                               at src/libstd/sys_common/backtrace.rs:49
   8:     0x7f46c36fbb15 - std::panicking::default_hook::{{closure}}::h3a8f42beb3bb8ae3
                               at src/libstd/panicking.rs:196
   9:     0x7f46c36fb806 - std::panicking::default_hook::h8f803b0bc31a5c37
                               at src/libstd/panicking.rs:210
  10:     0x7f46c36fc215 - std::panicking::rust_panic_with_hook::h825f041245da8739
                               at src/libstd/panicking.rs:473
  11:     0x7f46c341e488 - std::panicking::begin_panic::h984e4b60312952e1
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/panicking.rs:407
  12:     0x7f46c334c65a - winit::platform_impl::platform::EventLoop<T>::new_any_thread::h1b3b3225e6961cbd
                               at /home/ssilva/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0-alpha5/src/platform_impl/linux/mod.rs:561
  13:     0x7f46c334c0d1 - winit::platform_impl::platform::EventLoop<T>::new::hd5089acc5ced9d88
                               at /home/ssilva/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0-alpha5/src/platform_impl/linux/mod.rs:525
  14:     0x7f46c33477d1 - winit::event_loop::EventLoop<T>::with_user_event::h4a6f345aa2305156
                               at /home/ssilva/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0-alpha5/src/event_loop.rs:128
  15:     0x7f46c334779e - winit::event_loop::EventLoop<()>::new::h1df8502809ef4d38
                               at /home/ssilva/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.20.0-alpha5/src/event_loop.rs:114
  16:     0x7f46c3110f1a - rltk::hal::native::init::init_raw::h07c03332143d80d4
                               at /home/ssilva/.cargo/registry/src/github.com-1ecc6299db9ec823/rltk-0.5.12/src/hal/native/init.rs:13
  17:     0x7f46c30e0385 - rltk::rltk::Rltk::init_raw::had9e4c5163e0dfff
                               at /home/ssilva/.cargo/registry/src/github.com-1ecc6299db9ec823/rltk-0.5.12/src/rltk.rs:42
  18:     0x7f46c30e0183 - rltk::rltk::Rltk::init_simple8x8::h37b239c4c43449c3
                               at /home/ssilva/.cargo/registry/src/github.com-1ecc6299db9ec823/rltk-0.5.12/src/rltk.rs:53
  19:     0x7f46c311c6fa - hellorust::main::heac78d8dc26c03eb
                               at src/main.rs:12
  20:     0x7f46c31202b0 - std::rt::lang_start::{{closure}}::ha3c8a83d83341202
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/rt.rs:64
  21:     0x7f46c36fbc43 - std::rt::lang_start_internal::{{closure}}::ha04574f12d97cbe2
                               at src/libstd/rt.rs:49
  22:     0x7f46c36fbc43 - std::panicking::try::do_call::h7c2a8488f72db90c
                               at src/libstd/panicking.rs:292
  23:     0x7f46c36ffcaa - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:80
  24:     0x7f46c36fc70d - std::panicking::try::hc3a9b5da4250385d
                               at src/libstd/panicking.rs:271
  25:     0x7f46c36fc70d - std::panic::catch_unwind::hf27600bf8c37809a
                               at src/libstd/panic.rs:394
  26:     0x7f46c36fc70d - std::rt::lang_start_internal::h409d4f2fe51133b0
                               at src/libstd/rt.rs:48
  27:     0x7f46c3120289 - std::rt::lang_start::hd1ac00a4f0ae59d7
                               at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libstd/rt.rs:64
  28:     0x7f46c311c76a - main
  29:     0x7f46c1fc1b97 - __libc_start_main
  30:     0x7f46c309dcfa - _start
  31:                0x0 - <unknown>

I'm guessing this has to do with a dependency being incompatible with the recently released Rust 1.40. However, I can't figure out from the backtrace which one is the culprit.

I'm using version 0.5.15 and is calling Rltk::set_bg with Rltk::mouse_pos() as position. At first this follows the mouse pointer, but after I resize the window the mouse_pos position is no longer translated to the right position in console coordinate space.

It would be good to have flags for vsync on/off, as well as OpenGL configuration options. I'll need to figure out how to make this work with multi-backend support.

I'm going through the Rusty Roguelike and I'm up to chapter 1.7 - coding on the Mac didn't offer any problems, but when I tried to compile the project on either Linux or Windows (using the latest nightly build) I run into the same problem with each:

error[E0609]: no field `SwapBuffersWithDamageKHR` on type `&api::egl::egl::Egl`
   --> C:\Users\ysgar\.cargo\registry\src\github.com-1ecc6299db9ec823\glutin-0.22.0-alpha4\src\api\egl\mod.rs:694:17
    |
694 |         if !egl.SwapBuffersWithDamageKHR.is_loaded() {
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^ unknown field
    |
    = note: available fields are: `0`

error[E0599]: no method named `SwapBuffersWithDamageKHR` found for type `&api::egl::egl::Egl` in the current scope
   --> C:\Users\ysgar\.cargo\registry\src\github.com-1ecc6299db9ec823\glutin-0.22.0-alpha4\src\api\egl\mod.rs:714:17
    |
714 |             egl.SwapBuffersWithDamageKHR(
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^ method not found in `&api::egl::egl::Egl`

error[E0609]: no field `SwapBuffersWithDamageKHR` on type `&api::egl::egl::Egl`
   --> C:\Users\ysgar\.cargo\registry\src\github.com-1ecc6299db9ec823\glutin-0.22.0-alpha4\src\api\egl\mod.rs:740:13
    |
740 |         egl.SwapBuffersWithDamageKHR.is_loaded()
    |             ^^^^^^^^^^^^^^^^^^^^^^^^ unknown field
    |
    = note: available fields are: `0`

error: aborting due to 3 previous errors

This seems like it might be a problem with glutin-0.22.0-alpha4? I tried with both rltk 0.5.9 (recommended by the tutorial) and the latest, rltk 0.5.12.

In working through Roguelike Tutorial in Rust on Linux (chapter 08 so far, thanks again for the great work) I've had very high (100%) cpu utilization even "idle" on both an AMD GPU workstation and Intel GPU laptop.

Memory is quite reasonable at 30MB still.

In trying some of the demos in rltk I found them also to have the same behavior even with curses (curses14-dwarfmap) as the backend.

Is this expected behavior?

The rltk tick as I understand it is 60 per second but given how little it should be doing this seems like high utilization?

If the "parsing" feature isn't enabled, it doesn't compile correctly.

Hello, I'm trying to run the code from the roguelike guide (http://bfnightly.bracketproductions.com/rustbook/chapter_1.html), but unfortunately I'm getting this error: thread 'main' panicked at 'called Result::unwrap() on an Err value: NoAvailablePixelFormat', src\libcore\result.rs:999:5

Here's the full backtrace:
stack backtrace:
0: std::sys_common::backtrace::_print
at src\libstd\sys\windows\backtrace/mod.rs:95
at src\libstd\sys\windows\backtrace/mod.rs:82
at src\libstd\sys_common/backtrace.rs:71
1: std::panicking::default_hook::{{closure}}
at src\libstd\sys_common/backtrace.rs:59
at src\libstd/panicking.rs:197
2: std::panicking::default_hook
at src\libstd/panicking.rs:211
3: std::panicking::rust_panic_with_hook
at src\libstd/panicking.rs:474
4: std::panicking::continue_panic_fmt
at src\libstd/panicking.rs:381
5: rust_begin_unwind
at src\libstd/panicking.rs:308
6: core::panicking::panic_fmt
at src\libcore/panicking.rs:85
7: core::result::unwrap_failed
at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\src\libcore/macros.rs:18
8: core::result::Result<T,E>::unwrap
at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\src\libcore/result.rs:800
9: rltk::hal::native::init::init_raw
at C:\Users\Luis.cargo\git\checkouts\rltk_rs-9a03b5b24ea60f66\30ef14b\src\hal\native/init.rs:22
10: rltk::rltk::Rltk::init_raw
at C:\Users\Luis.cargo\git\checkouts\rltk_rs-9a03b5b24ea60f66\30ef14b\src/rltk.rs:41
11: rltk::rltk::Rltk::init_simple8x8
at C:\Users\Luis.cargo\git\checkouts\rltk_rs-9a03b5b24ea60f66\30ef14b\src/rltk.rs:52
12: roguelike_guide::main
at src/main.rs:13
13: std::rt::lang_start::{{closure}}
at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\src\libstd/rt.rs:64
14: std::panicking::try::do_call
at src\libstd/rt.rs:49
at src\libstd/panicking.rs:293
15: _rust_maybe_catch_panic
at src\libpanic_unwind/lib.rs:85
16: std::rt::lang_start_internal
at src\libstd/panicking.rs:272
at src\libstd/panic.rs:394
at src\libstd/rt.rs:48
17: std::rt::lang_start
at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c\src\libstd/rt.rs:64
18: main
19: _tmainCRTStartup
20: mainCRTStartup
21: unit_addrs_search
22: unit_addrs_search
error: process didn't exit successfully: target\debug\roguelike_guide.exe (exit code: 101)

What could be causing this error? I kindly ask for help. Thanks!

I'm trying to run the examples from https://github.com/thebracket/rustrogueliketutorial on Ubuntu 19.04, in a Wayland session, using rustc 1.37.0.

When I cargo run any of the examples (except the hello world one), the opened window keeps changing its size multiple times per second (once every frame perhaps?). The contents of the window shift up and down, the topmost few rows of tiles briefly hiding under the title bar, which might be A Clue?

I was also building Firefox in the background, which may have had an effect. Now that the Firefox build stopped, I can no longer reproduce the window size changes, but I've a different problem instead -- the built program is eating 100% CPU and ignoring all input events. I can't even close the window, I have to ^C in the console.

(Input worked when I was testing earlier, although in a jerky fashion -- it seemed like some of my key up/down events were being dropped, leading to the @ standing still while I was trying to move it, or sometimes running until it hit a wall despite me just briefly pressing and releasing an arrow key.)

My apologies if this is already possible.

One of the really nice things about SPECS is its automatic handling of parallelization. in my current (spaghetti code) project, I have a "rendering system" using tcod running on its own thread. Instead of calling render functions during the top-level game loop, I control exactly when it updates the game view, and because it is running concurrently, it does not need to wait for an entire game tick to finish (nor do other systems need to wait for it) in order to render. the console is simply a resource in the SPECS world that the rendering system (and possible other systems) gets mutable access to.

unfortunately, when I tried moving my project to use this (more fully-featured, modern, and native-feeling) library, I ran into the issue wherein I must wait for every system in the game to stop before flushing to the console (and vice versa), since I had to move the rendering logic into the tick() function for the State implementation. this moved the entire system outside of the SPECS world and into its own separate process which ran after every world update, slowing things down. It has been a little while since then, but I recall not being able to figure out how I would call the rendering functions from a system in the world.

I'm not a very good programmer, and so maybe there are ways i'm not seeing around this by writing my own multi-threaded implementation, but either way it adds some complexity to my project where there wasn't any before. i'd like to hear what your thoughts are on this, if there is some part of the rltk-rs I missed that takes care of this, and if the architecture of the library could support something along these lines.

I initialize a context as follows:

let mut ctx = Rltk::init_simple8x8(
    WIDTH,
    HEIGHT,
    "mygame",
    "resources",
);

As far as I tell, the last parameter is expanded to ./resources/terminal8x8.png, and is required to initialize a context using the terminal8x8.png font included in the resources directory. However, if I move terminal8x8.png to ./data instead of ./resources and change that parameter accordingly, my application panics. Even stranger, if I completely remove the resources directory and do a full recompile, my application still works as expected.

Panic message:

thread 'main' panicked at 'Failed to load texture: IoError(Os { code: 2, kind: NotFound, message: "No such file or directory" })', src/libcore/result.rs:1165:5

What am I not understanding here?

rltk_rs on my Linux machine can log that shift is being pressed but is unable to tell that any other keys are being pressed after it. I have tested the code on a Mac, Windows, and Archlinux machine and can confirm that the code only has problems on Linux. I have not figured out the source of this issue yet but will update this issue with a solution if I do.

Here's the backtrace:

thread 'main' panicked at 'attempt to multiply with overflow', C:\Users\herbe\.cargo\git\checkouts\rltk_rs-9a03b5b24ea60f66\8fb1ab7\src\fastnoise.rs:1951:10
stack backtrace:
   0: backtrace::backtrace::trace_unsynchronized
             at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.29\src\backtrace\mod.rs:66
   1: std::sys_common::backtrace::_print
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libstd\sys_common\backtrace.rs:47
   2: std::sys_common::backtrace::print
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libstd\sys_common\backtrace.rs:36
   3: std::panicking::default_hook::{{closure}}
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libstd\panicking.rs:200
   4: std::panicking::default_hook
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libstd\panicking.rs:214
   5: std::panicking::rust_panic_with_hook
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libstd\panicking.rs:477
   6: std::panicking::continue_panic_fmt
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libstd\panicking.rs:384
   7: std::panicking::rust_begin_panic
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libstd\panicking.rs:311
   8: core::panicking::panic_fmt
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libcore\panicking.rs:85
   9: core::panicking::panic
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libcore\panicking.rs:49
  10: rltk::fastnoise::FastNoise::val_coord_2d
             at C:\Users\herbe\.cargo\git\checkouts\rltk_rs-9a03b5b24ea60f66\8fb1ab7\src\fastnoise.rs:1951
  11: chapter_27_cellular_automota::map_builders::cellular_automota::CellularAutomotaBuilder::build
             at .\src\map_builders\cellular_automota.rs:143
  12: chapter_27_cellular_automota::State::generate_world_map
             at .\src\main.rs:379
  13: chapter_27_cellular_automota::main
             at .\src\main.rs:471
  14: std::rt::lang_start::{{closure}}<()>
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\rt.rs:64
  15: std::rt::lang_start_internal::{{closure}}
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libstd\rt.rs:49
  16: std::panicking::try::do_call<closure,i32>
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libstd\panicking.rs:296
  17: panic_unwind::__rust_maybe_catch_panic
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libpanic_unwind\lib.rs:82
  18: std::panicking::try
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libstd\panicking.rs:275
  19: std::panic::catch_unwind
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libstd\panic.rs:394
  20: std::rt::lang_start_internal
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\/src\libstd\rt.rs:48
  21: std::rt::lang_start<()>
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b\src\libstd\rt.rs:64
  22: invoke_main
             at d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  23: __scrt_common_main_seh
             at d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  24: BaseThreadInitThunk
  25: RtlUserThreadStart

Version 6.0.0

The background color is not being displayed when compiled for wasm32. I am using Rltk::init_simple8x8 and method set(x,y,fg,bg,glyph) (basically code from your tutorial). When compiled for native target everything works fine.

Is background color unsupported for wasm32, or is this bug?

RLTK needs an easy way to define multi-tile sprites for repeated rendering.

One of the few cheap ways to make a rogue like feel more responsive and "juicy".
Another way would be to add sound effects and music, but these could be easily added via external crates.

I love this library and your tutorial around it!

I'm trying to run the examples from https://github.com/thebracket/rustrogueliketutorial on Ubuntu 19.04, in a Wayland session, using rustc 1.37.0.

Most of the time all keyboard and mouse input gets ignored: I cannot move the little @ arround, and I cannot close the window by clicking the X button in the window title.

Input worked during my initial testing (but some of the events were dropped), when my system was busy compiling Firefox in the background, so I think this is due to some kind of race condition?

I've looked at the output of WAYLAND_DEBUG=1 cargo run and failed to find any keyboard/mouse events, just a tight loop of screen updates. But then I've never used WAYLAND_DEBUG before and I don't even know what the events are supposed to look like.

In case this was a typo, your license file says:

Copyright (c) 2010-2019 Google, Inc. http://angularjs.org

You probably want to replace Google, Inc with your name, or the name of your company.

Incidentally, the http://angularjs.org link does not conform to the MIT template (there should be no link)

Noticed this when trying to use it from the tutorial.
amethyst/rustrogueliketutorial#93

/u/Morego writes:

I tried to solve it. It was error in context detection with opengl and DirectX later on in Glutin I think. On my laptop RLTK compiled normally runned with integrated graphic card and after renaming with Nvidia graphic card. Renaming enables Optimus optimization and Nvidia graphic card with newer version of Opengl context.

Alternatively it could work just fine with magic numbers of Nvidia set, but I have hard time finding out how to export those variables.

EDIT: Those are magic values. I have hard time exporting from Rust. If you know, how to do it I would be thankful. It should be enough.

extern "C" { _declspec(dllexport)
DWORD NvOptimusEnablement = 0x00000001; }

See pull: #59 (merged).

I got these errors:

   Compiling rltk v0.5.14
error[E0599]: no variant or associated item named `EventsCleared` found for type `winit::event::Event<_>` in the current scope
  --> /home/orzogc/.cargo/registry/src/github.com-1ecc6299db9ec823/rltk-0.5.14/src/hal/native/mainloop.rs:45:20
   |
45 |             Event::EventsCleared => {
   |                    ^^^^^^^^^^^^^
   |                    |
   |                    variant or associated item not found in `winit::event::Event<_>`
   |                    help: there is a variant with a similar name: `MainEventsCleared`

error[E0599]: no variant or associated item named `RedrawRequested` found for type `winit::event::WindowEvent` in the current scope
  --> /home/orzogc/.cargo/registry/src/github.com-1ecc6299db9ec823/rltk-0.5.14/src/hal/native/mainloop.rs:78:30
   |
78 |                 WindowEvent::RedrawRequested => {
   |                              ^^^^^^^^^^^^^^^ variant or associated item not found in `winit::event::WindowEvent`

error[E0615]: attempted to take value of method `shift` on type `&winit::event::ModifiersState`
   --> /home/orzogc/.cargo/registry/src/github.com-1ecc6299db9ec823/rltk-0.5.14/src/hal/native/mainloop.rs:103:34
    |
103 |                     if modifiers.shift {
    |                                  ^^^^^ help: use parentheses to call the method: `shift()`

error[E0615]: attempted to take value of method `alt` on type `&winit::event::ModifiersState`
   --> /home/orzogc/.cargo/registry/src/github.com-1ecc6299db9ec823/rltk-0.5.14/src/hal/native/mainloop.rs:106:34
    |
106 |                     if modifiers.alt {
    |                                  ^^^ help: use parentheses to call the method: `alt()`

error[E0615]: attempted to take value of method `ctrl` on type `&winit::event::ModifiersState`
   --> /home/orzogc/.cargo/registry/src/github.com-1ecc6299db9ec823/rltk-0.5.14/src/hal/native/mainloop.rs:109:34
    |
109 |                     if modifiers.ctrl {
    |                                  ^^^^ help: use parentheses to call the method: `ctrl()`

error: aborting due to 5 previous errors

It seems like winit changed RedrawRequested event in the 0.20.0 alpha version:
rust-windowing/winit@0c151f9

It might be nice to support crossterm, it's a bit easier to work with than pancurses.

Basic steps are:

cargo new rl
cd rl
echo 'rltk = "*"' >> Cargo.toml
cargo build

We compile fine until we hit rltk at which point, I have the error.

This happens in both mac and windows (haven't had a chance to try in Linux yet).

Also, I tried compiling and building a simple winit app by itself and had no issues there.

What am I missing?

I took the default example_tiles.jpg and converted to example_tiles.png. Doing so, does require adding the 'png_codec' feature in Cargo.toml. It runs fine, but the output is all messed up.

This is the 07 tile example with a png spritesheet:

I'm on OSX 10.14.6 (18G95). So this might be related to mac drivers too.