eugeneloza/castle-engine

Castle Game Engine code and examples

Castle Game Engine

"Castle Game Engine" ( https://castle-engine.io/ ) is an open-source 3D and 2D game engine.

We have many graphic features (shadows, mirrors, screen effects...) and support many data formats for game assets (X3D, VRML, Collada, Spine...). We have a nice scene manager, with many optional components (like instant creatures with simple walking and attacking intelligence). We're cross-platform (desktop, mobile, web browser plugin).

See https://castle-engine.io/features.php for the complete list of engine features.

Documentation:

• The "Getting Started" page on https://castle-engine.io/documentation.php describes what to install and how to compile. See also the section below.

• Manual: See https://castle-engine.io/manual_intro.php .

• API reference: Online on https://castle-engine.io/apidoc/html/index.html . Offline in doc/reference/ subdirectory of the engine archive (if you downloaded the zip or tar.gz engine release), just open the file doc/reference/index.html in your WWW browser.

• Numerous examples are provided in the examples/ subdirectory. For example take a look at a simple FPS game example in the examples/fps_game/ subdirectory.

• Guide to creating game data: https://castle-engine.io/creating_data_intro.php

Questions? Ask on our forum: https://castle-engine.io/forum.php .

Support us on http://patreon.com/castleengine .

Compiling

Get Lazarus ( http://www.lazarus.freepascal.org/ ) and install in Lazarus two packages:

• packages/castle_base.lpk and
• packages/castle_components.lpk

Also, compile (but don't install) this package:

• packages/castle_window.lpk

Now you can compile and run all the examples by opening their .lpi files and running them as usual from Lazarus.

If you prefer to use bare FPC and the command-line, you can:

• Use the build tool to compile various examples and your own games for many plaforms: https://github.com/castle-engine/castle-engine/wiki/Build-Tool .

  It relies on the existence of CastleEngineManifest.xml file inside your project. The build tool allows to comfortably compile and package your game for various platforms, including Android and iOS.

• Or use xxx_compile.sh scripts to compile particular programs using FPC. Use make examples in the top engine directory to simply compile all the examples.

See the "Getting Started" page on https://castle-engine.io/documentation.php for more information.

License

The engine is available on the terms of LGPL >= 2 license with "static linking exception". This is the same license as used by FPC RTL and Lazarus LCL. In short, you can make commercial and closed-source games using the engine, you only have to share your modifications to the engine core. See COPYING.txt for details.

Have fun!

Michalis Kamburelis

castle-engine's Issues

Joystick problem in Windows

castle-engine#30

Joystick test program

castle-engine#31

Use CastleRandom in the Engine

castle-engine#64

Test speed of gzip/non-gzip reading/writing

castle-engine#55

Can't change CastleWindow size when open

castle-engine#36

Log improvement

castle-engine#68

Improve keyboard handling for UTF8 and other encodings

/As the issue is getting larger I'll try to copy everything here/

eugeneloza - Today at 8:11 AM
It looks like I am unable to input Russian/Ukrainian characters into TCastleEdit (while its default is AllChars)...?

michalis - Today at 10:06 AM
@eugeneloza The input of Russian/Ukrainian probably fails because we currently limit the input to things that can be expressed as Pascal "char". In particular, TInputPressRelease.KeyCharacter is a "char", along with some related properties. I'm guessing that some Russian/Ukrainian characters can only be expressed as multi-byte sequences in UTF-8, and thus they can be only expressed as AnsiString, not "char", in TInputPressRelease. Pull requests to fix this are welcome, of course -- please keep the TInputPressRelease.KeyCharacter working as char (for compatibility), but also add something like TInputPressRelease.KeyString: string that can express the typed character as a string (encoded using UTF-8, as all strings in CGE). Various CastleWindow backends will need to be adjusted to actually pass some useful content for KeyString.

eugeneloza - Today at 10:07 AM
Hmmm... Cyrillic keypresses don't generate OnPress at all!
Testing: OnPress for Cyrillic is generated in Windows but not in Linux
Ok. I finally get it. In Windows we receive 1-byte Win1251 char, and in Linux - UTF8 char, which is longer than 1 and therefore dropped. Not as easy as I'd think, I'll try to get how to extract the current OS encoding in Windows...
Ok. That seems to be relatively easy to do in GTK, but I'm really unsure how to fix that in Windows. I only wonder, why GTK reports Cyrillic keypresses as K_None... hmm... I might have an idea.

michalis - Today at 1:57 PM
@eugeneloza The TKey enumeration does not support all the possible characters. It is supposed to be used to represent "physical keys", not characters. So it's normal that some combinations may result in TKey=K_None, but with some meaningful character.
Indeed, as you found out, solving this requires dealing with encoding. You need to extract the key string as UTF-8. Lazarus does it too, so there must be a way (and you can probably peek how in Lazarus sources 😃 ).
eugeneloza - Today at 2:00 PM
@michalis should I modify GdkKeysymToKey to do that (yes, it has the corresponding keys of Cyrillic and other alphabets)? E.g. we can secure that GDK is always mapped at correct Latin keys (e.g. Russian Ы = Ukrainian і = keyboard s key)? This would create a huge case but should preform nicely - while returning the correct string for each native letter it will not break game controls which are bound to Latin keys and will require no modifications of Key_***. WDYT?
(Thou I'll be able to map only keyboard keys I'm aware of: Not Arabic or similar)
Or we may use Event^.hardware_keycode, thou I am unsure how it will behave on different hardware
michalis - Today at 2:09 PM
@eugeneloza No, definitely not. Do not try to calculate the character/string yourself, by analyzing the keys user pressed. GTK should provide you the information about the pressed character (as PChar), and it knows the user configured preferences, language, user preferred languages modifier key etc. Moreover, you do not want to modify the generated TKey at all -- the TKey does not, and should not, describe local characters.
@eugeneloza Briefly looking, this information is probably inside the string and length fields of GdkEventKey structure. We get this in signal_key_press_event and signal_key_release_event.(edited)

add {%MainUnit xxx.pas} to many of our include files

P.S. We could add {%MainUnit xxx.pas} to many of our include files. This would help Lazazarus CodeTools, and make it clear what is the origin unit.

Check issues left on sourceforge forum

I remember that there are several issues left open at SourceForge forum. I have to remember to systematize and address them.