wanp/townengine
2
1
Fork 0
Code Issues 6 Pull Requests Packages Projects Releases Wiki Activity

update about-townengine.html

Browse Source
This commit is contained in:
veclavtalica 2025-02-20 14:29:30 +03:00
parent 21d8e2c5a5
commit 3d51c8c48f
1 changed files with 15 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
docs/wiki/about-townengine.html
View File

@ -9,8 +9,7 @@
<a href="index.html">Go back
<p><a name="introduction"></a><strong>T1.1 </strong><strong>Introduction</strong>
<blockquote>
<p>Townengine, {twn}, is an opinionated game development framework designed around ideas of simplicity, managed state,
care for old devices, portability, language agnosticism, use-case orientation, iterability and low latency.
<p>Townengine, {twn}, is an opinionated game development framework designed around specific set of ideas:
<p><b>Simplicity.</b> It makes assumptions that trickle down to your game code. There's no delta between frames, nor resolution change.
Textures have constant known size, not requiring scaling.
<p><b>Managed state.</b> Designed around this we can provide hot reloading at any point,
@ -18,22 +17,28 @@
Every frame apparent engine state is cleared, which removes another variable for you to handle, - when to initialize.
There's no need for you to call `LoadImage()` of sorts before using it in render, you just pass filepaths around.
Input is initialized anew each frame, making rebinds trivial.
<p><b>Care for old devices.</b> It's to both to provide it for more people, who otherwise might not be able to make games they want,
as well as to have restrictions that constitute in desired aesthetic. Graphics capabilities are limited, but
<p><b>Device care.</b> Older hardware is still used in many parts of the world,
which users might not otherwise be able to make games they dream of.
Restrictions also constitute in desired aesthetics. Graphics capabilities are limited, but
what is present, - is heavily optimized. It is rather different from performance-driven approach that tries to take
advantage of the latest hardware and features, sacrificing both the reach and portability.
advantage of the latest hardware and features, sacrificing both the reach and portability in process.
<p><b>Portability.</b> Written in C11 with all dependencies being in C, it's possible to compile it to most platforms.
SDL2 is at the center and you cannot get better than this. Default graphics API is OpenGL 1.5 with extension detection.
As an example, it builds and runs on Haiku OS with LLVMpipe.
<p><b>Language agnosticism.</b> API is restricted to not require much glue.
<p><b>Language agnosticism.</b> API is restricted to minimize the amount of glue code.
Language interpreters don't need to be part of the engine itself. Anything with C ABI support can link to it.
/share/twn_api.json schema is provided for automatic binding and annotation generation.
<p><b>Use-case orientation.</b> It doesn't try to be a yet another general purpose engine conquering all and nothing.
Instead we seek particular use cases and implement the most essential parts.
User code copying should be promoted instead of delegating it all to the engine, this way we don't restrict.
<p><b>Iterability.</b> Defaults provided for most of the API, making initial code faster to spring.
Hot reloading for both assets and code.
<p><b>Low latency.</b> Care is given to various incarnations of feared latency. Engine is fast to build, allowing for low commitment patches.
Startup time is profiled and optimized. Streaming is used as much as possible for asset load.
</blockquote>
Hot reloading works for both assets and code.
<p><b>Low latency.</b> Care is given to various incarnations of feared latency. Engine is fast to build, allowing for low commitment local patches.
Startup time is profiled and frequently looked into. Streaming is used as much as possible.
<p><b>No-Versioning.</b> We don't stick to releases and "contract" obligations for things to remain stagnant.
It's fair to ask end user to put little effort if they need newer set of features, instead of putting all the burden on us.
You can always just stick to particular version you started the development of the project with,
{twn} doesn't need system wide installation.</blockquote>
<p><a name="wiki"></a><strong>T1.2 </strong><strong>Wiki</strong>
<blockquote>
<p>Purpose of this wiki is to collect information on various usages of {twn} across the genres, FAQ style.