Orx IDE

_N_

I am trying to figure the scope of what I can do with the orx API and use it as much as I can.

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?

sausage

Having ImGui is certainly a big step forward to having some kind of editor. There have been many attempts to build an editor, but usually people don't have the time to complete them.

You mentioned drawing sprites, but I would assume that people would use the package of their choice. And perhaps an editor should simply listen for changes to a person's files and reimport.

Might be worth taking a look at the efforts already started. You might find contributing to one of those might be a good start.

iarwain

N said:
I am trying to figure the scope of what I can do with the orx API and use it as much as I can.

Can I draw the sprite / object / texture into the buffer that holds the actual raster?

You can render to textures and reuse those as shader inputs or directly on objects. There are a few tutorials/samples on the wiki on that topic.

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.

Everything is usually rendered every frame, according to their current position/rotation/scale. You can have hierarchies of objects, each with their own graphic.

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

It really depends on your needs and preferences as well as your definition of optimal. Do you want to optimize for performance? code size? re-usability? In some cases it's easier to simply listen to an object's render event and do your own rendering, sometimes it's easier to modify the config at runtime and have regular objects.

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

One of the many advantages of the config system is that you can easily inherit and override properties.

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.

I have the feeling ImGUI won't make it easy to do so as it's designed to be immediate, whereas having a separate design/layout from the code execution is closer to a retained mode. That being said, if all you need is ImGUI, we already have an integration you can check at: https://github.com/iarwain/igtest/blob/master/src/orxImGui.cpp

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

That sounds like doable. As @sausage mentioned a few others have played with the idea of making editors in the past and it might be interesting to see where they are at the moment. You might want to poke @ainvar on that topic.

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.

If you want to add your own commands to run from the console or with tracks, it's definitely the way to go.

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?

It wasn't meant as a scripting language, but sometimes it starts feeling like the premise of one. I have some plans for making the syntax more palatable, but I have yet to find the time to work on it.

_N_

Thanks for the feedback.

To clarify, runtime drawing / object creation is related to scaling.

You mentioned drawing sprites, but I would assume that people would use the package of their choice.

One example might be creating a flowchart or a simulation software / game. Zooming in and out whilst keeping quality resolution both for graphics and fonts is my requirement.

The intent is to shortcut creating / using a png file and assemble assets on-the-fly.

Dear ImGui outputs vertex buffers and command lists that you can easily render in your application.

Akin to ImGUI I wish to draw at the pre-raster stage. Can Orx turn those draw call sets into Orx objects?

The second feature I want to work on is binding ImGUI functions to ini file properties and load and edit properties in a GUI hierachy property tree. It seems all the pieces to accomplish this are already in place.

And perhaps an editor should simply listen for changes to a person's files and reimport.

So yes, this scafold of an IDE could scan for changes in an ini file set, load and update the property tree.

I view scripting as the keystone of an IDE. Everything appears as if Orx had been prepped in that direction.

I am trying to gather core information about the architecture of an Orx based IDE.

Might be worth taking a look at the efforts already started. You might find contributing to one of those might be a good start.

I can look at links to earlier projects. I am open to review provided information and tips.

Having ImGui is certainly a big step forward to having some kind of editor. There have been many attempts to build an editor, but usually people don't have the time to complete them.

As far as project management, I'd like to focus on one limited scope, yet core tool, property hierachy GUI ini file set editing.

_N_

Can I draw the sprite / object / texture into the buffer that holds the actual raster?

You can render to textures and reuse those as shader inputs or directly on objects. There are a few tutorials/samples on the wiki on that topic.

If I can be directed to which tutorials and samples, I'll go through them.

sausage

Viewport render to texture is here: https://wiki.orx-project.org/en/tutorials/viewport_render_to_texture

All the shader tutorials are here: https://wiki.orx-project.org/en/tutorials/main#shaders

iarwain

There's also https://wiki.orx-project.org/en/tutorials/community/iarwain/compositing which is a bit outdated but the up-to-date approach can be then checked at https://bitbucket.org/iarwain/compositing/src/default/

iarwain

N said:
Thanks for the feedback.

My pleasure!

To clarify, runtime drawing / object creation is related to scaling.

You mentioned drawing sprites, but I would assume that people would use the package of their choice.

One example might be creating a flowchart or a simulation software / game. Zooming in and out whilst keeping quality resolution both for graphics and fonts is my requirement.

You'll then need to have some form of vector or procedural rendering. Both of which do not have the same level of support, from a data-driven standpoint, than plain textured quads rendering.
That being said, if you were to use Signed Distance Fields, for example, fragment shaders can be almost entirely data-driven with orx. For vector primitives, we support Bezier and CatmullRom interpolations, but you'll still have to generate the mesh yourself and render it using the orxDisplay API.

The intent is to shortcut creating / using a png file and assemble assets on-the-fly.

Dear ImGui outputs vertex buffers and command lists that you can easily render in your application.

Yes, cf. our current implementation mentioned a couple of posts above.

Akin to ImGUI I wish to draw at the pre-raster stage. Can Orx turn those draw call sets into Orx objects?

Not per se, no. Orx's objects are only rendered as textured quads at the moment. You'd have to handle the rendering yourself by listening to orxEVENT_RENDER_OBJECT_START.

The second feature I want to work on is binding ImGUI functions to ini file properties and load and edit properties in a GUI hierachy property tree. It seems all the pieces to accomplish this are already in place.

That should be easily doable, indeed.

And perhaps an editor should simply listen for changes to a person's files and reimport.

So yes, this scafold of an IDE could scan for changes in an ini file set, load and update the property tree.

If you've activated the resource watch list, you'll get notified of such changes with orxRESOURCE_EVENT_UPDATE.

I view scripting as the keystone of an IDE. Everything appears as if Orx had been prepped in that direction.

I am trying to gather core information about the architecture of an Orx based IDE.

All I'm saying is that the current commands might not be the best choices for a fully-fledged scripting approach for an IDE at the moment. They were intended for console/debugging and punctual data-driven automation.

_N_

The second feature I want to work on is binding ImGUI functions to ini file properties and load and edit properties in a GUI hierachy property tree. It seems all the pieces to accomplish this are already in place.

I uploaded an orxIDE test which allows creating and updating a few basic widgets from an Orx ini file.

I posted within ImGui the orx functions I use to interface with the config file for review, suggestions and comments.

I also test using a function pointer array to render the widgets, see the readme.txt for more details.

https://github.com/OneArb/orxIDE

iarwain

I'll have a look over the weekend. A quick question however, was there any limitation that prevented you from using https://github.com/iarwain/igtest/blob/master/src/orxImGui.cpp for the ImGUI integration instead?

_N_

I updated the test file so rendering a widget is only a single function pointer call for the widgets that are implemented and do not need parameters.

The implemented widget set taking parameters escapes through the other token.

I implemented a token function array so parsing the config file is set to n times per second.

My first idea was to look for a config file update event in OrxConfig module, but then the objective being editing Orx config file within ImGui would only require to update the token array upon key / section change, insert or delete.

I removed C++ function overloading, parameter and parameter free versions, to remain within C portable code space.

The next step is to add a parameter token.

Considering serializing parameters vs. a union structure.

LuaJIT only supports floating point arithmetic within the interpreter but optimizes to int in JIT. asm.js does not support int but its successor Wasm supports them.

Any direction for Orx?

Is there any evidence that L cache hits do make a difference in Orx performance or is C just a mean for platform compatibility?

orxMemory_GetCacheLineSize hints at the answer. Any speed metrics / function used in Orx to guide design?

I presume orxMemory_Allocate orxMEMORY_TYPE_CONFIG is the favoured memory allocation function.

I can test igtest.cpp with ImGui 1.75 and see if it fixes some of the window issues I encounter.

iarwain

I was able to run your code with minor adaptation with orxImGui.

Any direction for Orx?

Not that comes to mind, sorry, I usually opt for a union in those cases, but that doesn't mean it's the most appropriate approach in your situation.

Is there any evidence that L cache hits do make a difference in Orx performance or is C just a mean for platform compatibility?

orxMemory_GetCacheLineSize hints at the answer. Any speed metrics / function used in Orx to guide design?

I haven't done any measurement in years, sorry, no. I should probably do it again at some point. At the moment the cache line size is mostly used to align memory banks, as a good practice.

I presume orxMemory_Allocate orxMEMORY_TYPE_CONFIG is the favoured memory allocation function.

It is. This allows the backend to be more flexible on some more restrictive platforms. At the moment though, the implementation is based on dlmalloc for all the currently supported platforms. I do have a task to evaluate other general purposes memory allocator as well.

I can test igtest.cpp with ImGui 1.75 and see if it fixes some of the window issues I encounter.

I think I missed that part. Which window issues did you encounter?

iarwain

Ah yes, I forgot to mention: I'd recommend not to load the config files every frame, as it currently is the case, from my understanding.
You can use the WatchList property from the Resource module for that purpose, and listen to the update event.
Looking at the code of orxConfig_EventHandler should yield more information on that process.

If you do not wish orx to load the file automatically for you once it's been modified on disk, you could still get notification by adding a new resource group and add it to the watchlist. Then, aside to loading it with orxConfig_Load, you could call orxResource_Locate to make sure orx will track its status on disk.

Lastly, if you need to have code that runs periodically, you could either use orxClock_Register or orxClock_AddTimer/orxClock_AddGlobalTimer, depending on your needs (ie. long term vs short term).

_N_

I was about to try igtest.cpp.

Thanks for trying the code, can I look at your modified code?

I'll look into using orxConfig_EventHandler as for now I orxIDEConfig_Load and look for key changes every two frames.

orxIDE::framecount--;
!orxIDE::framecount && orxIDEparseWidgetToken();

_N_

I can test igtest.cpp with ImGui 1.75 and see if it fixes some of the window issues I encounter.

I think I missed that part. Which window issues did you encounter?

For one during launch I get a very high framerate which quickly settles down to 60. It may be an artifact of my code.

Despite setting a window_flags to 0, I cannot move nor close the window, although I can resize it. The close X button is activated when hoovering though.

Minor point, while resizing the entire window frame the framerate increases.

iarwain

Sure, I can share my code tonight if I still have it around.

Regarding the high framerate at the beginning, some OpenGL drivers go into busy loops with VSync if VSync is requested too soon after the creation of a window. To prevent this, we request VSync only half a second after the window's creation.

I'd have expected the framerate to decrease, not increase, when resizing the main window on Windows, as this operation blocks the main thread update until you let go of the resizing handle.

iarwain

Here's my quickly patched version of your test: https://pastebin.com/wiHnHeFG

_N_

Thanks for that version.

Using a stock igtestdirectory I get a MainViewport missing section.

In any case the window issues might stem either from the version used or my code to create a new window misses some detail.

iarwain

The MainViewport was part of the config you provided me in your archive.
The version I pasted above was a modification of that package to use orxImGui.cpp.