Flexible array recycling help
Author |
Message |
Raknarg
|
Posted: Sat Oct 15, 2011 11:38 am Post subject: Flexible array recycling help |
|
|
Alright so I've been going through an old game I started making about 8 months ago, an I'm redoing the entire program. However, there is one thing that I cannot fix. What it should be doing is making sure that the flexible array I'm using to keep track of the enemies doesnt get too big, but it doesnt seem to be doing anything. I used almost the exact same thing in another program and it worked.
It first looks through all the enemies and sees if any of them are dead. If they are, it sets the number to the array at that point. If none are, it'll just make a new enemy.
Turing: |
enemyTimer + = 1
if enemyTimer > 50 then
loop
enemyNum + = 1
exit when
enemyNum > upper (enemy ) or
enemy (enemyNum ).dead = true
end loop
if enemyNum > upper (enemy ) then
enemyNum := upper (enemy ) + 1
new enemy, enemyNum
end if
% here's where I would set all the stats of the new enemy
enemyTimer := 0
enemyNum := 0
end if
|
Any ideas on how to make it work? I can tell it's not working, because I've put the enemyNum on the screen, and it never goes down at all. It always just incrementally goes up by 1. |
|
|
|
|
|
Sponsor Sponsor
|
|
|
mirhagk
|
Posted: Sat Oct 15, 2011 11:45 am Post subject: RE:Flexible array recycling help |
|
|
it would never go down. Best it would do is not go up. Also your
Turing: |
if enemyNum > upper (enemy ) then
enemyNum := upper (enemy ) + 1
new enemy, enemyNum
end if
|
is useless, because when would the if statement be true, and the assignment be useful?
But other than that, check the enemy dieing code |
|
|
|
|
|
Raknarg
|
Posted: Sat Oct 15, 2011 3:14 pm Post subject: RE:Flexible array recycling help |
|
|
Oh yeah, I already knew that, I fixed it when I looked at it.
And the enemies do die, I already know that... Idk, maybe I'll find it later. For the moment, it doesnt seem to drag on the gameplay too much, so its not the end of the world |
|
|
|
|
|
mirhagk
|
Posted: Sat Oct 15, 2011 3:36 pm Post subject: RE:Flexible array recycling help |
|
|
Rather than a flexible array being resized, I'd suggest making a really big array, and then just find unused elements in that. You could even use a linked list, and then you wouldn't even need to do pretty much any processing when you add a new element. |
|
|
|
|
|
Raknarg
|
Posted: Sat Oct 15, 2011 3:59 pm Post subject: RE:Flexible array recycling help |
|
|
Yeah, I was considering just going for a regular array, I had to do the same thing for my bullets as well.
And as for linked lists (correct me if I'm wrong), it seems that I could achieve the same thing with flexible arrays with a lot less code. |
|
|
|
|
|
Tony
|
Posted: Sat Oct 15, 2011 4:02 pm Post subject: RE:Flexible array recycling help |
|
|
"less code" doesn't always mean "faster code" |
Tony's programming blog. DWITE - a programming contest. |
|
|
|
|
trishume
|
Posted: Sat Oct 15, 2011 4:25 pm Post subject: Re: Flexible array recycling help |
|
|
I had the same problem for dead particles for my particle engine. Solved using linked lists. I marked particles as dead and then deallocated them in batches. You can also recycle them by keeping a dead list and a live list.
For an example of how to implement it take a look at the particle engine on my github account.
https://github.com/trishume |
|
|
|
|
|
mirhagk
|
Posted: Sat Oct 15, 2011 4:45 pm Post subject: RE:Flexible array recycling help |
|
|
Adding a new element using your current code takes up to 2x as many operations as there are enemies, since it needs to search through the entire list, and then create a new array, and copy them over.
Adding a new element to a linked list takes the same amount of operations no matter how many enemies, and all it takes is changing 2 pointers (or indices depending on implementation) |
|
|
|
|
|
Sponsor Sponsor
|
|
|
Raknarg
|
Posted: Sat Oct 15, 2011 8:33 pm Post subject: RE:Flexible array recycling help |
|
|
It's ok guys, I solved the issue with a fixed array.
@Tony yeah, usually I go for simplicity this just makes more sense to me right now. I'll make a note to look at it in the future, however. |
|
|
|
|
|
|
|