Nowadays, I am developing a game with orx. At first,everything went well, I enjoyed the process of development. an bug disappearing destroy it :unsure: .
the result I want is that at the very begining of the ball appearance, it need to be hung up on the air, now it is the object without body, then after doing some FX effect, it drop down. Now it change to be an object with a dynamic orxBody.
I find no related function except orxBody_CreateFromConfig to add the orxBody to the object dynamicly. At first, it function well, but when I attemp to delete the object, the error come up. An assert return a null object error in orxStructure_update() called by orxPhysics. After I check the source of orx. I found the orxBody_CreateFromConfig only link the body to the object, meanwhile the body knows who its owner is but the object do not know its orxBody. therefore when I delete it, the body is not deleted and when the body is updated to do something related to the object. The bug appear.
:unsure: although in this case solving this and avoid the error is not very difficult, I can set the custom gravity, (at first is 0, then it is 300 or other), I think adding an body to the object without generated from ini script is an necessary function in this engine. so does modifing the body type from dynamic one to static.
Thanks for your help in advance
Comments
You're right about using the custom gravity as a work around. Also, do you need a body in this case? Bodies are only useful when you want collisions. You can still apply speed on an object that doesn't have a body.
However, yes, you can add/remove bodies at runtime. It's just a couple of additional lines of codes.
When adding a body at runtime, you were right when using orxBody_CreateFromConfig() but then you need to link it to the object (so that the object will be aware it has a body) using orxObject_LinkStructure().
As you created the body yourself explicitely, you also have to delete it explicitely (orx only deletes what it created itself). So before deleting your object, you have to unlink its body using orxObject_UnlinkStructure() and then destroy it using orxBody_Delete(). That should be it.
There's a trick to make orx responsible of the body deletion, but I don't recommend it as it breaks the symmetry of the code, which, to me, isn't a good thing.
Also if you want to change the properties of a body at runtime, some can be done using accessors and some others need the body to be deleted and a new one to be created.
For example, when scaling an object that has a body, orx has to delete the body and recreate it with the new scale as Box2D doesn't support scaling. As you can imagine this is an expensive operation.
Basically, I'd say that making the changes on the config at runtime is the safest way of doing it. Don't forget properties and section can be changed/added/removed at runtime using the orxConfig_ API. It's also a good tool to make a specialized version of a section without modifying this one:
Let's say you have a section called StaticBody and you want to create another body that is exactly the same except for one thing. You can create a new section by selecting/pushing it (if the section doesn't exist, it'll be created). Then you set its parent as StaticBody and you make your change. Now you can use this new section for your new body. Something like:
Now using the section DynamicBody will create a body almost identical to StaticBody, except it'll be dynamic.
You can also bypass completely the config system and create bodies/parts the hard way but I don't recommend it.
yes, in this game I want to handle collsions it start from completion of the FX effect and when collide with something,it will be deleted. Not only does it handle the speed, but also the collision, that's why I need the body and add it dynamicly.
I was expecting that, I just wanted you to know that if you need to move objects around using speed, they don't need a body for that.
Yes, only in memory unless you call orxConfig_Save(). You can even filter what you want to save or not and ask for encryption if you need it.
In memory a section takes 44 bytes (+size of the string) and a key/value pair 56 bytes (+size of both substrings). The reason why a key/value is that big is that it comes with a cache system for fast values accesses.
When you inherits from another section that doesn't take any additional byte in memory. So it's better for memory to use inheritance instead of copy/pasting all over the place.
That being said, let's say you have a total of 200 sections and 2000 key/values, which is already a good sized config storage. It will take less than 120KB in memory (+memory for the strings themselves), which I don't think is that bad at all.
There's a string/name system I planned to implement later that will save most of the string memory by making sure there are no duplicates and that will make string/CRC comparisons more effective, so thing should be even better in the future.
EDIT: Also you don't have to hold in memory all of your game config data. For example, if you define levels using the config system, you can clean sections when you're not using them anymore and get the memory back and then load the sections of the new level.
orx is a engine based on config, you must be confident in its efficiency. and use some fast access algorithoms to deal with its searching. could you introduce it brief. I am really curious about it.
The section storage is a hash table with a 128 entries table (orx's hash tables internally only allow power of two sizes so as to provide a fast dispatch function based on masking).
They also use 32bit unsigned ints as keys and banks for internal storage (preventing reallocation as much as possible).
Back to the config module, within each section, entries are stored in a simple cache-friendly linked list.
Each entry has a cache mechanism that works for every possible data type and random values too (no string re-parsing after the first access unless a new data type is asked for the same entry).
As a matter of fact, entry strings are only re-parsed in the case of local inheritance (Key = @OtherSection), for list accesses with a different index than the previous access or when requesting a new data type.
If a section is already selected, any subsequent call to push/select won't trigger any work nor string parsing. What could impact performances is to use big inheritance trees with no local override for entries (if there's local override, we won't have to go back to the root to find the value).
If you encounter any performance issues with it, please let me know and I'll investigate, but I'm pretty confident that most games built with it are more likely to be render-bound than config-bound.
Long name is hard to remember with the situation that no any assistance could be applied in config writing.
I am thinking about adding the namespace to the config system of orx. every namespace will have its own config data structure, meanwhile have section hash table..
for example:
[obj:mouse] which will store "mouse" into the hashtable in obj namespace.
and create the Object:
orxObject_createFromConfig(obj:mouse) first the system will search obj namespace and find the section in its hashtable.
I think it could help orx to query section faster than before when there are lots and lots of sections.
second the namespace could help developer knows what's type of this section. You see "mouse" could clear express that it is an object. and [graph:mouse] could clearly show it is a mouse graph.
Besides, we could save the config according to its namespace.
Only the configs in the namespace will be ready to save and call the saving callback function. Thus, it may improve the performance while saving and decrease the complexity when determining whether the section should be saved in saving callback function.
I am not sure how and how difficult to Realize this feature. Here I give my suggestion:
at first, the config module will create a default namespace. all
sections without any namespace like **** will store in this namespace.
For the namespace user defined like AAAA:***, the schema is The First time the config loading encouter Them, build the namespace whose keyword is AAAA and its data structure such as hashtable.
Thank you
Sure, why not. I personally don't think a namespace is necessary as I'd rather used long names (aka paths) instead.
So I'd still use [obj:mouse] (or [obj_mouse] of whichever separator you want to use) but without changing the code.
You can of course have deeper paths such as: [global:settings:mouse:sensitivity]
Mmh, yes and no. I'd depend on your config set size. Furthermore I don't think looking for section is a critical CPU time consumer. I'll add profiler markers in order to get concrete data.
I also increased the number of buckets for the config section table to 1024 which means that even for sets above 10 000 sections, finding them should be done in a reasonably small time.
I totally understand that, but again it doesn't have to be something "physical" in the code, it's simply a way to organize your data.
I understand your point, but I don't think saving is that complex as long as you stick with your naming convention: you simply have to check that the section begins with the name you want, such as a single call to orxString_Find with "global" for exemple. This way you can also choose the granularity used when saving ("global" vs "global:settings" for example).
As for the time saved, as you're only writing the sections you need to disk, all the others have been filtered out. The action of filtering them is probably far below 1 ms for 10 000 items on a computer and probably not much more on handheld devices. Again I can add markers to verify/infirm that hypothesis.
The issue with that approach is that you need to parse your string for each section query to find which namespace is used, in addition to extra cache misses when accessing different tables. I have the feeling that these costs would counterbalance any gain but I might be wrong.
You're welcome to try it on your side and I'd appreciate any performance/timing data that would show if changing the code brings some performance boost and to which extent. If they are consequent enough, I'd consider adding this feature to orx. For now I'll simply add some timers for your convenience so that you can check how much time is spent in config functions (the values getters are already instrumented).
Also, do you need to have all the 10 000 sections loaded at once for your game? Are they all criticals or do some defines data for specific levels/menus? In this case, you might want to consider loading/unloading them at runtime based on their naming convention (clearing all sections starting with "level:level2" before loading the file containing "level:level3" sections, for example).
Thank you[/quote]
I think the data stored in config system should be like a database include many tables. or try to design to be closer to it in dividing the data sections
Maybe you're right for having more than one table, but to me it looks like it forces users to order their config data in one way whereas I'd like it to be as free as possible.
Also using more than one table can become a performance hog depending on how the user organizes his data, whereas using one table doesn't performances doesn't depend on how the user organizes them but only on how much data is present.