Hi,

Im running macos high sierra 10.13.3.

I installed the dependencies like this

brew install sdl2 sdl2_image sdl2_mixer

But when I try to do on the example

cargo run --release

I get the following error

     Running `/Users/miguel/src/gate/target/release/example`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "OGG support not available"', libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Hi Matthew,

I hope this message finds you well. I found your Gate engine based on a tweet you sent out a while back, showing that platformer demo.

I've been digging through your code as a learning experience for myself, and I've really been liking how the whole thing's structured. I'm a big fan of Rust, and have been fiddling with WebAssembly in my spare time, so seeing a simple game engine in Rust that targets WebAssembly was something I was really interested in.

I decided to try my hand at using Gate to build a simple game of my own, but quickly ran into the issue that I wanted to use the mouse for input but there weren't any mouse events. I've added the mouse support on my own fork to see how it worked out. I know this is a bit out of the blue, but since I've done it now I thought I may as well offer the changes back in case you find them useful. I promise I won't take it personally if you completely restructure / reimplement / discard the stuff here.

In terms of design decisions, I refactored your keyboard event from two variables, KeyEvent and KeyCode which were passed around together, to an InputEvent enum. KeyPressed and KeyReleased are now InputEvents which contain a KeyCode. This is unfortunately a breaking change for client code, but was necessary to allow the MousePressed MouseReleased and MouseMotion events to have their own mousy data.

The other weird thing I had to do was involve the renderer in the input events. I'm admittedly a bit uncomfortable with this, but it was necessary to convert the x and y coordinates coming in from SDL / the browser from the coordinate system of the window to the coordinate system of the game. Only the renderer seemed to know the details of the window coordinates in order to do this transformation. The plus side is that by the time you get up to your game code, the mouse events have an x and y that are entirely in the game's internal coordinate system.

I'd love to hear your input and how you would have gone about this change.

Kind regards, Justin

When compiled to WebAssembly, the game does not seem to run in a Safari browser, at least on iPhone. The error message seems to indicate that Safari does not support Ogg Vorbis audio. More investigation is required. One possible solution might be to use mp3 audio as a backup if ogg is not supported.

@SergiusIW not sure where it's better to report this, but https links to luduminis.com don't work anymore, so links like https://arewegameyet.rs/games/puzzle/#pascal-penguin are broken.

I get a segmentation fault 11 on start:

Process: example [58930] Path: /Users/USER/Documents/*/example Identifier: example Version: 0 Code Type: X86-64 (Native) Parent Process: bash [53771] Responsible: example [58930] User ID: 501

Date/Time: 2020-03-22 19:41:42.810 -0700 OS Version: Mac OS X 10.14.6 (18G95) Report Version: 12 Bridge OS Version: 3.6 (16P6571) Anonymous UUID: 7E0E71B3-3DCD-A00A-8E9F-CFBF05A7AA12

Sleep/Wake UUID: DBCFD729-A209-4E91-8B21-9DBE88C30747

Time Awake Since Boot: 140000 seconds Time Since Wake: 32000 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000248 Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [58930]

VM Regions Near 0x248: --> __TEXT 000000010365c000-00000001036ea000 [ 568K] r-x/r-x SM=COW /Users/USER/Documents/*

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libGL.dylib 0x00007fff39fef841 glEnable + 15 1 example 0x000000010367a58a gl::Enable::h60d8f1ab17548bbd + 42 (bindings.rs:1869) 2 example 0x0000000103691097 gate::core::sdl::init_gl::h32763fb95a98fede + 39 (mod.rs:177) 3 example 0x000000010366b74d gate::core::sdl::run::h2f1c2b9bdbbef53b + 845 (mod.rs:82) 4 example 0x0000000103667f69 gate::run::hcfb4571876720453 + 121 (lib.rs:83) 5 example 0x000000010366acad example::main::h419b440b5ec65763 + 589 (main.rs:128) 6 example 0x0000000103668b82 std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h17c6fd08b627e158 + 18 (rt.rs:67) 7 example 0x00000001036b7578 std::panicking::try::do_call::hf2b35caddf59127c + 24 (panicking.rs:305) 8 example 0x00000001036b8fcb __rust_maybe_catch_panic + 27 (lib.rs:94) 9 example 0x00000001036b7e0e std::rt::lang_start_internal::h8e563903bf99e7c1 + 542 (rt.rs:51) 10 example 0x0000000103668b62 std::rt::lang_start::h19741c8b41a9a929 + 66 (rt.rs:67) 11 example 0x000000010366ad02 main + 34 12 libdyld.dylib 0x00007fff5cea83d5 start + 1

Thread 1: 0 libsystem_pthread.dylib 0x00007fff5d09b3f0 start_wqthread + 0

Thread 2: 0 libsystem_pthread.dylib 0x00007fff5d09b3f0 start_wqthread + 0

Thread 3: 0 libsystem_pthread.dylib 0x00007fff5d09b3f0 start_wqthread + 0

Thread 4: 0 libsystem_kernel.dylib 0x00007fff5cfdd27e semaphore_timedwait_trap + 10 1 libdispatch.dylib 0x00007fff5ce5bc99 _dispatch_sema4_timedwait + 76 2 libdispatch.dylib 0x00007fff5ce5c377 _dispatch_semaphore_wait_slow + 58 3 libdispatch.dylib 0x00007fff5ce691fd _dispatch_worker_thread + 317 4 libsystem_pthread.dylib 0x00007fff5d09c2eb _pthread_body + 126 5 libsystem_pthread.dylib 0x00007fff5d09f249 _pthread_start + 66 6 libsystem_pthread.dylib 0x00007fff5d09b40d thread_start + 13

Thread 5:: AudioQueue thread 0 libsystem_kernel.dylib 0x00007fff5cfdd22a mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff5cfdd76c mach_msg + 60 2 com.apple.CoreFoundation 0x00007fff30f2e1ee __CFRunLoopServiceMachPort + 328 3 com.apple.CoreFoundation 0x00007fff30f2d75c __CFRunLoopRun + 1612 4 com.apple.CoreFoundation 0x00007fff30f2cebe CFRunLoopRunSpecific + 455 5 org.libsdl.SDL2 0x0000000103896191 0x103858000 + 254353 6 org.libsdl.SDL2 0x000000010387237c 0x103858000 + 107388 7 org.libsdl.SDL2 0x000000010388d939 0x103858000 + 219449 8 libsystem_pthread.dylib 0x00007fff5d09c2eb _pthread_body + 126 9 libsystem_pthread.dylib 0x00007fff5d09f249 _pthread_start + 66 10 libsystem_pthread.dylib 0x00007fff5d09b40d thread_start + 13

Thread 6:: AQConverterThread 0 libsystem_kernel.dylib 0x00007fff5cfe086a __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff5d09f56e _pthread_cond_wait + 722 2 com.apple.audio.toolbox.AudioToolbox 0x00007fff2f85640a CAGuard::Wait() + 72 3 com.apple.audio.toolbox.AudioToolbox 0x00007fff2f8527b5 AQConverterManager::AQConverterThread::Run() + 375 4 com.apple.audio.toolbox.AudioToolbox 0x00007fff2f852633 AQConverterManager::AQConverterThread::ConverterThreadEntry(void*) + 9 5 com.apple.audio.toolbox.AudioToolbox 0x00007fff2f82f981 CAPThread::Entry(CAPThread*) + 77 6 libsystem_pthread.dylib 0x00007fff5d09c2eb _pthread_body + 126 7 libsystem_pthread.dylib 0x00007fff5d09f249 _pthread_start + 66 8 libsystem_pthread.dylib 0x00007fff5d09b40d thread_start + 13

Thread 7:: com.apple.audio.IOThread.client 0 libsystem_kernel.dylib 0x00007fff5cfdd22a mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff5cfdd76c mach_msg + 60 2 com.apple.audio.CoreAudio 0x00007fff3099deda HALB_MachPort::SendMessageWithReply(unsigned int, unsigned int, unsigned int, unsigned int, mach_msg_header_t*, bool, unsigned int) + 122 3 com.apple.audio.CoreAudio 0x00007fff3099de4f HALB_MachPort::SendSimpleMessageWithSimpleReply(unsigned int, unsigned int, int, int&, bool, unsigned int) + 45 4 com.apple.audio.CoreAudio 0x00007fff3099a39f HALC_ProxyIOContext::IOWorkLoop() + 1017 5 com.apple.audio.CoreAudio 0x00007fff30999df4 HALC_ProxyIOContext::IOThreadEntry(void*) + 122 6 com.apple.audio.CoreAudio 0x00007fff30999956 HALB_IOThread::Entry(void*) + 72 7 libsystem_pthread.dylib 0x00007fff5d09c2eb _pthread_body + 126 8 libsystem_pthread.dylib 0x00007fff5d09f249 _pthread_start + 66 9 libsystem_pthread.dylib 0x00007fff5d09b40d thread_start + 13

Thread 8:: SDLTimer 0 libsystem_kernel.dylib 0x00007fff5cfe086a __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff5d09f56e _pthread_cond_wait + 722 2 org.libsdl.SDL2 0x0000000103935bbe 0x103858000 + 908222 3 org.libsdl.SDL2 0x0000000103894f40 0x103858000 + 249664 4 org.libsdl.SDL2 0x000000010388e065 0x103858000 + 221285 5 org.libsdl.SDL2 0x000000010387237c 0x103858000 + 107388 6 org.libsdl.SDL2 0x000000010388d939 0x103858000 + 219449 7 libsystem_pthread.dylib 0x00007fff5d09c2eb _pthread_body + 126 8 libsystem_pthread.dylib 0x00007fff5d09f249 _pthread_start + 66 9 libsystem_pthread.dylib 0x00007fff5d09b40d thread_start + 13

Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000be2 rbx: 0x00007ffeec5a3290 rcx: 0x0000000000000000 rdx: 0x0000000000000001 rdi: 0x0000000000000be2 rsi: 0x00007f9d98600000 rbp: 0x00007ffeec5a28e0 rsp: 0x00007ffeec5a28e0 r8: 0x0000000000000001 r9: 0x00007f9d98627150 r10: 0x0000000000000002 r11: 0x0000000000000002 r12: 0x0000000103cf2000 r13: 0x0000000000000000 r14: 0x00007ffeec5a3288 r15: 0x00007ffeec5a3280 rip: 0x00007fff39fef841 rfl: 0x0000000000010206 cr2: 0x0000000000000248

Logical CPU: 2 Error Code: 0x00000004 Trap Number: 14

In this function you use the unsafe keyword for almost the entrie function body.

We need to mark unsafe operations more precisely using unsafe keyword. Keeping unsafe blocks small can bring many benefits. For example, when mistakes happen, we can locate any errors related to memory safety within an unsafe block. This is the balance between Safe and Unsafe Rust. The separation is designed to make using Safe Rust as ergonomic as possible, but requires extra effort and care when writing Unsafe Rust.

Hope this PR can help you. Best regards. References https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

This PR fixes the OpenGL texture binding not supported error on Windows 10. It does this by setting an SDL hint to use the opengles2 renderer.

Note: This error occurs both when running Chirperjax (See Chirperjax: Issue #2) and when running the gate example project.

The idea for the fix came from this post in the SDL forums:

I think it has something to do with the kind of video driver SDL2 is using behind the scenes. Ran into the same problem. However, on my Windows 10 when I specify…

SDL_SetHint(SDL_HINT_RENDER_DRIVER,"opengles2");

…before calling SDL_Init then binding the texture works, albeit with the RGB channels swapped. Also interesting, with and without the hint it answers it is using the windows driver when asked about (by calling SDL_GetCurrentVideoDriver).

The hint is only compiled in on Windows to avoid changing the renderer used on any other platform.

After updating from Rust 1.25 to Rust 1.26, I get a runtime exception with the wasm32-unknown-unknown target. Exported FFI functions are not being recognized properly, possibly a regression in Rust's WASM build. I am currently trying to isolate the issue.

Toolchain: stable-x86_64-unknown-linux-gnu (default) rustc 1.26.2 (594fb253c 2018-06-01)

Steps:

1. clone repo
2. cd example
3. cargo build --release --target wasm32-unknown-unknown
4. copy wasm file to example/html/
5. copy this howler.js to example/html/
6. basic-http-server .
7. Visit in chrome Version 81.0.4044.138 (Official Build) (64-bit)

Get this error:

Error
An exception was thrown: CompileError: WebAssembly.instantiate(): expected magic word 00 61 73 6d, found 3c 21 44 4f @+0

It compiles fine, but when I do cargo run, I get the error thread 'main' panicked at 'OpenGL texture binding not supported'

I got the same issue running the game Chirperjax :)

I'm using

• rustc 1.44.0 (49cae5576 2020-06-01)
• Windows 10
• Radeon RX 580 graphics card
• SDL2 2.0.12-VC

Stacktrace:

> cargo run
   Compiling example v0.1.0 (C:\Users\user\Documents\code\gate\example)
    Finished dev [unoptimized + debuginfo] target(s) in 0.85s
     Running `C:\Users\user\Documents\code\gate\target\debug\example.exe`
thread 'main' panicked at 'OpenGL texture binding not supported', C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\sdl2-0.29.1\src/sdl2\render.rs:1500:13
stack backtrace:
   0: backtrace::backtrace::trace_unsynchronized
             at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.46\src\backtrace\mod.rs:66
   1: std::sys_common::backtrace::_print_fmt
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd\sys_common\backtrace.rs:78
   2: std::sys_common::backtrace::_print::{{impl}}::fmt
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd\sys_common\backtrace.rs:59
   3: core::fmt::write
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libcore\fmt\mod.rs:1069
   4: std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd\io\mod.rs:1504
   5: std::sys_common::backtrace::_print
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd\sys_common\backtrace.rs:62
   6: std::sys_common::backtrace::print
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd\sys_common\backtrace.rs:49
   7: std::panicking::default_hook::{{closure}}
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd\panicking.rs:198
   8: std::panicking::default_hook
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd\panicking.rs:218
   9: std::panicking::rust_panic_with_hook
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd\panicking.rs:511
  10: std::panicking::begin_panic<str*>
             at C:\Users\user\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libstd\panicking.rs:438
  11: sdl2::render::Texture::gl_bind_texture
             at C:\Users\user\.cargo\registry\src\github.com-1ecc6299db9ec823\sdl2-0.29.1\src\sdl2\render.rs:1500
  12: gate::core::sdl::build_renderer<example::asset_id::AssetId>
             at C:\Users\user\Documents\code\gate\gate\src\core\sdl\mod.rs:137
  13: gate::core::sdl::run<example::asset_id::AssetId,example::TowerGame>
             at C:\Users\user\Documents\code\gate\gate\src\core\sdl\mod.rs:82
  14: gate::run<example::asset_id::AssetId,example::TowerGame>
             at C:\Users\user\Documents\code\gate\gate\src\lib.rs:82
  15: example::main
             at .\src\main.rs:127
  16: std::rt::lang_start::{{closure}}<()>
             at C:\Users\user\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libstd\rt.rs:67
  17: std::rt::lang_start_internal::{{closure}}
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd\rt.rs:52
  18: std::panicking::try::do_call
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd\panicking.rs:331
  19: std::panicking::try
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd\panicking.rs:274
  20: std::panic::catch_unwind
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd\panic.rs:394
  21: std::rt::lang_start_internal
             at /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd\rt.rs:51
  22: std::rt::lang_start<()>
             at C:\Users\user\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libstd\rt.rs:67
  23: main
  24: invoke_main
             at d:\A01\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  25: __scrt_common_main_seh
             at d:\A01\_work\6\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  26: BaseThreadInitThunk
  27: RtlUserThreadStart
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: process didn't exit successfully: `C:\Users\user\Documents\code\gate\target\debug\example.exe` (exit code: 101)

In gate_build atlas.rs there is an upper limit for the Sprite Atlas size of 512x512

line 28: const MAX_DIM: u32 = 512;

Is there any harm for me to manually increase this const to something larger?

Thank you, and very nice library!

When compiled to WebAssembly, there is a graphical glitch when rendering on certain devices: portions of textures that are transparent are being rendered as a solid color, usually white. The glitch has been reported on certain Pixel 2 and Pixel 3 phones, but may also affect other devices. This is almost certainly an issue with the WebGL setup being used in Gate.

Potentially relevant files:

• https://github.com/SergiusIW/gate/blob/master/gate_build/src/html/index.html
• https://github.com/SergiusIW/gate/blob/master/gate_build/src/html/gate.js
• https://github.com/SergiusIW/gate/blob/master/gate/src/renderer/shaders/sprite.frag
• https://github.com/SergiusIW/gate/blob/master/gate/src/renderer/shaders/sprite.vert