[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] I'm making a TinyCC-Based VR Game Engine

From: Christian Jullien
Subject: Re: [Tinycc-devel] I'm making a TinyCC-Based VR Game Engine
Date: Sun, 9 Feb 2020 11:12:40 +0100

Thank you for sharing your experience with us.




From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=address@hidden] On Behalf Of Charles Lohr
Sent: Sunday, February 09, 2020 00:34
To: address@hidden
Subject: [Tinycc-devel] I'm making a TinyCC-Based VR Game Engine


I've been spending the last 8 months or so working on a weird game engine that revolves around TCC.  I don't have any specific requests, or anything else but wanted to thank everyone here for all the work you've put into TCC.  TCC's portability, size and speed has allowed me to explore and push the boundaries of what is possible.  I wasn't sure if this was something would would interest you guys to see what I've been up to with this, but figured I'd post it.


The major lesson I've learned is:


Developers have solved various issues surrounding development cycles with tools (optimizations, build systems, complicated data structures, large libraries, etc.).  TCC circumvents the need for these tools by various means and thus provides a comfortable, useful and powerful environment without the baggage that those tools bring.


Some major take aways are:

(1) Development in Windows is VERY easy to get new programmers bootstrapped in - to build the main executable only TCC 0.9.27 is needed to be unzipped.  Setup is significantly easier than python which requires additional environment variables and settings.  If the user is only interacting with game code, no compiler or development tools are needed whatsoever.  All game code is compiled to RAM by the copy of TCC that is compiled into the main .exe.

(2) Because of TCC's speed, there is no need to save intermediate files.  No need for tracking, makefiles, etc. is needed.  To recompile the entire system, and TCC itself is faster than visual studio would be able to even do an incremental build.  

(3) By having the "scripting" language be the same as the "host" language, code, definitions and functionality can be freely copied without translation.  Additionally binding to additional functionality is trivial.

(4) Crashing is OK.  It's surprising how easy it was to capture events when some module goes off the deep end and writes to memory address 5.  Crashing, recording a call stack, and continuation of execution takes around 70us, which allows things to continue execution immediately.

(5) Optimizations available in more advanced compilers don't matter as much anymore.  Benchmarking between MSVC, GCC, Clang, and TCC itself shows that there isn't that much true performance differences to the end framerate.  I'm able to perform a tremendous amount of logic and game programming and complete frames in an order 1-2ms per frame.  Allowing for smooth 144 FPS operation of the VR games even under stressful conditions on poor hardware. This is in stark contrast to something like Unity which struggles to make 144FPS on even simple games and high performance hardware.

(6) The decision to NOT solve problems which do NOT NEED to be solved (even if people really want them to be solved) is a GOOD trade off.  It was so tempting to add larger or more complicated systems, but in practice when using the dune buggy over the rolls royce the experience you get at the end of the day is still really good.


My adventure is far from over with this, but I wanted to share it with you guys because you made it all possible.  I deeply appreciate your commitment to having what is currently an oddity, but ever so powerful.  You are making possible what seemed completely impossible and bending at least my expectations of reality and challenging the sensibilities I've developed as a industry seasoned programmer.


P.S. Can we please switch away from the current git server? :-p



reply via email to

[Prev in Thread] Current Thread [Next in Thread]