So I'm having 3 days education seminar which isn't of much use for me, so I'm writing my program on a paper and I'm wondering something since I can't test it at-the-moment.
I'm basically scanning my screen for image, and screen is divided into 8 segments. I don't need to scan all 8 segments, but for instance now, let's say I only need to scan 5 out of those 8 where image can pop out.
Is it faster to just make pyautogui to scan whole screen and write down coordinates where image was seen, and I'll then know by coordinated on which screen it popped, or is it faster to make multiple pyautogui searches with defined regions? So is it faster if pyautogui searches whole screen once or if pyautogui makes multiple searches with defined regions, searching only 20-70% of screen?
If it depends on how much screen in the end I search, what would be aproximate percentage where one becomes faster than other? For instance: searching 4 times 50% of screen is faster than searching once 100% screen, but searching 6 times 75% of screen is slower than searching once 100%.
I think that the faster and more efficient/accurate process here would be searching the whole screen through pyautogui and write down the coordinates where the image was seen, and you then knowing by the coordinated on which screen it popped...
So I would reccomend using this method as the second methos would be more slower and not as efficient as this
I am making an analogue clock in Python using turtle. It has to be renewed every t seconds. For that, I am redrawing it every t seconds. I need it to be redrawn immediately (now it places all the elements one by one taking more than my t seconds). How can I do that? Actually, it does not have to be redrawn every t seconds, it's just the hands that have to move. Is there any other, easier way?
I have tried making speed 0 but that does not help. Maybe, there are some other ways to make the hands move?
turtle.reset()
turtle.speed(0)
while True:
turtle.reset()
clock_face.draw()
hour_hand.showCurrentTime()
minute_hand.showCurrentTime()
second_hand.showCurrentTime()
turtle.up()
time.sleep(t)
You can use turtle.tracer(0, 0) which will turn off animation and should significantly speed up your animation. If you decide to turn off animation, you will need to use turtle.update() at the end of your code.
However if you want it to animate every so often, the first parameter is some n value that will animate the n-th animation, and the second is a delay.
Some people have gotten things working very fast here:
How to speed up python's 'turtle' function and stop it freezing at the end
So I am in the process of coding a simple pong game but right now the ball sometimes has a small weird jiggle. It doesn't mess up gameplay but the jiggle is certainly visible. I monitored the speed of the ball and it seems to have a constant integer speed. So why does the ball jitter slightly sometimes even though the speed of the ball remains the same?
A code sample would be ideal but some of the problems you may be facing include:
Pixel jitter because the ball needs to move at a speed that does not sync up with the frame rate of the game (so in 1 frame the ball move 3 pixels but in another it moves 2).
Integer rounding. The position of the ball may be rounding to unexpected locations, so go over your code and check calculations of the balls movement.
It may be helpful to look at this: https://stackoverflow.com/questions/14538991/smoother-motion-using-pygame.
However these are just speculation because I'm missing the source code.
Hope this helps :)
Thanks for taking the time to read this.
Right now I'm making a really basic tile based game. The map is a large amount of 16x16 tiles, and the character image is 16x16 as well. My character has its own class that is an extension of the sprite class, and the x and y position is saved in terms of the tile position.
To note I am fairly inexperienced with pygame.
My question is, I am planning to have character movement restricted to one tile at a time, and I'm not sure how to make it so that, even if the player hits the directional key dozens of time quickly, (WASD or arrow keys) it will only move from tile to tile at a certain speed. How could I implement this generally with pygame? (Similar to game movement of like Pokemon or NexusTk). One movement would result in a player being in a tile. They couldn't stop halfway between tiles for example.
Thanks for your time! Ryan
You store your characters location as a grid coordinate. So if he's at (2,0) he is rendered at (32,0). The game then animates him moving between tiles, but, he's either on one or the other. While in the move state, you render an (x,y) offset between 0 to tilewidth.
It sounds like you want one move per keypress, if time elapsed / animation has completed. So:
On keypress, toggle to: animating state
Set destination tile coordinate
draw offset, between 0 and tilewidth, depending on time elapsed. offset = (elapsed_ms / 1000.) * tile_w would scale between 0 to 16 if time is less<= 1 second.
Once time elapsed is >= animation length (I chose 1000. above), switch to stationary state.
If keypress happens while in animation state, ignore it.
Pygame example: using numpy for map array.
I am trying to decide if it is better to use a pre-rendered large image for a scrolling map game or to render the tiles individual on screen each frame. I have tried to program the game both ways and don't see any obvious difference in speed, but that might be due to my lack of experiences.
Besides for memory, is there a speed reasons to not use a pre-rendered map?
The only reason I can think of for picking one over the other on modern hardware (anything as fast and with as much ram as, say, an iPhone), would be technical ones that make the game code itself easier to follow. There's not much performance wise to distinguish them.
One exception I can think of, is if you are using a truly massive background, and doing tile rendering in a GPU, tiles can be textures and you'll get a modest speed bump since you don't need to push much data between cpu and gpu per frame, and it'll use very little video ram.
Memory and speed are closely related. If your tile set fits in video memory, but the pre-rendered map doesn't, speed will suffer.
Maybe it really depends of the map's size but this shouldn't be a problem even with a low-level-computer.
The problem with big images is that it takes a lot of time to redraw all the stuff on it so you will get an unflexible "map".
But a real advantage with an optimized image(use convert()-function and 16 bit) is are the fast blittings.
I work with big images as well on a maybe middle-good-computer and I have around 150 FPS by blitting huge images which require just ~ 100? MB RAM
image = image.convert()#video system has to be initialed
The following code creates an image(5000*5000), draws something on it, (blit this to the screen, fill the screen)*50 times and at the end it tells how long it took to do one blit and one flip.
def draw(dr,image,count,radius,r):
for i in range(0,5000,5000//count):
for j in range(0,5000,5000//count):
dr.circle(image,(r.randint(0,255),r.randint(0,255),r.randint(0,255)),[i,j],radius,0)
def geschw_test(screen,image,p):
t1 = p.time.get_ticks()
screen.blit(image,(-100,-100))
p.display.flip()
return p.time.get_ticks() - t1
import pygame as p
import random as r
p.init()
image = p.Surface([5000,5000])
image.fill((255,255,255))
image.set_colorkey((255,255,255))
screen = p.display.set_mode([1440,900],p.SWSURFACE,16)
image = image.convert()#extremely efficient
screen.fill((70,200,70))
draw(p.draw,image,65,50,r)#draw on surface
zahler = 0
anz = 20
speed_arr = []
while zahler < anz:
zahler += 1
screen.fill((0,0,0))
speed_arr.append(geschw_test(screen,image,p))
p.quit()
speed = 0
for i in speed_arr:
speed += i
print(round(speed/anz,1),"miliseconds per blit with flip")
Depends on the size of the map you want to make, however, with the actual technologies it's very hard to see a tile-map "rendered" to take longer than expected, tiled based games are almost extinguished, however is always a good practice and a starting point to the world of game programming