Earlier quoted context omitted.
Soldat was actually the first shareware I bought, as I totally didn't have to, yet I sunk so many hours in it. Without doing much progress skill wise :-D
haha me too! I sent a bank cheque to MM when I was 12 because I wanted to support the guy (and I was so glad that this game existed because I had a toaster and couldn't play any of the "modern" 3D games at the time)
Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal
81–90 of 103 posts
Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal
#82Hah pascal, the first language I learned to script some game named Soldat when I was a kid, fun times
It's still around. The FLOSS version is called OpenSoldat now (I plan to get it back on track eventually as it became unstable with Version 1.8).
Really enjoyed the quick compile times :)
Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal
#83Earlier quoted context omitted.
haha me too! I sent a bank cheque to MM when I was 12 because I wanted to support the guy (and I was so glad that this game existed because I had a toaster and couldn't play any of the "modern" 3D games at the time)
MM even opensourced it https://github.com/soldat/soldat
Later someone unknown hijacked the original url and copied an outdated version of the repository (you can see the mention of OpenSoldat.)
Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal
#84https://castle-engine.io/why_pascal I'm gonna have to put a damper on things, here. Most of the reasons listed are things available in any other modern language (safety, cross-platformness, libraries...) but one of the things cited is readability. I work on Pascal code 8 hours a day, and it is not more readable then conventional C syntax ; I'd argue it's much less. The fact that you need to use entire words to denote…
{$R+} // range checking on - nice for debugging
I want this (perhaps as a compiler and/or runtime option) for clang/gcc as well.Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal
#85I have a feeling those pascal developers are getting stuff done super productively.
This is what amazes me. If you go through the available Delphi/FPC libraries, you will find basically anything. From CAD drawing widgets to frameworks for building SCADA systems. Most are not present on GitHub, and if they are, don't have hundreds of stars. On the other hand I have an impression that in more popular languages like Rust - which I use for my projects, I admit - most projects fall into "grep for the 100…
Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal
#86Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal
#87Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal
#88Earlier quoted context omitted.
This is no different from yacc files being prefix by "yy". It makes it easier to spot which files are castle files and avoids collisions with files/units from other libraries. Meaningless nitpick.
Have to agree with the OP here. There may be a handful of yacc files in a large project, so prefixing them with "yy" is convenient to locate them quickly - though I'd still prefer a dedicated subdirectory. Every file in this project is a "castle file", so preceding every name with "castle" is pretty useless and hinders readability and navigation. If it's not part of castle, it shouldn't be checked into the repo.
This goes a long way into avoid namespace conflicts.
Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal
#89[1] https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...
Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal
#90Earlier quoted context omitted.
> The fact that you need to use entire words to denote syntax makes it much harder for your brain to parse things : Instead of immediately seeing "this is code structure" and "this is actual code", you need to actually read the words to make that distinction. It is very counter-productive and a bad design solution, imo. While I agree that it gets slightly tedious to read daily, I have to say that there is no language…
While I'm not the world's #1 Golang fan, this is something that they have. They took a lot of complexity out of the language, so any code you look at will seem very simple & readable. There's not a lot of magic syntactic sugar, you just write things down the simple verbose way. The flip side of that coin is you have to reimplement a lot of things yourself, so any essential complexity that the language doesn't handle…
Also, I hate that in languages with dynamic typing you have to read whole function to understand what type of arguments it takes and what is the return type. Nim is statically-typed, so all the types are properly declared.