Luna Game Pascal

[drezgames]

Hi, yea sure. Thanks. This link!

[SilverWarior]

Just tested your help and it seems that there is a problem in FindMimeType function becouse it always returns empty string when it is checking Mime Type of Java Scripts (.js files). Consequently no Java Scripts are loaded properly. I guess.

[drezgames]

I'm getting 'text/plain' for everything except the image files. I just added this:

if TPath.GetExtension(aURL) = '.js' then
    aMIMEType := 'application/javascript';

Still get those errors.

Interestingly, if you do this: WebBrowser1.Navigate('file:///' + TPath.Combine(TPath.GetDirectoryName(ParamStr(0)), 'HTML\index.html')), it all works as expected. So the Twebbrowser component can execute the javascript, there is something missing here that we need to do when running it through the protocol handler.

I've been goodling/bing'ing for hours, trying different things.... nothing so far. Sigh.

[Akira13]

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

[vgo]

So it seems...

I'd be interested to try it out, I'm looking for a game engine for an isometric project.

[drezgames]

Hi, here are the current builds i have of the project:

OneDrive: link

[Akira13]

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