You were right, there used to be a limit of 256 entries but that got bumped to 65536.
However, the internal buffer size to process config data is 8kb long, which means any list that would take more than 8kb of data would fail to be processed.
That being said, list accesses are very inefficient for big lists right now are there's no internal index table (the list is parsed from the beginning in order to find an item). They are not suited for general purpose array storage.
I am working on a scene editor (not sure you remember, I posted a video of it long ago, it is much more advanced now).
When I export the scene, I create a list of all the objects that should be rendered (it could be much more optimized by using the inheritence system, but right now I want to get things working).
My tests most have few objects (like 20 or so), but I was wondering what limits I should watch. The objects will just be drawn, so I don't need to keep track of them, hence I am using a list.
So I think you should be ok with the lists in that case. Another approach would be to use a prefixed sequence, akin to what I use to store objects placed in ScrollEd.
Well, pretty much the same stuff, but now you can select multiple objects and it also implements an undo/redo feature.
Another important question, are there limits for the flags in the GroupList? I remember you can have at most 16 collision flags. Is there a limit for GroupList as well?
Box2D imposes the 16 collision flags limit and as there isn't any other physics plugin available for now, I have to enforce that limit as well in orx.
Regarding the GroupList, those aren't really flags and there's no precise limit for them. They are 32 bit hashes, so theoretically you could have up to 2^32-1 groups, but in the facts you will probably end up with hash collisions before that. Probably after a few 10s or 100s of thousands different names, which shouldn't be something limiting for a game use. I hope.
Comments
You were right, there used to be a limit of 256 entries but that got bumped to 65536.
However, the internal buffer size to process config data is 8kb long, which means any list that would take more than 8kb of data would fail to be processed.
That being said, list accesses are very inefficient for big lists right now are there's no internal index table (the list is parsed from the beginning in order to find an item). They are not suited for general purpose array storage.
What are your needs exactly?
When I export the scene, I create a list of all the objects that should be rendered (it could be much more optimized by using the inheritence system, but right now I want to get things working).
My tests most have few objects (like 20 or so), but I was wondering what limits I should watch. The objects will just be drawn, so I don't need to keep track of them, hence I am using a list.
So I think you should be ok with the lists in that case. Another approach would be to use a prefixed sequence, akin to what I use to store objects placed in ScrollEd.
Another important question, are there limits for the flags in the GroupList? I remember you can have at most 16 collision flags. Is there a limit for GroupList as well?
Regarding the GroupList, those aren't really flags and there's no precise limit for them. They are 32 bit hashes, so theoretically you could have up to 2^32-1 groups, but in the facts you will probably end up with hash collisions before that. Probably after a few 10s or 100s of thousands different names, which shouldn't be something limiting for a game use. I hope.