Update readme
continuous-integration/drone/push Build is failing
Details
continuous-integration/drone/push Build is failing
Details
This commit is contained in:
parent
2274cb412e
commit
bb2745c3d0
50
readme.md
50
readme.md
|
@ -19,34 +19,28 @@ Ona is also the Catalan word for "wave".
|
|||
|
||||
## 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.
|
||||
|
||||
* 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.
|
||||
|
||||
* 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
|
||||
|
||||
### Requirements
|
||||
|
||||
Ona currently depends the following third-party tools to build it:
|
||||
|
||||
* Clang / LLVM toolchain with full C++20 support or above.
|
||||
* Python interpreter version 3.10 or above.
|
||||
|
||||
Additionally, Ona depends on the following third-party system-wide dependencies:
|
||||
|
||||
* SDL2 version 2.0.20 or above.
|
||||
* Operating system with support for SDL2 at version 2.0.20 or above.
|
||||
* Zig compiler toolchain.
|
||||
|
||||
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.
|
||||
|
||||
### 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
|
||||
|
||||
Scripting language designed around an execution speed-optimized design, and features like first-class support for common mathematic types.
|
||||
|
|
Loading…
Reference in New Issue