Draw 2D geometry inside CGE editor using Castle Lines 2D components

Posted on

Castle Lines 2D demo
Castle Lines 2D demo
Castle Lines 2D demo
Castle Lines 2D demo
Castle Lines 2D - point details
Castle Lines 2D - points list

I’m thrilled to present Castle Lines 2D, a set of custom CGE components done by Korchazhkin Sergey (KumurTash on GitHub). They extend our Castle Game Engine editor functionality allowing you to draw 2D lines and polygons (possibly textured, possibly non-convex) right inside the editor!

The basic idea is that

  • You add a component TCastleLine2D or TCastlePolygon2D to a viewport,

  • You right click on the component in hierarchy and select “Edit Mode ON”,

  • Then you just click around to add / move / delete points (left mouse click adds/moves, right mouse click deletes).

  • The editor remains fully functional during this, so in particular e.g. zooming or panning the view works as always.

The components are open-source, on GitHub: https://github.com/KumurTash/CastleLines2D. In addition, a great usage documentation (with screenshots) and API reference are available. Go ahead, download it and test!

We have a forum thread open where you can certainly post comments and contact the author.

The polygon does not have to be convex (but it cannot be self-intersecting). It can be textured (and the texture may be repeated and scaled). The line can have non-trivial thickness and also be textured. The way line segments are connected (joints) is also configurable.

It’s really a complete code and documentation that adds to our editor something I personally never even dared to attempt. So seeing this makes my heart warm 🙂 I have to say in general that seeing others adding custom extensions to CGE and just using CGE to make cool stuff is extremely rewarding. So please everyone share what you’re doing in Show Your Projects forum category or Discord channel #show_your_projects 🙂

Comments on the forum ➤

Comfortable Windows installer of Castle Game Engine, plus notes how to integrate InnoSetup with Jenkins and into your own applications

Posted on

Castle Game Engine installer
Castle Game Engine installed on Windows
Castle Game Engine installer
Castle Game Engine installer

Our Castle Game Engine download page now recommends Windows users to download the engine as a self-extracting installer (EXE), which is a typical installation method on Windows.

The installer is done using excellent and popular Inno Setup. It will install CGE to a user directory, like C:\Users\USERNAME\AppData\Local\Programs\Castle Game Engine. The installer automatically creates menu and desktop shortcuts, shows you the license summary, runs CGE editor for the 1st time if you want and generally makes the whole process completely straightforward for Windows users.

This is similar to e.g. VS Code, that also uses InnoSetup and installs for the current user. Note that we don’t install VS Code with CGE (though we may in the future), and as always you have a choice which IDE to use — VS Code, Lazarus, Delphi, Emacs or really any text editor you find suitable to edit Pascal.

As a bonus, unpacking using the InnoSetup is also much faster than unpacking the zip using built-in Windows zip support.

TODO: Note that the installer right now does not make system-wide install. I have an option to activate system-wide installlation for CGE (and the setup can offer you a choice whether to install for current user or system-wide). But it is hidden for now, because system-wide installation means that examples are read-only, and it means you cannot easily explore + just build / tweak the examples. At some point in the future, we should allow you to open example by making a copy of it and then we’ll reenable the option for system-wide installation here. Note that everything else worked smoothly with system-wide installation, the CGE editor and build tool work as usual, our tools in general have always been written to handle the case when they are installed in read-only directory.

Since you know I love automation and CI / CI, of course the whole process of building the installer is automated, and thanks to InnoSetup it was really trivial to automate. So the installer is rebuild using Jenkins after every commit (that passes a number of automated checks) and you always have the installer for the latest CGE snapshot available.

  1. We keep a ISS file describing how to package CGE.

  2. Our pack_release.sh script has an option to, once it prepared the CGE distributable files, instead of zip it can create a setup. To do this, it calls iscc with parameters that define input, output directory, version etc. It looks like this (this is bash script):

    # Detect iscc location
    INNO_SETUP_CLI='iscc'
    if ! which "${INNO_SETUP_CLI}" > /dev/null; then
      # if not on $PATH, try default location
      INNO_SETUP_CLI='c:/Program Files (x86)/Inno Setup 6/iscc.exe'
    fi
     
    # See https://jrsoftware.org/ishelp/index.php?topic=compilercmdline
    # and https://jrsoftware.org/ispphelp/index.php?topic=isppcc (for preprocessor additional options).
    "${INNO_SETUP_CLI}" \
      "${ORIGINAL_CASTLE_ENGINE_PATH}/tools/internal/pack_release/cge-windows-setup.iss" \
      "/O${OUTPUT_DIRECTORY}" \
      "/F${ARCHIVE_NAME}" \
      "/DMyAppSrcDir=${TEMP_PATH}castle_game_engine" \
      "/DMyAppVersion=${CGE_VERSION}"
  3. And that’s it 🙂 Jenkins archives the resulting exe, our scripts copy it to a GitHub release of the next snapshot, and we link to them.

The process was very straightforward I have to say, and in the future we will likely add an easy option to package your games into a self-extracting Windows installer too (using InnoSetup under the hood). For now, you can roll such setup on your own, using the output of CGE package in “directory” format as a start (input for Inno Setup) and following above notes and just Inno Setup documentation.

Comments on the forum (4) ➤

Ton of editor improvements – around views, run parameters, help, drag and drop

Posted on

"Run Parameters" with new FPS game underneath
"New Unit" window
Hierarchy of 3D world

We’ve made a lot of editor improvements lately, including features, fixes and UX improvements. This post goes with big “thank you!” to everyone testing and providing feedback! I am seriously proud of how the engine became much more user-friendly and approachable in the recent months. A number of big changes (big in their impact, but often quite easy to implement) made wonders. UI for many things became straightforward, both for new and advanced users.

And I know it’s not the end — I have a lot of valuable feedback prioritized, and one more big UX thing (this time only for Windows users) will arrive this weekend 🙂

Enough bragging. New things I want to announce today:

  1. “Run -> Run Parameters” menu, with options to disable sound, FPS limit, request window or fullscreen for the next application run. These menu options simply cause appropriate command-line parameters to be passed to the application. We supported these options since ~forever, now they are easy to actually use when working in CGE editor.

  2. Dragging and dropping in the hierarchy of TCastleTransform will preserve their world transformation. For example, if you have a box X with translation, that is a child of transformation Y with some rotation, and you change the parent of X to Z — we will make the world transformation of X stay the same, so it will visually stay at the same place. Internally, the box X translation/rotation will be adjusted to the new parent Z.

    This is similar to how drag and drop in hierarchy of TCastleUserInterface already behaved, so these things (dragging UI and dragging TCastleTransform in hierarchy) are now more consistent.

    Moreover, you can now hold “Ctrl” when dropping to not preserve the world transformation when changing parent. And it affects both dragging UI and TCastleTransform.

    Limitation: We preserve the world transformation only when scale (of the source and destination object, in world space) is identity. Otherwise, our current math cannot preserve the transformation correctly in all cases, so we outright cancel the “preservation” feature when we detect any scaling.

  3. Warnings and error lines are now properly colored in the output.

  4. Drag and drop in the hierarchy is more natural when you want to insert an item as a child of something. Previously it required to drop it over the right side of the item, which was unintuitive (it was non-standard UX and we didn’t inform you about this feature anywhere). Now by dropping over the middle of the row, we understand you want to “drop inside” (insert as child).

  5. We now show in UI a button to invoke context help (for the current class or property). I suspect that most advanced users already know to invoke it using F1. But new users were not aware of this super-useful feature — hopefully much more prominent now.

  6. If you try to remove a component that cannot be removed (e.g. root of the design) we now provide a helpful explanation why it cannot be removed, instead of silently ignoring the command.

  7. New light icons for our tools (translate, rotate, scale etc.) by Adrianna Matejek! Thank you!

  8. Various improvements to “New Unit” dialog, now you just input “base name” and in simple cases let everything else be as default. The dialog also features now new unit with behavior and a better template for view.

  9. The “Design” menu now clearly recommends the “New View” as the most often action you want to start there.

  10. The list of views is now sorted by name (and can be sorted by other columns) once you open the project.

  11. You can close the design with Ctrl+W. The current UI deliberately encourages to browse the views within the project, so exploring them (opening and closing) is natural.

  12. Focus after undo (Ctrl+Z) allows to make next Ctrl+Z immediately. You can undo multiple steps now more reliably.

  13. I added shadows to the default “3D FPS game” template design.

Comments on the forum ➤

Blending sort for scenes, behaviors docs, controlling sound source playing, tooltip control

Posted on

blending_sort
view3dscene viewports

Enjoy new features and a happy New Year! 🙂

(Note: I will not make predictions for next year this time. Because I am hard at work making new Castle Game Engine release, planned for the Christmas that happened last week! 🙂 )

New stuff:

  1. New property TCastleAbstractRootNode.BlendingSort, which you will usually use as MyViewport.Items.BlendingSort, allows to control the blending sorting when multiple scenes may have partially transparent objects.

    The full documentation how to set up blending correctly is here.

    It also supports now new options for sorting 3D objects: bs3DGround, bs3DOrigin. They may be useful in controlling the order better. For blending to work correctly, the engine must be able to decide what TCastleTransform in the front correctly.

  2. You can now control the TCastleSoundSource playing of its main sound using TCastleSoundSource.SoundPlaying property.

    It is documented in manual about sound.

    It is also used by the sample footsteps component, shown in new documentation about behaviors. It is, in turn, used by my “Lynch” game demo — it proved to be very useful.

  3. New property TCastleUserInterface.TooltipControl allows to control how does the tooltip look (and work).

    It is used by new new view3dscene versions with slicker buttons 🙂

Credits: level with trees from CGE #427 by Freedomax, Bronze figurine of Cthulhu from Sketchfab by Jedi2583.

Comments on the forum ➤

Summary of the New Physics Capabilities

Posted on

Physics hinges
Physics 3D shooter
Physics asteroids demo
Physics in 2D platformer
Physics explosion
Physics 3D demo

At the beginning of December we merged a big work on physics (and many related features) and later we merged another big work on physics joints (another big merge, 363 commits). It’s time to provide to you some readable summary of all the improvements 🙂

I also wrote a nice documentation about physics. And remember that we feature a lot of physics examples.

New physics (and related) features:

  1. New components, available in both editor and code, to control the physics.

    Just add to any TCastleTransform (usually to TCastleScene or a primitive like TCastleBox, TCastleSphere) some collider in the editor (the rigid body will be automatically added too), and observe that it’s affected by

    • gravity
    • collisions with other objects

    There are lots of options to tweak how things behave. See API docs for documentation.

    Hint: If you’re like me, the first thing you will want to make is a “bullet” that hits something with some speed, so that you can see how it behaves on collision. To make a bullet, just set TCastleRigidBody.LinearVelocity on the bullet object to something non-zero.

  2. New components have also additional features, like:

  3. Colliders are also visualized. Juse use “Physics->Show Colliders” menu item.

  4. There’s a new “Physics Simulation” mode available in the editor. Start it to make physics work. You can click around and modify the design even while the physics is running — this is a feature, albeit a bit dangerous one: the design is restored to the original state when physics stops.

    This is a great way to test how physics behaves without the need to actually run the game.

    Remember that it only runs physics simulation. In the future, more components may behave differently in this simulation. But it doesn’t run your project’s code (unless you put it into a custom component added to the project).

  5. There is a new API to apply forces from code. This can be used to simulate forces other than gravity. For example wind or explosion.

    See demo physics_forces to test out various method to apply forces.

    See demo physics_persistent_forces_components to see example forces components we can make. This is like Blender’s forces to make wind etc.

  6. Third person navigation:

    TCastleThirdPersonNavigation component got a significant upgrade that enables it to change transformation through physically-aware methods. By using physics to “drive” the navigation you get much more natural (physically-correct) movement and jumping.

    The way we change transformation is controlled by new TCastleThirdPersonNavigation.ChangeTransformation property. By default is has ctAuto value, which provides the most recommended way: if you have physics components (TCastleRigidBody, TCastleCollider) on avatar, we change using velocities, otherwise (this is backward-compatible) we change transformation directly.

    See TCastleThirdPersonNavigation.ChangeTransformation and TChangeTransformation docs for more details.

    third_person_navigation example was remade to use physics for movement. You can test various ChangeTransformation values.

    Going forward, we want to remake all our navigations to use physics. In particular, TCastleWalkNavigation (to walk/fly) will get a similar option soon too.

  7. Changing the transformation (like TCastleTransform.Translation) of an object affected by physics is now more reliable. You can do it even if TCastleRigidBody.Dynamic=true (although you should refrain from doing it every frame — the entire point of TCastleRigidBody.Dynamic=true is that you allow physics to affect it).

    TCastleRigidBody.Animated is now really only an “optimization hint” passed to Kraft (determines if we should set body as krbtKinematic or krbtStatic, when Dynamic = false). It has no other effect on CGE code functioning.

    In particular, we allow changing TCastleTransform from code regardless of whether TCastleRigidBody.Animated = true or false.

  8. We have new and powerful methods TCastleAbstractRootTransform.PhysicsRayCast and TCastleRigidBody.PhysicsRayCast. They return TPhysicsRayCastResult packed with information.

    Previously we only had TCastleRigidBody.PhysicsRayCast (new TCastleAbstractRootTransform.PhysicsRayCast allows to use it without starting from any particular TCastleRigidBody) and it didn’t return Point, Normal information.

    Also examples/viewport_and_scenes/collisions/ was extended to show PhysicsRayCast.

  9. The editor has now big buttons to

    • play / stop physics simulation
    • play / stop the application

    from the CGE header. Stopping the application (this also applies to “Run -> Stop External Process”) is also more robust now (we make sure to kill the final application, not only build tool process, in case of “castle-engine run“).

  10. Utility FindAllBehaviors (see physics_explosion for demo)

  11. Editor adjusts to dark theme (if you request it from your OS) better.

  12. We define new useful methods to override on behaviors, making behaviors more useful:

    procedure ParentAfterAttach; virtual;
    procedure ParentBeforeDetach; virtual;
    procedure WorldAfterAttach; virtual;
    procedure WorldBeforeDetach; virtual;
  13. Finally, physics objects also support joints to connect and constrain rigid bodies.

  14. Deprecation notice:

    For now, the old physics components (TRigidBody, TCollider) still exist, and the way to assign them still works (TCastleTransform.RigidBody, TRigidBody.Collider, TCollider.Create(const AParent: TRigidBody)).

    But, as the relation of old and new physics components can be a bit confusing, I would like to remove them rather sooner than later, likely before the 7.0 release. Please upgrade your physics usage to new components ASAP, and let us know on forum/Discord if you have any questions about how to upgrade!

    The TCastleTransform.Collides now has no effect on physics. Previously it had inconsistent effect on physics (TCastleTransform.Collides prevented collisions when exactly this TCastleTransform had a rigid body+collider, but TCastleTransform.Collides of parent didn’t matter).

Comments on the forum ➤

TUIState is now TCastleView, methods to change the view are now part of Container, new slick UI when opening the project

Posted on

Platformer game view
Editor UI to open existing views

We have an important change to one of our most important concepts: states (TUIState descendants) are now called views (and descend from TCastleView).

It’s a change in terminology, and a change in API. While previously you were changing states using class functions and properties, like TUIState.Current := Xxx, now you should use regular container methods, like Container.View := Xxx.

Oh, and to this we add a new slick UI when opening the project 🙂

Why?

It addresses two things:

  1. The name “state” was too generic and thus meaningless. Almost every variable and object instance in your application can be called some “state”.

    It made sense if you think “user interface state” or “state of a state machine… but the sole word “state” is too generic.

    Moreover, TUIState class name is not consistent with CGE naming. And TCastleUIState or TCastleUiState are too convoluted. So for a long time I knew it will have to be renamed to TCastleState or TCastleView. I finally finished the work to go with TCastleView.

    “View” doesn’t seem too bad name. It clearly communicates it’s something visual and is a way to “see” CGE stuff. And, view isn’t that often used as a noun, so when someone says “This view is amazing” you can fairly safely assume they talk about TCastleView (assuming you’re in the middle of CGE manual, not on a hiking trip 🙂 ).

    It is consistent e.g. with React view.

  2. The way we changed states, using TUIState class methods/properties, could be improved to use simple methods on Container.

    This way there’s often no need to know what is the “central” container (TCastleControl.MainControl is now deprecated) and every container has it’s own, separate, state stack (or rather: view stack now). This makes things simpler if you try to use multiple containers or TCastleControl (whether for LCL, VCL or FMX). You can just do

    MyControl.Container.View := PlayGame;

    instead of

    TCastleControl.MainControl := MyControl;
    TUIState.Current := PlayGame;

    This is already reflected in new TCastleControl docs.

Upgrading

This change is 100% backward-compatible. The old code will continue to work, though we advise you to upgrade to new names and container methods/properties.

In total, the upgrade path in typical applications is rather straightforward, although it will require to do a lot of replacements (I recommend to commit everything to your version control before doing the upgrade, and then have a nice diff to audit with state->view upgrade):

  1. Rename TUIState -> TCastleView.

  2. Remove CastleUIState unit from your uses clause. Make sure unit CastleUIControls is there (it likely is there already).

  3. Change in ApplicationInitialize:

    TUIState.Current := ...

    to

    Window.Container.View := ...
  4. Change in various states (views):

    TUIState.Current := ...
    TUIState.Push(...)
    TUIState.Pop(...)

    to (respectively)

    Container.View := ...
    Container.PushView(...)
    Container.PopView(...)
  5. Optionally, as a final touch: rename your units and designs.

    Previously we called them gamestatexxx . With class like TStateXxx, with variable like StateXxx.

    Now we advise to call them gameviewxxx . With class like TViewXxx, with variable like ViewXxx. If you choose to go with rename, you will likely find that a general interactive rename state->view, and accepting 99% of the replacements, it the way to go.

    You can just rename them everywhere. Remember that the unit also refers to the design, doing something like

    DesignUrl := 'castle-data:/gamestatemain.castle-user-interface';

    So if you rename both the unit and design (which we recommend, to keep F12 working nicely in CGE editor) then change also that line of code to

    DesignUrl := 'castle-data:/gameviewmain.castle-user-interface';

New editor UI when opening new project

This is accompanied by a cool upgrade to our CGE editor UI. It happened because of independent reasons (I did UX testing on a live human at Christmas :), and came back with lots of nice conclusions) but it is nicely connected with the whole views terminology.

Now, when opening any project, you will be greeted with a UI to

  • compile and run / stop the project
  • create a new view (Pascal unit and design)
  • open an existing view

This UI emphasizes your most recommended actions after opening the project.

Docs

Our documentation, including important chapters about view events and managing views, has been upgraded to new terminology.

Our examples are also fully upgraded now to use view terminology everywhere.

Comments on the forum (4) ➤

“Lynch” gamejam game release on itch.io, nice example code for footsteps and some creepy game logic

Posted on

"Lynch" game
"Lynch" game
"Lynch" game in CGE editor
"Lynch" game in CGE editor
"Lynch" game in CGE editor

“Lynch”, my gamejam game done using Blender and CGE, is now on itch.io — https://cat-astrophe-games.itch.io/lynch. Easy download for Windows and Linux.

The full source code and data are available on GitHub.

I did some cool post-gamejam improvements:

  1. Added sounds: new ambience, footsteps, statue sound.

    The demo code shows my recommended approach to add footsteps sound for 3D walking game, see the TFootstepsBehavior class in GameBehavior unit.

  2. Added 2 water surfaces.

  3. Added some creepy logic for the statues behavior 🙂

    The code of it is again quite nice and you can reuse it for your projects. It is in GameBehavior unit. I will let you figure out on your own what is exactly this “creepy logic” :), just play the game!

  4. Fixed octree creation (the roof was extremely high-poly by accident, at it was causing problems).

    I also added better facility to debug such things in CGE. Octree creation for shapes happens now reliably on load, and you can debug what is taking the most time by using our profiler. Just set Profiler.Enabled := true and look at log.

Comments on the forum ➤

Summary of 4th open meeting – physics, Pascal LSP, Android on-screen keyboard, near release plans, QuickJS; announcing 5th meeting

Posted on

4th Open Meeting
4th Open Meeting
4th Open Meeting

With so much going on around the engine, I barely have time to write it all down in news 🙂

First of all, we had our open meeting on Discord 2 weeks ago. A short summary:

  1. I showed our new physics features. You know, the things merged in that huge merge right before the meeting 🙂

    (Since the open meeting, I have actually merged the 2nd big part of this work: physics joints!)

    The documentation how to use physics is available along with a lot of examples in the engine examples/physics subdirectory.

  2. I showed our Pascal LSP, to provide intelligent code completion in Visual Studio Code and other editors.

  3. I showed other small features:

  4. We showed some things in progress:

  5. I described some plans. I guess the most important — release a new CGE version around Christmas (hey, so it’s really soon! 🙂 ).

    Then release 7.0 in January 2023. Most important things to finish: new materials components, AI behaviors, Steam integration.

  6. Then Coldzer0 gave us a great update about the progress about using Castle Game Engine from JavaScript through QuickJS.

    It exposes a really nice and comfortable JS API. And you can create instances, assign callbacks, and generally have the same power as CGE in Pascal.

    More information about it will come as available. My recommendation: look into scaling the implementation, to account for our 100+ classes and components :), and look into porting e.g. “3D FPS Game” template to JS.

I would like to immediately announce next open meeting: 5th Open Meeting: Spring 2023. Join us March 18th (Saturday), 2023. At the usual hour 15:00 UTC. Go ahead and click on the link to the meeting on Discord, there you can click “I’m interested”, see it in your timezone and add to the calendar.

Comments on the forum ➤

Watch tomorrow Castle Game Engine presentation at Embarcadero CodeRage 2022

Posted on

Enterprise CodeRage 2022

You’re welcome to watch Michalis presentation tomorrow, December 21, at Embarcadero Enterprise CodeRage 2022.

The topic of the presentation is using Castle Game Engine as a 3D visualization tool that you can add to the existing Delphi applications. As part of it, I also want to show for the first time a new feature, requested a few times by Delphi users — yeah, you guessed it, a CGE control you can put on FMX or VCL form! Of course, the talk will also feature a general overview of the engine capabilities, regardless of how you want to use it.

The hour is 3:00 PM in CST (Central Standard Time (US)).

The event is free, you can register a seat following this link or just watch a live stream on YouTube Embarcadero channel.

Comments on the forum ➤

My mind is blown. I can use AI to generate Castle Game Engine code to integrate it with PhysX. I can use AI to generate HTML documentation from comments in Pascal code.

Posted on

ChatGPT generating Pascal code integrating PhysX with Castle Game Engine
ChatGPT generating Pascal code integrating PhysX with Castle Game Engine
ChatGPT generating HTML documentation for Pascal source code
ChatGPT generating HTML documentation for Pascal source code
ChatGPT generating HTML documentation for Pascal source code

My mind is completely blown by the capabilities of OpenAI chat bot ChatGPT. It can tell jokes, invent stories and protagonists, write documents with game pitches, play an RPG game with you, pretend to be a virtual machine with an access to an Internet in a weird alternate universe (I checked, it works, you can even do wget https://castle-engine.io in that universe)…

Here are some interesting experiments with relation to Castle Game Engine and Pascal.

Integrating Castle Game Engine with PhysX

PhysX is a physics library from NVidia. It is not integrated with Castle Game Engine as of now. We use Kraft physics engine in CGE now.

As far as I know, no one has ever attempted so far to integrate PhysX with Castle Game Engine. Internet search doesn’t show any results even for PhysX in any Pascal application.

Yet AI can write ready code to do it..

My prompt: Write Pascal code implementation integrating PhysX with Castle Game Engine.

Bot answers:

uses CastlePhysX, CastleVectors;
 
var
  World: TPhysXWorld;
  Actor: PxActor;
  rigid_dynamic: PxRigidDynamic;
  shape: PxShape;
  material: PxMaterial;
  transform: PxTransform;
  pose: TPose;
  velocity: TVector3;
 
begin
  World := TPhysXWorld.Create;
 
  material := World.CreateMaterial(0.5, 0.5, 0.1);
  shape := World.CreateBoxShape(TVector3.One, material);
  transform := PxTransform.Create(PxVec3.Create(0, 10, 0), PxQuat.CreateIdentity);
  rigid_dynamic := World.CreateRigidDynamic(transform);
  rigid_dynamic.AttachShape(shape);
  World.AddActor(rigid_dynamic);
  actor := rigid_dynamic;
 
  velocity := TVector3.Create(0, -1, 0);
  rigid_dynamic.SetLinearVelocity(PxVec3.Create(velocity.X, velocity.Y, velocity.Z));
 
  repeat
    World.Simulate(0.016);
    World.FetchResults(true);
 
    pose := actor.GlobalPose;
    Writeln('Actor position: ', pose.Position);
  until pose.Position.Y < 0;
 
  World.Free;
end.

It also added a short explanation. See the screenshots.

AI just integrated 2 libraries, never ever before integrated in the whole history of the universe.

Sure, there are a lot of problems with this code. It doesn’t really compile, the usage of TVector.One is wrong, there’s no unit called CastlePhysX

But it’s like written by a programmer that knows CGE, knows PhysX and understands the core of the task. And was just too lazy to check on some API details.

  • It is using CGE vectors API,

  • It is using PhysX API (DuckDuckGo confirms that PhysX has concepts like PhysXWorld, PxTransform, PxRigidDynamic).

  • It runs the simulation ~60 times per second, and uses Pascal Writeln to output the result. It added initial velocity to the object, to observe that it changes position. This is exactly what I would do in my first attempt at such application, to test the integration.

Next day, I realized I can ask it to fill the remaining stuff. I can say things like “Given the Pascal example as below: … , implement CastlePhysX unit”. Yes it works. I still didn’t reach a complete code that compiles… but wow. This is impressive.

Generating HTML documentation from Pascal source code (like PasDoc)

Let’s try something else. Let’s make it perform the job of PasDoc.

My prompt: Generate HTML documentation for the Pascal class declared as below:

(here I pasted actual long multi-line code declaring the TCastleButton class, cut down to public and published sections)

Answer with complete HTML code that can be easily copied and pasted.

It answered…

Here is the HTML documentation for the TCastleButton class:

TCastleButton is a class that represents a button user interface element in the Castle Game Engine. It is derived from TCastleUserInterfaceFont and therefore has all the properties and methods of this class.
Constants

    DefaultImageMargin: Default distance between the text and the image on the button.
    DefaultPaddingHorizontal: Default horizontal padding of the button.
    DefaultPaddingVertical: Default vertical padding of the button.
    DefaultLineSpacing: Default line spacing for multi-line captions.
    DefaultTextAlignment: Default horizontal alignment of the caption text.

Constructors

    Create(AOwner: TComponent): Creates a new instance of TCastleButton.

Destructors

    Destroy: Destroys the TCastleButton instance and frees its resources.

Procedures

    Render: Renders the button on the screen.
    Press(const Event: TInputPressRelease): boolean: Called when the button is pressed.
    Release(const Event: TInputPressRelease): boolean: Called when the button is released.
    Motion(const Event: TInputMotion): boolean: Called when the mouse moves over the button.
    FontChanged: Called when the font of the button changes.
    VisibleChange(const Changes: TCastleUserInterfaceChanges; const ChangeInitiatedByChildren: boolean = false): Called when the visibility of the button changes.
    EditorAllowResize(out ResizeWidth, ResizeHeight: Boolean; out Reason: String): Determines whether the button can be resized in the editor.
    PropertySections(const PropertyName: String): TPropertySections: Returns the property sections for the button.
    DoClick: Called when the button is clicked.
    SetFocused(const Value: boolean): Sets the focus state of the button.

Properties

....

Next prompt: Show me the HTML markup of the above.

Bot answered with HTML markup…

Here is the HTML markup for the documentation of the TCastleButton class:

<h3>TCastleButton</h3>
 
TCastleButton is a class that represents a button user interface element in the Castle Game Engine. It is derived from TCastleUserInterfaceFont and therefore has all the properties and methods of this class.
 
<h4>Constants</h4>
 
<ul>
  <li>DefaultImageMargin: Default distance between the text and the image on the button.</li>
  <li>DefaultPaddingHorizontal: Default horizontal padding of the button.</li>
  <li>DefaultPaddingVertical: Default vertical padding of the button.</li>
  <li>DefaultLineSpacing: Default line spacing for multi-line captions.</li>
  <li>DefaultTextAlignment: Default horizontal alignment of the caption text.</li>
</ul>
 
<h4>Constructors</h4>
 
<ul>
  <li>Create(AOwner: TComponent): Creates a new instance of TCastleButton.</li>
</ul>
 
<h4>Destructors</h4>
 
<ul>
  <li>Destroy: Destroys the TCastleButton instance and frees its resources.</li>
</ul>
 
<h4>Procedures</h4>
 
<ul>
  <li>Render: Renders the button on the screen.</li>
  <li>Press(const Event: TInputPressRelease): boolean: Called when the button is pressed.</li>
  <li>Release(const Event: TInputPressRelease): boolean: Called when the button is released.</li>
  <li>Motion(const Event: TInputMotion): boolean: Called when the mouse moves over the button.</li>
  <li>FontChanged: Called when the font of the button changes.</li>
  <li>VisibleChange(const Changes: TCastleUserInterfaceChanges; const ChangeInitiatedByChildren: boolean = false): Called when the visibility of the button changes.</li>
  <li>EditorAllowResize(out ResizeWidth, ResizeHeight: Boolean; out Reason: String): D
 
<h3>TCastleButton</h3>
 
TCastleButton is a class that represents a button user interface element in the Castle Game Engine. It is derived from TCastleUserInterfaceFont and therefore has all the properties and methods of this class.
 
<h4>Constants</h4>
 
<ul>
  <li>DefaultImageMargin: Default distance between the text and the image on the button.</li>
  <li>DefaultPaddingHorizontal: Default horizontal padding of the button.</li>
  <li>DefaultPaddingVertical: Default vertical padding of the button.</li>
  <li>DefaultLineSpacing: Default line spacing for multi-line captions.</li>
  <li>DefaultTextAlignment: Default horizontal alignment of the caption text.</li>
</ul>
 
<h4>Constructors</h4>
 
<ul>
  <li>Create(AOwner: TComponent): Creates a new instance of TCastleButton.</li>
</ul>
 
<h4>Destructors</h4>
 
<ul>
  <li>Destroy: Destroys the TCastleButton instance and frees its resources.</li>
</ul>
 
<h4>Procedures</h4>
 
<ul>
  <li>Render: Renders the button on the screen.</li>
  <li>Press(const Event: TInputPressRelease): boolean: Called when the button is pressed.</li>
  <li>Release(const Event: TInputPressRelease): boolean: Called when the button is released.</li>
  <li>Motion(const Event: TInputMotion): boolean: Called when the mouse moves over the button.</li>
  <li>FontChanged: Called when the font of the button changes.</li>
  <li>VisibleChange(const Changes: TCastleUserInterfaceChanges; const ChangeInitiatedByChildren: boolean = false): Called when the visibility of the button changes.</li>
  <li>EditorAllowResize(out ResizeWidth, ResizeHeight: Boolean; out Reason: String): D

Yes, it’s a real HTML code. It’s cut — just a limitation of free ChatGPT version I guess, they limit the length of the answer.

It performed the basic job of PasDoc (convert Pascal code with comments -> HTML)….

Holy f**.

Comments on the forum ➤