| Readme: In the following pseudo code, [] indicates a subroutine. | |
| Sometimes I choose to write the subroutine inline under the [] in order to maintain context. | |
| One important fact about the way rollbacks are handled here is that we are storing state for every frame. | |
| In any real implementation you only need to store one game state at a time. Storing a game | |
| state for every frame allows us to only rollback to the first frame where the predicted inputs don't match the true ones. | |
| ==Constants== | |
| MAX_ROLLBACK_FRAMES := Any Positive Integer # Specifies the maximum number of frames that can be resimulated | |
| FRAME_ADVANTAGE_LIMIT := Any Positive Integer # Specifies the number of frames the local client can progress ahead of the remote client before time synchronizing. |
As C programmers, most of us think of pointer arithmetic for multi-dimensional arrays in a nested way:
The address for a 1-dimensional array is base + x.
The address for a 2-dimensional array is base + x + y*x_size for row-major layout and base + y + x*y_size for column-major layout.
The address for a 3-dimensional array is base + x + (y + z*y_size)*x_size for row-column-major layout.
And so on.
Memory Optimization (Christer Ericson, GDC 2003)
http://realtimecollisiondetection.net/pubs/GDC03_Ericson_Memory_Optimization.ppt
Cache coherency primer (Fabian Giesen)
https://fgiesen.wordpress.com/2014/07/07/cache-coherency/
Code Clinic 2015: How to Write Code the Compiler Can Actually Optimize (Mike Acton)
http://gdcvault.com/play/1021866/Code-Clinic-2015-How-to
| /* ======================================================================== | |
| $File: tools/ctime/ctime.c $ | |
| $Date: 2016/05/08 04:16:55PM $ | |
| $Revision: 7 $ | |
| $Creator: Casey Muratori $ | |
| $Notice: | |
| The author of this software MAKES NO WARRANTY as to the RELIABILITY, | |
| SUITABILITY, or USABILITY of this software. USE IT AT YOUR OWN RISK. |
| Why do compilers even bother with exploiting undefinedness signed overflow? And what are those | |
| mysterious cases where it helps? | |
| A lot of people (myself included) are against transforms that aggressively exploit undefined behavior, but | |
| I think it's useful to know what compiler writers are accomplishing by this. | |
| TL;DR: C doesn't work very well if int!=register width, but (for backwards compat) int is 32-bit on all | |
| major 64-bit targets, and this causes quite hairy problems for code generation and optimization in some | |
| fairly common cases. The signed overflow UB exploitation is an attempt to work around this. |
| #include "mu.h" | |
| #define _CRT_SECURE_NO_WARNINGS | |
| #include <malloc.h> | |
| #define _USE_MATH_DEFINES | |
| #include <math.h> | |
| #define _NO_CRT_STDIO_INLINE | |
| #include <stdio.h> | |
| #include <stdarg.h> | |
| #define NO_STRICT |
| ; This code is hereby released by its author (Per Vognsen) into the public domain. | |
| ; It's mostly a proof of concept though it was surprisingly usable for how simple it was to code. | |
| ; If you want to use it as a starting point for a more polished package, go right ahead. | |
| (require 'cl) | |
| (defstruct wm-window buffer (point 0) (start 0) (hscroll 0) dedicated) | |
| (defvar wm-windows) | |
| (defvar wm-windows-alist) |
For the last few weeks I spend some time coding, writing and cleaning up my notes from almost a year since I published nuklear.
Basically this is a possible implementation for a graphical user interface builder backend with support for an immediate mode style API. So it provides a way to define non-mutating UI state, an immediate mode style API for dynamic UI components (lists,trees,...) and a combination of both.
The core implementation is ~800 LOC without any kind of default widgets or extensions. At first this seems quite counter intuitive. However since the inherent design allows for lots of different ways to define any widget like buttons it does not make sense to provide a specific default implementation. The way this code was architectured furthermore removes the need for style/skinning configurations used in Nuklear since widget painting is just calling a small
| /* =========================================================================== | |
| * | |
| * LIBRARY | |
| * | |
| * =========================================================================== */ | |
| /* Proof of Concept GUI: | |
| * - PoC UI implementation in ~2.5kLOC of C89 (ANSI C) | |
| * => Core solutions has no external dependencies (removing standard library dependency is trival) | |
| * => Does not use or require any special language constructs or macro constructs just pointers and enums | |
| * - Combines both "retained" and "immediate mode" UI by providing control over update frequency |