Mercurial > games > semicongine

comparison README.md @ 194:93f661a20f74

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
did: a bit of cleanup with the config, also add some documentation
author Sam <sam@basx.dev>
date Sun, 07 May 2023 00:23:46 +0700
parents b14e078690dc
children e4ba91da416b
comparison
equal deleted inserted replaced
193:ee1aea493736 194:93f661a20f74
17 Run ```nim help``` to see a list of available build commands. 17 Run ```nim help``` to see a list of available build commands.
18 18
19 Roadmap 19 Roadmap
20 ------- 20 -------
21 21
22 Still tons to do. Making render pipeline and scenegraph somewhat compatible 22 Here a bit to see what has been planed and what is done already. Is being
23 seems like it will require quite a bit more of work. Also, audio might require 23 updated frequently (marking those checkboxes just feels to good to stop working).
24 quite a bit of work, no experience there (note: audio was super easy to implement)
25 24
26 Rendering: 25 Rendering:
27 26
28 - [x] Vertex attributes, vertex data 27 - [x] Vertex attributes, vertex data
29 - [x] Shaders (allow for predefined and custom shaders) 28 - [x] Shaders (allow for predefined and custom shaders)
30 - [x] Uniforms 29 - [x] Uniforms
31 - [x] Per-instance vertex attributes (required to be able to draw scene graph) 30 - [x] Per-instance vertex attributes (required to be able to draw scene graph)
32 - [x] Fixed framerate 31 - [x] Fixed framerate
33 - [x] Instanced drawing (currently can use instance attributes, but we only support a single instance per draw call) 32 - [x] Instanced drawing (currently can use instance attributes, but we only support a single instance per draw call)
34 - [ ] Textures 33 - [x] Textures
34 - [ ] Multisampling
35 - [ ] Allow different shaders (ie pipelines) for different meshes
36
37 Required for 3D rendering:
38
35 - [ ] Depth buffering 39 - [ ] Depth buffering
36 - [ ] Mipmaps 40 - [ ] Mipmaps
37 - [ ] Multisampling
38 - [ ] Allow different shaders (ie pipelines) for different meshes
39 41
40 Asset handling: 42 Asset handling:
41 - [ ] Resource concept: load from directory, zip or in-memory-zip, select "mod" as root 43 - [ ] Resource concept: load from directory, zip or in-memory-zip, select "mod" as root
42 - [ ] Mesh files (Wavefront OBJ, MTL) (use something from sketchfab for testing, https://sketchfab.com/) 44 - [ ] Mesh files (Wavefront OBJ, MTL) (use something from sketchfab for testing, https://sketchfab.com/)
43 - [ ] Image files (BMP RGB + BMP Graysscale for transparency) 45 - [ ] Image files (BMP RGB + BMP Graysscale for transparency)
56 - [x] Linux 58 - [x] Linux
57 - [x] Windows Waveform API 59 - [x] Windows Waveform API
58 - [ ] Generic configuration concept (engine defaults, per-user, etc) 60 - [ ] Generic configuration concept (engine defaults, per-user, etc)
59 - [ ] Input-mapping configuration 61 - [ ] Input-mapping configuration
60 - [ ] Telemetry 62 - [ ] Telemetry
61 - [ ] Add simple event logging service 63 - [x] Add simple event logging service
62 - [ ] Add exception reporting 64 - [ ] Add exception reporting
63 - [ ] Documentation? 65 - [ ] Documentation?
64 66
65 Advanced features (very low priority): 67 Advanced features (very low priority):
66 - [ ] Text rendering 68 - [ ] Text rendering
76 - [x] Better scenegraph API 78 - [x] Better scenegraph API
77 - [x] Better rendering pipeline API 79 - [x] Better rendering pipeline API
78 80
79 Build-system: 81 Build-system:
80 - [x] move all of Makefile to config.nims 82 - [x] move all of Makefile to config.nims
83
84
85 Documentation
86 =============
87
88 Okay, here is first quick-n-dirty documentation, the only purpose to organize my thoughts a bit.
89
90 Engine parts
91 ------------
92
93 Currently we have at least the following:
94
95 - Rendering: rendering.nim vulkan/*
96 - Scene graph: entity.nim
97 - Audio: audio.nim audiotypes.nim
98 - Input: events.nim
99 - Settings: settings.nim
100 - Meshes: mesh.nim
101 - Math: math/*
102 - Telemetry: telemetry.nim (wip)
103 - Resources/mods: resources.nim (wip)
104
105 Got you: Everything is wip, but (wip) here means work has not started yet.
106
107 Configuration
108 -------------
109
110 Or: How to organize s**t that is not code
111
112 Not sure why, but this feels super important to get done right. The engine is
113 being designed with a library-mindset, not a framework mindset. And with that,
114 ensuring the configuration of the build, runtime and settings in general
115 becomes a bit less straight-forward.
116
117 So here is the idea: There are three to four different kinds of configurations
118 that the engine should be able to handle:
119
120 1. Build configuration: Engine version, project name, log level, etc.
121 2. Runtime engine/project settings: Video/audio settings, telemetry, log-output, etc.
122 3. Mods: Different sets of assets and configuration to allow easy testing of different scenarios
123 4. Save data: Saving world state of the game
124
125 Okay, let's look at each of those and how I plan to implement them:
126
127 **1. Build configuration**
128
129
130 **2. Runtime settings**
131
132 This is mostly implemented already. I am using the Nim module std/parsecfg.
133 There is also the option to watch the filesystem and update values at runtime,
134 mostly usefull for development.
135
136 The engine scans all files in the settings-root directory and builds a
137 settings tree that can be access via a setting-hierarchy like this:
138
139 setting("a.b.c.d.e")
140
141 ```a.b``` refers to the settings directory ```./a/b/``` (from the settings-root)
142 ```c``` refers to the file ```c.ini``` inside ```./a/b/```
143 ```d``` refers to the ini-section inside the file ```./a/b/c.ini```
144 ```e``` refers to the key inside section ```d``` inside the file ```./a/b/c.ini```
145
146 ```a.b``` are optional, they just allow larger configuration trees.
147 ```d``` is optional, if it is not give, ```e``` refers to the top-level section
148 of the ini-file.
149
150 **3. Mods**
151
152 A mod is just a collection of resources for a game. Can maybe switched from
153 inside a game. Current mod can be defined via "2. Runtime settings"
154
155 I want to support mods from:
156
157 a) a directory on the filesystem
158 b) a zip-file on the filesystem
159 c) a zip-file that is embeded in the executable
160
161 The reasoning is simple: a) is helpfull for development, testing of
162 new/replaced assets, b) is the default deployment with mod-support and c) is
163 deployment without mod-support, demo-versions and similar.
164
165 Should not be that difficult but give us everything we ever need in terms of
166 resource packaging.
167
168 **4. Save data**
169
170 Not too much thought here yet. Maybe we can use Nim's std/marshal module. It
171 produces JSON from nim objects. Pretty dope, but maybe pretty slow. However, we
172 are indie-JSON here, not 10M of GTA Online JSON:
173 https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/