I recently discovered ORX and I have a game idea I want to make reality. But... I am not that interested in C or C++ - but I do like the up and coming Nim language. I have worked a bit with Nim, making my own little language in it and some other utilities. I also know the creator and the Nim community fairly well - top notch and very sharp people.

So, since ORX is C99 and Nim integrates VERY well with C/C++ I have created a first shot at a wrapper. Nim compiles via C which means the calls to ORX have zero overhead. Nim also produces fast C code so there is seldom any real performance difference. However, Nim is a richer language while being much easier to program in. One can always take a peek at https://nim-by-example.github.io

If one wants to play with it, the best place to start is via my ORX clone at github. The wrapper lives in the subdirectory code/nim:

https://github.com/gokr/orx/tree/master/code/nim/norx

I will try to keep it in sync with the ORX master branch!

I develop on Linux but Nim is cross platform so it should be possible to use Norx on all platforms. There is just a silly port of the "spinning logo" so far, but the wrapper should in theory (modulo bugs of course) be complete because it was in most part autogenerated from the ORX headers. While using it I intend to "smooth things out" making it less "C" and more "Nim".

Any and all comments welcome!

regards, Göran

AINVAR Document syntax proposal
; [SectionName] - no modifications
;
; KeyName[FreeKeyName|PostFixedKeyName|Enum] = [[ValueType(limit):Default|None] | [[ValueType(limit):Default|None] & [ValueType(limit):Default|None]]:
;
; KeyName attributes:
;   FreeKeyName         = KeyName is a place holder for a list of free key names
;   PostFixedKeyName    = KeyName is a place holder for a list of free key names that will have KeyName as postfix
;   Enum                = Value of an existing enum known or defined in place. 
;                         Known enums are conveniently input keys (mouse/keyb/joy)
;                         Enums defined in place will follow *enum definition syntax*
;
; Value attributes:
; [[ValueType(limit|(min<max)):Default|None]
;
;   ValueType           = Int|UInt|Bool|Float|Vector|String 
;                           (min & max can be applied, if present. the interval can be open (min<) = min to infinite (<max) = -infinite to max)
;                         Enum
;                         Template:TemplateType
;                         List:Type:... ; In this case the (limit) value is used to express the max list size
;                         FilePath:DynamicLibrary|Storage|Config|Image|Sound
;                         DirectoryPath
;                         Command
;                         ShaderExtension
;
;   Default             = type default value, if appliable
;                         None that by default the key is not defined
;                         
;
; Since a key may have multiple value rapresentations, we can give a way to document such alternatives
; KeyName = [[typedef1] | [typedef1]] ; means we can have valuedef1 type or typedef2
; KeyName = [[typedef1] | [[typedef1] &# [typedef3]] ; means we can have valuedef1 type or typedef2 and typedef3 separated by #
;
;


; Enum definition syntax
; [Enum:name{value1|value2|value3|...}]
;
; In addition, to make the document more readable, I propose a special section used to declare enums and avoid in-place definitions
; [@EnumDefs@]
; EnumNameA = value1|value2|value3|...
; EnumNameB = value1|value2|value3|...

An example using hp, where equipped_list and effects_list are keys on the object that are just lists of other sections that currently affect the character:

[StatSolver]
Equations  = StatEquations
Defaults   = StatDefaults
Update     = change

[StatDefaults]
base_hp      = 10
base_mult_hp = 1
damage_hp    = 0

[StatEquations]
max_hp                = Clamp(0, max_hp_cap, (base_hp * base_mult_hp) + (equipment_mod_hp * equipment_mod_mult_hp))
total_hp              = max_hp + (temporary_mod_hp * temporary_mod_mult_hp) - damage_hp
max_hp_cap            = infinity
equipment_mod_hp      = Sum(equipped_list, equip_modifier_hp, default: 0)
equipment_mod_mult_hp = Sum(equipped_list, equip_modifier_mult_hp, default: 0)
temporary_mod_hp      = Sum(effects_list, temp_modifier_hp, default: 0)
temporary_mod_mult_hp = Sum(effects_list, temp_modifier_mult_hp, default: 0)

This would, given any orx object, generate the attributes base_hp, base_mult_hp, damage_hp, total_hp, max_hp_cap, equipment_mod_hp, equipment_mod_mult_hp, temporary_mod_hp, and temporary_mod_mult_hp on that object.

I've currently got a parser and topological sort working, I've started on setting up a VM for it, but I noticed that the orxConfig API isn't thread safe, which I would need if I wanted to solve for multiple characters in parallel if the equations are referencing lists of config sections, but not if they're just referencing other variables on the object itself, since that can be saved to a hashtable beforehand. The only solutions I can think of so far are either manually doing mutex locks when reading the config (not ideal), duplicating the code from the config module to read values from another section without modifying the config section stack (also not ideal), or just dealing with solving for one object at a time (which limits how much it can be used). Just wondering if there's any tips on this.

You can follow us on Twitter, Mastodon, Facebook, Google+

Can I draw the sprite / object / texture into the buffer that holds the actual raster?
The idea is to redraw the asset according to the scale and / or zoom factor and also draw assets on the screen at runtime to create new objects.

The more general question is what is the optimal standard Orx way to design runtime objects from scratch?

I looked over CreationTemplate.ini and I can see the benefit of mapping properties and commmands to text.

In order to facilitate an Orx IDE the next step would be binding Dear ImGui commands and push the GUI design through the ini file.

Editing ini files through an ImGUI IDE property tree and issuing OrxConfig calls to save is a goal.

I gather orxCOMMAND_REGISTER_CORE_COMMAND / orxCommand_Register seems to be the way to register and orxCommand_Execute to access functions and maintain object properties in ini.

I presume all the commands in the bouncing demo can be executed within the ini file so this is the basis to bind a scripting language to Orx?

VGAME facilitates music and sound integration into video games. We offer a high-end quality music and audio library as well as a powerful search engine to take advantage of while searching for the perfect track.

More than 4000 tracks specifically curated for all types of video games

Music & Audio License: https://www.vgame.ca/licenses-table

Sprites - 2D pixel art
https://opengameart.org/art-search-advanced?keys=&field_art_type_tid[]=9&sort_by=count&sort_order=DESC

FAQ
https://opengameart.org/content/faq

But available too

some textures:
https://opengameart.org/art-search-advanced?keys=&field_art_type_tid[]=14&sort_by=count&sort_order=DESC

Musics
https://opengameart.org/art-search-advanced?keys=&field_art_type_tid[]=12&sort_by=count&sort_order=DESC

Sounds Effects
https://opengameart.org/art-search-advanced?keys=&field_art_type_tid[]=13&sort_by=count&sort_order=DESC

Follows a summary of the flags reviewed by iarwain at this point:
https://github.com/orx/orx/pull/43

Clang Orx diagnostic flags status
    https://clang.llvm.org/docs/DiagnosticsReference.html

summary of first reviewed batch

-Wno-sign-compare
-Wno-unused-parameter
-Wno-c++98-compat-pedantic

- disable
+ enable

    [-Wbad-function-cast]
 -  [-Wc11-extensions]
 -  [-Wc++98-compat-pedantic]
    [-Wcast-align]
 +  [-Wcast-qual]
    [-Wcomma]
    [-Wconditional-uninitialized]
    [-Wconversion]
    [-Wdeprecated]
    [-Wdisabled-macro-expansion]
 +  [-Wdocumentation]
    [-Wdocumentation-deprecated-sync]
    [-Wdocumentation-unknown-command]
 -  [-Wdouble-promotion]
    [-Wextra-semi]
    [-Wfloat-conversion]
 -  [-Wfloat-equal]
 -  [-Wformat-nonliteral]
    [-Wglobal-constructors]
    [-Wgnu-anonymous-struct]
    [-Wgnu-empty-initializer]
 -  [-Wgnu-zero-variadic-macro-arguments]
    [-Wimplicit-fallthrough]
    [-Wimplicit-function-declaration]
    [-Wmissing-prototypes]
    [-Wmissing-variable-declarations]
    [-Wnested-anon-types]
    [-Wnull-pointer-arithmetic]
    [-Wold-style-cast]
 -  [-Wpadded]
 -  [-Wpedantic]
 -  [-Wreserved-id-macro]
    [-Wshadow]
    [-Wshadow-field-in-constructor]
 +  [-Wshorten-64-to-32]
    [-Wsign-compare]
 +  [-Wsign-conversion]
 -  [-Wstrict-prototypes]
 -  [-Wswitch-enum]
 +  [-Wundef]
    [-Wunknown-warning-option]
    [-Wunused-macros]
    [-Wunused-parameter]
    [-Wvla]
    [-Wweak-vtables]
    [-Wzero-as-null-pointer-constant]
    [-Wzero-length-array]

1. Change premake and use CMake instead:
   I know you may dislike CMake (It's really ugly and generates a lot of garbage, syntax sucks) but it's a de facto standard and it's better than having a custom modified old premkake 4 version.
   More important, it fits really well with proposal 2.

2. Use conan.io as package manager:
   No more need to have a complete custom package management with rebol, downloading zips, etc.
   You simply create a packet for each dependency (if vanilla may be they are already available) and declare on conan recipe that you need such packet.
   Users will use conan directly in their development flow and just add something like "orx/1.10.0@orx/stable" and they will obtain all needed stuff to build the game.
   This gives a you a quite standard way to create and distribute pre-built binaries.
   In the same time allows users to automatically build orx and dependencies in case a pre-build for such exotic configuration does not exists.

3. Divide orx code base in multiple packages:
   This would allow plugin injection on a vanilla orx version just by overriding a dependency using conan.
   Just to make an example, assume I have a modified orxPlugin_Display that can expose the GLFW window identifier to the orx host application.
   With just one line of configuration I could substitute such orxPlugin_Display at compile time without loosing benefits of being aligned to last orx vanilla version.
   Orx code-base seems already ready to be conan-ized as it really well separated between core and plugins.

Of course it's a lot of stuff to be done but if you're interested I can help you with that as I'm doing this on all projects at my workplace (~50+ repos now converted to packages and inserted in CI).

and updated it with an axial/cubial coordinate system as detailed in this article: https://www.redblobgames.com/grids/hexagons/.

I believe it simplifies the original example a little bit, and also allows you to switch between horizontal and vertical orientations of hexagons quite easily.

You can find it here if you're interested: https://github.com/LudiG/tut_hex

Or posting here

This is a question that is often asked if Orx can support a minimal UI library for doing buttons, dropdowns and other controls.

These can be either used in-game, or to make applications with Orx, like editors, for example.

You can use Ainvar's repository to learn how to set up imgui in Orx: https://bitbucket.org/ainvar/imguiorx

Also, you can see many examples of control usage at: https://github.com/ocornut/imgui

The actual file that contains a handful of functions so that Orx can use imgui to render and get inputs is here: https://bitbucket.org/ainvar/imguiorx/src/dac596c944cf17fbeaa1b0837e76861f526959e8/src/ImGui_Orx.cpp?at=master&fileviewer=file-view-default

There is also a nuklear test at: https://github.com/vurtun/nuklear

Tutorials will be available soon on the wiki on how to start, and how to use simple controls to build up an application.

This includes Visual Studio 2015 / 2017, Codelite, Code::Blocks, gmake, Xcode, on Windows, Linux and Mac.

Everything passes.

auto wait_for_food_behavior = sequence{
    execute_command(inherit, "none", "SetConstraints", $o("Sparrow"), "SparrowConstraints"),
    execute_command(inherit, "none", "SetController",  $o("Sparrow"), "SparrowEatConverger"),
    wait_for_state($o("Sparrow"), "Chew")
};

auto cursor_move_to_flake_behavior = sequence {
    execute_command(inherit, "Target", "GetFirstNodePosition", $o("Flake")),
    move($o("Cursor"), $v("Target"), 12)
};

auto cursor_behavior = repeat <<= sequence {
    invert <<= repeat <<= any {
        timeout(0.3),
        invert <<= cursor_move_to_flake_behavior
    },
    execute_command(inherit, "none", "Object.SetAnim", $o("Cursor") ,"HandTouchAnim"),
    timeout(0.2),
    execute_command(inherit, "Target", "Object.GetPosition", $o("Sparrow")),
    move($o("Cursor"), $v("Target"), 12),
    execute_command(inherit, "none", "Object.SetAnim", $o("Cursor") ,"HandHoverAnim")
};

auto tutorial_feeding_stage = sequence {
    create(inherit, "Text","TutorialWelcomeBoard"),
    timeout(1),
    create(inherit, "Sparrow","TutorialSparrow"),
    timeout(1),
    set_content($o("Text"),"TutorialSparrowIntroductionText"),
    timeout(1),
    create(inherit, "Flake", "TutorialCheeseFlake"),
    timeout(1.5),
    create(inherit, "Cursor", "TutorialCursor"),
    any {
        wait_for_food_behavior,
        cursor_behavior
    },
    set_content($o("Text"),"TutorialSparrowFeedCongratulations"),
    destroy(inherit, "Cursor"),
    execute_command(inherit, "none", "SetNextLevel", inherit, "RegularLevel"),
    constant(behavior_t::RUNNING)
};

auto wait_for_food_behavior = sequence{
    execute_command(inherit, "none", "SetConstraints", $o("Sparrow"), "SparrowConstraints"),
    execute_command(inherit, "none", "SetController",  $o("Sparrow"), "SparrowEatConverger"),
    wait_for_state($o("Sparrow"), "Chew")
};

auto cursor_move_to_flake_behavior = sequence {
    execute_command(inherit, "Target", "GetFirstNodePosition", $o("Flake")),
    move($o("Cursor"), $v("Target"), 12)
};

auto cursor_behavior = repeat <<= sequence {
    invert <<= repeat <<= any {
        timeout(0.3),
        invert <<= cursor_move_to_flake_behavior
    },
    execute_command(inherit, "none", "Object.SetAnim", $o("Cursor") ,"HandTouchAnim"),
    timeout(0.2),
    execute_command(inherit, "Target", "Object.GetPosition", $o("Sparrow")),
    move($o("Cursor"), $v("Target"), 12),
    execute_command(inherit, "none", "Object.SetAnim", $o("Cursor") ,"HandHoverAnim")
};

invert <<= repeat <<= any {
    timeout(0.3),
    invert <<= cursor_move_to_flake_behavior
}

auto tutorial_feeding_stage = sequence {
    create(inherit, "Text","TutorialWelcomeBoard"),
    timeout(1),
    create(inherit, "Sparrow","TutorialSparrow"),
    timeout(1),
    set_content($o("Text"),"TutorialSparrowIntroductionText"),
    timeout(1),
    create(inherit, "Flake", "TutorialCheeseFlake"),
    timeout(1.5),
    create(inherit, "Cursor", "TutorialCursor"),
    any {
        wait_for_food_behavior,
        cursor_behavior
    },
    set_content($o("Text"),"TutorialSparrowFeedCongratulations"),
    destroy(inherit, "Cursor"),
    execute_command(inherit, "none", "SetNextLevel", inherit, "RegularLevel"),
    constant(behavior_t::RUNNING)
};