noah1510 / redhand Goto Github PK

The includes should be modified in a way that allows using of precompiled headers allowing for way faster compile times and makes including the whole library and its includes easier and faster.

At the moment the code is not really taking advantage of a lot of c++11 and newer features.
Before the public release at least all pointers going in and out of the engine should be smart pointer (shared or unique pointers).

The following things have to be implemented before releasing version 0.1.0:

• use rValues as function returns (createRecktangle, createCircle)
• removing copy constructors
• if object shader is nullptr use default shader

At the moment there are no test except a simple compile test for windows and ubuntu.
For the first release there should be at least some unit tests to validate that the code does what it is supposed to do.

At the moment a lot of the functions are documented but not that well and for examples all the scripts don't have any documentation at all except for the --help option which gives a little bit of information but not enough.

• document input system
• document events
• document project setup
• document script usage
• more api documentation
• more example projects with details documentation
• more information for potential contributers

Having implemented the new library, the obvious thing to do is to test it out, but since the testgame has no connection to the main redhand compiled code, it is not imported automatically. Should I just import the new audio.hpp + *.cpp script by hand?

At the moment not all images load properly and e.g. svg files are not supported at all.

• use vips and remove stb
• fix some png images that are not rendered correctly
• svg support
• get transparency to work correctly

What is missing in the Input System:

• mouse information
• text input
• key input (kind of optional)
• joystick support (kind of optional)

I haven't been able to build Redhand using Windows.

I have downloaded MSys2 as suggested and I ran the script build.sh. As you can see in the output I included below, it fails to run the commands pip, meson, and ninja, after successfully downloading and installing most of what it needs.

Here is my output when I try to build:
output1.txt

• OS: Windows 10 Home
• Version 10.0.18363 Build 18363
• MSys2 runtime version 3.1.7-2

The conventions have to be specified somewhere for a project of this size. This will also help the new developers to maintain the code similarity between the different project modules. This issue isn't a high priority, however it has to be done in the near future.

This is or rather will be one of the most important features since it is the class almost everything that you see on the display is based on.

Unlike the game_object, it should own a pointer to the used shader, unless it is the default shader, in that case the pointer should be nulltpr and the default_shader added to the active world should be used.
*The actor always uses the default shader!~

Things that are still missing:

• implement the Actor class as abstracted game_object
• collision events #18
• updates to the testgame to only use actors

Basically there should at least be the option to render all the stuff in batches, instead of having different Buffers for each objects.
This will be a speedup for larger games but could potentially slow smaller games down.
So an option would be good, because this solutions might only be necessary when there are a lot of objects on the screen and only works if all objects use the same shader.

Just like the Actor is an abstraction of the game_object there needs to be a simple World class that abstracts the complex_world and should only accept Actors as acting objects.

• implement World class
• update testgame to utilize the World class

working example and implementation of audio playback with OpenAL-soft library #33

The package should be able to be build for arm64 and maybe armhf.

• update the control file for arm64
• update the control file for armhf not needed
• fix any problem that happens
• release v0.1.1 with arm support
• release v0.1.2 with working arm build

A lot of functions like the draw or act functions should be rewritten in an event based manner.

This makes hooks and additions to function calls more natural and adds flexibility and simplicity to the codebase.

The following events should be implemented at first:

• game_loop event

• The game_loop event should also report the time difference from the last call allowing programmers to write the code in a manner that causes movements to have the same speed regardless of the tick speed of the game. (This is part of the event)

• The game loop should run with a constant time difference, allowing to have a more hardware independent game tick speed.

• input events There won't be input events. For input the input_system can be used to query the key states inside game_loop events. See b760a00 for details.

• drawing event

• world switching

• world activation

• The engine should have a function that allows other objects to add or remove functions as event handlers to the engine which are called at the right time. done for game loop events

It seems like find_library never finds the library even if the location is in the HINTS and the correct name is in the NAMES.

This is only a minor problem since all windows libraries are manually compiled and moved to specific folders so it does not really matter but the current way is very inflexible and might easily break in the future.

However this is low priority bug and will be addressed in the future.

Almost all of the properties have to be locked with some mutex to prevent racing as much as possible.

Well both of them are essential for games so naturally you need some kind of ui and some kind of text rendering

• Find a text library and get it working

The idea is to strictly separate the test game from the actual engine.
This way there would be the option to provide the engine as a precompiled library.
This would also clean things up a bit and allow better documentation for the installation and implementation of games.

Since collision detection is essential for any game engine, there should be a least a simple implementation when this is public.