There appears to be quite different methods between remove object and remove index.Would there be a way to perhaps grab the particular objects location and is the remove index number any faster than remove object function?

There's not just towers but also projectiles to worry about too don't forget. But yes, 150,000 collision checks isn't really a lot, unless you really need those cycles for something else. Anything under a couple of milliseconds is going to leave you plenty of CPU to do graphics and other game logic. Or of course you can cheat at run at 30fps

Cas

We still cheat with homing missiles or instant beams. If we change this then it might be worth change lot other things too. But have to make gameplay ready and optimize after that. Still running 900fps at desktop so no problems yet(libgdx is that effective.)

There appears to be quite different methods between remove object and remove index.Would there be a way to perhaps grab the particular objects location and is the remove index number any faster than remove object function?(...)

Unfortunately the remove index is just one part of the equation. To make this fast, it needs to get rid of data moving to fill the gap of an removal without slowing down addition.

I was more thinking along the lines of an unsorted Bag having a stack of empty slot indices, so you can have something like

This should be very fast, but clearly has problems:- it limits a collection to only store specific kind of objects- you can only store a Collectable in one collection- you need an emptySlots stack the size of the collections' capacity- iterating the contained objects is more difficult

Now this really is premature optimisation! We're talking about 300 removes and 300 adds per frame - and that's only for entities that have actually moved! So no turrets, just mobs and bullets. It's noise.

Now this really is premature optimisation! We're talking about 300 removes and 300 adds per frame - and that's only for entities that have actually moved! So no turrets, just mobs and bullets. It's noise.

The OP doesn't mention a certain amount of entities.

Hence it's perfectly valid to assume it's massive and everything has to be done to queeze out the last drop of performance

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Otherwise here is some thought craft. Try storing the index within the object that you are storing. If you disallow random insertions and appending to the beginning (which is quite common for a lot of ArrayList usage), then you only have to update the objects indexes when an element is removed. You can skip that by storing null in an empty position, rather then compacting the array down, and store the location of the null element in an int array (a stack). When you next insert, read from the stack, decrement the size and then place the new object at that location.

If the arraycopy is slower then the stack read + size decrement, then this optimization should end up improving the speed. It does mean you are essentially removing based on reference (by telling giving each instance to hold a unique array index), rather then on equality. Presuming it totally works, I'd put money that any speed improvement is exceptionally trivial. You'd need millions (10s of millions?) of elements before you'd see any real gain.

Any real optimizations also depend heavily on what you are trying to achieve. For example are you iterating over this array to handle collisions? If so then you might consider a Grid or OctTree instead, as you can then avoid large sections of your objects.

This should be very fast, but clearly has problems:- it limits a collection to only store specific kind of objects- you can only store a Collectable in one collection- you need an emptySlots stack the size of the collections' capacity- iterating the contained objects is more difficult

Hey, thanks for all the comments on this! I'm not asking this in a particular context, but more as to how the problem should be solved the most efficiently, and keeps that when scaling. It's not a matter if it makes the time, but what method is fastest, while offering the features needed in a given situation.

I very much like the idea of the grid. With that in mind, it seems wierd that quadtrees should be remarkably slower (at least to me). Can someone explain the reason for that? Also, would octrees be any good compared to quadtrees, in 2D space?

Finding the hypotenuse of a triangle gives pretty accurate results, right? But that expensive Math doesn't need to take place when comparing the entities left, after we find out what's in a given square in the grid, does it?

1 2 3

yDis = pos.y - targ.yxDix = pos.x - targ.xdistance = yDis + xDis

I don't see immidiate problems with this, and it is (..it should be) faster than doing the actual geometry math?

Hey, thanks for all the comments on this! I'm not asking this in a particular context, but more as to how the problem should be solved the most efficiently, and keeps that when scaling. It's not a matter if it makes the time, but what method is fastest, while offering the features needed in a given situation.

I very much like the idea of the grid. With that in mind, it seems wierd that quadtrees should be remarkably slower (at least to me). Can someone explain the reason for that? Also, would octrees be any good compared to quadtrees, in 2D space?

Finding the hypotenuse of a triangle gives pretty accurate results, right? But that expensive Math doesn't need to take place when comparing the entities left, after we find out what's in a given square in the grid, does it?

1 2 3

yDis = pos.y - targ.yxDix = pos.x - targ.xdistance = yDis + xDis

I don't see immidiate problems with this, and it is (..it should be) faster than doing the actual geometry math?

EDIT:Actually, I do! If xDis is negative, it might give unwanted behavior. A Math.abs(xDis), would fix this. Anyone know of the expensiveness (because that's totally a word), of Math.abs?

Alright, I've run into a really silly problem with the Grid implementation. When creating arrays of ArrayLists, is there really no way to speficy what kind of objects can be in there? Normally I would do ArrayList<Shtuff> and that would be fine, but when doing this:

1

privateArrayList<Entity>[][] list = newArrayList<Entity>[cols][rows];

it fails Is there really no way around doing

1 2

if (oinstanceofShtuff) {}

In this case? I've always been tought that not only is that hacky, it's also costly in the long run. In this case my OOP OCD screams at me, for doing instanceof.

Alright, I've run into a really silly problem with the Grid implementation. When creating arrays of ArrayLists, is there really no way to speficy what kind of objects can be in there? Normally I would do ArrayList<Shtuff> and that would be fine, but when doing this:

1

privateArrayList<Entity>[][] list = newArrayList<Entity>[cols][rows];

it fails Is there really no way around doing

1 2

if (oinstanceofShtuff) {}

In this case? I've always been tought that not only is that hacky, it's also costly in the long run. In this case my OOP OCD screams at me, for doing instanceof.

I think your looking for: ArrayList< ArrayList< Stuff > >()

You'd also have to use: grid.get( x ).get( y ), rather than: grid

[y]

Using [] is reserved exclusively for arrays (which I don't agree with).

To expand on cylab's post: It depends. The size of the cells vs. maximum extents, what queries are important to speed up, etc. For example for collision detection you only need to store objects in one cell, say the upper-left most one that it covers, then do a grid-based sweep-and-prune. Sketch:

1) walk grid rows from top-to-bottom2) walk the row left-to-right3) walk the contained entities in the cell first to last and perform broad-band collision detection with all enities "forward" in the list. If this entity crosses one-or-more cells to the left and/or bottom of this cell's edges check all of those cells as well.

You never need to check entities to the right or above because they've already done that work.

Beyond that, again, it depends. An example: If you've a very low probability that an entity will cover more than 4 cells (being close to a corner) then for other queries you can simply expand your search by one cell and when an entity happens to cover more than just it's nearest neighbors you note that in an auxiliary list for all further away cells (which you obviously need to check for all other queries).

Don't do abs. Just square each number. If EVERYTHING in your game is relative to the square length. Distance = x^2 + y^2 then the "physics" of it will be fine. If rendering is an issue you can scale it back by division (try and experiment with a division factor). This stops you from doing Math calls all the time. This is how I do my particle simulations anyway.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org