Live data from Hacker News

Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal

castle-engine.io

81–90 of 103 posts

Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal

#81

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)

MM even opensourced it https://github.com/soldat/soldat

Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal

#82

Hah pascal, the first language I learned to script some game named Soldat when I was a kid, fun times

FYI Soldat used/uses PascalScript and had no classes in the beginning (they where added later to the ScriptCore.)

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

#83

Earlier 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

In the meantime the repository moved to: https://github.com/opensoldat/opensoldat After MM sold the game to someone else I felt like it would be better to make sure the name is different as the new owner had different plans and did not want to continue releasing the source code.

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

#84

https://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…

Noticed this on the modern object pascal intro page:

    {$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

#85

I 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…

Except most of that stuff in Free Pascal doesn't really have documentation.

Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal

#87
post #29

I've never commited to going deep on a project in Pascal. Seems a bit too high-pressure for me.

that should be no bar to using it

You're giving me high blood pressure.

A pascal walked into a bar.

Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal

#88

Earlier 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.

And what happens when these castle_xx files have to be combined with files from other libraries?

This goes a long way into avoid namespace conflicts.

Re: Castle Engine – Free open-source cross-platform 3D/2D game engine using Pascal

#89
I like pascal - learnt it in second year if tertiary and used off and on for a while. In my opinion as a bad developer and less-bad product manager FPC is the embodiment of duct-tape programming [1] is only that and c# in which I have seen that ethos in developers.

[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

#90
post #39

Earlier 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…

> Python's decent at this too. It's almost pseudocode. Nim has Python-like syntax. But, I find it even easier to read/parse at a glance than Python.

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.

Post reply on HN