in ConsoleEngine::init, a target_fps > 1000 results in a division by 0 error

[aaronik]

Describe the bug
I'm finding that if I set target_fps to anything over 1000, I get the following error:

thread 'main' panicked at 'attempt to calculate the remainder with a divisor of zero', /home/aaron/.cargo/registry/src/github.com-1ecc6299db9ec823/console_engine-2.5.0/src/lib.rs:737:17
stack backtrace:
   0: rust_begin_unwind
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/panicking.rs:142:14
   2: core::panicking::panic
             at /rustc/897e37553bba8b42751c67658967889d11ecd120/library/core/src/panicking.rs:48:5
   3: console_engine::ConsoleEngine::poll
             at /home/aaron/.cargo/registry/src/github.com-1ecc6299db9ec823/console_engine-2.5.0/src/lib.rs:737:17
...

Note this is only happening using the event feature.

To Reproduce

use console_engine::events::Event;
use console_engine::pixel;
use console_engine::Color;
use console_engine::ConsoleEngine;
use console_engine::KeyCode;

let mut engine = console_engine::ConsoleEngine::init(10, 10, 1001).unwrap();          
      
loop {          
    // Poll next event          
    match engine.poll() {          
        // A frame has passed          
        Event::Frame => {          
            // step(&mut engine, &mut world);          
            println!("hiya");          
        }          
      
        // A Key has been pressed          
        Event::Key(keyevent) => {          
            if keyevent.code == KeyCode::Char('q') {          
                break;          
            }          
        }          
      
        // Mouse has been moved or clicked          
        Event::Mouse(_mouseevent) => { /* ... */ }          
      
        // Window has been resized          
        Event::Resize(_w, _h) => { /* ... */ }          
    }                                                                                                                                                                                           

Expected behavior
Any value up to u32::MAX can be used without any sort of error

Screenshots
N/A

Additional context
Looks like version 2.5.0 from the trace, and fwiw uname -a gives me Linux dellbert 5.15.0-57-generic #63-Ubuntu SMP Thu Nov 24 13:43:17 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Additional additional context

Actually, it would be very nice if there didn't need to a frame rate set here, and instead there was an option to let it run as fast as possible. Maybe setting it to 0 means no delay at all, instead of panicking. Or maybe it could take an Option and a None could be passed in or something.

[aaronik]

I think the problem is here:

console_engine/src/lib.rs

Line 103 in 0b002eb

time_limit: std::time::Duration::from_millis(1000 / target_fps as u64),

That needs to be a float, not an unsigned int.

Haven't tested this theory at all and could easily be way off.

[VincentFoulon80]

Hello,

Thank you for that report.
I like your proposal to set target_fps as an option. The only issue I kind of foresee with that is the non-event mode require a minimal amount of time to catch inputs. Gotta try working that out in some way or another.

I'll have a look at this issue later today.

[aaronik]

Awesome thank you. I did notice that the non event code needed a minimal amount of time when i set the `target_fps` to `u32::MAX` and couldn't escape it. So that issue exists anyways. This is a little off topic but it might also be good to add a catch for interrupts like if i `ctl-c` while the application is running.

…

On Thu, Jan 12, 2023, 11:00 PM Vincent Foulon ***@***.***> wrote: Hello, Thank you for that report. I like your proposal to set target_fps as an option. The only issue I kind of foresee with that is the non-event mode require a minimal amount of time to catch inputs. Gotta try working that out in some way or another. I'll have a look at this issue later today. — Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKDMOIX3QZ3V6FMPEB4PN3WSD4PDANCNFSM6AAAAAAT2A24C4> . You are receiving this because you authored the thread.Message ID: ***@***.***>