An alternative ggez implementation on top of miniquad.

Overview

Good Web Game

Discord chat Docs Status license Crates.io

good-web-game is a wasm32-unknown-unknown implementation of a ggez subset on top of miniquad. Originally built to run Zemeroth on the web.

It currently supports most of the ggez 0.7.0 API. If you're already working with ggez you might use this library to port your game to the web (or even mobile). Since it also runs well on desktop it also offers an alternative implementation of ggez, which might always come in handy.

If you are just looking for a well supported, more serious, minimal high-level engine on top of miniquad you might want to take a look at macroquad.

Supported Platforms

The idea behind good-web-game is to offer a way to easily port ggez games to the web and even to mobile platforms. As it's mostly a subset of ggez, porting from good-web-game to ggez is even simpler.

Note that we don't give any guarantees for iOS / macOS support, as we currently simply don't have Macs lying around to test it on. In theory, it should work though.

Status

"good-web-game" implements most of the ggez 0.7.0 API.

Differences

  • boilerplate code differs slightly, as shown here
  • audio API differs somewhat due to use of quad-snd instead of rodio for easy portability
  • if you want to run on the web, shaders have to be written in GLSL100, due to support for WebGL1
  • API for creation of shaders and their corresponding uniform structs differs slightly, but the workflow remains the same, see the shader example

Missing / Not available:

  • ggez (and therefore good-web-game) usually loads files in a blocking fashion, which doesn't work on WASM
    • loading files asynchronously is possible through load_file_async everywhere though
  • filesystem with writing access (if you need it take a look at quad-storage)
  • writing your own event loop (doesn't make much sense on callback-only platforms like HTML5)
  • spatial audio (overall audio support is still relatively limited)
  • resolution control in fullscreen mode
  • setting window position / size (the latter is available on Windows, but buggy)
  • screenshot function
  • window icon
  • gamepad support on WASM (as gilrs depends on wasm-bindgen)

Demo

Running Zemeroth: https://not-fl3.github.io/miniquad-samples/zemeroth.html

screen

You can also check out astroblasto running on the web (source).

Building for different platforms

To build and run an example as a native binary:

cargo run --example astroblasto

WebAssembly

rustup target add wasm32-unknown-unknown
cargo build --example astroblasto --target wasm32-unknown-unknown

And then use the following .html to load .wasm:

index.html
<html lang="en">

<head>
    <meta charset="utf-8">
    <title>TITLE</title>
    <style>
        html,
        body,
        canvas {
            margin: 0px;
            padding: 0px;
            width: 100%;
            height: 100%;
            overflow: hidden;
            position: absolute;
            background: black;
            z-index: 0;
        }
    </style>
</head>

<body>
    <canvas id="glcanvas" tabindex='1'></canvas>
    <!-- For now this is just the same js glue macroquad uses: https://github.com/not-fl3/macroquad/tree/master/js -->
    <script src="https://psteinhaus.github.io/js/js_bundle.js"></script>
    <script>load("astroblasto.wasm");</script> <!-- Your compiled wasm file -->
</body>

</html>

To run it you need a server. An easy way to start one:

cargo install basic-http-server
basic-http-server .

Android

Recommended way to build for android is using Docker.
miniquad uses a slightly modifed version of cargo-apk

docker run --rm -v (your project folder):/root/src -w /root/src notfl3/cargo-apk cargo quad-apk build --example astroblasto

APK file will be in target/android-artifacts/(debug|release)/apk

With "log-impl" enabled all log calls will be forwarded to the adb console. No code modifications for Android required.

Note that all examples starting with numbers (for example 03_drawing.rs) won't install correctly. You need to remove the leading numbers: drawing.rs

iOS

See miniquad iOS sample project.

On blurry graphics

You may run into somewhat blurry graphics. This is caused by high-dpi rendering:

When run on a system with a scaling factor unequal to 1 the graphics may appear blurry, due to the drawbuffer being scaled up, to achieve a window of the size requested by your OS. This size is usually "the size you specified in Conf" * "your OS scaling factor".

To avoid this set Conf::high_dpi to true. This leads to the drawbuffer being the size of your actual physical window. It also means though that you can't be sure how big your drawable space will actually be, as this will then depend on where the program is being run.

We aim towards changing this, so that windows are always created with the physical size specified in Conf, but that's not directly supported by miniquad currently.

Architecture

Here is how good-web-game fits into your rust-based game:

software stack

Comments
  • ggez-0.6 update

    ggez-0.6 update

    Ok, this PR is going to be a big one, sry. But it's not as bad as it seems, as most of the long code is just copy-pasted examples from ggez.

    I basically changed the API to conform to ggez-0.6 and then added example after example. For each example I implemented (i.e. mostly copied from ggez) the functionality that was necessary to run it, thereby pushing good-web-game closer towards being a complete ggez implementation.

    If you go through the changes you can see that I also changed some things here and there (for example removing InputHandler from KeyboardContext), but I tried not to touch any sensitive parts like the filesystem, where opinions on how to move forward may differ. So I tried to stick to things like bumping lyon, etc.

    I also ran into some nasty problems, which I wasn't able to fix on my own until now. The most prominent one being the one discussed in #40, that drawing things like text or meshes sometimes leads to a STATUS_ACCESS_VIOLATION, which can sometimes be worked around by adding even more draw calls for some reason, but sometimes can't... (see the many TODOs)

    Other problems include things like color being off in the colorspace example, not being able to render to canvases sometimes and miniquad::EventHandlerFree::key_down_event always handing us repeat values of false, even when the key was obviously repeated (this last one should be easy enough to workaround, but I thought I should mention it in case this bug is still present in miniquad; maybe updating to a newer version of miniquad might fix it, haven't checked yet.

    Now the question is how we want to advance. We could either keep this PR open and work on my fork, or we could merge it right away and work on it right here (meaning using the issue tracker of this repo instead of my fork). I'd prefer the latter option, but I could of course understand if you didn't want to merge this PR before being 100% content with it.

    EDIT: I just saw that #49 also features some fixes, including some that this PR doesn't, so I guess it might be better to merge that one first, perhaps.

    opened by PSteinhaus 10
  • Stability issues

    Stability issues

    Finally uploaded my stuff to a server. I'm having some weird stability issues:

    • Google Chrome on desktop seems to be handling stuff best and in general has no issues at all.
    • Firefox on desktop is working mostly okay, although lower FPS than Chrome. I did run into an issue with it too though, crashing my entire system with itself, not super fun.
    • iPhone Safari consistently crashes after 2-3 seconds.

    Zemeroth works fine for me, so this issue must be due to something I'm doing different, which is either the SpriteBatch or Canvas (Framebuffer). I'll investigate more.

    opened by maciejhirsz 9
  • LinkError when running in browser

    LinkError when running in browser

    After successfully building the examples on the wasm32-unknown-unknown target and serving them alongside the .html file from the miniquad readme (which appears to be the correct way to deploy to web according to the current instructions) I get the following error in the browser (Chrome):

    Uncaught (in promise) LinkError: WebAssembly.instantiate(): Import #57 module="env" function="time" error: function import requires a callable

    The examples from miniquad itself work fine following the same process.

    opened by adambiltcliffe 6
  • Use Arc<AtomicBool> instead of Cell<bool>

    Use Arc instead of Cell

    I was trying to reference a graphics::Image inside an ECS (hecs) that expects components to be thread-safe. I think wrapping the dirty flag in an Arc<AtomicBool> instead of a Cell<bool> should fix the issue.

    See https://github.com/Ralith/hecs/issues/38

    opened by canadaduane 6
  • "No such file or directory" when building for Android

    OS: Ubuntu 22.04.1 LTS

    I cloned the repository and when I run the following command in the root folder: sudo docker run -e RUST_BACKTRACE='full' --rm -v $(pwd)":/root/src" -w /root/src notfl3/cargo-apk cargo quad-apk build --example meshbatch I get this output:

    Updating crates.io index
     Downloading crates ...
      Downloaded dasp_frame v0.11.0
      Downloaded num-integer v0.1.45
      Downloaded num-iter v0.1.43
      Downloaded ordered-float v2.10.0
      Downloaded num_cpus v1.13.1
      Downloaded owned_ttf_parser v0.15.2
      Downloaded proc-macro2 v1.0.46
      Downloaded quote v1.0.21
      Downloaded quad-alsa-sys v0.3.2
      Downloaded ppv-lite86 v0.2.16
      Downloaded rand v0.7.3
      Downloaded rand_core v0.5.1
      Downloaded rand_core v0.4.2
      Downloaded rand_hc v0.1.0
      Downloaded rand_chacha v0.2.2
      Downloaded rand_os v0.1.3
      Downloaded rand_core v0.3.1
      Downloaded rand_pcg v0.1.2
      Downloaded rustc-hash v1.1.0
      Downloaded rayon v1.5.3
      Downloaded sapp-android v0.1.15
      Downloaded sapp-linux v0.1.13
      Downloaded scopeguard v1.1.0
      Downloaded serde v1.0.145
      Downloaded smallvec v0.6.14
      Downloaded sid v0.6.1
      Downloaded serde_derive v1.0.145
      Downloaded smart-default v0.6.0
      Downloaded syn v1.0.102
      Downloaded thiserror v1.0.37
      Downloaded twox-hash v1.5.0
      Downloaded ttf-parser v0.15.2
      Downloaded uuid v0.8.2
      Downloaded vec_map v0.8.2
      Downloaded thiserror-impl v1.0.37
      Downloaded xi-unicode v0.3.0
      Downloaded zip v0.5.13
      Downloaded approx v0.3.2
      Downloaded audir-sles v0.1.0
      Downloaded approx v0.5.1
      Downloaded adler32 v1.2.0
      Downloaded ab_glyph v0.2.17
      Downloaded autocfg v0.1.8
      Downloaded audrey v0.3.0
      Downloaded bytemuck v1.12.1
      Downloaded byteorder v1.4.3
      Downloaded bytemuck_derive v1.2.1
      Downloaded png v0.15.3
      Downloaded rand v0.6.5
      Downloaded ab_glyph_rasterizer v0.1.7
      Downloaded cgmath v0.17.0
      Downloaded crossbeam-channel v0.5.6
      Downloaded crossbeam-epoch v0.9.11
      Downloaded dasp_sample v0.11.0
      Downloaded crossbeam-utils v0.8.12
      Downloaded float_next_after v0.1.5
      Downloaded deflate v0.7.20
      Downloaded euclid v0.22.7
      Downloaded getrandom v0.1.16
      Downloaded gilrs v0.8.2
      Downloaded glyph_brush_draw_cache v0.1.5
      Downloaded image v0.22.5
      Downloaded lewton v0.9.4
      Downloaded hound v3.5.0
      Downloaded lyon_algorithms v0.17.7
      Downloaded lyon v0.17.10
      Downloaded linked-hash-map v0.5.6
      Downloaded inflate v0.4.5
      Downloaded lyon_geom v0.17.7
      Downloaded lyon_path v0.17.7
      Downloaded memoffset v0.6.5
      Downloaded lyon_tessellation v0.17.10
      Downloaded miniquad v0.3.0-alpha.38
      Downloaded mint v0.5.9
      Downloaded rand_jitter v0.1.4
      Downloaded rayon-core v1.9.3
      Downloaded rand_xorshift v0.1.1
      Downloaded unicode-ident v1.0.5
      Downloaded glyph_brush v0.7.2
      Downloaded either v1.8.0
      Downloaded crossbeam-deque v0.8.2
      Downloaded gilrs-core v0.3.2
      Downloaded libudev-sys v0.1.4
      Downloaded maybe-uninit v2.0.0
      Downloaded glyph_brush_layout v0.2.3
      Downloaded rand_chacha v0.1.1
      Downloaded ogg v0.7.1
      Downloaded rand_isaac v0.1.1
      Downloaded nix v0.23.1
      Downloaded num-traits v0.2.15
      Downloaded num-rational v0.2.4
      Downloaded ndk-sys v0.2.2
      Downloaded libm v0.2.5
      Downloaded libc v0.2.134
      Downloaded quad-snd v0.2.5
     Downloading crates ...
      Downloaded keyframe_derive v1.0.0
      Downloaded oorandom v11.1.3
      Downloaded num-derive v0.3.3
      Downloaded quad-rand v0.2.1
      Downloaded keyframe v1.1.1
      Downloaded glam v0.17.3
       Compiling lewton v0.9.4
       Compiling audrey v0.3.0
       Compiling quad-snd v0.2.5
       Compiling good-web-game v0.5.0 (/root/src)
    warning: field is never read: `root`
      --> src/filesystem.rs:24:5
       |
    24 |     root: Option<path::PathBuf>,
       |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
       |
       = note: `#[warn(dead_code)]` on by default
    note: `Filesystem` has a derived impl for the trait `Debug`, but this is intentionally ignored during dead code analysis
      --> src/filesystem.rs:22:10
       |
    22 | #[derive(Debug)]
       |          ^^^^^
       = note: this warning originates in the derive macro `Debug` (in Nightly builds, run with -Z macro-backtrace for more info)
    
    warning: `good-web-game` (lib) generated 1 warning
    thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/ops/build/compile.rs:165:18
    stack backtrace:
       0:     0x55a48f0e2c6d - std::backtrace_rs::backtrace::libunwind::trace::h22893a5306c091b4
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
       1:     0x55a48f0e2c6d - std::backtrace_rs::backtrace::trace_unsynchronized::h29c3bc6f9e91819d
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
       2:     0x55a48f0e2c6d - std::sys_common::backtrace::_print_fmt::he497d8a0ec903793
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:66:5
       3:     0x55a48f0e2c6d - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h9c2a9d2774d81873
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:45:22
       4:     0x55a48f10aeac - core::fmt::write::hba4337c43d992f49
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/fmt/mod.rs:1194:17
       5:     0x55a48f0dda81 - std::io::Write::write_fmt::heb73de6e02cfabed
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/io/mod.rs:1655:15
       6:     0x55a48f0e5115 - std::sys_common::backtrace::_print::h63c8b24acdd8e8ce
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:48:5
       7:     0x55a48f0e5115 - std::sys_common::backtrace::print::h426700d6240cdcc2
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:35:9
       8:     0x55a48f0e5115 - std::panicking::default_hook::{{closure}}::hc9a76eed0b18f82b
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:295:22
       9:     0x55a48f0e4dc9 - std::panicking::default_hook::h2e88d02087fae196
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:314:9
      10:     0x55a48f0e5662 - std::panicking::rust_panic_with_hook::habfdcc2e90f9fd4c
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:698:17
      11:     0x55a48f0e5547 - std::panicking::begin_panic_handler::{{closure}}::he054b2a83a51d2cd
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:588:13
      12:     0x55a48f0e3124 - std::sys_common::backtrace::__rust_end_short_backtrace::ha48b94ab49b30915
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:138:18
      13:     0x55a48f0e5279 - rust_begin_unwind
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:584:5
      14:     0x55a48e97ffe3 - core::panicking::panic_fmt::h366d3a309ae17c94
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:143:14
      15:     0x55a48e9800d3 - core::result::unwrap_failed::hddd78f4658ac7d0f
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/result.rs:1785:5
      16:     0x55a48e9e8c2c - <cargo_quad_apk::ops::build::compile::SharedLibraryExecutor as cargo::core::compiler::Executor>::exec::hecd7f5a732703b11
      17:     0x55a48eafc29c - core::ops::function::FnOnce::call_once{{vtable.shim}}::h89048bd199c4c0bd
      18:     0x55a48eafafcc - core::ops::function::FnOnce::call_once{{vtable.shim}}::h53362546aa0cb559
      19:     0x55a48eafafcc - core::ops::function::FnOnce::call_once{{vtable.shim}}::h53362546aa0cb559
      20:     0x55a48ea16366 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h8587960837c1a47f
      21:     0x55a48ea7cfee - std::sys_common::backtrace::__rust_begin_short_backtrace::h18f4b9ad908d67c2
      22:     0x55a48ecd71ca - core::ops::function::FnOnce::call_once{{vtable.shim}}::haf12b2dab199031b
      23:     0x55a48f0ebeb3 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::ha99802c2c52ada61
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/alloc/src/boxed.rs:1861:9
      24:     0x55a48f0ebeb3 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::ha39aea1c57e28a15
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/alloc/src/boxed.rs:1861:9
      25:     0x55a48f0ebeb3 - std::sys::unix::thread::Thread::new::thread_start::h9f8e3d72b1f7662f
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys/unix/thread.rs:108:17
      26:     0x7f15c01c6ea7 - start_thread
      27:     0x7f15bffaadef - clone
      28:                0x0 - <unknown>
    error: worker panicked
    thread 'main' panicked at 'child threads shouldn't panic: Any { .. }', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/cargo-0.62.0/src/cargo/core/compiler/job_queue.rs:565:10
    stack backtrace:
       0:     0x55a48f0e2c6d - std::backtrace_rs::backtrace::libunwind::trace::h22893a5306c091b4
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
       1:     0x55a48f0e2c6d - std::backtrace_rs::backtrace::trace_unsynchronized::h29c3bc6f9e91819d
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
       2:     0x55a48f0e2c6d - std::sys_common::backtrace::_print_fmt::he497d8a0ec903793
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:66:5
       3:     0x55a48f0e2c6d - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h9c2a9d2774d81873
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:45:22
       4:     0x55a48f10aeac - core::fmt::write::hba4337c43d992f49
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/fmt/mod.rs:1194:17
       5:     0x55a48f0dda81 - std::io::Write::write_fmt::heb73de6e02cfabed
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/io/mod.rs:1655:15
       6:     0x55a48f0e5115 - std::sys_common::backtrace::_print::h63c8b24acdd8e8ce
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:48:5
       7:     0x55a48f0e5115 - std::sys_common::backtrace::print::h426700d6240cdcc2
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:35:9
       8:     0x55a48f0e5115 - std::panicking::default_hook::{{closure}}::hc9a76eed0b18f82b
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:295:22
       9:     0x55a48f0e4dc9 - std::panicking::default_hook::h2e88d02087fae196
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:314:9
      10:     0x55a48f0e5662 - std::panicking::rust_panic_with_hook::habfdcc2e90f9fd4c
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:698:17
      11:     0x55a48f0e5547 - std::panicking::begin_panic_handler::{{closure}}::he054b2a83a51d2cd
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:588:13
      12:     0x55a48f0e3124 - std::sys_common::backtrace::__rust_end_short_backtrace::ha48b94ab49b30915
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/sys_common/backtrace.rs:138:18
      13:     0x55a48f0e5279 - rust_begin_unwind
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:584:5
      14:     0x55a48e97ffe3 - core::panicking::panic_fmt::h366d3a309ae17c94
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/panicking.rs:143:14
      15:     0x55a48e9800d3 - core::result::unwrap_failed::hddd78f4658ac7d0f
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/result.rs:1785:5
      16:     0x55a48eb468c9 - cargo::core::compiler::job_queue::JobQueue::execute::hba7ec7a43962ba31
      17:     0x55a48eacf87c - cargo::core::compiler::context::Context::compile::h12a1634d09886c54
      18:     0x55a48ec97aab - cargo::ops::cargo_compile::compile_ws::hc7ed5025c3dd63b8
      19:     0x55a48ec978b1 - cargo::ops::cargo_compile::compile_with_exec::hdd1df846945e4d8f
      20:     0x55a48e9e5212 - cargo_quad_apk::ops::build::compile::build_shared_libraries::h2e67de507c24ff76
      21:     0x55a48e9b7945 - cargo_quad_apk::ops::build::build::h1b15337b0f0cb992
      22:     0x55a48e9c8aca - cargo_quad_apk::main::he8379582492ed856
      23:     0x55a48e9cbe53 - std::sys_common::backtrace::__rust_begin_short_backtrace::h70860d16cf446d25
      24:     0x55a48e9f8599 - std::rt::lang_start::{{closure}}::he9d9d9652557586f
      25:     0x55a48f0d665e - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::had4f69b3aefb47a8
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/core/src/ops/function.rs:259:13
      26:     0x55a48f0d665e - std::panicking::try::do_call::hf2ad5355fcafe775
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:492:40
      27:     0x55a48f0d665e - std::panicking::try::h0a63ac363423e61e
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:456:19
      28:     0x55a48f0d665e - std::panic::catch_unwind::h18088edcecb8693a
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panic.rs:137:14
      29:     0x55a48f0d665e - std::rt::lang_start_internal::{{closure}}::ha7dad166dc711761
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/rt.rs:128:48
      30:     0x55a48f0d665e - std::panicking::try::do_call::hda0c61bf3a57d6e6
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:492:40
      31:     0x55a48f0d665e - std::panicking::try::hbc940e68560040a9
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panicking.rs:456:19
      32:     0x55a48f0d665e - std::panic::catch_unwind::haed0df2aeb3fa368
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/panic.rs:137:14
      33:     0x55a48f0d665e - std::rt::lang_start_internal::h9c06694362b5b80c
                                   at /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/rt.rs:128:20
      34:     0x55a48e9cbce2 - main
      35:     0x7f15bfed3d0a - __libc_start_main
      36:     0x55a48e9802da - _start
      37:                0x0 - <unknown>
    

    I'm not sure what could be the problem, however when I ran the same command in the miniquad repo the build completed and it worked successfully on my Android device.

    opened by MOj0 4
  • Implement DirtyFlag as naked AtomicBool

    Implement DirtyFlag as naked AtomicBool

    This is an attempt at fixing the Arc<AtomicBool> work I did earlier. I believe this is more in-line with what @Ralith had in mind (see https://github.com/not-fl3/good-web-game/pull/23). The idea is that each thread would have its own dirty_filter rather than copying a reference counter to a single dirty_filter.

    I took implementation hints from this rust-lang thread: https://users.rust-lang.org/t/struct-with-atomic-fields-still-require-arc-and-clones/21348/2

    opened by canadaduane 4
  • What goes in the 'js' folder?

    What goes in the 'js' folder?

    The readme shows how to get started building the example game for wasm:

    rustup target add wasm32-unknown-unknown
    cargo build --example astroblasto --target wasm32-unknown-unknown
    cp target/wasm32-unknown-unknown/debug/examples/astroblsato.wasm js
    cd js/ #  and launch http server with wasm MIME, maybe check index.html to match>
    

    It looks to me like the js/ folder already exists? What goes inside?

    opened by canadaduane 4
  • WASM failed to load, probably incompatible gl.js version

    WASM failed to load, probably incompatible gl.js version

    When trying to launch my game using wasm, i get 2 errors at f12 in the browser:

    WASM failed to load, probably incompatible gl.js version
    (anonymous) @ js_bundle.js:1
    
    TypeError: WebAssembly.instantiate(): Import #6 module="__wbindgen_placeholder__" error: module is not an object or function
        at js_bundle.js:1
    (anonymous) @ js_bundle.js:1
    

    Whot logs / code should i provide to help resolve the issue? Also, for me, the same error appers when trying to launch the example, using instructions from the readme file.

    opened by Szybet 3
  • WASM support for RNG

    WASM support for RNG

    We see that all examples use something like:

    qrand::srand(12345);

    I tried to use the std SystemTime but got a panic:

    PanicInfo { payload: Any { .. }, message: None, location: Location { file: "library/std/src/sys/wasm/../unsupported/time.rs", line: 39, col: 9 } }

    What options do we have ?

    opened by ccie18473 3
  • Canvas API

    Canvas API

    I've got most of the API surface done here, but I've run into an issue. I've been following this tutorial on rendering to a texture with WebGL (so the Canvas in this case is a Framebuffer wrapper, NOT the <canvas> element, which might be confusing but I reckon is closer to ggez).

    Everything seems to be fine, I get no errors from WebGL anymore, so texture is properly initialized. I can bind the framebuffer to the gl context and it stops rendering stuff on main canvas, but rendering the image bound to the buffer leaves me with a blank image.

    I'll look at this again tomorrow with fresh eyes.

    opened by maciejhirsz 3
  • Add key up event binding

    Add key up event binding

    Hello!

    I've added bindings to key_up events. Would you find these useful?

    Thank you for publishing your work to github. I found this source code very helpful while I was tinkering with rust, webassembly, and game programming.

    opened by Terkwood 3
  • shadows example

    shadows example

    The shadows example has now been added, but is still incomplete. To see how, just compare it to the one in ggez.

    The blocks and text are rendered, but the lights and shadows aren't. Instead, one sees only a black background right now.

    The shaders are already the same, so it's probably something in the code drawing it all, or even something faulty in the library itself...

    Anyway, I perhaps didn't pay that much attention while porting it. If you should find anything, please speak up. Help here is very welcome.

    enhancement help wanted 
    opened by PSteinhaus 0
  • to_rgba8 support

    to_rgba8 support

    I found that "pub fn to_rgba8(&self, ctx: &mut Context) -> GameResult<Vec>" is not implemented in gwg. Do we have any other method to do the same ? If not, what steps do we need to implement it in gwg ?

    I'm looking to the source code at:

    https://github.com/ggez/ggez/blob/master/src/graphics/image.rs

    And I'm thinking that maybe this is too much for me :)

    Thanks.

    opened by ccie18473 2
  • `TypeError: wasm_exports.crate_version is not a function`

    `TypeError: wasm_exports.crate_version is not a function`

    I'm trying to start a new little (so far empty) project and for starter - just serve it locally to see if it works. Unfortunately I'm hitting TypeError: wasm_exports.crate_version is not a function, no matter which "gl.js" / "js_bundle.js" I use. I've found https://github.com/not-fl3/macroquad/issues/221 , however I'm unsure which file to use exactly as Cargo.toml points at miniquad = "0.3.0-alpha.37"

    opened by dpc 1
  • Canvases and multisampling

    Canvases and multisampling

    Ok, this is the most annoying bug for me in ggez currently. I thought good-web-game just wouldn't have it, but it turns out I was wrong.

    In ggez 0.6 trying to create a Canvas with a NumSamples count other than 1 leads to this bug: https://github.com/ggez/ggez/issues/695

    If we stick to 1 things work out ok, but as soon as multisampling is activated globally the canvas starts to get drawn slightly blurry. This effect increases with multisampling level.

    Now the sad thing is: good-web-game currently has the same bug. To recreate try the 03_drawing example, set multisampling to 16 (uncomment a line in the boilerplate) and press a button to switch between drawing onto the screen directly and drawing onto the offscreen canvas, which is then drawn onto the screen.

    drawn directly: no_canvas

    drawn on canvas: canvas

    As you can see by looking at the white thing somewhat in the middle (which is drawn using a nearest neighbor filter) no MSAA has been applied when drawing it in the second case. The only reason it looks less jagged (but still wrong) is because the whole canvas was drawn somewhat blurry...

    The good news is: This replicates the ggez behavior when using a Canvas with multisample count 1 perfectly, so we might fix it by somehow specifying that the framebuffer supplied by a canvas is supposed to have the same level of multisampling as the application. But, AFAIK, there is currently no feature present in miniquad to achieve this.

    bug help wanted 
    opened by PSteinhaus 3
  • blend modes behave differently than in ggez

    blend modes behave differently than in ggez

    Here are both blend_modes examples. Top is ggez, bottom is good-web-game:

    blendmodes

    For some reason the blend modes behave differently, though they should be the same.

    • ggez's blend modes: https://github.com/ggez/ggez/blob/f85d89a7dd2803c1f0e79543dc5f6076c4bbde8d/src/graphics/shader.rs#L80-L160
    • gwg's blend modes: https://github.com/ggez/good-web-game/blob/d46b3388df49da5aa8ce1f52dd2bd19a4c812467/src/graphics/shader.rs#L35-L100

    The first step to analyzing this might be calculating some colors by hand using these formulas to then check whether one of the two cases actually produces this expected result. This would at least give us an answer to which of the two is actually "correct".

    bug 
    opened by PSteinhaus 0
  • wasm-bindgen

    wasm-bindgen

    Apparently some dependencies used require wasm-bindgen to get them to work on WASM.

    Since I've never worked with WebAssembly or Javascript before it's safe to say that I'm the wrong person for this job, though.

    Therefore I hereby humbly ask for help.

    bug help wanted 
    opened by PSteinhaus 8
Releases(0.6.0)
Owner
null
Bevy engine + miniquad render plugin

Bevy engine + miniquad renderer This is a plugin for Bevy engine that replaces default windowing and rendering plugins with miniquad based one. Usage

Tomasz Sterna 31 Dec 9, 2022
Rust/Javascript interop demo with miniquad

Rust/Javascript interop demo with miniquad

Fedor Logachev 3 Mar 16, 2022
Scion is a tiny 2D game library built on top of wgpu, winit and legion.

Scion is a 2D game library made in rust. Please note that this project is in its first milestones and is subject to change according to convience need

Jérémy Thulliez 143 Dec 25, 2022
3d transformation gizmo built on top of the egui library.

egui-gizmo 3d transformation gizmo built on top of the egui library. Try it out in a web demo Usage let gizmo = Gizmo::new("My gizmo") .view_matri

Urho Laukkarinen 69 Dec 10, 2022
General purpose client/server networking library written in Rust, built on top of the QUIC protocol which is implemented by quinn

Overview "This library stinks!" ... "Unless you like durian" durian is a client-server networking library built on top of the QUIC protocol which is i

Michael 92 Dec 31, 2022
A novel path-based approach to UI built on top of existing Bevy features

Bevy Lunex A novel path-based approach to UI built on top of existing Bevy features. A recreation of Cyberpunk 2077 menu in Bevy using Lunex Table of

Bytestring 4 Jun 29, 2023
A 2d top-down shooter written in Bevy, capable of handling 100K enemies

Bevy 2D Shooter This is a 2d top-down shooter written in Rust using the Bevy game engine. It's capable of handling 100K enemies and uses a kd-tree to

Bones-ai 41 Jul 21, 2024
Terminal command correction, alternative to thefuck written in Rust

Pay Respects Typed a wrong command? Pay Respects will try to correct your wrong console command by simply pressing F! ?? Blazing fast suggestion: You

iff 11 Aug 7, 2023
A no-frills Tetris implementation written in Rust with the Piston game engine, and Rodio for music.

rustris A no-frills Tetris implementation written in Rust with the Piston game engine, and Rodio for music. (C) 2020 Ben Cantrick. This code is distri

Ben Cantrick 17 Aug 18, 2022
An (unofficial) open source Rust implementation of the Discord Game SDK.

⚔️ discord-sdk An (unofficial) open source Rust implementation of the Discord Game SDK. Why not use this? This project is not official and is using a

Embark 86 Dec 23, 2022
Terminal UI implementation and types for the Dark Forest game

dark-forest.rs Terminal UI implementation and types for the Dark Forest game Development We use the standard Rust toolchain cargo check

Georgios Konstantopoulos 63 Nov 12, 2022
Rust implementation of Another World (aka Out of this world) game engine

RustyWorld Rust implementation of Another World (aka Out of this world) game engine. I wanted a fun project to challenge myself while learning Rust, a

Francesco Degrassi 3 Jul 1, 2021
Implementation of the great book Ray Tracing in One Weekend in Rust.

Ray Tracing in One Weekend (Rust) Implementation of the great book Ray Tracing in One Weekend in Rust. Fun easy way to pick up and learn Rust (was rou

Stanley Su 6 Dec 29, 2021
A Rust implementation of the legendary solitaire game

Freecell Yet another implementation of the legendary total information solitaire. Play patience like it's 1991, complete with sights and sounds. Build

null 16 Dec 14, 2022
Game of life implementation written in Rust.

Game of life Game of life implementation written in Rust. Part of my journey in learning Rust. Pattern files The patterns are based on the example pat

Hashem Hashem 2 Nov 17, 2022
A simple implementation of Conway's Game of Life using Fully homomorphic Encryption

Game of life using Fully homomorphic encryption A simple implementation of Conway's Game of Life built using Zama's concrete-boolean library. Build Ju

Florent Michel 4 Oct 3, 2022
An implementation of the Game of Life

Lifeee – An implementation of the Game of Life I realized this application to keep learning Rust, discover the front-end library Yew, and because I’m

Sébastien Castiel 58 Nov 23, 2022
A simple, very minimal Minecraft server implementation in Rust.

A simple, very minimal Minecraft server implementation in Rust. For a simple Minecraft server that isn't supposed to do much (for example, a limbo ser

Chris 8 Dec 22, 2022
Rust implementation of the Nomic Bitcoin sidechain

Nomic Bitcoin Bridge testnet v0.3.0 (codename "gucci") Guccinet In this testnet, we've added two core featues: staking and Bitcoin integration. Full s

Nomic 77 Dec 28, 2022