Future of the project

[max-mishin]

I'm just starting to experiment in this area (CGS and ECS) after a few years of working with OOP. And I want to ask @kvark about the fate of the CGS project, because the latest version is 0.4.4 (Oct 25, 2017).

I would like to ask why the development of the project has stopped. Perhaps you decided that this is the wrong way or, perhaps, you have changed the sphere of your interests and do not have time for further development of the project.

I just hope your experience can speed up my research a little. Thank you.

[kvark]

Hi!

The short story is that I stopped messing around gamedev libraries and focused on lower level (rebuilding gfx-rs ecosystem). Three-rs was the pilot project for Froggy, and I think these two worked very well. But three-rs could no longer be developed without upgrading the graphics subsystem, and it's still in this stale state.

In terms of retrospective, I consider Froggy to be a successful experiment. The only concern I met so far was that it could be dissected into a slab allocator with reference counting for items. I do agree that the slab allocation logic is built-in here. However, the reference counting integrated into the storage allocation is the main know-how, so the core value is unchanged.

I'm hoping to get back playing with threads, ECS/CGS, and engines, soon :) Please feel free to use the project and submit patches!

[OvermindDL1]

Have you thought of multiple storage types?

An example of some ideas, the Storage as it stands is good for a general 'often-full' use, but some other possibles:

• A Storage with, say, a skiplist (another array the same length as the data array but of just integers (of some size) that contains how many elements to skip to get to the next valid one, have to update from the place of one added/removed and going back in the skiplist until you get to a valid while updating along the whole way) or perhaps an ordered index array (another array that contains the indexes, in order, of the main array containing only valid ones, have to sort on add/remove though). A skiplist Storage would be very efficient for a mostly-full array with some strides missing and the sorted set would likely be useful for a mostly empty storage that occasionally gets filled. I'm unsure how useful this one would be as this one and the current stock one don't allow for optimizations when iterating a component type related to SIMD.
• Perhaps a Storage that uses a sparse lookup, it would add an extra indirection between the handle/pointer index for cost (the handle index would look up in the sparse set, which then contains the index to look up in the dense array). This one would allow for the fastest iteration (just a slice) with the most opportunities for optimizations while having slightly slower access through handles. This one would be very very useful for certain cases but not for the generic case.
• A storage that holds different arrays of values for a single given handle, so you can split up the data to only iterate specific parts that you'd need to iterate. Could even make a paged version so there can conditionally be certain columns of data or not as well so you can iterate subsets of the data efficiently without lots of checks (just a set of valid slices).

Have a few other ideas for storages as well. A nice thing is that you could have many different storage types, and due to the way they work they would work fine together.

Also, any thought of renaming Pointer to Handle (along with the Weak variants)? It is a Handle and not a Pointer after all.

You say PR's are welcome, but how big of sweeping changes are you interested in? All with benchmarks and tests of course.

[kvark]

@OvermindDL1 the project where we explored all the variety of storage type is Specs. I don't think Froggy would need that flexibility though. ECS has large sparse areas or gaps because all the storages are aligned to entities. In Froggy, they are totally independent, so my understanding is that they will always be mostly full without lots of gaps. The current structure of a storage fits this use case rather fine.

A storage that holds different arrays of values for a single given handle

That sounds like a way to chunk the storages. I think that would be an improvement, although likely huge amount of work.

Also, any thought of renaming Pointer to Handle (along with the Weak variants)? It is a Handle and not a Pointer after all.

Yes, that sounds like a fine rename.

You say PR's are welcome, but how big of sweeping changes are you interested in? All with benchmarks and tests of course.

At this point the bar to accepting PRs is low as long as the author would be willing to maintain and use the code. I'd appreciate if before coming with the changes and the benchmarks you could explain a practical use case where the changes are expected to help. Otherwise, we are risking to waste a lot of time :)