- Generated by
1.9.1
|
ASGE
3.2.0
Simple Game Framework in GL
|
Released 23/02/2022
Add debug texture support [8fdd8c2]
To help with debugging of sprites without an attached texture, this change automatically allocates a transparent debug texture to all newly constructed sprites. This prevents the renderer from crashing when a texture has not been attached to a sprite. It can also be used for rendering simple blocks of colours i.e. backdrops.
The texture is transparent and pink by default and scaled with the currently attached viewport.
Better GamePad support [6198eb6]
Updated the GamePad retrieval function to use GLFW's specific functions that allow buttons to be mapped correctly. As part of these changes the user is now able to load updated bindings using the input system and as a quality of life addition, a new version of getGamePad has been added that will return the first attached controller on the system.
MSDF Rendering [041436d], [45c952a], [e5076bd], [853ceed], [9c8259c]
Experimental support for SDF rendering based on the msdfgen library. Currently, when fonts are loaded an atlas texture is still generated, but instead of using the freetype library msdfgen is used to load the glyphs and generate MSDF's for them. At the moment the textures are able to load and are working, but there are still a number of areas for improvement. These include:
Upcoming versions of ASGE will aim to include caching and improved multi-threaded support for generating them. This will help remove the dependency on OpenMP.
Remove static GameSettings [9fd9b2b], [a85ff8f]
This is a fairly big change to the code-base due to the way game settings were being accessed throughout the engine. Instead, the data will be stored within objects where they are most relevant. This has led to most of them to be moved in to the Renderer, however, some have been placed in to the Game itself.
GameSettings were never really intended to be used like they were. Instead they're were designed to be a simple struct that a launcher could generate via a UI and then pass on to the constructor of the game. This brings it more in line with this original idea.
Render States [2651804]
These new render states keep track of changes to the viewport or the camera view. Now instead of flushing every time one of these changes a snapshot is taken. This snapshot is then associated with each quad that needs to be drawn via its batch number. Then when rendering the quad batch, the correct snapshot can be used or applied as needed.
This allows for users to change these settings when rendering and know that the state the renderer was in when the render request was made will still be correct when the batches are rendered.
More work needs to be done to better optimise these changes, especially in the sort method for the batch renderer as the aim would be to reduce the number of switches and batches required to draw the user requested scenes.
Rewrite of viewport and resolution scaling [963cfd3]
A particularly large re-write of the scaling and viewport code has taken place. A new Resolution data structure has been added. Its job is to store all the relevant resolution data such as window, desktop and game dimensions.
As part of this refactor/re-write and to help support correct window scaling the idea or concept of a design resolution has been included. This design resolution is known as the base resolution and can be thought of as the size of the game world. It is independent from pixel space.
Now when running the game in different resolutions the base resolution can be used to ensure scaling maintains the correct ratios, leaving objects to remain in their correct proportions and to be aligned correctly on this screen. Well, technically this depends on the new resolution policy that's also been added. If you prefer it is possible to "fit" the viewports to the window, but this will lead to scaling issues.
It's recommended to review the new Resolution class for more info and guidance on the available policies.The hope is that these changes now allow for flexible resizing of the game window, without the developer having to invest too much time and thought in to. Want it to scale and maintain its aspect ratio? Just set the policy to "maintain" and be done with it.
Texture attachment flags [59293f1]
These new flags are designed to control how a texture is attached to a sprite. Currently, when attaching a new texture to a sprite, it will automatically reset the width/height and UV coordinates set on the existing sprite. However, it may be desirable to have more granular control over this process. These new attach flags are an attempt to allow this to happen. They can be set to retain the sprites properties or to allow them to be reset depending on the developers preferences.
Add support for Tiles to the engine. Tiles are semantically different to sprites and thus are easier to convey using their own data structure. Unlike a sprite, they do not store any information regarding their positioning. When rendering tiles, the {X,Y} coordinates will need to be provided as tiles can be "rendered" within a larger context such as a map. The map will known each tile's {X,Y} and render them accordingly.
Released 18/11/2021
Released 17/11/2021
boundsY
Released 16/11/2021
Released 15/11/2021
Released 07/11/2021
Released 01/11/2021
Released 31/10/2021
Released 18/10/2021
Released 14/05/2021
Released 10/05/2021
Released 23/04/2021
Released 29/02/2020
Released 20/02/2019
Released 08/01/2019
Released 12/12/2018
Released 12/11/2018
Released 12/11/2018
Released 16/10/2018
Released 10/10/2018
Released 14/09/2018
Released 28/06/2018
Released 03/04/2018
Released 14/03/2018
Released 07/03/2018
Released 15/02/2018
Released 18/12/2017
Released 14/09/2018
1.9.1