r g b a

While making the taquin, I saw that there was no transparency on png textures.

It's needed for bitmap fonts

The tetris should have this following features:

• Have only one image and each shape type has 1 tile
• playable as a classic tetris
• Be pausable with ESC
• Display the next piece in the ui
• Display the score in the ui
• Have a death condition. No retry etc... button are for another milestone

Today, ECS is like a 'magic' word for games, game libs and game engine. But ECS is not and must not be considered as an universal answer to multiple questions.

I believe that ECS has its strength and its weaknesses. The choice of it here is made because the main target game of this lib is to be able to make a complex city building game.

I need to explain this somewhere on the project.

The goal of this feature is to provide users a way to easily have a list of timers without always needing to stock it in systems or game layers.

It will also later be used internally to handle animations timing.

This is personal preference.

Currently, using Scion::app() will try to read Scion.toml at the exe root.
The goal is to replace this behaviour by a scion.json.

Currently, we also have two ways to enter the Scion app (scion::appand scion::app_with_config). I need to also be able to give a custom path to the config as I don't want to be too restrictive on the project hierarchy.

Add a Scion::app_from_path(path: Path)

Also provide a way to give a custom path for the main config file

The main idea is to provide a solid logging implementation based upon the log crate. These are the main concepts :

• Configurable logging output
• Colored

I would like to have an issue pattern for the project.

Something simple like :

Bug or feature

Description
How to reproduce (if it's a bug)

There are two places where we filter the rendering according to the fact that there is a camera.

https://github.com/grzi/scion/blob/main/src/core/resources/time.rs#L175

and

https://github.com/grzi/scion/blob/main/src/rendering/bidimensional/scion2d.rs#L59

Both are called each time, so the message is not needed on both. So let's add one on the place it fits the most

So, I kinda want to have something cool to show on the main page of Scion about the architecture of the project.

A diagram made with draw.io should do the trick.

Well inspired by the idea I've used on another engine I set Scion.toml. But as of today, I kinda think we could want to create the app with a config that come from the code. So we need to add this to the Scion app.

Goal :

Ba able to call Scion::app_with_config(config)

Good commit messages are :

• feat: xxx
• fix: xxx
• doc: xxx
• chore: xxx

Create a window config and use it in the main scion config to configure the miniquad window

We need default arrows inputs to be able to do basic controls

Why this choice ?

The goal of this tiny engine is to be a minimalist 2D engine. Going with Miniquad seemed the right way for this, but I have some problem (not with miniquad, it's a really good lib !), about what I want to achieve with this project, and what Miniquad gives to me.

Minimalist doesn't mean old

Miniquad is based on old version of everything. First, it's on openGL. openGL will still be a good thing for a couple of years but it's dying. At this time, to be able to deploy everywhere, you need to stick to openGL version 100. That's ES 1.0 from 2003. And we're in 2021.

My learning time is limited. I think the best investment for me as I want something durable, is to learn either about WGSL or SPIR-V. As of today, the main lib providing a multi platform way around this is wgpu-rs. It's based on WGSL (or it's moving to WGSL at least). So, I'll stick to this choice.

OpenGL is dying

OpenGL is not something to build new engines on, on a long term. It stills has some time left as written before, but I'm pretty sure it won't attract people.

lib dependencies vs WASM

Yeah, this engine uses legion for the ECS part. And clearly, it's not compatible with the WASM pipeline provided by Miniquad (because of transitive wasm-bindgen).

Problem : Now we have 70 dependencies, tomorrow we'll have like .. 200 :(

Currently, we can only give a TexturedVertex to a component. It should be changed

It's the first text rendering I have to do.

In my knowledges there are two main types of text rendering : bitmap and free type.

Bitmap are just texture with uv map, so no font size for the text since it's just the one you gave.
It's a easier pipeline to create and also a lightest. As for now, the tetris will be on a fixed size, It's okay if I go with this

Later, when I'll do complex UI, I surely will add free type rendering, but until then, I'll just do a simple bitmap.

Create an internal Messaging Systems that allow :

• Concurrency (multi consumers, multi producers): This is needed because we don't want to duplicate the events.
• Topics: One topic is dedicated to one event type.
• Bounds : Optionally set a limit per topic. Convenience to be able to have a limited in memory size for the topics.
• Pull based consumers: Consumers call the topic to get the new events using an offset. Each consumer has a pull size limit to know the maximum event it can pull in one call
• Pausable: When pausing the game, switching layers, some topics may want to stop receiving && accept pull request from consumers

That's all, then we use it to track event in the game engine and allow users to create topics, producers, consumers with either convenience functions or macros.

So the concept is easy. Draw a simple colored triangle on the window. Not the final feature, but will be the first step in the rendering process with Miniquad

We need a sprite with 8 colored bloc, one for each shape in tetris and one for the borders

We also need a ui mask to set on top of everything

This is an effort to provide a way to create Layers in the game engine that connects with the main game loop.

A game should be considered as a pile of layers.
Layers are always executed from the top of the pile (LIFO).

A layer can either be Weak or Strong:

• Weak : Does not stop the next layer execution
• Strong : Stops the next layer execution (Useful for pause)

A layer is a Trait that needs to have this list of function :

• start
• stop
• fixed_update
• update
• late_update
• on_enable
• on_disable

In the scion data, each added state must be flagged as enabled/disabled or be totally removed from the pile.

Creates a new default resource that simply keeps track of the main windows dimensions.

Create a simple file loader that takes a file and load it in memory to bytes.

This will be used internally but should be accessible to the end user.

Some sources to understand why and what and how :

https://learnopengl.com/Getting-started/Camera
https://sotrh.github.io/learn-wgpu/beginner/tutorial6-uniforms/#uniform-buffers-and-bind-groups

The goal is to create a resource that will consistently update the mouse position to know every time where it is.

Every component has its own vertex buffer descriptor and indexes buffer descriptor

As you can see in https://github.com/grzi/scion/blob/main/src/core/components/ui/ui_image.rs

The problem is that due to a lot of copy paste, we now have wrong label for all of the renderable components.
We need to change the name of the buffers to reflect the real object beeing created

For this issue, let's find all Renderable component and clean the labels of each one.

Even if for now only one renderer is planned, I would like to make it so it's possible to give a renderer from the app config.

So in the future, I'll be able to give a custom renderer or choose between the internal ones

The goal is to provide a way to store, access player settings during && between different sessions.

The purpose is not to store game saves. It should be used only to store settings (windows, langage, in game volume etc...)

Actually, the only way to create a pausable system is to specify in each pausable system something like

if myresource.myvalue != 'the value that set it to pause' {
execute the code
}

I want a more convenient way to do this.

I may take the side of do something like this :
By default, I add something like ScionState that will keep a track of what the last state on the pile is.
I also want this state to have an easy way to store basic bool for the user if he wants to.

Then, I'll be able do to something like this :

Scion::app()
           .with_pausable_system(my_system(), |scion_state| scion_state.top_state != 'Pause');

BECAUSE 1 MACOS MIN = 10 MIN Grrr

So it's time to decide what path I want to take next.

0.0.1 was a proof of concept to make the lib work and decide whether or not I should continue. I'm kinda proud of the result.

Back in 2020 I made a tetris like game with Amethyst engine. So I have a working tetris source code.

Going for tetris is a good path as it's a standard in the learning process of beeing an hobbyist game dev. It will also be a nice exemple for potential users.

what do I need ?

• Basic UI (Render text and images on top of everything)
• Sprite material
• Keyboard inputs
• Pausable systems

/usr/bin/ld: cannot find -lGL
/usr/bin/ld: cannot find -lXi

On the doc it's written :

apt install libx11-dev libxi-dev libgl1-mesa-dev

Check the after this to be sure it's ok

Here : https://github.com/grzi/scion/blob/main/src/core/components/shapes/square.rs#L20

The origin should be deleted and 0. 0. should be used instead.
It's the Transform's job to set the position.

Beware, may have an impact on the Taquin example (or maynot, but in every case should be tested)

This should only render images under or on top of everything else.

This means to handle transparency.

Actually, there is no way to add / remove a layer once the game is started.
This is needed to be able to add for example a pause layer.

This issue to plan the Tiles support in the future