Code Monkey home page Code Monkey logo

good-web-game's Introduction

ggez

ggez logo

What is this?

Build status Docs Status license Crates.io Crates.io Discord chat

ggez is a Rust library to create a Good Game Easily.

The current version is 0.9.3.

More specifically, ggez is a lightweight cross-platform game framework for making 2D games with minimum friction. It aims to implement an API based on (a Rustified version of) the LÖVE game framework. This means it contains basic and portable 2D drawing, sound, resource loading and event handling, but finer details and performance characteristics may be different than LÖVE.

ggez is not meant to be everything to everyone, but rather a good base upon which to build. Thus it takes a fairly batteries-included approach without needing a million additions and plugins for everything imaginable, but also does not dictate higher-level functionality such as physics engine or entity component system. Instead the goal is to allow you to use whichever libraries you want to provide these functions, or build your own libraries atop ggez.

Features

  • Filesystem abstraction that lets you load resources from folders or zip files
  • Hardware-accelerated 2D rendering built on the wgpu graphics API
  • Loading and playing .ogg, .wav and .flac files via the rodio crate
  • TTF font rendering with glyph_brush.
  • Interface for handling keyboard and mouse events easily through callbacks
  • Config file for defining engine and game settings
  • Easy timing and FPS measurement functions.
  • Math library integration with mint.
  • Some more advanced graphics options: shaders, instanced draws and render targets

Non-Features (i.e. things to add from elsewhere if needed)

Supported platforms

  • Fully supported: Windows, Linux, MacOS
  • Not officially supported but might work anyway: Android, iOS, Web

For details, see docs/BuildingForEveryPlatform.md

If you want to run ggez (up to 0.7 as of now) on Android, iOS or the web using WebAssembly right now, take a look at good-web-game.

Who's using ggez?

Check out the projects list!

Usage

ggez requires rustc >= 1.42 and is distributed on crates.io. To include it in your project, just add the dependency line to your Cargo.toml file:

ggez = "0.9.3"

ggez consists of three main parts: A Context object which contains all the state required to interface with the computer's hardware, an EventHandler trait that the user implements to register callbacks for events, and various sub-modules such as graphics and audio that provide the functionality to actually get stuff done. The general pattern is to create a struct holding your game's data which implements the EventHandler trait. Create a new Context object with default objects from a ContextBuilder or Conf object, and then call event::run() with the Context and an instance of your EventHandler to run your game's main loop.

See the API docs for full documentation, or the examples directory for a number of commented examples of varying complexity. Most examples show off a single feature of ggez, while astroblasto and snake are small but complete games.

Getting started

For a quick tutorial on ggez, see the Hello ggez guide in the docs/ directory.

Examples

See the examples/ directory in the source. Most examples show off a single feature of ggez, while astroblasto is a small but complete Asteroids-like game.

To run the examples, just check out the source and execute cargo run --example in the root directory:

git clone https://github.com/ggez/ggez.git
cd ggez
cargo run --example 05_astroblasto

If this doesn't work, see the FAQ for solutions to common problems.

Basic Project Template

use ggez::{Context, ContextBuilder, GameResult};
use ggez::graphics::{self, Color};
use ggez::event::{self, EventHandler};

fn main() {
    // Make a Context.
    let (mut ctx, event_loop) = ContextBuilder::new("my_game", "Cool Game Author")
        .build()
        .expect("aieee, could not create ggez context!");

    // Create an instance of your event handler.
    // Usually, you should provide it with the Context object to
    // use when setting your game up.
    let my_game = MyGame::new(&mut ctx);

    // Run!
    event::run(ctx, event_loop, my_game);
}

struct MyGame {
    // Your state here...
}

impl MyGame {
    pub fn new(_ctx: &mut Context) -> MyGame {
        // Load/create resources such as images here.
        MyGame {
            // ...
        }
    }
}

impl EventHandler for MyGame {
    fn update(&mut self, _ctx: &mut Context) -> GameResult {
        // Update code here...
        Ok(())
    }

    fn draw(&mut self, ctx: &mut Context) -> GameResult {
        let mut canvas = graphics::Canvas::from_frame(ctx, Color::WHITE);
        // Draw code here...
        canvas.finish(ctx)
    }
}

Implementation details

ggez is built upon winit for windowing and events, rodio for sound, and a 2D drawing engine implemented with wgpu. It is entirely thread-safe (though platform constraints mean the event-handling loop and drawing must be done in the main thread), and portable to Windows and Linux.

ggez is pure Rust™.

Help!

Sources of information:

  • The FAQ has answers to common questions and problems.
  • The API docs, a lot of design stuff is explained there.
  • Check out the examples.

If you still have problems or questions, feel free to ask! Easiest ways are:

License: MIT

good-web-game's People

Contributors

ameobea avatar atul9 avatar canadaduane avatar cataractar avatar kurble avatar maciejhirsz avatar mystal avatar not-fl3 avatar ozkriff avatar psteinhaus avatar tantandev avatar terkwood avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

good-web-game's Issues

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.

SpriteBatch to actually handle batch rendering

Now that #10 got merged, it would make sense to actually batch the renders from it, as good-web-game is doubly penalized for not using it (once for having to access GPU per every sprite, twice by having to do that by whatever magical JS bindings stdweb provides).

I can tackle this, but not immediately.

eimigui fails to build

Hello. When building any of the examples on Windows native, emigui-miniquad fails to build.

error[E0432]: unresolved import `emigui::Mesh`
 --> C:\Users\Moxinilian\.cargo\git\checkouts\emigui-miniquad-166b794becee653c\6457ba3\src\painter.rs:1:14
  |
1 | use emigui::{Mesh, Texture};
  |              ^^^^ no `Mesh` in the root

error: aborting due to previous error

Is this because of an outdated commit? If not, should I open an issue at emigui-miniquad?

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:
    impl From<BlendMode> for (BlendState, BlendState) {
    fn from(bm: BlendMode) -> Self {
    match bm {
    BlendMode::Add => (
    BlendState::new(
    Equation::Add,
    BlendFactor::Value(BlendValue::SourceAlpha),
    BlendFactor::One,
    ),
    BlendState::new(
    Equation::Add,
    BlendFactor::Value(BlendValue::SourceAlpha),
    BlendFactor::One,
    ),
    ),
    BlendMode::Subtract => (
    BlendState::new(
    Equation::ReverseSubtract,
    BlendFactor::Value(BlendValue::SourceAlpha),
    BlendFactor::One,
    ),
    BlendState::new(Equation::Add, BlendFactor::Zero, BlendFactor::One),
    ),
    BlendMode::Alpha => (
    BlendState::new(
    Equation::Add,
    BlendFactor::Value(BlendValue::SourceAlpha),
    BlendFactor::OneMinusValue(BlendValue::SourceAlpha),
    ),
    BlendState::new(
    Equation::Add,
    BlendFactor::OneMinusValue(BlendValue::DestinationAlpha),
    BlendFactor::One,
    ),
    ),
    BlendMode::Premultiplied => (
    BlendState::new(
    Equation::Add,
    BlendFactor::One,
    BlendFactor::OneMinusValue(BlendValue::SourceAlpha),
    ),
    BlendState::new(
    Equation::Add,
    BlendFactor::OneMinusValue(BlendValue::DestinationAlpha),
    BlendFactor::One,
    ),
    ),
    BlendMode::Multiply => (
    BlendState::new(
    Equation::Add,
    BlendFactor::Value(BlendValue::DestinationColor),
    BlendFactor::Zero,
    ),
    BlendState::new(
    Equation::Add,
    BlendFactor::Value(BlendValue::DestinationAlpha),
    BlendFactor::Zero,
    ),
    ),
    BlendMode::Replace => (
    BlendState::new(Equation::Add, BlendFactor::One, BlendFactor::Zero),
    BlendState::new(Equation::Add, BlendFactor::One, BlendFactor::Zero),
    ),
    }
    }
    }

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

incompatible gl.js version

Been able to build and test successfully WASM targets under Ubuntu, Copied the files to a windows 10 machine and it worked fine. Copied the files to another windows 10 machine and it failed:
(Chrome logs)
js_bundle.js:1 WASM failed to load, probably incompatible gl.js version
(anonymous) @ js_bundle.js:1
js_bundle.js:1 TypeError: Failed to execute 'compile' on 'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'.
(anonymous) @ js_bundle.js:1
How do I troubleshoot this ? I'm using js_bundle.js (0.1.26) and Python 3.7 basic web server.

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.

Versioning issues while compiling for android

So Im trying to compile for android using comand

sudo docker run --rm -v <path to my project>:/root/src -w /root/src notfl3/cargo-apk cargo quad-apk build    

I cant compile good-web-game as seen down below,

 Compiling good-web-game v0.4.0
error[E0433]: failed to resolve: could not find `Cache` in `conf`
  --> /home/pavel/.cargo/registry/src/github.com-1ecc6299db9ec823/good-web-game-0.4.0/src/conf.rs:31:40
   |
31 |                 cache: miniquad::conf::Cache::No,
   |                                        ^^^^^ could not find `Cache` in `conf`

error[E0433]: failed to resolve: could not find `Cache` in `conf`
  --> /home/pavel/.cargo/registry/src/github.com-1ecc6299db9ec823/good-web-game-0.4.0/src/filesystem.rs:28:32
   |
28 |         if let miniquad::conf::Cache::Tar(tar_file) = conf.quad_conf.cache {
   |                                ^^^^^ could not find `Cache` in `conf`

error[E0412]: cannot find type `Cache` in module `miniquad::conf`
  --> /home/pavel/.cargo/registry/src/github.com-1ecc6299db9ec823/good-web-game-0.4.0/src/conf.rs:62:49
   |
62 |     pub fn cache(mut self, val: miniquad::conf::Cache) -> Self {
   |                                                 ^^^^^ not found in `miniquad::conf`

error[E0560]: struct `miniquad::conf::Conf` has no field named `cache`
  --> /home/pavel/.cargo/registry/src/github.com-1ecc6299db9ec823/good-web-game-0.4.0/src/conf.rs:31:17
   |
31 |                 cache: miniquad::conf::Cache::No,
   |                 ^^^^^ `miniquad::conf::Conf` does not have this field
   |
   = note: available fields are: `window_title`, `window_width`, `window_height`, `high_dpi`, `fullscreen` ... and 3 others

error[E0609]: no field `cache` on type `miniquad::conf::Conf`
  --> /home/pavel/.cargo/registry/src/github.com-1ecc6299db9ec823/good-web-game-0.4.0/src/conf.rs:63:24
   |
63 |         self.quad_conf.cache = val;
   |                        ^^^^^ unknown field
   |
   = note: available fields are: `window_title`, `window_width`, `window_height`, `high_dpi`, `fullscreen` ... and 3 others

error[E0609]: no field `cache` on type `miniquad::conf::Conf`
  --> /home/pavel/.cargo/registry/src/github.com-1ecc6299db9ec823/good-web-game-0.4.0/src/filesystem.rs:28:70
   |
28 |         if let miniquad::conf::Cache::Tar(tar_file) = conf.quad_conf.cache {
   |                                                                      ^^^^^ unknown field
   |
   = note: available fields are: `window_title`, `window_width`, `window_height`, `high_dpi`, `fullscreen` ... and 3 others

Some errors have detailed explanations: E0412, E0433, E0560, E0609.
For more information about an error, try `rustc --explain E0412`.
error: could not compile `good-web-game` due to 6 previous errors

but I also cant select newer version of good-web-game because of:

error: failed to select a version for the requirement `good-web-game = "=0.5.0"`
candidate versions found which didn't match: 0.4.0, 0.3.0

Am I missing something here?

Use window.devicePixelRatio

Basically on hidpi/retina screens, the canvas width and height properties need to be multiplied by window.devicePixelRatio (rounded or floored), with CSS pixel values entered as CSS width/height values, otherwise the image will be blurred (linear upscaling, most commonly by a factor of 2 on hidpi / retina screens). Hidpi desktop screens are not super common yet outside of Apple products (although I don't know how anyone can live without them :P), most phones are typically retina/hidpi though, at least as far as web is concerned.

Memory deallocation bug in `Drawable`s

When running the drawing example I see a problem with memory comsumption; the process crashes after a few minutes. Same behavior under Ubuntu or Centos. This seems the buggy memory allocation:

amsoares@ubuntu:drawing$ pmap -x 4964 | grep renderD128 | wc -l # <-- Value increases until it crashes
64488
amsoares@ubuntu:drawing$ pmap -x 4964 | grep renderD128 | wc -l # <-- Already crashing
48439
amsoares@ubuntu:drawing$ pmap -x 4964 | grep renderD128 | wc -l # <-- Process dead
0
amsoares@ubuntu:drawing$

I'm not a developer, I'm just learning Rust and ggez/gwg.

Originally posted by @ccie18473 in #57 (comment)

Better font rendering?

The current demo displays the Level and Score as poorly rendered DejaVuSerif:

image

Is this something on the radar to be fixed later?

`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 not-fl3/macroquad#221 , however I'm unsure which file to use exactly as Cargo.toml points at miniquad = "0.3.0-alpha.37"

examples/ui not runable

From a fresh checkout:

cargo web start
   Compiling ui v0.1.0 (/home/wathiede/Downloads/good-web-game/examples/ui)
error[E0599]: no method named `window` found for type `good_web_game::goodies::megaui::Ui` in the current scope
  --> src/main.rs:53:17
   |
53 |         self.ui.window(
   |                 ^^^^^^
error[E0599]: no method named `window` found for type `good_web_game::goodies::megaui::Ui` in the current scope
  --> src/main.rs:66:17
   |
66 |         self.ui.window(
   |                 ^^^^^^
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0599`.
error: Could not compile `ui`.

Maybe there's some local changes to src/goodies/megaui.rs for a method window on goodies::megaui::Ui that didn't get commited along with the example?

shaders

ggez currently features three functions allowing you to use custom shaders when drawing:

It should be possible to implement them using miniquad, but since I'm relatively inexperienced when it comes to shaders (and using shaders with miniquad) I leave this open for now for anyone willing to help.

Once the functionality is implemented porting the two examples shader.rs and shadows.rs should be pretty straightforward (at least for shader.rs, not sure whether the shaders in shadows.rs can be written to work in glsl100).

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.

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.

warning: unnecessary `unsafe` block

Can these unsafe calls be removed? (I'd be happy to PR):

warning: unnecessary `unsafe` block
  --> src/lib.rs:30:21
   |
30 |             let r = unsafe { rand() } as f32 / miniquad::RAND_MAX as f32;
   |                     ^^^^^^ unnecessary `unsafe` block
   |
   = note: `#[warn(unused_unsafe)]` on by default

warning: unnecessary `unsafe` block
  --> src/lib.rs:36:21
   |
36 |             let r = unsafe { rand() } as f32 / miniquad::RAND_MAX as f32;
   |                     ^^^^^^ unnecessary `unsafe` block

warning: unnecessary `unsafe` block
  --> src/lib.rs:43:21
   |
43 |             let r = unsafe { rand() } as f32 / miniquad::RAND_MAX as f32;
   |                     ^^^^^^ unnecessary `unsafe` block

WASM runtime errors

I built the astroblasto example, like it is specified in the README. The build works, but when I open it in browser, I immediately get the following errors:

  • gl version mismatch: Version mismatch: gl.js version is: 0.1.26, rust sapp-wasm crate version is: 0.3.13
  • some sort of audio error: Uncaught TypeError: AudioParam.value setter: Value being assigned is not a finite floating-point value. audio_play_buffer https://psteinhaus.github.io/js/js_bundle.js:1 animation https://psteinhaus.github.io/js/js_bundle.js:1
  • input handling error(s): Uncaught RuntimeError: unreachable executed onkeydown https://psteinhaus.github.io/js/js_bundle.js:1

Also I remember this worked a couple of months ago, so there has to be a breaking change somewhere else, that needs to be resolved.

How to log message in wasm?

Hi,

Thanks for building goog-web-game, this project is really cool.

I try to use this framework to learn more about game development and wasm, but I can not find a correct way to log the message into the console.

In the picture of Readme, I should use sapp-console-log to log things.

Is that log crate ready to use? Or something I may help with this.

Thanks.

ref: yanganto/rust-wasm-sokoban#5

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

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: ggez/ggez#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.

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 ?

good_web_game::graphics::draw not working correctly on Windows

In my game I am doing something like this in order to draw multiple rectangles using a single Mesh instance (in different destinations of course, but I deleted that code for brevity):

graphics::draw(
                ctx,
                quad_ctx,
                &self.my_mesh,
                graphics::DrawParam::default(),
            )
            .unwrap();
graphics::draw(
                ctx,
                quad_ctx,
                &self.my_mesh,
                graphics::DrawParam::default(),
            )
            .unwrap();

This works fine on Linux (Ubuntu 22.04)
3rectangles

However when running the same code on Windows it looks like this:
image

I don't know what the issue is, but it seems only one (the last) out of three rectangles got drawn.
Also there were similar issues with drawing text, where text from one draw call got mixed up with another, but I fixed that by using the queue_text function.

screenshot

A screenshot function, similiar to the one in ggez should be relatively straightforward to implement.
My naive first guess:

  • call glFinish
  • copy the renderbuffer texture
  • create a new Image from that copy
  • return it

GC Image's Texture somehow?

It doesn't look like we call gl_ctx.delete_texture anywhere if the Image is dropped? It might be nice to add if some images are created and dropped, maybe use an Rc or some such on the Texture? Either way, I don't think it's a high priority right now.

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.

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?

filesystem

The current filesystem is a remnant from a time when miniquad wasn't able to load files via URL on WASM.
Since it's now able to do so we might think about removing the embedded file cache. On the other hand it might still be nice to have in some circumstances and could just be disabled by default.

What should be addressed though is writing data, or even creating folders and the like. It should be easily possible to recreate ggez's filesystem by copying the code and then hiding it behind conditional compilation for WASM (since I assume Android and iOS do support std::fs, gotta take a look into it).

One may argue though, whether this is actually the right thing to do, as good-web-game is (obviously) meant to be portable to the web, which these functions aren't.

Progressive Web Apps

ios since 11.3 as well as android support progressive web apps, so it would be nice to implement all the PWA boilerplate for good-web-game.

google play is now supporting PWA, making it the easiest way to deploy good-web-game to play market.
Probably this will never happens on appstore, but who knows?

  • write .webmanifest, figure out how the icons and all the meta information works in PWA
  • support offline service-workes for filesystem
  • cargo apk like tool to build play store's .apk from the PWA
  • same for Microsoft Store?

Mesh?

First thanks for the nice lib :) Wondering, any chance of porting graphics::mesh over?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.