I first tried a linked list. This worked great, that is until I had a whole bunch of memory allocation and deleting problems and realized that I could accomplish the same thing with a static array and a lot less work. The thing that you have to realize is that you _don't_ need unlimited bullets, as that would make no sense. My bullet structure is something like 30-40 bytes in size, which means that I could hold roughly 25,000 bullets in one MB of RAM. As for the removing of bullets from the array, just make it so that when the player shoots, a loop executes that checks for the first empty spot in the array and inserts the bullet there. Make sure this loop is an infinite loop that breaks on inserting the bullet, cause if it's only a for loop, it may not run long enough to find an empty spot. Another thing is to make all the bullet elements in your bullet array pointers, for the obvious reason of creation and deleting.

You can check out the game I am working on at : http://members.home.net/chris-man/

Hope this helps.

Umm... i disagree

I have used linked lists to hold it and have found that to work quite well (and I think wasting a whole mb of memory for holding bullets is a great big waste... but maybe it's just me.)

The reason i don't like the array idea is when you have a lot of enemies and a lot of shots alive. Say you have 10 enemies... each has shot 5 times. And you yourself have shot 3 times yourself. In one iteration, 6 of your enemies and yourself decide to shoot... now think of all the searching that goes on just to find an empty slot!!! I used to do the array idea, but i found it to be just too slow.

With linked list i could just allocate and dealloc as I please. It may cost more time with fewer shots on screen, but if there's only a few shots you won't notice... as more shots/enemies appear, the list starts to go faster as it doesn't have to search. Also, it saves memory.

Just my thoughts...

and g'luck with the game.

Hm, you think that alloc function doesn't search for free space in memory pool? Yes, it do, and it much slower than searching for something you know to search for. I can suggest only one thing:
First, start with allocation memory for, say, 10 bullets. Then, if you want to add new bullet, check if there is enought free space (num_active_bullets

------------------
FlyFire/CodeX
http://codexorg.webjump.com

Well if you alloc a pool of memory for your program at start up, of the maxium free memory and lock it.... Youll pull of what quake does basicly. Then you can just alloc,malloc from that pool. Just watch for not to much memory fragmentation.

Or, as a completely different solution, do bullets like they have in Death Rally- you don't even see them because as soon as you fire them they hit. No array needed.

------------------

Lack

Thanks a heap everyone. Although I didn't understand about some of that stuff, I now know about all these wonderful things I didn't know about earlier (ie linked lists).

Thanks LackOfKnack - most weapons hit automatically, but for a rocket launcher, I though it would be cool to have a rocket actually on the screen.

Anyway, i'd just like to say thanks...

Maybe you can help me then Queasy, you seem to know about linked lists. I agree that they are faster for when you have more bullets, and my linked list worked great. That is, it worked great on my computer! As soon as I tried it on another computer, it would crash after some number of bullets. This number was very odd too. First it would crash after the 22nd bullet fired, no matter how many bullets were on screen, or when it was fired. I changed some memory allocation code and then it crashed every time after the 36th bullet. This didn't happen on my computer, even though it is a really old and crappy computer. Do you have any idea of why this could be happening?

On another note, I noticed that when I changed to the array, the game did not slow down noticeably when I had more bullets on screen (Well, it did, but that was because of all of the explosions happening; this slowdown occurred with the linked list as well). But you are right, I certainly do not like the idea of having all that memory used for bullets when it could be as clean as a linked list.

Thanks

Just thought I'd chime in because I didn't see this mentioned...

There's no need to search for an empty slot if you're doing array bullets. Make a static integer, say, curbullet, set it to 0 at the start of the program. Whenever you need a new bullet, put it in bulletarray[curbullet], then increment curbullet. if curbullet is greater than the size of the array, set it back to zero.

I've found that this method usually works well, with one catch: you have to calc every bullet in the array, so it's best to keep the arrays small (I think I set mine to like 50 or 100, tops). The good news is that this helps to avoid slowdown, since you're doing the same amount of work regardless of how many bullets are actually on the screen; the bad news is that when a new bullet is created, it has the potential to overwrite one that's still active... but with 50 bullets on the screen, no-one's going to notice.

Mason McCuskey
Spin Studios
www.spin-studios.com

The list method is the generic solution.
Works well, and scaleable for as many bullets as you have memory for. However, if your concerned about effienciy then the array method is proably acceptable. However as you noted you'll have to search the array for an open bullet slot, to add new bullets, which is a performance hit but given a reasonable array size, proably negilable. A simple way of seeing which slot is open would be to simulate a link list within the array. Where each slot holds information about the next open slot, and the previous slot its linked too. If your array is small, say under 255 elements thats just 2 bytes of extra data per slot. You manage it like a linked list but since the elements are already allocated there wont be a hit in terms of allocation/deallocation, which for c++ is considerable with all the constructors and destructors. Ya Good Luck!

-ddn

Cromulus,

Yes, i've had your problem before, and the solution was pretty stupid

Heh, what was happening to me (and i'm not sure about you) was that my ptr to the head of the list was not updated to see the next element. So basically... i guess all i can say is be careful when you allocate the next element, and make sure it's linked properly.

If you want (and if i have time ) i can look at that part of the source for you...

And about the speed issue... i have found from experience that it's faster without the arrays (way back in the dos days). But if you (guys) say there's no speed difference when you tried it then i guess i'm wrong