Optimizations + Notris Example

Optimizations

FindChildOfType() is a nice method, but it's pretty slow when you're getting the same child over and over again. Objects now keep track of the first Transform, Rigidbody, and Collider they're given which can be retrieved with GetTransform(), GetRigidbody(), and GetCollider(). This speeds up drawing and physics immensely.

Bug fixes

Certain callback methods (OnStart and OnActivate, for example) could be called out of order (if the object started deactivated, for example). This has been corrected

Notris

I've created a new example to showcase GameStates better - Notris.

Attached files

All precompiled libraries were built with g++ (MinGW.org GCC-6.3.0-1) 6.3.0. If your compiler doesn't support cross compilation with this compiler, you can build your own libraries from the attached source code.

• libAspen.a
  • Release build of the engine
  • Do not use with libAspendbg.a
• libAspendbg.a
  • Debug build of the engine
  • Do not use with libAspen.a
• libimgui.a
  • Precompiled ImGui + ImGui_SDL library in release mode
  • For license, see attached ImGui.ImGui_SDL.License.txt
• Example-Notris.zip
  • Tetris-inspired example showcasing the engine's features.
  • Extract and run Notris.exe to try it.
  • Extract and open main.cpp for the source code.

Callback Reorder

Quick fix: Aspen::Object::Object::OnActivate() would be called before Aspen::Object::Object::OnStart() if the object started deactivated. See the minor version's release for more info on v0.1: https://github.com/BtheDestroyer/Aspen/releases/tag/v0.1

Initial Release

V0.1 - Welcome, Aspen

So I've been working on this for about a month and while it's nowhere near perfect, I think it's at a point that I'm comfortable releasing an initial version. Let's go through all the features:

Full Wiki

Doxygen based wiki is available here. If you have any questions as to how something works, check there first - everything is documented. I plan on adding a tutorial later, but I want to add a bit more first.

Audio

Based on SDL_Mixer, I've made an audio manager that can play sound effects and music. I've added a bit of functionality over raw SDL_Mixer such as determining if a specific sound effect or music object is playing.

Here's the wiki page

Graphics

To start, I just have SDL as a backend, but I would love to add other alternatives like OpenGL, DX, Vulcan, etc. You can create a static sprite or animation using multiple sprites and/or uniform spritesheets (although I also plan on adding dynamic spritesheets).

Here's the wiki page

Debugging

Minimal debugging is currently available via the Log class and Debug class.

Log class

Allows for easy, well, logging - both to the console and a file. Aspen includes four available default Logs for different information levels that can be turned on and off via a boolean: Debug, Info, Warning, and Error.

Logs can be created with a standard prefix and suffix and then written to as a functor:

Aspen::Log::Log myLog("prefix: ", " :D");
myLog("Hello world!"); // Prints: [0000] prefix: Hello world! :D

Here's the wiki page

Debug class

Acts as a wrapper for ImGui and ImGui_SDL. If you don't want to deal with compiling those two libraries yourself, thanks to their use of the MIT license, I'm able to include a precompiled, statically linked library below (it's also generated if you use the Makefile included with Aspen).

Now, as for the Debug class: currently, it's only being used to display a tree of all objects (belonging to the same root). If you middle click any object (with a collider), then it'll even shrink everything currently open and expand the object you just clicked on so you can find it easily.

Here's the wiki page

GameStates

In engines like Unity, GameMaker, or Clickteam Fusion, GameStates are just data files that are effectively meaningless without the engine. In Aspen, GameStates are just classes that inherit the base GameState class written in standard C++. There are some pros and cons to this:

• Pros:
  • You can modify your GameStates to work with another C++ engine.
  • It's much harder to decompile raw C++ to modify it without the source code.
  • You can modify the source code of your GameStates to work exactly how you want.
• Cons:
  • You have to stick to C++.
  • Some people have a hard time working with raw code and would prefer a visual editor.

I do plan on making an editor in the future, but that'll be a while from now at the earliest. It's quite an undertaking to make data-based editor, let alone one that spits out C++ code, so I'm not making any promises.

For an example of how to create your own GameState, check out the attached Example.zip

Here's the wiki page

Objects

I've been kind of skirting around it, but since it's now relevant I'll talk about how Objects work in Aspen.

Practically everything in Aspen inherits Object for a couple of reasons:

1. It affords a parent/child ownership tree structure.
2. It affords a user-friendly callback system.

I've partially lifted the callback system from my experience working with Unity's C# MonoScripts. For a full list, check the wiki page for anything called "On*****", but the most important ones are OnStart(), OnUpdate(), and OnEnd() which are called when an object is created, once every frame, and when an object is destroyed respectively.

For example, to make my player character I could do this:

class Player : public Aspen::Object::Object
{
public:
  Player(Object *parent = nullptr, std::string name = "Player") : Object(nullptr, name) {}

  void OnStart()
  {
    // Add animations as children for movement and idle
    // Add a player controller as a child
    // Add a Rigidbody as a child
    // Add a Transform as a child
  }

  void OnUpdate()
  {
    // Disable/Enable children animations depending on the player controller
  }
}

That's it - everything else will be taken care of for you once you once you add a Player to a GameState.

Here's the wiki page

Physics

Physics is all custom written, and because I'm not mainly a physics programmer, it's not amazing. That being said, it should work well enough for people who choose to stick with it.

Objects can have a Rigidbody child to be affected by physics (gravity, drag, velocity, etc.) and a Collider child to interact with other objects. I've created CircleColliders and AABBColliders, but due to how collision is tested and resolved, theoretically any other type of collider could be added.

Here's the wiki page

Time

Time is kept track of by the Time class. It tracks delta time, current time, when the program started, and the current FPS. It also lets you set a target framerate as a cap.

Here's the wiki page

Events

EventListeners take SDL events and respond to them. I'm planning on adding the ability to use this to send custom messages as well, but currently it's not implemented.

Here's the wiki page

Engine

Finally, the core engine. Engine should be the root object of all Aspen Object trees and owns the other controllers (Audio, Graphics, EventHandler, Time, etc.) as direct children. If you don't want to set it up, there's a list of START_FLAGS that can be passed to its constructor (or you can just use START_FLAGS::ALL to get everything).

Here's the wiki page

Compiling a project with Aspen

I've attached a MinGW build of Aspen below, but you can compile your own library with the source code to work with whatever compiler you prefer. You'll also have to compile with ImGui:

• ImGui
• ImGui_SDL

Here are the other prerequisites you'll need to install to compile a project with Aspen:

• SDL2 Development Libraries
• SDL2_image Development Libraries
• SDL2_ttf Development Libraries
• SDL_mixer Development Libraries

Finally, here's the command to compile your project with the attached precompiled libraries:

g++ [your .cpp source files] -lAspen -o[output name]