Leaderboard

We are proud to announce the Castle Game Engine 7.0-alpha.2 release! After 18 months of intensive development since 7.0-alpha.1, we have a lot of new features that upgrade the engine to a new level Castle Game Engine is a cross-platform (desktop, mobile, console) 3D and 2D game engine. We feature a visual editor, we support glTF, X3D, Spine and more. We are of course using modern Pascal (FPC and Delphi). The engine is free and open-source. More complete list of features here. Notable new features in this release: Sprite Sheet editor Many new components in the viewport - primitives, text, image, reference Font components Sound components, ability to design spatial sounds in editor Lights components Background (gradient, skybox) Fog New camera and navigation handling - much more natural, camera is a transformation and can have children and be a child of something else Components to visualize terrains Tested and documented how to use engine with GitHub Actions, GitLab CI, Jenkins Build Debian packages for your project Delphi support! Numerous smaller editor improvements, like double-clicking to open Pascal files at proper file and proper line glTF improvements: step interpolation, cameras fix, normal scale handling, ability to pick a subset of glTF Inspect your game hierarchy and logs at runtime — just press F8 Integration with Vampyre Imaging Library Android building improvements macOS improvements: Cocoa backend in TCastleWindow and more A lot of documentation upgrades This is just a summary of the full release announcement with all the details and plans. In related news, we will host an open meeting on Discord this Saturday. We'll talk about the new features and plans, and it's an open meeting -- everyone can ask questions and show their work too. You are invited We count on your support via Patreon to fund more engine development.

In this case the feature is the ability to write identifiers in Unicode, but I would rather call that an abomination than a feature.

Hi, when you read the title, you probably already had the standard answer in your head: "Does not work with Indy, supports only OpenSSL 1.0.2 at most and thus no TLS 1.3". I can reassure you, that is not my point. Or actually even more precisely: That is exactly my point 😉 I've spent "a little" time writing the Indy support for OpenSSL 1.1.1 and TLS 1.3, and added a push request to Indy: #299. At the same time I have fixed a few issues that have been posted to GitHub (see PR). I wrote 2 new IO handlers ( one for server and one for client), the old ones are unchanged to avoid conflicts. Everything was written and tested in Delphi Berlin 10.1.2 on Win32 and Win64. I have neither macOS nor iOS nor Linux nor Android, nor FreePascal, nor older (or newer) Delphi versions. I have tried to keep older Delphi versions in mind to ensure that it will run on them, but there have been no tests on my part. I have tested it extensively in small test applications with other servers/clients. In addition, I built it into a large Real World program with TCP server/client, SMTP/IMAP/POP clients, FTP client, HTTP client, and it also ran there without problems. Unfortunately the nice man, who has provided new binary files of OpenSSL under indy.fulgan.com has said that he does not offer versions > 1.0.2 anymore. So I used the versions of slWebPro in the beginning (they even still work on WinXP), later I used the versions of Overbyte, because they do not have any external dependencies (and are digitally signed, but no XP anymore^^). But both worked without problems. All files are located in the subfolder "Lib/Protocols/OpenSSL". There are also subfolders "static" and "dynamic" which offers quite extensive imports of the OpenSSL API, once for static linking, once for dynamic loading/unloading. For dynamic loading there are also possibilities in the "IdOpenSSLLoader.pas" to trigger the loading/unloading itself, if you need the API outside of the IO handler (e.g. for your own x509 generation). To save me the double writing of the imports, I wrote a kind of intermediate code in the folder "Intermediate", which I let generate with "GenerateCode" to the two variants. The tool "GenerateCode" is only a simple string customization and actually only designed for Berlin, so I didn't bother about downward compatibility. As a normal user of the IO handlers you don't need them, only if you make changes to the API implementation. So and now comes your. It would be nice if one or the other would test this, so that it is not only WOMM certified, but can withstand more real situations. For me it also works with the Indy, which comes with Delphi Berlin, when I create another unit, which provides some new Indy types and functions. Of course some units have to be adapted locally to use the new unit.

Would be interesting to know what the issue was so that other may solve the same issue.

I have TSplitter interposer in Commons.UI.SyncSplitters unit and method procedure SyncSplitters(aSplitter1, aSplitter2: TSplitter);. So all I do is use the unit and call SyncSplitters - which sets the Siblings, in one method. Perhaps I'm already doing what you are suggesting.

Now i have released a new version of the WP-Plugin. Go to https://dwp.gksoft.ch to download them. Also look at the known issues! The drag and drop does not yet work as I would like it to, because it still has errors in the TControlList

Well, not quoting the entire post would be good start...

10.3 and 10.4 were major versions. Then you got 10.3.n and 10.4.n as incremental upgrades. They changed this with version 11. 11.0, 11.1 and 11.2 are the same version.

Exactly. There should be an option in the Version Info to override what the IDE defaults to (currently 30). I've now added this report to the Quality Portal: https://quality.embarcadero.com/browse/RSP-38976

Sorry, not being specific. Late I found, really by chance, why the code I used procedure TForm110.btnDetailClick(Sender: TObject); // numeric sort on detail var Compare : TFMXObjectSortCompare; begin Tri:=btnDetail.Tag; if btnDetail.Tag=1 then btnDetail.Tag:=0 else btnDetail.Tag:=1; ListBox1.Sorted:=False; Compare:=function(item1, item2: TFmxObject): Integer var n1,n2 : Single; begin n1:=StrToFloatDef(TListBoxItem(item1).ItemData.Detail,0); n2:=StrToFloatDef(TListBoxItem(item2).ItemData.Detail,0); if n2=n1 then result:=0 else begin if n2>n1 then Result := 1 else Result := -1; end; if tri=0 then result:=result*-1; end; ListBox1.Sort(Compare); // here end; seems to be useless. Just resizing the form (to take a picture) 'refreshed' the aligned list. Before solving, I used a BeginUpdate/EndUpdate sequence with no effect ! So that was why I don't understood the usage of list.sort(compare) was not 'working'. A self.width:=self.width+1; self.width:=self.width; confirmed that but was not the solution. Finally, digging in the source code, I found the solution ListBox1.RealignContent; Just after the sort did it. Joined, comparative runtime screens (first alpha sort on text using sorted:=true, second numeric sort on detail using sort(compare) twice to have DESC order)

My main scene using ~500MB ram already, on this scene I have 25 different kind texture but need only 5 live (5 enemy on screen), I can not pre-load all because iPhone 6 devices crash after 645MB usage