The goal of 0.1.1 is making to be able to making simple tower stacking game (Similar to this one (http://m.softgames.de/games/stack-tower).

TODO

• [x] Change name to "unrust"
• [x] Alpha sorting
• [x] GameObject hierarchy
• [x] Add Sponza scene example
• [x] Add DDS Support
• [x] Shadow map / (Hard and Soft)
• [x] Basic sound support (sub-crate)
• [x] Skybox
• [x] Added World module to improve usage : basic.rs
• [x] Remove [[bin]] and move the box demo to example
• [x] Setup CI
• [x] Drop naglebra and use cgmath instead.
• [x] Added #include support in uni_glsl

Next milestone

• [ ] Sky Light
  • We should decide how the 'standard material' works first to implement this.

The following items maybe fixed by switch to SDL2, which right now block by winit crate.

• [ ] Able to us resizable / fixed window ( unimplemented in winit for Windows and Macs )
• [ ] Able to toggle fullscreen ( unimplemented in winit for Windows and Macs )

> cargo run --release
opengl 3.3 (Core profile) Mesa 17.2.8
shading language 3.30
vendor VMWare, Inc.
[...]
thread 'main' panicked at 'GLError : vertex attrib pointer 1282 (invalid operation)', webgl/src/webgl_native.rs:17:13
[...]
6: webgl::webgl::<impl webgl::common::GLContext>::vertex_attrib_pointer

So it appears certain versions of opengl require a vertex array object to be able to call vertex_attrib_pointer. This seems to depends whether you're using compatibility (works without VAO) or core profile (requires VAO).

Adding a vao fixes the native version, but breaks the web version as VAO is only supported in webgl 2.0 : https://developer.mozilla.org/en-US/docs/Web/API/WebGLVertexArrayObject

I don't know if there's a common way to make it work for every version or if we need to branch code depending on the driver version.

I managed to make it work for both native and web version, but this relies on parsing the GetString(gl::VERSION) string, which is crappy...

Ok so this is the next step towards being able to do render-to-texture / post-processing effects. It makes it possible to create and bind a framebuffer with an empty texture.

This PR is mainly to discuss how to enable the framebuffer/texture bind using framebuffer_texture2d. Right now I added a with_framebuffer bool to Texture.bind. I'm not sure that's great.

This still doesn't break unigame's demo and actually allow to render in a 1024x1024 texture as seen here (texture grabbed with RenderDoc) : https://i.imgur.com/8w4DACX.jpg For some reason, depth test is not enabled. I have to check why. This also stresses the fact that face culling is not currently enabled in the engine.

The next step has more impact on the engine since it should be able to render a screen covering quad using this texture and some fx shader. Not sure yet how to integrate this with the existing game objects / ECS pattern.

This is a basic implementation of native gamepad support using gilrs. But so far, it doesn't work on windows 10. I tried with two different gamepads, including one official XBOX360 gamepad. The gamepad is detected but the state is not updated. To be investigated.

You can use this pull request to test the Mac port using the basic example.

It is related to commit https://github.com/edwin0cheng/unrust/commit/726e14f3080c61427652aeea87c61bf0604fef62

It seem like the keyboard not only keyboard layout dependents, and it is OS depenents: https://www.berrange.com/posts/2010/07/04/a-summary-of-scan-code-key-codes-sets-used-in-the-pc-virtualization-stack/

Maybe we should use integer from upstream library instead of remapping it ?

@jice-nospam

This is a first draft for feedback. I didn't implement stop_sound and unload_sound yet. And for now it's only working on native side because I haven't found an easy way to integrate the wavefile loader with unrust asset database system. We'll probably have to fork wavefile for that.

The main API is SoundSystem. It's available at world.sound. It provides the user methods (load_sound, play_sound). Check the new sound example for a usage example.

The Generator is the sound dedicated thread. SoundSystem communicate with it through SoundEvents. It contains the samples cache and CHANNEL_COUNT (4) stereo channels.

The channels can play a mono or stereo buffer, do panning and dynamic resampling if the buffer sample rate it not equal to the driver sample rate. It's better and faster to use samples that use the same rate as the driver.

This is a basic system, as planed for 0.1.1. Not sure you want to keep it further. It would be better to find a robust sound library but until then, it can do the job.

I also set wasm32-unknown-unknown as default web target so you just have to 'cargo web start'. Also I'm displaying the opengl error type in check_gl_error.

This is merely a test pull request to see if you're accepting them or if you'd rather walk alone for now.

Things I'd like to work on :

• better separation of the game and the engine, having the engine in a separate crate
• better support of some specific opengl versions (for example some 3.x versions require a vertex array object)

Ok this is a bit involved and should be considered a first draft. It only covers the lower uni-snd layer and not its integration into the unrust engine. I hacked a sound example to demonstrate how to use the uni-snd library, not how to properly integrate it in unrust.

There's a SoundDriver that has a very different behavior in native and web.

On the native side, it starts a detached thread and sends data to the audio interface, pulling it from the provided SoundGenerator.next_value function. Since the SoundGenerator is owned by the thread, you cannot keep a reference and call methods on it. instead, you have to use the SoundDriver.send_event method to send messages through a channel.

On the web side, the frame function should be called every frame so that it keeps the audio buffer filled.

Right now, stereo mode is hardcoded and the sound generator should alternatively provide the left and right channels values.

Shouldn't we use directly the tuples MaterialParam::VecN instead of going through a na::VectorN ? (to avoid creating temporary objects and be lighter on garbage collector for the web version)

I started using the lower crates (webgl, uni-app, uni-glsl) for another project. Do you think they're stable enough to be moved to independant projects like unrust/webgl, unrust/uni-app and unrust/uni-glsl ? This makes it possible to reference them directly in the Cargo.toml through git URLs instead of having to clone the whole unrust project.

• possibility to hide mouse cursor with uni-app::AppConfig.show_cursor=false

• uni-app::AppEvent::MousePos event

• added webgl::uniform_1fv

They work fine on native. Can't test the web part right now as wasm target is broken on nightly

If you try to use newer stdweb, running the example gives errors of the form:

LinkError: import object field '__js_uniform4vf' is not a Function

You can avoid the problem by adding = in the Cargo.toml of uni-pad:

stdweb =  "=0.4.8"

It seems there is no problem with stdweb 0.4.10 but stdweb 0.4.11 is broken.

In newer rustcs you get the following error:

error[E0034]: multiple applicable items in scope
   --> -6a12abe767e4c76b/downcast-0.9.2/src/lib.rs:120:38
    |
120 |     fn is_type(&self) -> bool { self.type_id() == TypeId::of::<T>() }
    |                                      ^^^^^^^ multiple `type_id` found
    |
note: candidate #1 is defined in the trait `Any`
   --> -6a12abe767e4c76b/downcast-0.9.2/src/lib.rs:29:5
    |
29  |     fn type_id(&self) -> TypeId { TypeId::of::<Self>() }
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    = help: to disambiguate the method call, write `Any::type_id(&self)` instead
note: candidate #2 is defined in the trait `std::any::Any`
    = help: to disambiguate the method call, write `std::any::Any::type_id(&self)` instead

Upgrading nphysics3d to at least 0.10 would fix the issue (newest is 0.11).

Currently the asset loading mechanism is a bit messy, i would like to refactor it to use Warmy. However, Warmy currently do not support async-loading, this issue is for tracking its progress :

Related: https://github.com/phaazon/warmy/issues/15

This is an exploratory issue. wasm-bindgen is making great progress and might be much faster than stdweb for passing data between Rust and js. That might be very interesting, especially for opengl buffers. https://hacks.mozilla.org/2018/04/javascript-to-rust-and-back-again-a-wasm-bindgen-tale/

Maybe we could start investigating wasm-bindgen on some lower module, like uni_pad or uni_snd

Goal

Standard Material

• [ ] Decide how the standard material and render pipelines works
• [ ] Sky Light

Engine Refactoring

• [ ] Change Component from Rc<RefCell> to Rc<T:Clone> which allow us to use Rc::make_mut instead of borrow_mut()
• [ ] Add TextRenderer for support bitmap and truetype font (maybe by RustType?)
• [ ] Able to us resizable / fixed window
• [ ] Able to toggle fullscreen

File Structures

• [ ] Use workspace instead of virtual crate
• [ ] Find a way to allow end-user to use the engine with standard assets

Assets

• [ ] gltf support

Unrust-Editor Basic

... TBD