-.-
Now I feel pretty dumb haha. I did not expect the ‘help’ to be that useful, so never selected it.
That will help out a ton! Thanks for mentioning that @mikael

Exactly, they are tuples.
Most of my learning comes from

Print(f’Some identifier name: {variableImCuriousAbout}’)

That and adding a break point in areas just to browse local variables and their contents/types. Same with globals, but either way. Printing and just being curious helps a ton.

I’m not great with SW, definitely more knowledgeable in the EE/circuit analysis region, but I am learning just like you. @mikael has been a great help so far and so has @JonB so keep an eye out for their posts!

@mikael said:

@Robert_Tompkins, I gave the game a try on an iPhone 11 Pro. It looked good, and I noticed no performance issues.

I did not get very far in the game, though, mainly due to some playability kinks:

• Ship jumping to finger location. instead of moving relative to finger movement, killed me several times.
• Game tended to go to the pause screen very easily, which broke the flow.
• Game balance seemed off, first a few little rocks, then a screenful.

Hey thanks for trying it out, I wonder why I keep running into performance issues then.
The jumping shouldn’t happen at all!
Pausing should only happen when your finger lifts off the screen.
I added that ‘feature’ because the upgrading required you to pause the game (top left corner) and by the time you came back out of it, the meteors would be on you before you had time to react lol.

Yes, balance is way off in that version haha, that’s my ‘dev’ version. I tweaked it so that there was only 1 main currency, and it awarded a HUGE amount, and dropped often. This way I could upgrade a ton and stress it. But regardless, thanks for the feedback!

I also tweaked the stages from 30 seconds down to 10. So that may explain the none then flood.

Oh and also, define your width and height parameters BEFORE you define its location.
This way it can take the width and height into consideration when calculating where the center should be.

@resserone13 said:

@Robert_Tompkins can you explain to me what’s going on here. I figure you account for something by subtracting and multiplying. Also what is the center[0] doing?

stopSelectorButton.x = (stormView.center[0] - (stopSelectorButton.width * 0.5))

And here.
add_room_button.center = ( (add_room_view.width / 2), (add_room_view.height / 2) )

Alright, so first things first..
stopSelectorButton is essentially an object that will be placed on screen.
We need to describe what it looks like, and where it will be.

The size consists of a width and a height (in pixels?)
So size can be defined as ( (object.width = 100), (object.height = 50) )

To answer your questions:
stopSelectorButton.x = (stormView.center[0] - (stopSelectorButton.width * 0.5))
Here we are defining where to place the LEFT side of the button.

The StormView.center parameter contains an x and a y coordinate describing where it’s center point is located.
Printing it produces something like this: (100.00, 200.00).
This is a list of 2 items:
’index 0’ or ‘[0]’ contains 100.00 This is the x coordinate of its center
‘Index 1’ or ‘[1]’ contains 200.00 This is the y coordinate of its center

So by saying: stormView.center[0], we are specifying The value of its x coordinate center point, 100.00
If we place the button’s left side at: stormView.center[0]
Our button would start at the center of stormView, but would extend 100 pixels to the right since the button is 100 pixels wide.

To make up for this, I took half of the button’s width: stopSelectorButton.width * 0.5
And subtracted that from the center of the view’s x coordinate to shift it left by half of its width.

The easier way is the second one you pointed out.
By placing the button using its center coordinate, we could place it in the center of the view like this:

add_room_button.center = ( (add_room_view.width / 2), (add_room_view.height / 2) )
or
add_room_button.center = ( (add_room_view.center[0]), (add_room_view.center[1]) )
or
add_room_button.center = add_room_view.center

Since our button’s center parameter must be a set of 2 values: x and y coordinates any should do the trick.

Long story short, I am accounting for the width and height of the button, which is only necessary if you are placing it using its x and y corner coordinates (top left).
Because the button will extend Right past the x coordinate by its width, and Down past its y coordinate by its height.

Ahh, sorry for making you wait so long! Totally been ignoring my notifications lately. Let me go back and see if I can answer your questions!

I may or may not be able to help you. However, somebody can.
But I bet that somebody will ask to see what your code looks like :p

Use the </> button and paste the code producing those errors.

This is NOT inside update(), it is in setup. Just for reference.
Time to add 5000 MiniRockets List: 0.2149660587310791

These are all inside of update.
Max Item Collision execution time: 0.001150369644165039
Max Laser Collision execution time: 0.026622772216796875
Max Spawn Item execution time: 0.0004971027374267578
Max Should Fire execution time: 0.0007219314575195312

The max value is a global variable and is only overwritten if the current call is > Max.
It looks like Laser Collisions are the worst, with Item Collisions coming in second.
Let me know if you have any recommendations on improving the laser collision checks. Aside from what you already recommended, of course.

Here is how I’m recording it:

def update(self):
        global maxExecutionTimeItem
        global maxExecutionTimeLaserCollision
        global maxExecutionTimeSpawnItem
        global maxExecutionTimeShouldFire
        #if self.game_over:
            #return
        
        startTimeItem = time()
        self.check_item_collisions()
        stopTimeItem = time()
        executionTimeItem = stopTimeItem - startTimeItem
        if executionTimeItem > maxExecutionTimeItem:
            maxExecutionTimeItem = executionTimeItem
        #print(f'Item Collision execution time: {executionTimeItem}')
        startTimeLaser = time()
        self.check_laser_collisions()
        stopTimeLaser = time()
        executionTimeLaser = stopTimeLaser - startTimeLaser
        if executionTimeLaser > maxExecutionTimeLaserCollision:
            maxExecutionTimeLaserCollision = executionTimeLaser
        #print(f'Laser Collision execution time: {executionTimeLaser}')
        
        startTimeSpawnItem = time()
        if random.random() < 0.05 * self.stageNumber:
            if len(self.items) < 100:
                self.spawn_item()
        stopTimeSpawnItem = time()
        executionTimeSpawnItem = stopTimeSpawnItem - startTimeSpawnItem
        if executionTimeSpawnItem > maxExecutionTimeSpawnItem:
            maxExecutionTimeSpawnItem = executionTimeSpawnItem
        #print(f'Spawn Item execution time: {executionTimeSpawnItem}')
        
        if (len(self.touches)) >= 1:
            startTimeShouldFire = time()
            self.shouldFire()
            stopTimeShouldFire = time()
            executionTimeShouldFire = stopTimeShouldFire - startTimeShouldFire
            if executionTimeShouldFire > maxExecutionTimeShouldFire:
                maxExecutionTimeShouldFire = executionTimeShouldFire
            #print(f'Should Fire execution time: {executionTimeShouldFire}') 

@JonB Awesome, thanks for taking the time to play around with it!
I will look into what you mentioned about the meteor init and try it out.

I did notice an improvement when I added the fragments into a list.
But the moment I did the same for the meteors, I noticed that things start slowing down a ton, even without a bunch of fragments on screen.
For example, using the laser weapon, I still see the ‘slow-mo’ movement. I also disabled all sound except the weapon firing to help me listen for changes in performance. I can hear it bogging down for sure.

I did add some logging to determine the time difference between creating a huge list and then popping everything from the list with the variable being using a ‘deque’ and using a standard list. Did the same with a dictionary. Funny enough, list seems faster. I tried to use it the way it was intended (fast access/modification from either end of list) but still saw the list out-performing.

I am in the process of simplifying my meteor creation and removing unnecessary calls, arguments, etc. so once I have it barebones, I will look at it from a ‘meteor generator’ perspective.

The other idea I had was similar to Chicken Invaders. Where instead of meteors, it was a set amount of enemies on screen, that just moved back and forth slightly, dropping danger until they are destroyed. Then a new stage is presented, etc.. This would limit the number of ‘items’ on screen, or at least define the exact number being presented. But this would require a lot more work, and I would want to clean everything up before I do that anyway.

Thanks for the ideas and feedback! I will add some more code to figure out what might be eating up resources. I did try multi-threading on each collision method, this may have improved performance slightly, but had some ‘pop from empty list’ errors, understandably.

Great, thanks. I will try swapping out my lists later today or tomorrow.
I might also need to play around more with the whole ‘parent’ side of things, since I feel like that keeps hanging me up. I could benefit a ton by understanding it fully.
I’ll paste the instructions I typed out yesterday before I found out I couldn’t upload it here lol.

If you have an iPhone 11 pro max, or Can resize the scene for your device easily.. feel free to try it out and experience it first hand.
If you tap Load Profile and enter ‘ADMIN’ or ‘SUDO’, you can specify a stage number and start with enough cash to upgrade either weapon plenty.

I removed most of the sounds and most of the explosion textures, etc to narrow down the cause.
I also commented out all the unused functions/code to make it easier to navigate.
But it isn’t perfect haha. I typically clean my code up once I am happy with the functionality, which I haven’t achieved yet.

Below you will find the program, as well as a modified game_menu.py that I modified to allow me to resize the menu by passing in additional arguments. I believe I only needed this functionality when I was recording and displaying a leaderboard. Anyway.

Make sure you name the game_menu as follows:
GameMenu.py

If you have issues running it, let me know. I think I added handling in there to take care of any custom-made items that others may not have on their device but could have missed something.
And no guarantees it will work/compile at all!
But it does work on my iPhone 11 Pro Max iOS 13.0 with Pythonista version 3.3 (latest version on Apple App Store).

Here is the Main Code
https://gist.github.com/dad61ed3b8a5a83cd72f4acc5932db42

Here is the modified menu code
https://gist.github.com/56ee84710967319b7bc4e8904d9391cf