This is from a class assignment:
This program is about listening to colors. We will treat pictures as piano scores.
Write a function called listenToPicture that takes one picture as an argument. It first shows the picture. Next, it will loop through every 4th pixel in every 4th row and do the following. It will compute the total of the red, green and blue levels of the pixel, divide that by 9, then add the result to 24. That number will be the note number played by playNote.
That means that the darker the pixel, the lower the note; the lighter the pixel, the higher the note. It will play that note at full volume (127) for a tenth of a second (100 milliseconds). Every time it moves to a new row, it prints out the row number (y value) on the console.
Your main function will ask the user to select a file with a picture. It will print the number of notes to be played (which is the number of pixels in the picture divided by 16; why?). It will then call the listenToPicture function.
Ok I edited in what I have so far and the only thing I haven't figured out (I believe) is how to print the number of notes in the main function. By the way, thanks to everyone who helped. You guys are amazing. Is there a place to donate to this site?
def main():
pic=makePicture(pickAFile())
show (pic)
listenToPicture(pic)
def listenToPicture(pic):
w=getWidth(pic)
h=getHeight(pic)
for y in range(0,h,4):
printNow(str(y))
for x in range (0,w,4):
px=getPixel(pic,x,y)
r=getRed(px)
g=getGreen(px)
b=getBlue(px)
tot=((r+g+b)/9)+24
playNote(tot,100,127)
Robbie is right for the width/height for loops.
The loop you are using to get the pixels and play the notes looks as if it is getting ALL the pixels and playing them all every time you get a unique x and y. What you should be doing is be getting the pixel at (x,y) then pulling out the rgb values and calling play note on that. You really shouldn't even need the 3rd for loop. You're not too far off. Try writing the problem out in logical steps in plain English. I find that helps a ton before I start coding.
Good Luck.
You asked about similar things before. Well, since you didn't put any code in about actually retrieving the pixel value, I'll assume that you still aren't able to do that. I know this is going way beyond your question, but last time you were pretty vague about your question and indicated that you needed more help than just what you had asked. If any of this is not necessary then just ignore it. I'm just trying to offer some advice and you can take it or leave it.
In case you haven't figured out how to read a pixel, I recommend using PIL. It has functions for opening images documented here. Then you can access a pixel in the image by its x and y value using getpixel which is documented on the same page.
For playing the note I would recommend looking into the PyAudio module and just making your own sinusoids of various frequencies (depending on the magnitude of the pixel) that you write to an open audio stream. There might be better packages for this part, but this is what I have used in my small adventures in Python audio.
For the audio stuff, I would try just outputting a sound at a fixed frequency before trying to actually emit a varying frequency.
Edit:
Your loops look better now so I took out my stuff about your loops.
Related
I'm generating PSF-free images, so no atmosphere and no diffraction, and the images I'm getting out have stars in "quantized" positions. I'm wondering if there is an option in GalSim to prevent this, i.e. to have a more sinc-like distribution of the photons, so the behaviour of photons landing somewhere between pixels is taken into account. If there isn't an option for this, I suppose I would need to create my own sinc-function PSF and implement it around the drawImage() step?
Stars are inherently supposed to look like point sources if you don't have any PSF at all (no atmosphere, no diffraction). They are a delta function in that case, so all of the photons should fall into a single pixel. GalSim is doing exactly what you are asking it to do.
It sounds like you actually do want to have a PSF; I suggest using the galsim.Airy class, representing a diffraction-limited PSF.
I'm trying to make a simple game on an FPGA board and I was hoping to use sprites for background and player characters. To do this I was told to use either Python or Matlab to take an image and convert it to a sprite. I am trying to convert the images to have 16 bits per pixel since the memory on the board can hold 16 bits per memory location.
For the past few days I've been searching for a tutorial or some sort of example to help me figure this out, but I've had no real luck. So I'm just hoping someone can give me advice on how to accomplish this or just point me in the right direction.
I don't know if this helps but I've discussed this with another person and the advice they gave me is to just take an image and put it into a matrix and divide it by 8. Then I'll have 15 bits for color, 5 each for RGB, and then a 16th bit for transparency. I should then write this matrix to a hex file and put it onto the boards memory. There is a program that properly edits the hex file into the correct format so that's not something I have to worry about.
Does this approach seem right? Or is there a better way? Thanks in advance!
ok, I've got into programming with python and thus far was having a fair amount of success. I've typed up a program that uses pyautogui to automates atask I need to do on a monthly basis.
I took Screenshots of where I needed the mouse to click and when all was done I had a working program that searched the screen for the button to clicked, controlled the mouse that location, and printed out the report I needed. So, all I needed to do was plug it into the task scheduler and it would do the work for me!
Several days afterwards, I decided to go ahead and schedule it. I ran the program again, and it crashed! Long Story short, the screen shots didn't match. I took a screen shot again, and zoomed both images 800% in Paint, and check the pixel next to the "I" in The two different images and sure enough the rgb values are different.
I tried several other places to, and while they looked the same... The rgb values are different by maybe one or two points! I'm curious as to why is this happening!
Use confidence, default value is 0.999. Reason is pyscreeze is actually used by pyautogui which has the confidence value which most likely represents a percentage from 0% - 100% for a similarity match. Looking through the code with my amateur eyes reveals that OpenCV and NumPy are required for confidence to work otherwise a different function would be used that doesn't have the confidence value.
for example:
by doing pyautogui.locateCenterOnScreen('foo.png', confidence=0.5) will set your confidence to 0.5, which means 50%.
So I've been making a game using Python, specifically the PyGame module. Everything has been going fairly well (except Python's speed, am I right :P), and I've got a nice list of accomplishments from this, but I just ran into a... speedbump. Maybe a mountain. I'm not to sure yet. The problem is:
How do I go about implementing a Camera with my current engine?
That probably means nothing to you, though, so let me explain what my current engine is doing: I have a spritesheet that I use for all images. The map is made up of a double array of Tile objects, which fills up the display (800 x 640). The map also contains references to all Entity's and Particles. So now I want to create a a camera, so that the map object can be Larger than the display. To do this I've devised that I'll need some kind of camera that follows the player (with the player at the center of the screen). I've seen this implemented before in games, and even read a few other similar posts, but I need to also know Will I have to restructure all game code to work this in? My first attempt was to make all object move on the screen when the player moves, but I feel that there is a better way to do this, as this screws up collision detection and such.
So, if anyone knows any good references to problems like this, or a way to fix it, I'm all ears... er.. eyes.
Thanks
You may find this link to be of interest.
In essence, what you need to do is to distinguish between the "actual" coordinates, and the "display" coordinates of each object.
What you would do is do the bulk of the work using the actual coordinates of each entity in your game. If it helps, imagine that you have a gigantic screen that can show everything at once, and calculate everything as normal. It might help if you also designed the camera to be an entity, so that you can update the position of your camera just like any other object.
Once everything is updated, you go to the camera object, and determine what tiles, objects, particles, etc. are visible within the window, and convert their actual, world coordinates to the pixel coordinates you need to display them correctly.
If this is done correctly, you can also do things like scale and otherwise modify the image your camera is displaying without affecting gameplay.
In essence, you want to have a very clear distinction between gameplay and physics logic/code, and your rendering/display code, so your game can do whatever it wants, and you can render it however you want, with minimal crossover between the two.
So the good news is, you probably don't need to change anything about how your game itself works. The bad news is, you'll probably have to go in and rewrite your rendering/drawing code so that everything is drawn relative to the camera, not to the world.
Since I can't have a look into your code, I can't assess how useful this answer will be for you.
My approach for side scroller, moveable maps, etc. is to blit all tiles onto a pygame.Surface spanning the dimensions of the whole level/map/ etc. or at least a big chunk of it. This way I have to blit only one surface per frame which is already prepared.
For collision detection I keep the x/y values (not the entire rect) of the tiles involved in a separate list. Updating is then mainly shifting numbers around and not surfaces anymore.
Feel free to ask for more details, if you deem it useful :)
I'm making Tetris and im trying to make a line clear function. I have a way to do this that is a bit complicated and im looking to simplify.
My idea is to check some pixel RGB values and see if they're not black (the color of the background). Is there a quick way to get the RGB value of a pixel on the screen?
pygame.PixelArray should do the trick. You can use it on the screen surface.
But personally, I wouldn't recommend that you use the pixels as a reference.
Handling everything logically is a lot better.
As Icfseth noted "Handling everything logically is a lot better."
Tetris is an array of blocks that occupy a logical space that has a granularity larger than a pixel. Your game model should operate in "block coordinates" and detect whether a space is open or filled based on that. The screen is just a representation or "view" of the block space.
Try first just moving a 16px square around a 320x320px screen in steps of 16px. You could keep track of every pixel, but it makes much more sense to have have the block position ranging from x = [0..20], y = [0..20], and let the display code worry about how to show a block at position (2,3).