darsto / spooky Goto Github PK

• java bindings for Android builds, which would read files from inside the apk file
• Windows version of dirent.h

This could also fix cross-platform support, as it's broken for now.

Some cache could be useful.

Android devices loose OpenGL context with every app minimization, so it has to be reloaded. Right now it also causes texture atlases to load again and then manual mipmap generation slows down this process a lot.

Just a quick try out, and found that it does not build on OSX. There seems to be some linux-specfics used, e.g. ".../" instead of "../../". A quick fix might be required if OSX support gets a chance to your list of goals?

venus:spooky wc$ mkdir -p build/android && cd build/android
venus:android wc$ cmake -DCMAKE_TOOLCHAIN_FILE=[...]/toolchain-android.cmake -DANDROID_ABI="armeabi" -DCMAKE_BUILD_TYPE=Debug -DBUILD_SHARED=ON ../..
CMake Error at /usr/local/Cellar/cmake/3.5.2/share/cmake/Modules/CMakeDetermineSystem.cmake:104 (message):

• Application class
• context
• windows
• input

This will also at the same time establish the premises of the engine. Some additional refactoring may follow.

• clean it up
• remove useless code
• move to separate directories
• use namespaces
• add exception handling
• add documentation

I'm aware that not many ppl have that library installed on their systems. It might be a good idea to use SOIL2 [1]. However, that is a premake mercurial repository, so a CMake git alias repo would have to be created.

[1] https://bitbucket.org/SpartanJ/soil2

Some render/ subdirectories have been already refactored, but the majority is still full of garbage.

As usually:

• cleanup, remove unnecessaries
• move to c++11
• add exception handling (as no tests can be done)
• add documentation
• wrap in namespaces

Since Spooky is supposed to be a library, it might be wise to wrap everything in "spooky" namespace.
Also, particular parts of the engine could have their own sub-namespaces. (like rendering)

It's a real mess for now, completely unreadable. The structure is also very inconsistent.

Many features will follow.
The gui code will be heavily refactored, but there's no other way to decide on the code design.

• fix position index handling of GuiElement
• allow non-square textures to be used by the shader
• manage memory more wisely, cleanup
• add a common interface for regular textures & texture atlases
• add documentation