Re:Create your own Game Engine but don't use it
by yellowapple on Thursday July 13, 2017 @12:37PM
(#14762735)
A growing number of languages are ABI-compatible with C. A small but significant subset of those languages is ABI-compatible with C++. Quite a few languages (Perl 6, Julia, Tcl w/ critcl, pretty much everything that uses libffi AFAICT) are able to do this without having to write full-blown wrappers for a whole C/C++ library (though you still need to wrap specific functions in most cases).
Re:Create your own Game Engine but don't use it
by ihnorton on Thursday July 13, 2017 @01:00PM
(#14762938)
Julia JIT compiles C calls via LLVM, so there's no libffi performance overhead (similar to LuaJIT's CFFI, though that does not use LLVM).
Re:Create your own Game Engine but don't use it
by yellowapple on Thursday July 13, 2017 @04:48PM
(#14765071)
Neither does Tcl's critcl AFAIK (I think it just sticks the C code in a Tcl extension and compiles it using the system compiler). My intent there was just to list cases where wrapping a whole C/C++ library is unnecessary, not to imply that Julia uses libffi :)
On that note, LLVM helps a lot here, too. Are there any LLVM-based languages that don't have some degree of C compatibility?
Re:Create your own Game Engine but don't use it
by ihnorton on Thursday July 13, 2017 @05:38PM
(#14765493)
Parse error on my part, excuse the pedantry :) Tcl is such a weird and wonderful language, and I occasionally miss it (though I don't miss working with a GUI written in C++ wrapped around tk).
Re:Create your own Game Engine but don't use it
by pjmlp on Wednesday July 12, 2017 @02:57PM
(#14755448)
On a past life I used to be an IGDA member, attended GDCE a couple of times, and knew personally developers working in a few European game studios, until deciding boring IT work was a better way to make a living and enjoying life.
As soon as you say you are throwing out C/C++ you better have amazing alternatives that make sense for the language you are working on. Games are large enough projects with broad enough scope that if you don't have a language that works well with a bunch of external libraries you are immediately in the weeds once you end up with a problem that isn't covered by what is already available. If you find this out too late in the project (especially in a hobby/side project) this can be a death knell.
This is a constant problem in game engines or other large frameworks- once you get off the rails in a significant way all your development time is going to making that kludge work. If you are using a language that is just wrapping C API libraries often a lot of this development time is just fixing the wrappers to the actual library instead of getting anything done.
If you know the end product is 100% covered by a game engine you can save all the game engine development time and the kludge fix time all at once. I had written a whole tutorial series based on XNA for instance because it was easy to demonstrate the concepts I wanted to share, but when trying to start working on a particular topic I realized the engine's limitation and it all went to hell and I had to scrap it.