Managing bullet object lists

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
User avatar
ExPorygon
Prole
Posts: 10
Joined: Tue Apr 04, 2017 1:57 pm
Location: New York, United States
Contact:

Managing bullet object lists

Post by ExPorygon » Thu Nov 28, 2019 5:55 am

I'm building a bullet hell shmup system and I'm trying to determine the best way to implement a list of shot objects, since there are going to be a lot of them. I had decided that generating brand new objects for each bullet at the time of firing would be inefficient. So instead I decided to initialize 5000 dead bullet objects in advance.

Code: Select all

for i = 1, 5000 do
    local obj = ObjShot(0,0) --generates bullet with default coordinates (0,0)
    obj.isDelete = true --ensures that its inactive
    shot_all[i] = obj --adds to the shot list
end
For bullet creation, I use a function to find the first available dead bullet object for its reactivation.

Code: Select all

function findDeadBullet()
	local x = 0
	while true do
		x = x + 1
		if shot_all[x].isDelete == true then --if bullet object is inactive then it is returned for use
			break
		end
	end
	return x
end
The reactivation would, however, still consist of re-running the function that initializes its default values. I can include that code too, but it gets more complicated from there.

I realize now that when there are a lot of bullets already in existence, the findDeadBullet function has to iterate through more of the shot list to find a dead one, which may be significant.

I was wondering if there was a different, more efficient way of handling this. One thing I thought of that was an extension on this was to start the bullet list small and increase its size as needed. This might not have a tangible benefit, however, and may in fact introduce hitches when generating the new dead shots for the size increases.

User avatar
raidho36
Party member
Posts: 1954
Joined: Mon Jun 17, 2013 12:00 pm

Re: Managing bullet object lists

Post by raidho36 » Thu Nov 28, 2019 8:54 am

You can put all your dead bullets on a stack. That way, any bullet at all from that stack is guaranteed to be dead (so this variable isn't needed anymore), and you can just remove one from the tail, which is a very fast operation. The list of live bullets might be a gapless array - a regular array with very fast but non-order-preserving removal operation. Both of those are implemented in a single library: https://bitbucket.org/rcoaxil/lua-minil ... uarray.lua

I've also made a dedicated library for handling object pools: https://bitbucket.org/rcoaxil/lua-minil ... t/pool.lua It too however will run :init function of objects that it retrieves from storage. I did it this way so that dead object can be initialized in the same function call, not separately. You can however simply call some lightweight "revival" function instead, but my solution is to have lightweight init function.

User avatar
ExPorygon
Prole
Posts: 10
Joined: Tue Apr 04, 2017 1:57 pm
Location: New York, United States
Contact:

Re: Managing bullet object lists

Post by ExPorygon » Sat Nov 30, 2019 9:44 pm

Ah thanks, a stack is a good suggestion. Going to try that out. I was actually already looking at uarray.lua as something to potentially be used for bullet lists, but I hadn't come across pool.lua. Looking at it, I'm not sure exactly how its meant to be used.

User avatar
raidho36
Party member
Posts: 1954
Joined: Mon Jun 17, 2013 12:00 pm

Re: Managing bullet object lists

Post by raidho36 » Sun Dec 01, 2019 1:54 am

Code: Select all

Bullet = Class ( )
function Bullet:init ( x, y, damage, ... )

bulletpool = Pool ( Bullet )

newbullet = bulletpool ( x, y, damage, ... )
bulletpool:push ( deadbullet )
Also my mistake. The "uarray.lua" datastructure has additional bookkeeping to prevent duplicate objects in it so you don't need to write that same code before every insertion. You can probably do with "array.lua", which has the same exact functionality but no object bookkeeping, so it's faster.

Post Reply

Who is online

Users browsing this forum: No registered users and 14 guests