Render queue specification
This commit is contained in:
parent
99ba25abec
commit
d3a4f4c91f
1 changed files with 12 additions and 5 deletions
17
README.org
17
README.org
|
|
@ -23,11 +23,10 @@ Components are SRFI-99 records which store data associated for a particular enti
|
|||
|
||||
** Systems
|
||||
Systems are functions which modify state and draw to the screen.
|
||||
Systems are stored in the ~systems~ list as a record containing a name (symbol), rendering (a symbol), a priority (integer), entity criteria (list of symbols), and the function itself.
|
||||
Systems are stored in the ~systems~ list as a record containing a name (symbol), a priority (integer), entity criteria (list of symbols), and the function itself.
|
||||
Each system specifies the components an entity (the entity criteria) must have for it to be processed by that system. The entities are then selected for the system from the ~component-sets~.
|
||||
Each system is applied to all entities which match its entity criteria.
|
||||
Systems have a priority which defaults to 0. Lower priority systems will be executed before higher priority systems. Systems within the same priority execute in order of addition to the ~systems~ list.
|
||||
If a system defines a rendering symbol of 3D, it will be wrapped in ~with-mode-3d~. If a system defines a rendering symbol of 2D, it will be wrapped in ~with-mode-2d~. All systems run in render loop, wrapped in ~with-drawing~, and can draw non-2D and non-3D elements arbitrarily. In this way ~with-mode-3d~ and ~with-mode-2d~ can be avoided in system function bodies, and non-3D/2D systems can draw in screen space.
|
||||
|
||||
The ~systems~ list is sorted on each addition and removal of a system.
|
||||
Like entities, the addition of systems is queued for the beginning of each frame. This prevents the system list from being sorted multiple times per frame.
|
||||
|
|
@ -43,6 +42,14 @@ Systems can choose to either pop the event off the bus (removing it from further
|
|||
The symbol an event is associated by is essentially an "action". The event bus can have multiple events of the same type (for example, multiple different key presses can occur in a frame). Only one event of each name (for example, only 1 event can be called "jump", which might correspond to a space key press) is allowed in the bus at any one time.
|
||||
Custom event buses can be created and stored in the ~event-buses~ hash table. Systems can query a particular event bus within that list for a particular event.
|
||||
|
||||
** Rendering
|
||||
Imgui maintains 3 render queues, with one each for screen, 2D and 3D drawing.
|
||||
Systems can push render objects to any of these queues, which are simply pairs of integers and a lambda thunk.
|
||||
The initial integer denotes a layer, while the lambda thunk contains the drawing function to evaluate.
|
||||
When drawing the next frame, the system iterates and executes every drawing thunk in order from the smallest to the largest layer.
|
||||
The 3D queue is executed first, followed by the 2D queue, followed by the screen queue.
|
||||
For 2D and 3D drawing, systems can set the currently active camera object on the parameters ~*active-camera-2d*~ and ~*active-camera-3d*~.
|
||||
|
||||
** Resources
|
||||
When a resource, such as a font or texture, is loaded from the filesystem, the pointer is stored in an SRFI-69 hash table ~resources~ keyed by the path.
|
||||
When records are first loaded, a finalizer is set for them ensuring they are unloaded when collected by the GC.
|
||||
|
|
@ -75,10 +82,9 @@ Functions for creating, removing, and fetching entities. ~id~ must be a symbol,
|
|||
When entities are created or removed, the creation/deletion is added to an internal queue. Entity creation and removal to/from the ~world~ state from the queue is performed at the top of each frame, or when ~(resolve-queues)~ is executed.
|
||||
*** Systems
|
||||
#+begin_src scheme
|
||||
(make-system name rendering priority criteria process)
|
||||
(make-system name priority criteria process)
|
||||
(system? record)
|
||||
(system-name system)
|
||||
(system-rendering system)
|
||||
(system-priority system)
|
||||
(set-system-priority! system priority)
|
||||
(system-criteria system)
|
||||
|
|
@ -86,7 +92,7 @@ When entities are created or removed, the creation/deletion is added to an inter
|
|||
(system-process system)
|
||||
(set-system-process! system process)
|
||||
#+end_src
|
||||
Functions for creating systems, which are SRFI-99 records. ~name~ must be a symbol, ~rendering~ must be a symbol and either ~3d~, ~2d~, ~screen~, or ~none~, ~priority~ must be an integer, ~criteria~ must be a list of symbols, and ~process~ must be a zero argument procedure.
|
||||
Functions for creating systems, which are SRFI-99 records. ~name~ must be a symbol, ~priority~ must be an integer, ~criteria~ must be a list of symbols, and ~process~ must be a zero argument procedure.
|
||||
|
||||
#+begin_src scheme
|
||||
(add-system system)
|
||||
|
|
@ -142,6 +148,7 @@ Functions for creating and fetching events. ~bus~ must be a symbol referencing a
|
|||
(create-window process: (next-frame) close-predicate: (window-should-close?))
|
||||
#+end_src
|
||||
~create-window~ creates a window using the window parameters described above, then enters a loop which runs the ~process:~ function (~next-frame~ by default) on each frame, unless ~close-predicate:~ (Raylib's ~window-should-close~ function by default) returns true, in which case the window is closed.
|
||||
|
||||
* Dependencies
|
||||
The following Chicken dependencies are required:
|
||||
- raylib
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue