I'm making a TinyCC-Based VR Game Engine

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

I'm making a TinyCC-Based VR Game Engine

Charles Lohr
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

Thanks.

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: I'm making a TinyCC-Based VR Game Engine

Christian Jullien-3

Thank you for sharing your experience with us.

 

C.

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]] On Behalf Of Charles Lohr
Sent: Sunday, February 09, 2020 00:34
To: [hidden email]
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

 

Thanks.


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: I'm making a TinyCC-Based VR Game Engine

uso ewin
Thanks for sharing.

I'm making a game engine that use Tinycc for scripting too(I still use
gcc/clang to compile the engine):
https://github.com/cosmo-ray/yirl
But I'm developing mostly on an old netbook with 1GB of ram and an old
atom CPU with a chipset
that support only opengl1, so for now I only do 2D.

Nevertheless It's nice to see other peoples using tcc for scripting.

Also it would be nice to have an IRC or something like that to talk
tcc and game development ?

On Sun, Feb 9, 2020 at 11:12 AM Christian Jullien <[hidden email]> wrote:

>
> Thank you for sharing your experience with us.
>
>
>
> C.
>
>
>
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]] On Behalf Of Charles Lohr
> Sent: Sunday, February 09, 2020 00:34
> To: [hidden email]
> 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.
>
>
>
> https://www.youtube.com/watch?v=a2DjjG9wVY0&list=PLDRymMFQl3NldBEGAaeZlqINSU0ALUqRQ&index=3
>
> https://github.com/cnlohr/cnovr
>
>
>
> 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
>
>
>
> Thanks.
>
> _______________________________________________
> Tinycc-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel