If this is your first visit, be sure to check out the FAQ by clicking the link above. You have to register before you can post.

If you have recently signed up, please make sure you log in so that your activity is registered. This is required for automatic promotions to work and to ensure your account is not deleted during the registration process.

Is it just me, or is this like the fourth time in the last decade or so this guy has released what amounts to essentially the same engine (GameEngine, PyroGine, Hadron, now Luna) aggressively marketed it for a short while, and then removed all download links from both the forums and his website and just disappeared? Very bizarre......

Uh, how do you expect this to be useful without the source code? What is anyone possibly supposed to do with nothing other than a 32-bit DLL (with no headers to describe the methods it contains) and an editor that's nothing more than than a really really stripped down objectively worse version of the Delphi IDE?

For starters, it isn't 2005 anymore... the vast majority of people are using x64 machines. 32-bit is legacy. Any engine that doesn't natively support the creation of x64 binaries is useless. You might say, "oh, but 64-bit machines can run 32-bit binaries!" but you don't realize how much slower 32-bit code is on 64-bit machines. Basically 32-bit anything should be avoided at all costs except when absolutely necessary.

I get that your engine is obviously built in Delphi which has rather poor x64 support, but that's kinda your problem for not using FPC instead...

Secondly, to further the point about it not being 2005 anymore: there is absolutely no one who has any interest these days in using a closed-source engine with all of its functionality contained in a dynamic library. And for good reason: it's a terrible design that introduces unnecessary latency (especially with regards to any vector math methods you might have in there.)

Furthermore if your DLL is compiled in Delphi it means that the most recent instruction set used by the compiler is definitely the ancient SSE... whereas if the code was available, anyone could compile it with the relevant CPU optimization flags for their setup all the way up to AVX2.

Lastly, if your overall reason for it being closed source is that you're expecting to actually sell it and make money, you're delusional. It's just not going to happen, ever, I promise. That's not even me being pessimistic: it's just that in 2017 the game engine market is massively over-saturated and you need to be doing some crazy crazy stuff to even have a remote hope of gaining the slightest bit of visibility. (I.E, not using an outdated verson of DirectX to draw a bunch of pedestrian 2D stuff everyone's seen million times before as your engine basically does. Sorry to be blunt... that's just how it is!)

@Akira13
Then you can simply use another product, right?. That is the wonderfully great thing about choices. You asked for the product, that is the snapshot of where its at. There are no plans of being open source. I'm using commercial software/libraries/components to make this product so there is no way it can be open source. It's a shame that you have to be rude AF when you could have simply messaged me privately and I could have explain the situation. But you choose to go the dick'ish route and piss me off. I don't have a problem with people voicing their opinions, but jeez bro, you're acting like I just let you down and prevented you from completing your project. You came at me hard, so yea i'm a little salty right now. Not so much because of your opinion, but more so from your lack of common courtesy. But that is ok, just like 2005 it's good to know that people are still dicks. Sorry to be blunt... that's just how I see it still too.

And furthermore, who are you to dictate how and for whom I make my own projects? You seem to be taking it way more personal than necessary. This is a project that I'm working on and I posted on these forums to get a little feedback. But you come in making all these claims and assumptions. Taking it so personal as if you paid money. Bro, this product is alpha, something I'm working on more so far my own personal use. You're attacking me and making assumptions. You can't dictate to me which development tools I choose to use, really bro? Anyway, after all these years, nothing really has changed around here. I pop in every so often with a project i'm working on (some my own, some 3rd party) just to get some feedback and every time nothing really changes. The state of the community remains the same. This will most likely be my last visit to this site.

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!

Why wouldn't it be useful without the source code?
There are many closed sourced game engines out there like Unity, Unreal Engine etc. and they are still very popular. So why do you think that Luna Game Pascal needs to be open sourced to be useful?

Originally Posted by Akira13

What is anyone possibly supposed to do with nothing other than a 32-bit DLL (with no headers to describe the methods it contains) and an editor that's nothing more than than a really really stripped down objectively worse version of the Delphi IDE?

Sure Luna Game Pascal needs some good documentation and working examples to become more appealing but since it is still in development and being developed by a single developer (as far as I know) you can't explect it to have same features and same quality as some other game engine that is being developed by a team of hundred or more developers.

Originally Posted by Akira13

For starters, it isn't 2005 anymore... the vast majority of people are using x64 machines. 32-bit is legacy. Any engine that doesn't natively support the creation of x64 binaries is useless.

If anything except 64 bit is useless then why do big game engines still support creation of 32 bit games?
Any way I think that 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. Since creating another custom compiler with 64 bit support is not an easy task I'm guessing piradyne might be currently focusing more on other features in order to gain at least some users for his engine.

Originally Posted by Akira13

I get that your engine is obviously built in Delphi which has rather poor x64 support, but that's kinda your problem for not using FPC instead...

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.

Originally Posted by Akira13

Furthermore if your DLL is compiled in Delphi it means that the most recent instruction set used by the compiler is definitely the ancient SSE... whereas if the code was available, anyone could compile it with the relevant CPU optimization flags for their setup all the way up to AVX2.

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?

Why wouldn't it be useful without the source code?
There are many closed sourced game engines out there like Unity, Unreal Engine etc. and they are still very popular. So why do you think that Luna Game Pascal needs to be open sourced to be useful?

To be precise full source of UE4 is available on github.

Originally Posted by SilverWarior

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?

@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?

Originally Posted by SilverWarior

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.

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.

Originally Posted by SilverWarior

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.

Originally Posted by SilverWarior

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

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.