We need to get up and running on clang-format based on our current code style. Some stuff keeps passing in PRs when it shouldn't and really it'd be great to automate this with clang-format.

This is a minor tweak for the FPS counter.

Currently the colour is hard coded, but @tannergooding has pointed out in PR #34 that it will make it hard to read in certain circumstances.

This feature should eliminate this problem.

In a recent PR by @Nihlus (that I lazily merged after seeing someone else say LGTM), a set of sanitisation flags were added that work for older versions of GCC but not for anything newer than GCC 8 as far as I know. They are also incompatible with clang. Due to my mistake (and the fact I really don't have time to test GCC extensively right now) I have amended the offending flags for clang as that's our first and foremost priority in terms of compiler support, although its not in master yet. Once it is this ticket can be worked on.

This ticket is free for anyone to pick up should they wish to do so.

There are a few moments that I would like to resolve before continuing to wrap core api in C. Should we build the library as static or dynamic? And do we only provide C api for consuming or C++ as well?

As per #73 I have introduced the groundwork for supporting multiple camera view/projection view types.

Its a bit messy and needs cleaning up, but once its done we can look into this in further detail for Novel3D probably, I can't see them getting too much use out of it in the current state of the engine.

We can either remove it or try to implement it however I'm a bit "on the fence" about it, and would like other people's opinions.

Currently, the header files are declaring fields at the bottom of the class (which I believe is "standard" C++ practice).

This frequently leads to code like:

class MyClass {
public:
    inline int getValue() const;

private:
    int _value;
};

inline int MyClass::getValue() const {
    return _value;
}

Reordering these such that fields are at the top could simplify this greatly:

class MyClass {
private:
    int _value;
public:
    inline int getValue() const {
        return _value;
    }
};

As the title suggests, I think it would be good to add a configurable texture type that houses all the relevant texture information as part of #56 .

This is primarily to allow us to create texture-coordinate-based effects amongst other things while also aiding with the instancing ticket.

It would also bring us more in-line with engines such as Unity3D that support this sort of behaviour out of the box.

Thoughts?

Title.

Currently our approach to loading the same normalised data (upcoming in a WIP feature branch) is not that efficient. We need to instance the data onto the GPU ideally.

As discussed on Discord, a basic implementation would look like this:

• You track a scene graph
• Interactions can trigger events
• External services (like a timer) can trigger events

This would be part of a central eventing API, as well as to avoid scenarios as below -

As referenced in the basic audio PR:

There is a subtle, but non obvious bug here that deals with floating-point values and timestamps in general. Namely around Frequency being significantly larger than the TicksPerSecond, which you've defined to be 1000. For example, on my box, Frequency is 10'000'000, which means that this has a risk of producing a really tiny result and incurring rounding error.

Originally posted by @tannergooding in #33

There has been many discussions about LLAPI supporting a variety of games.

To that end, I am wondering if we should provide physics support via Box2D or Bullet.

It would only be LLAPI though, as I have no intention of supporting physics in the HLAPI due to the nature of said HLAPI.

Thoughts?

Currently, the text rendering PR introduces an intermittent bug where the rendering of textures (i.e. Novel-Chan in this case) fails. So far, it's only reproducing in LInux (specifically Ubuntu atm).

We need a way to simplify calculating the positions of objects relative to other key points in the window. Specifically things such as the world space margins and probably other objects - essentially kind of like a "local space". It would mean yet another plane of space but it would resolve LLAPI positioning concerns raised by @tannergooding and it is something I was considering adding for the HLAPI anyway, so how we go about this is open for debate.

Title, mostly, but this is basically a ticket for supporting a perspective counterpart to the orthographic factory method effectively. Not urgent, but definitely on the TODO.

Title.

The reason why is because in the future the public facing API will be flexible on these objects and all NovelRenderObjects require these things to function as per the UBO changes (which have yet to be merged).

As per a previous discussion with @tannergooding , the code style is being modified to not use the const modifier in places where pointers and references are not being used. Its a simple task however we have it in many locations right now, so may take a little while to actually fully do.

As it stands, each text rect will load a font at a specified size irrespective if that font is already loaded in, even if it is the same size.

The proposal is to add some form of API to accommodate shared font loading between the text rects. This will probably involve abstracting font loading logic into a new type (name to be announced.

This will be coming relatively shortly and is something I will implement myself.

When the engine starts, window size auto-adjusts to main screen size whilst not adjusting correctly to the resolution.

Expected to correctly display at screen resolution or Window size to be limited to display resolution.

Window size adjusts to 32:9 aspect ratio without the display adjusting to 3840 x 1080 resolution.

To reproduce, run project on 32:9 monitor at 3840 x 1080 resolution. Testing on other monitor resolutions advised.

We should probably think about proper logging for the runtime, as logging is incredibly important for projects of any size

AB#3

After discussion, the current implementation of the Audio Service does not meet the original specification as discussed/designed.

What was sought was for is a three-part system:

AudioService -> AudioChannel -> AudioSource

The Service would handle creation of channels, and the channel would handle creation of sources/files. This would also allow for manipulation of the channel as a whole, as well as channel grouping.

This will need to be done as well to help support additional Audio back-ends (i.e. XAudio, OpenAL-Soft) in the future.

Currently, we are checking against constants or magic numbers, especially when dealing with SDL-based calls. These should get wrapped in a helper method so that if they fail, we can handle them appropriately with logging.

As referenced in basic audio PR:

SDL_SUCCESS in particular seems like something that could be solved by a helper method. Namely something like ThrowIfFailed(MyFunc(args), "Error Message")

This would then check for success, log the error, and throw an exception.

Originally posted by @tannergooding in #33

As called out on #34 (comment), the StepTimer can technically bug out if the hardware timer frequency is greater than the TicksPerSecond.

This is problematic because the math is using integer arithmetic and follows (counterDelta * TicksPerSecond) / _frequency, so if _frequency > TicksPerSecond you can end up getting "zero" as the tick delta.

A solution should be devised that takes this into account so that users still get the appropriate updates.

As per a discussion on PR #34 started by @tannergooding the CMake's source file handling is becoming a little unwieldy and unreadable. After the discussion the proposed solution is to do the following:

set (NOVELRT_SOURCES
 a.cpp
 b.cpp
 c.cpp
)

set (NOVELRT_HEADERS
  a.h
  b.h
  c.h
)

Followed by:

add_executable(NovelRT ${NOVELRT_SOURCES} ${NOVELRT_HEADERS})

This should help make it more readable.

As per the title, we need a header file that includes all the other header files for end users to hook into.

Why?

TL;DR

• Low-entry for users who aren't familiar with coding
• Better overview of branching dialogue
• Can allow for a more cohesive UX*

Many games that contain a more complicated dialogue system use some kind of node-editor to visualize and editor dialogue.

Articy craft is a good example of a professional tool designed exactly for that. Used by Ubisoft, CD Projekt Red, EA, and many other professional studios.

This is how Articy Craft visualizes a dialogue. By using a node-editor and icons it makes it very intuitive for a user to create and edit dialogues.

A simpler version of this could look something like this:

*= The reason why this can allow for better UX is that you can allow the user to edit other data by selecting items/buttons inside of the node. An example would be the avatar. You could have a small edit button, double-tap, etc. to open up a window to change that character's data.

How?

It's completely up to the team on how to go about implementing something like this but I would like to pitch in my two cents on this.
It's important to avoid dependencies and keep editor code completely separate.
So I think ideally you would want to generate API code (Lua,Ink,etc.) using the node-editor.
The editor could even be a separate application by all means whilst generating scripts.
Really depends on how exactly you want things to work in tandem.

In order to set up multi-threading as well as making it easier to develop future services, we should break NovelRunner apart, allowing NovelRT to have the following setup:

-- Application (Singleton, Exposes Services)
-- Various Services
-- Dispatcher (Per Thread, Runs the Event Pump)

Currently, NovelRunner does both of what the "Application" and the "Dispatcher" would do, and is not currently a singleton. This can pose many problems, as theoretically end users can create as many runners as they want, which would multiply the number of services per runner.

The suggested method of doing this, as per @tannergooding's comments in Discord, would be to:

• Rename Runner to Application
  • It exposes a static getCurrent() method so anyone can retrieve services, etc
• Break out the event loop logic into some kind of Dispatcher (or Runner) class
  • This allows you to queue/dispatch pending events
  • This is "per thread" and are created lazily

This would be a larger refactoring job, and may need to wait until other PRs are merged (logging, UBO, etc).

This type will purely exist to abstract OpenGL/DX/Vulkan from the engine core as shaders are now becoming more frequently passed around.

I'm unsure if this is even beneficial for us at this point but I've recently discovered GLM exists.

GLM is the official OpenGL maths library

Any thoughts on whether we should refactor to use it? Its probably faster than our own implementation but it may hurt our support for DX and Vulkan in the future.

For NovelAudioService::load()

It would be good if you gave back some kind of "opaque handle" that could be used instead of the file name. Basically just something that, for an already loaded sound, can be used to play a sound with O(1) (or really cheap) lookup.

For the overload that takes a name, you would effectively just have

auto soundHandle = loadSound(soundName);
playSound(soundHandle);

Originally posted by @tannergooding in #33

As per a discussion on #98 pointed out, our extensibility is a bit limited in certain places at the moment. To rectify this, it has been proposed we make a new TextureRect type that things such as ImageRect and, in the future, TextRect can inherit from.

This sould provide better granularity and customisation options for developers.

Due to how I've implemented the UBO changes as per #73 some janky code has crept in.

We need to reorganise this so its less terrible.

As per the most recent PR (#75 ) for our CI/CD pipeline, Doxygen isn't actually working when used in our CI/CD setup currently.

We need to figure out how we get this functional and then figure out how to package it up SDK in the future.

As described in #98 , a new type is required for handling audio instancing.

This will be a part of the new audio rework.

This ticket specifically lays out what is required for the .NET and Ink bindings.

We need to be able to essentially mount/host CoreCLR ourselves from inside the engine Unity style. There has been multiple discussions on why we wish to take this approach over just using extern C like we are for Rust and JS and then just P/Invoking in is because this will actively sacrifice universal Ink support. One of the main goals of this engine is to provide Ink to all of the language APIs universally. To see more about Ink, you can view it here: https://github.com/inkle/ink

The other main reason for hosting the CLR ourselves is because we can have communication both ways - as in, the engine core invokes C# code which can then come back into the engine core, much like how Unity approaches it.

The downside to this is, naturally, it will to be more work to implement, test, etc. This will probably require extensive tests once we have set up the google test suite (this is still on our TODO).

The other concern is without this, we can't actually make an alpha build of any kind as we planned to have C# and possibly Ink from the get-go in terms of the roadmap.

If there is a faster way to achieve this, you are welcome to suggest it here, however this is probably the best approach to my understanding.

AB#6

AB#2

Requirements for a basic Audio Implementation (new SDL_Mixer v1):

Stuff needed:

• Add SDL_mixer to project
• Add music / sound
• Play music / sound individually
• Play music & sound together

This project seems to have a lot of active changes and PRs. It makes sense to add a Continous Integration to the codebase to verify that PRs aren't breaking anything.

Due to (what seems to be) the newest update to the SDL2-mixer vcpkg files, adding in any modules for SDL2-Mixer besides core is broken on Windows. This is due to the bug resolving to .lib for every module which does not play nicely (i.e. using Vorbisfile results in a 0xc000012f error as it links to the library via .lib instead of .dll)

Until this is resolved, we can only support whatever formats SDL2 Mixer supports OOB.

For reference:
microsoft/vcpkg#8429

As pointed out in #98 , the logging service API restricts instantiation and usage in ways that violate the principle of "the runner owns all services".

We need to find a way to make this friendlier and to adhere to our codebase structure and service management.

At the moment the only way for objects to be deleted is when the game is torn down.

Naturally this isn't very feasible long term. An API needs to be added to support deleting render objects on the fly.

NovelRunner should be updated such that it can report frame diagnostics.

This should initially just track simple information like current FPS, the min/max FPS, average FPS, and total frame count.

However, it could also be extended to report additional information, like how many objects are rendered in the frame, the loaded shaders, and other information that may be useful for debugging.

The user can then request the frame diagnostic information and display it to the user or perform other suitable actions with it.

I keep running into problems in the engine core of going from a string view to const char* for the C-based APIs, specifically OpenGL, FreeType and SDL2.

It's a pain, and uneeded cost, to go from std::string_view to std::string followed by calling c_str(). We could call for the data pointer instead but that's nowhere near as safe as it might not be a null-terminated string in the view.

Thoughts?

Title.

Seeing as how we tend to have slight issues when it comes to having new contributors start building, we should probably write some steps to build NovelRT.

Included sections would be:

• Prerequisites
• Building using the automated build scripts
• Building manually (without using build.cmd)

This could be added to a Wiki page, and then linked to the readme, or it could be just added directly to the readme.

As suggested by @tannergooding in PR #42 it might make more sense to build the lib directly into the executable rather than splitting the code and having two separate (and possibly near-duplicate) build configurations.

Thoughts?

Currently, we have a lot of types prefixed with Novel; see: NovelObject.cpp, NovelRenderingService.cpp, etc.

We use this to describe the fact that the type is core to the engine - but we could use namespaces instead.

This comes with some design considerations. What do we do for commonly named types, e.g. NovelObject - Object itself would be way too generic. Do we try to be consistent with all naming and just remove the prefix no matter the ambiguity? Do we do this selectively, considering if the type name would be descriptive enough without the prefix?

Currently, launch issues can arise due to not having normalized paths for files that are used as input to the engine (i.e. the Basic and Texture shaders).

As per Ruby's suggestion, this could be resolved by a filesystem handling service or something of that nature, that would allow the engine core to properly find and open the files being called.
(Input is appreciated on this)

Where we're at right now

As it stands, the arguments the rendering service takes to create rects are a little...long. It makes maintenance a little cumbersome.

As an example, currently to instantiate an image rect the constructor looks like:

    NovelImageRect::NovelImageRect(NovelRenderingService* novelRenderer, const float screenScale, const GeoVector<float> &position, const std::string_view imageDir,
                                   const float rotation, const GeoVector<float>& scale, const int layer, const int orderInLayer)

but with a struct, this could be reduced to

NovelImageRect::NovelImageRect(NovelCommonArgs, std::string_view imageDir)

Opinions?

At the moment, NovelRT utilizes Glad as a rendering layer and function loader, allowing it to access various OpenGL extensions and profiles in a unified manner.

However, Glad is being imported via vcpkg, which is orthogonal to the way Glad is designed to be used. By design, Glad generates a single source file and two header files, which are intended to be directly included in projects utilizing it. The files are generated to fit the needs of the project, in terms of which Khronos specification it uses, the version of the specification, the extensions it would like to have available, etc.

This presents itself as an issue in the following ways:

• NovelRT does not have control over what OpenGL API it accesses, and is constrained to the one selected by the packager of Glad in vcpkg
• NovelRT cannot be built without the use of vcpkg, since, by design, no distribution of Linux, Windows, or Mac has a system-level package available for Glad

Fixing this issue by directly generating and including Glad in NovelRT would allow building the project without the use of vcpkg, and let NovelRT define exactly which extensions and what OpenGL version it requires.

See the following links for information about Glad, and its intended use.

• Khronos Wiki - Glad
• Glad's web-based API generator
• learnopengl - Getting Started, explaining Glad

With the oncoming changes to macOS (namely dropping OpenGL), we will need to wait until Vulkan support is brought into the engine to support macOS Catalina and above. With that being said, we can currently support macOS / Mac OS X variants below as certain Macs (around 2010+) come with OpenGL 4.1 built in.

We should add a Microsoft-hosted build agent to allow the CI to test against Mac builds as well. This allows us to test our code against Macs to ensure our code won't break if an end user is trying to use a Mac instead of Linux or Windows.

Currently, we have no implementation for an asset loading/registering system. This is useful for many different things, and also relates to #24 - an asset database would be nice for loading and resolving of types.

Example: (C# due to my inexperience with C++)

var brickTexture = await AssetDatabase["textures"].GetAsync("brick.png");

We could also implement special folder handling. Like the above example, to register a special folder for "textures" it could be:

AssetDatabase.RegisterSpecialFolder("textures", "./Textures", createFolder: true);

This would allow for flexibility and some abstraction for user end assets over the file system proposal.