Re: [pygame] man oh man Java is painful
On Wed, Nov 2, 2011 at 7:19 PM, Greg Ewing wrote: > On 03/11/11 04:31, Ian Mallett wrote: > >> C++ is a pain to learn, but it's definitely worth it. In my >> opinion it's the best compiled language. >> > > I'm afraid I can't share your opinion of C++. I liked it myself > at first, but after 10 years or so of experience I came to > the conclusion that it goes to extreme lengths to solve a > problem you shouldn't be having in the first place. > > My opinion now is that if what you're doing is too big to do > easily in plain C, you should be using a language that provides > you with properly isolated high-level abstractions -- such > as Python, for example. :-) > Oh definitely. I just think that if you're going to go with a compiled language, a good general purpose one is C++. If I want to hack something up quickly, I'll use Python. I contend that good design is definitely possible with C++ (in a way that it often isn't with C), but that yes, it can take a while to get right. However, I often tell students that, although having an elegant, structured design is desirable--being so simple as to require only a basic one is better. For projects of most practical scopes (like a simple game or utility), you don't need anything too involved. Ian
Re: [pygame] man oh man Java is painful
On 03/11/11 04:31, Ian Mallett wrote: C++ is a pain to learn, but it's definitely worth it. In my opinion it's the best compiled language. I'm afraid I can't share your opinion of C++. I liked it myself at first, but after 10 years or so of experience I came to the conclusion that it goes to extreme lengths to solve a problem you shouldn't be having in the first place. My opinion now is that if what you're doing is too big to do easily in plain C, you should be using a language that provides you with properly isolated high-level abstractions -- such as Python, for example. :-) I've yet to decide whether there's a place for a language that combines Python's flexibility and get-out-of-your-way nature with static type checking and efficient code generation. If there is, I don't think that language exists yet. -- Greg
Re: [pygame] man oh man Java is painful
On 03/11/11 04:28, Sean Wolfe wrote: I have been thinking that since I want to eventually port my game to iphone, I'll have to learn obj-c, so why not java first... how hard can it be? haha. Can't see how that would help -- ObjC is nothing at all like Java. Learning Smalltalk would actually be better preparation for ObjC (and would be a lot more enjoyable besides!) -- Greg
Re: [pygame] man oh man Java is painful
On 03/11/11 03:45, Sean Wolfe wrote: I'm getting into the wonderful world of Android which means Java. Dear lord I remember now why I hate this language. I love the pythonic philosophy that there should be an obvious way to get things done. There's at least one project afoot to enable pygame programming on Android: http://pygame.renpy.org/ And there are some encouraging words concerning Python in general on Android here: http://www.linuxjournal.com/article/10940 -- Greg
[pygame] pygame.init()/pygame.mixer.init() Hangs
Hi, I've never had a problem with this before, but pygame.init() is hanging indefinitely. The only thing I can think of is that I uninstalled some programs. These might have deleted some .dll or something. However, I tried reinstalling PyGame, to no effect. By testing the modules individually, I've concluded that pygame.mixer.init() is the function that hangs. Help? Thanks, Ian
Re: [pygame] a bit #ot: design for a game board supporting user facing different directions?
On Nov 2, 2011 4:11 PM, "Alex Hall" wrote: > Moving 2 steps, facing 90 degrees. Starting at (0.0, 0.0) > Now at (2.0, 1.2246468525851679e-16) > > What happened to make the second coordinate so far off? TIA. This is not a very large number, but a very *small* number. Note the negative exponent. This is due to inevitable rounding errors in floating point maths: it's not possible to represent the angle PI/2 perfectly without a tiny amount of rounding. Depending on what you're doing, you can probably ignore it, but you might need to think about margins of error when comparing floating point numbers, and you might want to think about how much precision you want to keep when printing them out. > > > On 10/30/11, DR0ID wrote: > > On 30.10.2011 04:29, Alex Hall wrote: > >> It is real-time. I don't want it as accurate as movement acceleration > >> for stepping, at least not yet, but I am not sure how I would manage a > >> map without a grid. How, for instance, will the computer know where > >> the player is in relation to objects? If the player fires a weapon, > >> how can the computer calculate if the projectile will hit a target? > >> Currently I am planning to manage targeting by getting the slope of > >> the line and the point of the player, then extending the line to the > >> weapon's range and seeing if it intersects a point on which there is > >> an object. > >> For my game creation I am using the Blastbay Game Toolkit, which is a > >> subset of C++ but written specifically for use with audio games and > >> run sort of as a scripting language through an interpreter. For > >> instance, there is a sound class, a tts class for speaking text, > >> sound_pool (sort of like a "world" that manages sound positioning > >> relative to the player), a timer, and so on. Sound_pool, which I > >> subclass for my Map class, relies on a grid to properly position > >> sounds, which is the other reason I am using grid-based positioning. I > >> can't imagine how it would work with no grid. Is there a way? > >> > >> On 10/29/11, René Dudfield wrote: > >>> Hi, > >>> > >>> a few notes, and questions... > >>> > >>> Is your game turn based? Or is it real time? > >>> > >>> If you don't have realistic 3d sound, then using a grid is probably > >>> easier > >>> for players. > >>> > >>> Instead of frame rate, think about it like the update rate of your main > >>> loop. > >>> > >>> Before the player takes a step they are standing. When standing, speed > >>> is > >>> zero. When stepping, the person gets some acceleration and moves. Then > >>> they get some deceleration and stop. > >>> > >>> It's more complicated than that, but the more physically accurate you > >>> want > >>> it, then more complex your code will be. If you're more interested in > >>> making the game, than a physics engine, you might want to consider > >>> looking > >>> at one of the physics engines available. > >>> > >>> Keeping the game movement to grids might make it easier to play as well > >>> as > >>> program. > >>> > >>> > >>> cheers, > >>> > >> > > > > Hi Alex > > > > Do you know about coordinates and vectors (vector math)? This is how it > > is done in most games. If you make your game grid based, I have not > > understand if you want just go from one grid cell to another or if you > > want to allow arbitrary positions in between cells. According to your > > example it looks to me as if you want to go from one cell to another, so > > going diagonal would just move you to the next cell diagonally. Of > > course this means you travel faster because you cover a longer distance > > (diagonal is sqrt(2) longer) than moving orthogonal. You could restrict > > movement to just up/down and left/right and not allow diagonal movement > > at all. If you want to allow diagonal movement then you need to decide > > if you want to move from cell to cell (where diagonal movement is faster > > then) or if you want to allow arbitrary positions. > > > > I hope it helps. > > > > ~DR0ID > > > > > -- > Have a great day, > Alex (msg sent from GMail website) > mehg...@gmail.com; http://www.facebook.com/mehgcap
Re: [pygame] a bit #ot: design for a game board supporting user facing different directions?
Never mind, I found it. The result is very small, but not quite 0 due to Python's standard floating point numbers not having the precision to go further. I'll just check for this sort of thing and assume 0 if the result is too low. On 11/2/11, Alex Hall wrote: > I am wanting arbitrary positioning. The grid squares are for > positioning objects on the map and reporting the user's location to > give them an idea of where they are. > I think I can do this in Python, using sound_lib > (http://hg.qwitter-client.net), so I am back on familiar ground as far > as the language goes. However, I tried using the equations you guys > gave me and odd things happened. First, here is my move() function, > stored in the Object class, where Object is something on a map. > self.stepLength is how long each step is and is currently at 1 > (meter). I use x and z instead of x and y because of how the bass > audio library, on which sound_lib is based, works; y is height, not > forward/backward movement as one would expect. > > def move(self, direction=None, steps=1): > #move the specified number of steps in the specified direction (in > radians) > if direction is None: direction=self.angle #currently set to 0 degrees) > print "Moving "+str(steps)+" steps, facing "+str(direction)+" > degrees. Starting at "+str((self.x, self.z)) > for i in range(steps): >self.x+=self.stepLength*math.sin(math.radians(direction)) >self.z+=self.stepLength*math.cos(math.radians(direction)) > print "Now at "+str((self.x, self.z)) > > Starting at (0, 0), you would expect the new position to be (0, 2) > since two steps were taken straight ahead, and this does indeed > happen. However, when you turn to 90 degrees, you would expect 2 steps > to get you to (2, 0), but instead you get this: > > Moving 2 steps, facing 90 degrees. Starting at (0.0, 0.0) > Now at (2.0, 1.2246468525851679e-16) > > What happened to make the second coordinate so far off? TIA. > > > > On 10/30/11, DR0ID wrote: >> On 30.10.2011 04:29, Alex Hall wrote: >>> It is real-time. I don't want it as accurate as movement acceleration >>> for stepping, at least not yet, but I am not sure how I would manage a >>> map without a grid. How, for instance, will the computer know where >>> the player is in relation to objects? If the player fires a weapon, >>> how can the computer calculate if the projectile will hit a target? >>> Currently I am planning to manage targeting by getting the slope of >>> the line and the point of the player, then extending the line to the >>> weapon's range and seeing if it intersects a point on which there is >>> an object. >>> For my game creation I am using the Blastbay Game Toolkit, which is a >>> subset of C++ but written specifically for use with audio games and >>> run sort of as a scripting language through an interpreter. For >>> instance, there is a sound class, a tts class for speaking text, >>> sound_pool (sort of like a "world" that manages sound positioning >>> relative to the player), a timer, and so on. Sound_pool, which I >>> subclass for my Map class, relies on a grid to properly position >>> sounds, which is the other reason I am using grid-based positioning. I >>> can't imagine how it would work with no grid. Is there a way? >>> >>> On 10/29/11, René Dudfield wrote: Hi, a few notes, and questions... Is your game turn based? Or is it real time? If you don't have realistic 3d sound, then using a grid is probably easier for players. Instead of frame rate, think about it like the update rate of your main loop. Before the player takes a step they are standing. When standing, speed is zero. When stepping, the person gets some acceleration and moves. Then they get some deceleration and stop. It's more complicated than that, but the more physically accurate you want it, then more complex your code will be. If you're more interested in making the game, than a physics engine, you might want to consider looking at one of the physics engines available. Keeping the game movement to grids might make it easier to play as well as program. cheers, >>> >> >> Hi Alex >> >> Do you know about coordinates and vectors (vector math)? This is how it >> is done in most games. If you make your game grid based, I have not >> understand if you want just go from one grid cell to another or if you >> want to allow arbitrary positions in between cells. According to your >> example it looks to me as if you want to go from one cell to another, so >> going diagonal would just move you to the next cell diagonally. Of >> course this means you travel faster because you cover a longer distance >> (diagonal is sqrt(2) longer) than moving orthogonal. You could restrict >> movement to just up/down and left/right and not allow diagonal movement >> at all. If you want to allow diagonal movement then you ne
Re: [pygame] a bit #ot: design for a game board supporting user facing different directions?
I am wanting arbitrary positioning. The grid squares are for positioning objects on the map and reporting the user's location to give them an idea of where they are. I think I can do this in Python, using sound_lib (http://hg.qwitter-client.net), so I am back on familiar ground as far as the language goes. However, I tried using the equations you guys gave me and odd things happened. First, here is my move() function, stored in the Object class, where Object is something on a map. self.stepLength is how long each step is and is currently at 1 (meter). I use x and z instead of x and y because of how the bass audio library, on which sound_lib is based, works; y is height, not forward/backward movement as one would expect. def move(self, direction=None, steps=1): #move the specified number of steps in the specified direction (in radians) if direction is None: direction=self.angle #currently set to 0 degrees) print "Moving "+str(steps)+" steps, facing "+str(direction)+" degrees. Starting at "+str((self.x, self.z)) for i in range(steps): self.x+=self.stepLength*math.sin(math.radians(direction)) self.z+=self.stepLength*math.cos(math.radians(direction)) print "Now at "+str((self.x, self.z)) Starting at (0, 0), you would expect the new position to be (0, 2) since two steps were taken straight ahead, and this does indeed happen. However, when you turn to 90 degrees, you would expect 2 steps to get you to (2, 0), but instead you get this: Moving 2 steps, facing 90 degrees. Starting at (0.0, 0.0) Now at (2.0, 1.2246468525851679e-16) What happened to make the second coordinate so far off? TIA. On 10/30/11, DR0ID wrote: > On 30.10.2011 04:29, Alex Hall wrote: >> It is real-time. I don't want it as accurate as movement acceleration >> for stepping, at least not yet, but I am not sure how I would manage a >> map without a grid. How, for instance, will the computer know where >> the player is in relation to objects? If the player fires a weapon, >> how can the computer calculate if the projectile will hit a target? >> Currently I am planning to manage targeting by getting the slope of >> the line and the point of the player, then extending the line to the >> weapon's range and seeing if it intersects a point on which there is >> an object. >> For my game creation I am using the Blastbay Game Toolkit, which is a >> subset of C++ but written specifically for use with audio games and >> run sort of as a scripting language through an interpreter. For >> instance, there is a sound class, a tts class for speaking text, >> sound_pool (sort of like a "world" that manages sound positioning >> relative to the player), a timer, and so on. Sound_pool, which I >> subclass for my Map class, relies on a grid to properly position >> sounds, which is the other reason I am using grid-based positioning. I >> can't imagine how it would work with no grid. Is there a way? >> >> On 10/29/11, René Dudfield wrote: >>> Hi, >>> >>> a few notes, and questions... >>> >>> Is your game turn based? Or is it real time? >>> >>> If you don't have realistic 3d sound, then using a grid is probably >>> easier >>> for players. >>> >>> Instead of frame rate, think about it like the update rate of your main >>> loop. >>> >>> Before the player takes a step they are standing. When standing, speed >>> is >>> zero. When stepping, the person gets some acceleration and moves. Then >>> they get some deceleration and stop. >>> >>> It's more complicated than that, but the more physically accurate you >>> want >>> it, then more complex your code will be. If you're more interested in >>> making the game, than a physics engine, you might want to consider >>> looking >>> at one of the physics engines available. >>> >>> Keeping the game movement to grids might make it easier to play as well >>> as >>> program. >>> >>> >>> cheers, >>> >> > > Hi Alex > > Do you know about coordinates and vectors (vector math)? This is how it > is done in most games. If you make your game grid based, I have not > understand if you want just go from one grid cell to another or if you > want to allow arbitrary positions in between cells. According to your > example it looks to me as if you want to go from one cell to another, so > going diagonal would just move you to the next cell diagonally. Of > course this means you travel faster because you cover a longer distance > (diagonal is sqrt(2) longer) than moving orthogonal. You could restrict > movement to just up/down and left/right and not allow diagonal movement > at all. If you want to allow diagonal movement then you need to decide > if you want to move from cell to cell (where diagonal movement is faster > then) or if you want to allow arbitrary positions. > > I hope it helps. > > ~DR0ID > -- Have a great day, Alex (msg sent from GMail website) mehg...@gmail.com; http://www.facebook.com/mehgcap
Re: [pygame] man oh man Java is painful
Yeah I'm an Android and C noob, but I've been a bit excited reading about NDK and being able to use C instead of Java maybe. But from what I've read it's not designed to replace java but rather provide potential performance benefits in certain parts of an android app. I mean to a certain extent I'm thinking, as far as learning Java for android, if you can't beat em join em. And I dig the Android platform more as far as the tablets themselves. And since I have to (and should do, if I want to be a well rounded programmer) learn some compiled languages, hell why not start with fortran. I mean Java. I mean, it's all a learning adventure. It's just that coming from a Python world where you can play around, take risks and have fune, the heavyweight syntax is just an enthusiasm crusher. If I try anything different Eclipse freakin explodes with complaints, then its off to Java or Android documentation which scares the crap out of me, whereas I find python.org pretty good reading actually. Of course over time I will know more and there will be less crushing going on. Preaching to the choir here I know but... I guess I'm in a ranting mood. Thanks for listening. On Wed, Nov 2, 2011 at 12:33 PM, Stuart Axon wrote: > I guess for android it must be possible to do stuff with the NDK and C++ ... > and if that works shedskin might be a possibility .. > > On 2 November 2011 15:31, Ian Mallett wrote: >> >> Curiously enough, I've recently been ruing Java's existence myself. In >> summary--it has syntax as bad as C, but is slower and more convoluted--not >> to mention not as capable (pointer arithmetic, anyone?). C# is basically >> Java, except it's garbage collector sucks (Java's is actually very good), >> and it's unportable. C++ is a pain to learn, but it's definitely worth it. >> In my opinion it's the best compiled language. > -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow
Re: [pygame] man oh man Java is painful
I guess for android it must be possible to do stuff with the NDK and C++ ... and if that works shedskin might be a possibility .. On 2 November 2011 15:31, Ian Mallett wrote: > Curiously enough, I've recently been ruing Java's existence myself. In > summary--it has syntax as bad as C, but is slower and more convoluted--not > to mention not as capable (pointer arithmetic, anyone?). C# is basically > Java, except it's garbage collector sucks (Java's is actually very good), > and it's unportable. C++ is a pain to learn, but it's definitely worth it. > In my opinion it's the best compiled language.
Re: [pygame] man oh man Java is painful
Curiously enough, I've recently been ruing Java's existence myself. In summary--it has syntax as bad as C, but is slower and more convoluted--not to mention not as capable (pointer arithmetic, anyone?). C# is basically Java, except it's garbage collector sucks (Java's is actually very good), and it's unportable. C++ is a pain to learn, but it's definitely worth it. In my opinion it's the best compiled language.
Re: [pygame] man oh man Java is painful
Cool ... I quite like the idea of phonegap and javascript, not sure about performance though .. the last android I did, the parts of the app that were inside a webview were so much easier and quick to do than the traditional parts that it might be worth considering that way too (especially for avoiding objectiveC + java). On 2 November 2011 15:28, Sean Wolfe wrote: > Yeah, I saw that and poked around a bit and it's great. I should mess > around some with it. I have been thinking that since I want to > eventually port my game to iphone, I'll have to learn obj-c, so why > not java first... how hard can it be? haha. > > I actually found a great android game tutorial just now... it's almost > pygame ish, even uses words like Rect and Surface. go figure! > > http://mobile.dzone.com/articles/beginning-android-game > > > > > On Wed, Nov 2, 2011 at 12:17 PM, Stuart Axon > wrote: > > Hey, I'm sure being on this mailinglist you've seen this: > > http://pygame.renpy.org/ > > > > Apart from that there seem to be a lot of potential ways of using python > or > > python like languages but nothing that is nicely packaged up and easy > > > > (For instance a quick google finds this for cython > > http://gitorious.org/nava#more > > ). > > > > I'm obviously aware of the android scripting environment, but that > doesn't > > seem like a good solution for distributing apps. > > > > On 2 November 2011 14:45, Sean Wolfe wrote: > >> > >> I'm getting into the wonderful world of Android which means Java. Dear > >> lord I remember now why I hate this language. I love the pythonic > >> philosophy that there should be an obvious way to get things done. It > >> means I get to experiment and more often than not, my first experiment > >> actually works! > >> > >> It seems like just as Python is great at taking out syntax and > >> overhead to let you get to actually working on your ideas, to the same > >> or greater extent, Java gets in the way. I mean in the Python world I > >> don't really need an IDE, maybe a souped up text editor is all. But > >> now I see why IDEs are so much more helpful in the java world... cause > >> there is so much more overhead to manage. > >> > >> That being said, being a mostly Python programmer up to this point, > >> I'm sure C++ and C# are just as horrible. So it's not specific to > >> Java. > >> > >> Anyhow, back to work. But please somebody tell me the joy of game > >> programming will come back cause right now I'm just slogging through > >> muck. > >> > >> > >> *sniff* thanks for letting me cry... > >> > >> > >> -- > >> A musician must make music, an artist must paint, a poet must write, > >> if he is to be ultimately at peace with himself. > >> - Abraham Maslow > > > > > > > > -- > A musician must make music, an artist must paint, a poet must write, > if he is to be ultimately at peace with himself. > - Abraham Maslow >
Re: [pygame] man oh man Java is painful
Yeah, I saw that and poked around a bit and it's great. I should mess around some with it. I have been thinking that since I want to eventually port my game to iphone, I'll have to learn obj-c, so why not java first... how hard can it be? haha. I actually found a great android game tutorial just now... it's almost pygame ish, even uses words like Rect and Surface. go figure! http://mobile.dzone.com/articles/beginning-android-game On Wed, Nov 2, 2011 at 12:17 PM, Stuart Axon wrote: > Hey, I'm sure being on this mailinglist you've seen this: > http://pygame.renpy.org/ > > Apart from that there seem to be a lot of potential ways of using python or > python like languages but nothing that is nicely packaged up and easy > > (For instance a quick google finds this for cython > http://gitorious.org/nava#more > ). > > I'm obviously aware of the android scripting environment, but that doesn't > seem like a good solution for distributing apps. > > On 2 November 2011 14:45, Sean Wolfe wrote: >> >> I'm getting into the wonderful world of Android which means Java. Dear >> lord I remember now why I hate this language. I love the pythonic >> philosophy that there should be an obvious way to get things done. It >> means I get to experiment and more often than not, my first experiment >> actually works! >> >> It seems like just as Python is great at taking out syntax and >> overhead to let you get to actually working on your ideas, to the same >> or greater extent, Java gets in the way. I mean in the Python world I >> don't really need an IDE, maybe a souped up text editor is all. But >> now I see why IDEs are so much more helpful in the java world... cause >> there is so much more overhead to manage. >> >> That being said, being a mostly Python programmer up to this point, >> I'm sure C++ and C# are just as horrible. So it's not specific to >> Java. >> >> Anyhow, back to work. But please somebody tell me the joy of game >> programming will come back cause right now I'm just slogging through >> muck. >> >> >> *sniff* thanks for letting me cry... >> >> >> -- >> A musician must make music, an artist must paint, a poet must write, >> if he is to be ultimately at peace with himself. >> - Abraham Maslow > > -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow
Re: [pygame] man oh man Java is painful
Hey, I'm sure being on this mailinglist you've seen this: http://pygame.renpy.org/ Apart from that there seem to be a lot of potential ways of using python or python like languages but nothing that is nicely packaged up and easy (For instance a quick google finds this for cython http://gitorious.org/nava#more ). I'm obviously aware of the android scripting environment, but that doesn't seem like a good solution for distributing apps. On 2 November 2011 14:45, Sean Wolfe wrote: > I'm getting into the wonderful world of Android which means Java. Dear > lord I remember now why I hate this language. I love the pythonic > philosophy that there should be an obvious way to get things done. It > means I get to experiment and more often than not, my first experiment > actually works! > > It seems like just as Python is great at taking out syntax and > overhead to let you get to actually working on your ideas, to the same > or greater extent, Java gets in the way. I mean in the Python world I > don't really need an IDE, maybe a souped up text editor is all. But > now I see why IDEs are so much more helpful in the java world... cause > there is so much more overhead to manage. > > That being said, being a mostly Python programmer up to this point, > I'm sure C++ and C# are just as horrible. So it's not specific to > Java. > > Anyhow, back to work. But please somebody tell me the joy of game > programming will come back cause right now I'm just slogging through > muck. > > > *sniff* thanks for letting me cry... > > > -- > A musician must make music, an artist must paint, a poet must write, > if he is to be ultimately at peace with himself. > - Abraham Maslow >
[pygame] man oh man Java is painful
I'm getting into the wonderful world of Android which means Java. Dear lord I remember now why I hate this language. I love the pythonic philosophy that there should be an obvious way to get things done. It means I get to experiment and more often than not, my first experiment actually works! It seems like just as Python is great at taking out syntax and overhead to let you get to actually working on your ideas, to the same or greater extent, Java gets in the way. I mean in the Python world I don't really need an IDE, maybe a souped up text editor is all. But now I see why IDEs are so much more helpful in the java world... cause there is so much more overhead to manage. That being said, being a mostly Python programmer up to this point, I'm sure C++ and C# are just as horrible. So it's not specific to Java. Anyhow, back to work. But please somebody tell me the joy of game programming will come back cause right now I'm just slogging through muck. *sniff* thanks for letting me cry... -- A musician must make music, an artist must paint, a poet must write, if he is to be ultimately at peace with himself. - Abraham Maslow
Re: [pygame] pygame.surfarray.pixels2d does not work with OpenGL?
Mmh, I see. Is there any way to have a 32 bit source alpha surface have pixels in that order? Or is there any other way how to speed up my code by replacing tostring? On Tue, Nov 1, 2011 at 10:14 PM, Lenard Lindstrom wrote: > Hi, > > Function tostring unmaps each pixel into an RGBA sequence, with the R byte > lowest. Function pixels2d returns a view of the actual surface memory. A 32 > bit source alpha surface need not, and probably does not, have pixels in an > RGBA order. > > Lenard Lindstrom > > On Oct 31, 2011, Florian Krause wrote: > > Hi everyone, > > can anyone tell me what I am doing wrong here? > Please have a look at the attached example code. > > When using pygame,image.tostring for getting the pixel values to > transform them into a texture, everything works well (see the > outcommented part with WORKS). > > However, when I replace this part with pygame.surfarray.pixels2d, then > the resulting texture seems broken for some reason. > > Does anyone have an idea what is going on here? > > Thanks in advance, > Florian > -- www.fladd.de - fladd.de: Homepage of Florian Krause blog.fladd.de - fladd's Blog: Blog of Florian Krause intermezzo.fladd.de - Intermezzo: Music by Florian Krause and Giacomo Novembre
