I’m training myself on a bullet hell pattern generator and noticed that bullets move stuttering only when close to screen boundaries. This bug can be noticed especially when bullets are moving towards to the bottom right part of the screen.
In some cases, I also happen to see removed bullets on random points of the screen ( at least until mesh is being cleared every 4000 bullets )
what am I doing wrong?
This code is quite the same I use for other kind of objects in my game and in fact they all seem affected by the same movement/removal issue.
thank you and sorry for the quite long bit of code to look at
@deactive I think it’s something to do with your bounds test, from line 183
I changed your edge padding to 200 and it seemed to remove the movement artefact.
if pos.x < -200 or pos.x > WIDTH + 200 then
--self:removeRect(v.index,k)
v.alpha = 0
table.remove(self.missiles,k)
end
if pos.y < -200 or pos.y > HEIGHT + 200 then
--self:removeRect(v.index,k)
v.alpha = 0
table.remove(self.missiles,k)
end
It seemed as if the rects were getting removed from the update table too soon (i.e., while still visible).
Edit: It looks like you are not accounting for your (potential) randomly added offset (hs, ws) when doing the bounds check on pos as well.
@deactive The problem is with your table delete. You can’t delete an item from a table in the same loop you’re drawing them. When an item is deleted, everything in the table shifts down and items get skipped. If you want to verify this, comment out the lines where you delete the items in FoeMissilesm:draw(). Add a self.delete= false in init. Set this to true when the object should be deleted and have another loop that checks this and delete it.
@deactive - it seems to me that it may just be Codea struggling with a lot of work. Here are a few suggestions.
Each time you add a sprite in draw, you are reading the same image off disk. Read it once, in setup.
All your mesh objects appear to be identical. If this is the case, just create one mesh, in setup, and use it to draw all your objects. This cuts down on the number of meshes and the amount of work required to create objects.
anything else that reduces the amount of work being done in draw
So I would do these things to speed it up, then see if you still have problems.
hi @ignatz, as usual thank you for taking a look at my code.
readImage, you’re right is being recalled 60 times a second, that’s what happens when you copy and paste code out of a major project stupid me.+
I actually use a single mesh with multiple rectangles ( each comes with a texture ). Is this what you meant?
However if you run my code with a few objects so that you’ll have a stable 60fps, you’ll notice the movement issue remains. The movement issue I meant, does not seem to relate to speed/fps matters. ( as far as I can understand )
edit : i looked back at my code, readImage is recalled only once when downloadtimer == 1 and when the image has been entirely downloaded from my public dropbox, that’s not seem to be the reason.
I still see speed issues related to the amount of work being done
One cause may be that although the number of objects levels off after a few seconds, the number of vertices in the mesh keeps climbing, in other words, you are not deleting dead objects from the mesh. Try printing self.mesh.size and you will see what I mean.
What I meant about the mesh was instead of having a rectangle for each object, and altering all the vertex positions with setRect, create just one triangle object in a mesh, then translate and rotate and draw it for all the objects.
--I'm not using your variable names, this is just an example
--if m holds the triangular object
for i,O in pairs(objects) do
translate(O.pos.x,O.pos.y,O.pos.z) --O.pos holds position
rotate(O.rot) --O.rot holds rotation
m:draw()
end
I don’t know if this will be faster, but I expect it would help (and make things simpler).
@deactive After you start your code, tap the < icon to make your program display in full screen. Tap the video recording icon and record the screen for about 20 seconds. Then replay the video and select the drag icon so you can play the video a frame at a time. If you watch the lower right corner, you’ll see that some of the objects aren’t being drawn in the correct places and are causing the irregular movement. At this point I’m not sure what’s causing it, but this gives you a slower view of what’s happening.
@simeon, your suggestion did the trick for the weird movement when close to screen boundaries, thank you ( not sure why it did happen thou, since position check was made when outside the screen view )
@dave1707, when removing an object i put it in a trash table i wipe afterwards in a separate loop, it seems to be working so far.
@ignatz, I’m really interested to know how to implement your sample, I remember a similar topic some weeks ago, but it the translate approach did not let me move each rect individually. This seems slightly different, but i’m not sure how to do it.
@deactive Here’s what happens when you delete something from a table that you’re also using to draw from. Let’s say you draw items 1 thru 10, then you delete item 11. Items 12 thru the end of the table shift down 1 position. Since you were at position 11, you’re next position is at 12. Since item 12 got shifted to position 11, it gets skipped and item 13 is now at position 12 and gets processed. So as you delete items, the table keeps shifting down and items get skipped and aren’t drawn at their new location. So the next time thru you see them at their old location which causes them to appear out of position with the other items.
@deactive If you want to draw and delete items in the same loop, then the loop needs to be processed from the end of the table to the beginning. By going backwards, as you delete items and the table shifts down, you’re not skipping any items.
@deactive - there are quite a few problems, which suggests that it would be a good idea to start with just one object, and track it closely, frame by frame, to remove all the bugs. That’s how a lot of professionals write code - start small, test often.
thanks @dave1707, that explains a lot of things @ignatz, you’re right, i’ll start over taking more care of what i’m writing, thanks anyway for spending your time on my code
stupid me.+