It looks like you're new here. If you want to get involved, click one of these buttons!
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.
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?
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.
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.
Everything is usually rendered every frame, according to their current position/rotation/scale. You can have hierarchies of objects, each with their own graphic.
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.
One of the many advantages of the config system is that you can easily inherit and override properties.
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
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.
If you want to add your own commands to run from the console or with tracks, it's definitely the way to go.
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.
Thanks for the feedback.
To clarify, runtime drawing / object creation is related to scaling.
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.
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.
I can look at links to earlier projects. I am open to review provided information and tips.
As far as project management, I'd like to focus on one limited scope, yet core tool, property hierachy GUI ini file set editing.
If I can be directed to which tutorials and samples, I'll go through them.
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
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/
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
Yes, cf. our current implementation mentioned a couple of posts above.
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
That should be easily doable, indeed.
If you've activated the resource watch list, you'll get notified of such changes with
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.
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.
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
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_GetCacheLineSizehints at the answer. Any speed metrics / function used in Orx to guide design?
orxMEMORY_TYPE_CONFIGis the favoured memory allocation function.
I can test
igtest.cppwith ImGui 1.75 and see if it fixes some of the window issues I encounter.
I was able to run your code with minor adaptation with
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.
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.
It is. This allows the backend to be more flexible on some more restrictive platforms. At the moment though, the implementation is based on
dlmallocfor all the currently supported platforms. I do have a task to evaluate other general purposes memory allocator as well.
I think I missed that part. Which window issues did you encounter?
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
WatchListproperty from the
Resourcemodule for that purpose, and listen to the update event.
Looking at the code of
orxConfig_EventHandlershould 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_Locateto make sure orx will track its status on disk.
Lastly, if you need to have code that runs periodically, you could either use
orxClock_AddTimer/orxClock_AddGlobalTimer, depending on your needs (ie. long term vs short term).
I was about to try
Thanks for trying the code, can I look at your modified code?
I'll look into using
orxConfig_EventHandleras for now I
orxIDEConfig_Loadand look for key changes every two frames.
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_flagsto 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.
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.
Here's my quickly patched version of your test: https://pastebin.com/wiHnHeFG
Thanks for that version.
Using a stock
igtestdirectory I get a
In any case the window issues might stem either from the version used or my code to create a new window misses some detail.
MainViewportwas part of the config you provided me in your archive.
The version I pasted above was a modification of that package to use