Why orx use ini as configure file not xml?

edited July 2013 in General discussions
Why orx use ini as configure file not xml? I am new to orx :)

Comments

  • jimjim
    edited July 2013
    Hey, welcome here :) I dont know the exact cause, but there are many. What I feel is editing xml files is a bit cumbersome. I have used xml for other projects, and they are really pain if you are to edit them manually. I find ini files much straight forward and easy to edit them as text files.

    XML is good if you are using any editing tool or editing them using other programs. On the other hand, understanding ini is no problem at all. They are much simpler than xml

    Parsing xml is more complex than parsing ini files. Hence parsing xml is slower than parsing ini. Ini files are more readable than xml, which I find a bit alien to read as text.

    So, xml is good for storing complex data structure where you have to maintain a hierarchy of some sort. Ini is good for simpler stuff.
  • edited July 2013
    Hi nowolfer and welcome here! :)

    Jim already summed it up pretty well: I believe INI format to be easier to read and edit and its syntax, being very straightforward, makes it prefect for writing a custom parser and extend the format with features such as inheritance, for example.

    That being said, there's an api to modify all the config content at runtime so one can write his/her own serialization in any format.

    Don't hesitate if you have any other questions! :)
  • edited July 2013
    Hey jim :) Thank you for your reply. I just wonder if ini file can be use for complex situation such as scene contain layer, layer contain actor(or object?) and have properties at the same time. Meanwhile why not json? :huh:
  • edited July 2013
    What do you means of modify the config content at runtime, store in xml then read ini ways, or store in ini then format in xml?
    iarwain wrote:
    Hi nowolfer and welcome here! :)

    Jim already summed it up pretty well: I believe INI format to be easier to read and edit and its syntax, being very straightforward, makes it prefect for writing a custom parser and extend the format with features such as inheritance, for example.

    That being said, there's an api to modify all the config content at runtime so one can write his/her own serialization in any format.

    Don't hesitate if you have any other questions! :)
  • edited July 2013
    The same consideration apply to json even if it's less verbose than xml: writing a custom parser for it is still less straightforward than for INI.

    Regarding storing maps, that's what I'm doing in scroll, using the native INI/config format, however some other users have written their own map format in the past too, some were binary, some were xml-based.

    What I mean by using the api at runtime is that you can write your own serialize/deserialize functions for any format you'd like. Internally the config data is a simple key value pair dictionary with inheritance.
    If it's too limited for your needs you can bypass it entirely of course, however I personally find it to be one of the most powerful systems I used over those last 12 years making games. :)
  • edited July 2013
    Thank you B)
    By the way, are there some editor aid for orx, like generator the ini file or Scene, Map, Level, etc... tools?

    iarwain wrote:
    The same consideration apply to json even if it's less verbose than xml: writing a custom parser for it is still less straightforward than for INI.

    Regarding storing maps, that's what I'm doing in scroll, using the native INI/config format, however some other users have written their own map format in the past too, some were binary, some were xml-based.

    What I mean by using the api at runtime is that you can write your own serialize/deserialize functions for any format you'd like. Internally the config data is a simple key value pair dictionary with inheritance.
    If it's too limited for your needs you can bypass it entirely of course, however I personally find it to be one of the most powerful systems I used over those last 12 years making games. :)
  • edited July 2013
    There are a couple of more or less mature tools made by the community.
    Some are still early in Dev whereas others are already usable in their current state, such as the svg->Orx converters.

    My own contribution is a C++ wrapper that had support for in-game level edition as well as a convenience wrapper for managing objects. Scroll's the name and it had been discussed at length on these forums.

    Most of those tools (but not all) can be found on the outed bitbucket page: https://bitbucket.org/orx

    You can find some additional information on some of these tools in the community tutorials on the wiki.
  • jimjim
    edited July 2013
    I just wonder if ini file can be use for complex situation such as scene contain layer, layer contain actor(or object?) and have properties at the same time.
    I think iarwain totally missed this question. I am giving my answers btw. Orx does not implement scene and layer system the way we see in some other game engines or framework. Instead, what orx has viewport and camera system. You can have multiple viewport in your game and each viewport can have multiple camera. You then can add objects in a camera

    So, you can consider viewport as scene and camera as layer. Also any orx object can have multiple child object or even camera as their child (i am not sure about camera though). And all this can be achieved using simple ini syntax. You can learn more about ini syntax here

    http://orx-project.org/wiki/en/orx/config/main
    http://orx-project.org/wiki/en/orx/config/syntax
  • edited July 2013
    jim wrote:
    Hey, jim :) Thank you for your reply!
    Are there some tutorial of viewport as scene and camera as layer(how to? structure /flow tree?). Amazing work!
    I just wonder if ini file can be use for complex situation such as scene contain layer, layer contain actor(or object?) and have properties at the same time.
    I think iarwain totally missed this question. I am giving my answers btw. Orx does not implement scene and layer system the way we see in some other game engines or framework. Instead, what orx has viewport and camera system. You can have multiple viewport in your game and each viewport can have multiple camera. You then can add objects in a camera

    So, you can consider viewport as scene and camera as layer. Also any orx object can have multiple child object or even camera as their child (i am not sure about camera though). And all this can be achieved using simple ini syntax. You can learn more about ini syntax here

    http://orx-project.org/wiki/en/orx/config/main
    http://orx-project.org/wiki/en/orx/config/syntax
  • jimjim
    edited July 2013
    There are tutorials on wiki sections. You will find pretty much what you were looking in the following links
    http://orx-project.org/wiki/en/orx/tutorials/frame
    http://orx-project.org/wiki/en/orx/tutorials/viewport

    First one is frame tutorial which shows you that how you can have multiple objects as your child object. So, they follow their parents. This behavior is also similar to layers.

    2nd link is where you create 4 viewport and 3 camera. But I am afraid that I could not find a way to add an object specific to a camera or viewport. You have to wait till iarwain answers. So, you can use empty objects (without graphics) as layers, because layers are nothing but container for grouping objects.
  • edited July 2013
    jim wrote:
    I just wonder if ini file can be use for complex situation such as scene contain layer, layer contain actor(or object?) and have properties at the same time.
    I think iarwain totally missed this question.
    Well, I thought I did with this:
    Regarding storing maps, that's what I'm doing in scroll, using the native INI/config format, however some other users have written their own map format in the past too, some were binary, some were xml-based.
    But I guess it wasn't very precise. :)

    Let me refine a bit jim's answer regarding scenes and layers.

    Layers

    Layers are handled by depth range (ie. Z coordinate), not by names. You can define them as you see fit and with as many as you need.
    Let's say you want three of them for emulating UI, foreground and background, you can say that Z < 0 is UI, 0 <= Z < 1 is foreground and Z >= 1 is background, for example.
    Cameras have a frustum which only permit them to "see" through a range of Zs, allowing them to only render the "layers" you want. In that respect it behaves similarly to layers but is completely implicit.

    That being said, on my todo list there's an entry to support tagging, which will allow cameras to render objects with given tags only, in addition to the depth sorting: https://bitbucket.org/orx/orx/issue/38/add-tagging-to-objects-filtering-to-camera

    When it's implemented, you'll get a more traditional layer system.

    Scenes

    In addition to the camera/viewport couple, I think the concept of scene is actually more tied to the concept of object itself.

    One can have an empty root object that has children (the real game/UI objects) which in turn can have children too. When creating that root object, all the children will get created as well. When deleting it, the children will get deleted.
    So basically going from one scene to another can be handled with those root objects. Transition effects can easily be handled with orxFXs (which are curve combinations that can affect many properties of objects such as: color - either in RGB, HSL or HSV space, alpha, position, speed, rotation, scale, volume, pitch, ...)

    As Jim mentioned, the scene graph hierarchy allows for trees of not only objects but of anything that contains an orxFRAME (natively in orx those are orxOBJECTs, orxCAMERAs and orxSPAWNERs, but users can use orxFRAMEs for their own custom needs).

    Having objects as children of a camera means they'll scale, rotate and move with the camera, actually behaving like a UI. That means UI objects are just regular objects attached to a camera and that they can use the same features than "game" objects, such as: physics, shaders, FXs, sound/music, clocks, ...
    That also makes supporting different resolutions almost completely transparent to the user (some attention is still required for different aspect ratios depending on what result the user desires).

    When you feel a bit more comfortable with orx, I'd recommend looking at a tutorial I recently wrote for a different purpose: its goal was to showcase how to add custom archive support (in the example resource are all loaded from ZIP archives). However it also uses extensively some more advanced orx concepts such as shaders, scene hierarchy, generic inputs, timelines and commands.

    https://bitbucket.org/iarwain/resource

    Note that all the data is stored within the .zip archive in /data, but for user convenience they're also stored in a non-archived way in /assets (the tutorial doesn't use that folder, it's only for human reading convenience).

    Very little game logic is actually done in C++ code here:
    - add custom support for ZIP files (which is the bulk of the C++ code but isn't really game logic)
    - load config file data.ini (it's done manually after the support for zip file is added as data.ini is stored within a zip file)
    - create a viewport
    - create a single object named "Scene"
    - in the run loop: handled interaction (basically Click/Release): the way it's done is by picking the object under the cursor and looking if it's an interactive object. If it's interactive, it add the corresponding timeline that will handle all the work. Timelines are sequences of commands entirely defined in config

    PS: For map/level handling (and for any gamedev done with orx, actually), I recommend having a look at Scroll as it's very handy. :) Scroll does have the concept of layers, which simply abstracts the Z value from the user as described earlier in my post.
  • jimjim
    edited July 2013
    Thanks iarwain, it was much informative. Tagging would be great, this way we could handle our object rendering more efficiently, depending on our need.

    Using z-value as layers makes much more sense. So, to efficiently draw objects one should try to use same image or spritesheet for objects of same z-value or layer. As draw calls are also batched depending on z value and texture, same z-value and same texture would ensure the least draw calls, am I right ?
  • edited July 2013
    Yes, that's definitely correct! :)

    Also, for objects to be rendered within the same batch, make sure you're using the same shader (without UseCustomParam = true), the same blending and the same filtering (aka smoothing).

    Even if the Z are different, as long as there's no objects using different texture/shader/blending/smoothing in-between, they'll still get batched. :)

    PS: One can see the number of batches in the profiler screen, it's the number of calls to orxDisplay_DrawArrays. :)
  • jimjim
    edited July 2013
    Okay, that's very neat (orx batching) :)
  • edited July 2013
    Wow, great B)
    iarwain wrote:
    jim wrote:
    I just wonder if ini file can be use for complex situation such as scene contain layer, layer contain actor(or object?) and have properties at the same time.
    I think iarwain totally missed this question.
    Well, I thought I did with this:
    Regarding storing maps, that's what I'm doing in scroll, using the native INI/config format, however some other users have written their own map format in the past too, some were binary, some were xml-based.
    But I guess it wasn't very precise. :)

    Let me refine a bit jim's answer regarding scenes and layers.

    Layers

    Layers are handled by depth range (ie. Z coordinate), not by names. You can define them as you see fit and with as many as you need.
    Let's say you want three of them for emulating UI, foreground and background, you can say that Z < 0 is UI, 0 <= Z < 1 is foreground and Z >= 1 is background, for example.
    Cameras have a frustum which only permit them to "see" through a range of Zs, allowing them to only render the "layers" you want. In that respect it behaves similarly to layers but is completely implicit.

    That being said, on my todo list there's an entry to support tagging, which will allow cameras to render objects with given tags only, in addition to the depth sorting: https://bitbucket.org/orx/orx/issue/38/add-tagging-to-objects-filtering-to-camera

    When it's implemented, you'll get a more traditional layer system.

    Scenes

    In addition to the camera/viewport couple, I think the concept of scene is actually more tied to the concept of object itself.

    One can have an empty root object that has children (the real game/UI objects) which in turn can have children too. When creating that root object, all the children will get created as well. When deleting it, the children will get deleted.
    So basically going from one scene to another can be handled with those root objects. Transition effects can easily be handled with orxFXs (which are curve combinations that can affect many properties of objects such as: color - either in RGB, HSL or HSV space, alpha, position, speed, rotation, scale, volume, pitch, ...)

    As Jim mentioned, the scene graph hierarchy allows for trees of not only objects but of anything that contains an orxFRAME (natively in orx those are orxOBJECTs, orxCAMERAs and orxSPAWNERs, but users can use orxFRAMEs for their own custom needs).

    Having objects as children of a camera means they'll scale, rotate and move with the camera, actually behaving like a UI. That means UI objects are just regular objects attached to a camera and that they can use the same features than "game" objects, such as: physics, shaders, FXs, sound/music, clocks, ...
    That also makes supporting different resolutions almost completely transparent to the user (some attention is still required for different aspect ratios depending on what result the user desires).

    When you feel a bit more comfortable with orx, I'd recommend looking at a tutorial I recently wrote for a different purpose: its goal was to showcase how to add custom archive support (in the example resource are all loaded from ZIP archives). However it also uses extensively some more advanced orx concepts such as shaders, scene hierarchy, generic inputs, timelines and commands.

    https://bitbucket.org/iarwain/resource

    Note that all the data is stored within the .zip archive in /data, but for user convenience they're also stored in a non-archived way in /assets (the tutorial doesn't use that folder, it's only for human reading convenience).

    Very little game logic is actually done in C++ code here:
    - add custom support for ZIP files (which is the bulk of the C++ code but isn't really game logic)
    - load config file data.ini (it's done manually after the support for zip file is added as data.ini is stored within a zip file)
    - create a viewport
    - create a single object named "Scene"
    - in the run loop: handled interaction (basically Click/Release): the way it's done is by picking the object under the cursor and looking if it's an interactive object. If it's interactive, it add the corresponding timeline that will handle all the work. Timelines are sequences of commands entirely defined in config

    PS: For map/level handling (and for any gamedev done with orx, actually), I recommend having a look at Scroll as it's very handy. :) Scroll does have the concept of layers, which simply abstracts the Z value from the user as described earlier in my post.
  • edited May 2014
    So, has anyone around here looked at supporting JSON?

    I know some people have no trouble with the config files, but they have always been difficult for me to use. Text editors don't fold them to indicate parent/child relationships and I get lost easily.

    If there aren't any projects to support JSON, I'll seriously consider doing one. There are JSON libraries for C like Jansson that should integrate well.
  • edited May 2014
    I don't remember hearing about anyong working on any JSON support.

    I'm not sure if that would be much of an improvement, but jim wrote an orx-ini language support for Notepad++ and I find the INI language support in Sublime Text good enough for all my needs (you have to install it using package control or by hand as it's not part of the vanilla Sublime Text).

    That being said, I'm sure other would appreciate have JSON support.
    You'll have to work a bit to support some of the custom features such as lists, randoms, includes, inline commands and, more importantly, all the different flavors of inheritance.
    If you have any questions regarding those, just lemme know. :)
Sign In or Register to comment.