kayomn
/
ona
1
0
Fork 0
Code Issues 8 Pull Requests Projects 4 Releases Activity

Update readme
continuous-integration/drone/push Build is failing Details

This commit is contained in:
kayomn 2023-04-19 01:34:06 +02:00
parent 2274cb412e
commit bb2745c3d0
1 changed files with 7 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
readme.md
View File

@ -19,34 +19,28 @@ Ona is also the Catalan word for "wave".
## Goals ## Goals
* Fully-featured two-dimensional raster and vector-derived rendering capabilities. * Fully-featured two-dimensional raster and vector rendering capabilities.
* Support major computer gaming ecosystems; Namely Microsoft Windows, SteamOS, and GNU Linux systems running on X11 or Wayland. * Support major computer gaming ecosystems; Namely Microsoft Windows, SteamOS, GNU Linux systems running on X11 or Wayland, and the web.
* Avoid shipping external dependencies beyond the executible itself. * Minimize external dependencies.
* Be lightweight in base engine memory usage and disk size. * Be lightweight in base engine memory usage and disk size.
* Provide a simple scene graph system that translates graph nodes into a cache-friendly representation at runtime. * Provide utilities for handling rendering but otherwise leave the higher-level game logic data structuring to the programmer.
* Provide an execution-speed optimized scripting interface through a Lua-inspired language named "Kym", with features like first-class support for common mathematic types used in rendering. * Provide a simple scripting interface for people who want to do something quick and a powerful plug-in API for engine-level extensions and speed-critical application logic.
* One data serialization and configuration system to rule them all backed by the Kym scripting language. * One data serialization and configuration system to rule them all backed by the Kym scripting language.
* Opt-in overhead via a native C plug-in interface that allows for systems-level programmers to easily extend engine-level functionality and scripting language library tools.
## Technical Details ## Technical Details
### Requirements ### Requirements
Ona currently depends the following third-party tools to build it: Ona currently depends the following third-party tools to build it:
* Clang / LLVM toolchain with full C++20 support or above. * Operating system with support for SDL2 at version 2.0.20 or above.
* Python interpreter version 3.10 or above. * Zig compiler toolchain.
Additionally, Ona depends on the following third-party system-wide dependencies:
* SDL2 version 2.0.20 or above.
As the project evolves, dependencies on libraries external to the project codebase will be minimized or removed outright to meet the goals of the project as closely as possible. As the project evolves, dependencies on libraries external to the project codebase will be minimized or removed outright to meet the goals of the project as closely as possible.
@ -56,36 +50,6 @@ Once all third-party tools and system-wide dependencies are satisfied, navigate
By default, the build script will build the engine runtime, required for running games built with Ona, in release-debug mode. By default, the build script will build the engine runtime, required for running games built with Ona, in release-debug mode.
### Project Structure
As Ona uses C++20, it is able to make use of the new modules language feature. While this brings with it a number of drawbacks, like a lack of widescale vendor adoption, it also provides some key benefits.
#### No Headers
A core benefit to the project, and the one which weighed most on this decision, is that all first-party code is free of header usage. Code is grouped in a module and package dichotomy, where each `.cpp` file in the root source directory represents the common package of a module grouping.
Alongside the surface-level benefit of writing having fewer lines of code, this also means there is less work necessary to maintain the codebase at large and a smaller space to create duplication errors in.
#### Module Conventions
The standard is loose on how modules are named and structured, so this codebase enforces its own convention of a package-like structure.
At the source root-level, each `.cpp` file contained represents the core module of each respective library. Higher-level extensions of the core library that do not cyclically depend on each other reside within folders that share a matching name (sans the extension). For example, the `coral.cpp` source file contains many common memory manipulation and floating point mathematics utilities, which are made use of in `coral/image.cpp` for modifying CPU-bound pixel data.
Each module tries to manage a responsibility of the overall project while also not introducing too many inter-dependencies in each other.
##### Coral
Common operating system-independent memory, math, and data structure utilities for use in all other first-party library modules.
##### Oar
The (O)na (Ar)chive format; a non-compressing data bundling format optimized for quick I/O operations and resolving the problem of having free-standing asset files complicating the cross-platform application distribution process.
##### App
Operating system-abstracted interface for building graphical and headless applications.
##### Kym ##### Kym
Scripting language designed around an execution speed-optimized design, and features like first-class support for common mathematic types. Scripting language designed around an execution speed-optimized design, and features like first-class support for common mathematic types.