Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Space partitioning #440

Open
olofson opened this issue Mar 23, 2017 · 0 comments
Open

Space partitioning #440

olofson opened this issue Mar 23, 2017 · 0 comments

Comments

@olofson
Copy link
Owner

olofson commented Mar 23, 2017

Problem

The 0.7.x engine still uses the original XKobo design; all objects are kept in arrays (one for enemies, and one for player bullets) with no space partitioning or other optimizations. This means every object needs to be checked when rendering, and more importantly, we rely completely on the fact that there is no enemy-to-enemy collision checking, which would require all-to-all tests.

Solution

Since we're dealing with small and/or wrapping maps, the most straightforward solution is probably to subdivide the map into suitably sized tiles, and keep objects in per-tile doubly linked lists.

Z-order - The non-trivial trivial problem

To preserve Z order when rendering, so they don't "pop" randomly when moving across tiles, we need some extra logic. They can either be sorted on the fly when rendering (potentially expensive, though we can probably arrange it so we don't have completely unsorted input), or we keep objects in a global linked list.

Hybrid: Maintain a Z-order sorted list or array of on-screen objects. Objects insert themselves in the right spot when the go onscreen, and remove themselves as they go offscreen.

Regardless of solution, we should probably guarantee unique Z-order for each object. For example, we can encode priority or layer in the upper N bits of a priority field, and reserve the lower bits for the engine to assign unique Z-orders within the respective group.

Another solution might be to organize objects in per-group lists, and just rely on position in the group list for group local Z-order. Simple and fast, but does not provide explicit control of Z-order within groups.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant