- Notifications
You must be signed in to change notification settings - Fork31
An alternative ggez implementation on top of miniquad.
License
ggez/good-web-game
Folders and files
| Name | Name | Last commit message | Last commit date | |
|---|---|---|---|---|
Repository files navigation
good-web-game is a wasm32-unknown-unknown implementation of aggez subset on top ofminiquad. Originally built to runZemeroth 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 atmacroquad.
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, itshould work though.
"good-web-game" implements most of the ggez 0.7.0 API.
- boilerplate code differs slightly,as shown here
- audio API differs somewhat due to use of
quad-sndinstead ofrodiofor 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, seethe
shaderexample
- 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_asynceverywhere though
- loading files asynchronously is possible through
- 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
gilrsdepends on wasm-bindgen)
Running Zemeroth:https://not-fl3.github.io/miniquad-samples/zemeroth.html
You can also check outastroblasto running on the web (source).
To build and run an example as a native binary:
cargo run --example astroblastorustup target add wasm32-unknown-unknowncargo build --example astroblasto --target wasm32-unknown-unknownAnd then use the following .html to load .wasm:
index.html
<htmllang="en"><head><metacharset="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><canvasid="glcanvas"tabindex='1'></canvas><!-- For now this is just the same js glue macroquad uses: https://github.com/not-fl3/macroquad/tree/master/js --><scriptsrc="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-serverbasic-http-server .Recommended way to build for android is using Docker.
miniquad uses a slightly modifed version ofcargo-apk
docker run --rm -v (your project folder):/root/src -w /root/src notfl3/cargo-apk cargo quad-apk build --example astroblastoAPK file will be intarget/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 example03_drawing.rs) won't install correctly. You need to remove the leading numbers:drawing.rs
See miniquad iOSsample project.
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 inConf" * "your OS scaling factor".
To avoid this setConf::high_dpi totrue. 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 inConf, but that's not directly supported by miniquad currently.
Here is howgood-web-game fits into your rust-based game:
About
An alternative ggez implementation on top of miniquad.