Luna Game Pascal

[Akira13]

@Akira13
I know that if I had something to say like that, I would have message you privately and in a more professional manner. The one thing you learn as you live life, is that it's the wrong assumption to assume the people will conduct themselves in a like manner as yourself. Sigh!

Admittedly I was a little more aggressive in that message than necessary. I wasn't really "asking" for the "product" though, nor was I personally that interested in it (as it's just a rehash of the same thing you've been posting forever.) I was simply pointing out that you have been following this cycle of releasing essentially the same thing over and over again and then just randomly disappearing and going scorched earth on all links to any downloads for the better part of a decade. Which is extremely odd behaviour IMO, that you've still never attempted to explain. Also, given the fact that it has virtually identical example demos as what you posted as far back as 2010 and earlier, calling it an "alpha product" is rather disingenous as the codebase is obviously years old, don't you think?

You say this like FPC is the only way to go. But it isn't.
Sure Delphi has some flaws but so does FPC. Neither of them is perfect. If one of them would have been perfect then entire Object Pascal Programming community would have switched to that tool already.

It kinda is these days for stuff that falls into the category of what PGD is focused on (i.e. games and other "high-performance-required" 2D and 3D graphics applications.) Delphi's RTL and VCL are certainly more expansive than the FCL and LCL, I don't think anyone would question that, but FPC itself is a massively better compiler than DCC32 that produces far faster code.

Not true. As you can read in the Stack Owerflow question bellow Delphi does also support newer instruction sets.
https://stackoverflow.com/questions/...e-instructions

Don't think you understood my point. Yes, you can use newer instruction sets in Delphi if you're writing assembly by hand. The Delphi compiler however does not, cannot, and will not make use of anything higher than SSE (or SSE2 with the 64-bit version, occasionally) when generating ASM from Pascal code in the process of compiling an actual "normal" executable. Compare this with FPC where you can simply set the optimization flag relevant to your CPU (which go all the way up to AVX2, again) and the compiler will attempt to make the best use of instructions up to that set that it can.

Any way I thinkthat piradyne would love to offer 64 bit support but from what I have seen it seems that Luna Game Pascal has its own custom compiler.

lol "custom". I guarantee you he's just using the PaxCompiler Delphi component, which does in fact support the 64-bit Delphi compiler.

Any way @Akira13 if you know so much about game engines and how they "should" be made why don't you take reign as project leader of PGDCE and help by leading comunity into making one of the best game engines for Object Pascal?

Obviously this is a "if you're so great why don't you do XYZ thing" sort of suggestion, but I have actually dug around the PGDCE codebase quite a bit in the past year or so... IIRC I had gotten pretty far with replacing that include-file nightmare "template" library it uses with real generic containers from Generics.Collections, and had also begun making a pass at converting the various vector-math records from using free-standing comparison functions to using overloaded internal "class" operators.

If there was any real interest I'd be more than happy to make finishing what I was working on in that regard a personal priority, and then deciding where to go from there. (I think I'd probably look at getting rid of the deprecated fixed-function matrix manipulation routines that the main OpenGL renderer used, next. I mean, it doesn't make a lot of sense to name it TCEOpenGL4Renderer when it calls glLoadMatrixF, glScaleF, e.t.c....)

[SilverWarior]

but I have actually dug around the PGDCE codebase quite a bit in the past year or so... IIRC I had gotten pretty far with replacing that include-file nightmare "template" library it uses with real generic containers from Generics.Collections, and had also begun making a pass at converting the various vector-math records from using free-standing comparison functions to using overloaded internal "class" operators.

If so why haven't you posted any of the changes you made back to Github repository? Perhaps there would be more interest from others if they would know that someone is working on PGDCE at the moment. But until now I haven't seen any indication that you are working on PGDCE and I'm checking PGD forums almost on a daily basis.

[Akira13]

If so why haven't you posted any of the changes you made back to Github repository? Perhaps there would be more interest from others if they would know that someone is working on PGDCE at the moment. But until now I haven't seen any indication that you are working on PGDCE and I'm checking PGD forums almost on a daily basis.

I had simply downloaded it a while ago and was working on it locally. I was aware that the original team for the engine for some reason cared about supporting Delphi 7 (which obviously has no generics or operator overloading) meaning none of the changes I was making would be usable. It was just sort of a fun side-project for me.

That being said, again, I'd be perfectly happy to do some "real" development on the repo and commit the changes I'd made personally if anyone was interested (after cleaning them up, haven't looked at them for a while), if it is in fact the case that people have finally realized that Delphi 7 came out in 2002 and is not something that anyone should care about supporting anymore. Also, a game engine that actual game developers might actually want to use in 2017 needs to support OpenGL 3.3+ as the default/base, with MAYBE an OpenGL 2.0 "fallback" (although personally I'd leave it out...) Leave the OpenGL 1.0 fixed function stuff "at home", as they say...

[laggyluk]

That being said, again, I'd be perfectly happy to do some "real" development on the repo and commit the changes I'd made personally if anyone was interested (after cleaning them up, haven't looked at them for a while), if it is in fact the case that people have finally realized that Delphi 7 came out in 2002 and is not something that anyone should care about supporting anymore. Also, a game engine that actual game developers might actually want to use in 2017 needs to support OpenGL 3.3+ as the default/base, with MAYBE an OpenGL 2.0 "fallback" (although personally I'd leave it out...) Leave the OpenGL 1.0 fixed function stuff "at home", as they say...

I guess dropping D7 and moving away from old GL wouldn't be much of a problem since those interested in them also wore out and don't contribute anymore

[Akira13]

I guess dropping D7 and moving away from old GL wouldn't be much of a problem since those interested in them also wore out and don't contribute anymore

I'm not really sure what your point is here, or whether you're agreeing or disagreeing with what I had said... but in case of the latter (or even if not, as I know there are others who do still believe D7 is the best thing since sliced bread, even if you're not one of them), here's what I think:

The bottom line is that while yes, the merits of the newer, 2009+ Delphi versions versus FPC/Lazarus can certainly be debated, the merits of Delphi 7 vs FPC/Lazarus can't be. FPC/Lazarus is objectively better than Delphi 7 in every possible way by a huge margin. Anyone still using Delphi 7 who doesn't want to pay for a newer Delphi version should just switch to Lazarus, end of story. It is a massive upgrade for zero dollars. There's no logical argument to the contrary. (I say this as someone who used Delphi 7 professionally at the time of its release and for years afterwards, by the way. You could not pay me enough to go back to using it after having used Lazarus and newer Delphi versions for as long as I have since.)

So, adding generics/operator overloading/e.t.c to the engine would not actually be excluding anyone, because if they didn't have access to a 2009+ Delphi version they could just use FPC/Lazarus instead, as it supports all the same modern features. (And indeed, using it with FPC would be the first choice of a large number of people, as opposed to a secondary option after Delphi.) Look at something like Castle (which arguably IS the best Object Pascal game engine there is, currently): it only very recently began to make moves towards supporting any form of Delphi at all, and for most of its existence has only supported FPC.

Have you ever seen anyone complaining about that? No, because there is pretty much no real person that is both highly interested in using Pascal for game development, and also completely dead-set on using Delphi 7. Even when Castle does get to a point where it could be considered to have "full" Delphi support, it still absolutely will not support pre-2009 Delphi versions as it makes heavy use of generics and operator overloading. Again though, you won't see anyone complaining, because there isn't actually anyone who sees this as a problem. As I said yesterday, Delphi 7 came out in 2002. It's 15 years old!

How much other 15-year-old computer software or hardware do you use in your daily life? Likely none. What's different about D7 that merits it an exception? Nothing, in reality. It's horribly outdated, and it's not remotely reasonable for anyone to assume that it should still be as usable in all cases as it was when they first got it. Nor do I remotely understand why they'd want to keep using it. Have you actually tried to develop anything in it recently? It's not a good user experience, at all, unless you're wearing several pairs of rose-tinted glasses.

Lastly, to your point about "old GL": I don't think the engine was really trying to use it in the first place. It just had it in a few strange spots, presumably as placeholders. Someone with a GPU that did not support at least OpenGL 2.0 (which is virtually no one) would not have actually been able to run anything written in it anyways.