Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Hello,I have been dabbling with this queue problem and delta for the last month or so off and on. I finaly figured it out in several ways.One has 3 options when using a system like pygame or pyglet:1. give everything its own addition each loop, wont be pretty if you have many objects. But basically, you can add to the objects elapsed time every iteration of the game loop. Just make sure you are sending the sleeping time value to the objects.2. You can create a queue for all your object (either a set or a list, I dont think it matters), and run a loop each game loop to do: first, add the sleeping time to the time elapsed for each object. second, check if the object now should run and if so, run it. 3rd, if the object should run, it checks if the object should repeat (stay on the queue), or if it should remove the object from the queue. Other than that, it just goes on to the next iteration.3. You have a built-in queue system y ou use for keyboard input and system events in pygame already. pygame.event... I have not quite figured out how using this for custom events works, but it is totally possible!In other news, I found a fantastic tutorial on sighted game programming that I have been going through. I am commenting the code with comments about what each graphic and rendering thing does, Ive been using my small amount of sight to see the drawing and text events that happen as well as reading the awesome descriptions in the tutorial of what is supposed to happen. So I hope that I can manage to make incorporating basic graphics (like text and whatnot) second nature. It is really not hard once you figure out all the things you need to do. There is just a ton of initializing, creating objects, drawing to objects then putting those objects into the internal screen, then updating the hardwares screen for each graphic.I was amusing myself by drawing heads and lines and making stuff run around the screen.What I still need to know is:Can pygame render graphics in half a pixel or less? Because there is this huge complaint by sighted people when graphics are not smooth, which means that they are jumping too far each frame.good things I have found out:When creating the screen for any of my stuff, the normal screen is this really really small box up on the top right corner of the screen that no sane person can see. (well they probably can, it is just like an inch by 2 inches though)So I keep their values, but here is what I do to make the screen full screen:displaySurface = pygame.display.set_mode((400, 300), pygame.FULLSCREEN)This goes right under pygame.init() and replaces the other values they put in pygame.display.set_mode. There is often a 0, 32 after the size tuple and those two numbers are not important, they will default to w hat they need to be.second, in the game loop they write something about if event.quit:pygame.quit(). But this does not work with a keyboard. All that does is quit the screen if you can click on the little x at the top of the screen. Instead, make your keyboard loop look like this: for event in pygame.event.get():if event.type == KEYDOWN and event.key == K_ESCAPE: pygame.quit() sys.exit()Press escape to exit. Otherwise, hit alt-tab to get to your command prompt and hit ctrl C to kill the games operation.Third, when working with graphics, you need to call the update to your screen each game loop. This line looks like: pygame.display.update(). The tutorial puts in sys.exit() under pygame.quit() and says it is there because the ide they say for you to use crashes without sys.exit(). But the real reason why they need that sys.exit() is because there is this pesky video error when you call pygame.display.update() after pygame.quit(). To get around this there are two options:1. do what they say to do in the tutorial and do:pygame.quit()sys.exit()2. right proper code and make a variable above the while loop that then becomes False when you hit escape and call pygame.quit() at the bottom of the script.3. just ignore the video error because it really is not going to change how your code runs! URL: http://forum.audiogames.net/viewtopic.php?pid=192672#p192672 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Hello,I have been dabbling with this queue problem and delta for the last month or so off and on. I finally figured it out in several ways.One has 3 options when using a system like pygame or pyglet:1. give everything its own addition each loop, wont be pretty if you have many objects. But basically, you can add to the objects elapsed time every iteration of the game loop. Just make sure you are sending the sleeping time value to the objects.2. You can create a queue for all your object (either a set or a list, I dont think it matters), and run a loop each game loop to do: first, add the sleeping time to the time elapsed for each object. second, check if the object now should run and if so, run it. 3rd, if the object should run, it checks if the object should repeat (stay on the queue), or if it should remove the object from the queue. Other than that, it just goes on to the next iteration.3. You have a built-in queue system you use for keyboard input and system events in pygame already. pygame.event... I have not quite figured out how using this for custom events works, but it is totally possible!In other news, I found a fantastic tutorial on sighted game programming that I have been going through. I am commenting the code with comments about what each graphic and rendering thing does, Ive been using my small amount of sight to see the drawing and text events that happen as well as reading the awesome descriptions in the tutorial of what is supposed to happen. So I hope that I can manage to make incorporating basic graphics (like text and whatnot) second nature. It is really not hard once you figure out all the things you need to do. There is just a ton of initializing, creating objects, drawing to objects then putting those objects into the internal screen, then updating the hardwares screen for each graphic.I was amusing myself by d rawing heads and lines and making stuff run around the screen.What I still need to know is:Can pygame render graphics in half a pixel or less? Because there is this huge complaint by sighted people when graphics are not smooth, which means that they are jumping too far each frame.good things I have found out:When creating the screen for any of my stuff, the normal screen is this really really small box up on the top right corner of the screen that no sane person can see. (well they probably can, it is just like an inch by 2 inches though)So I keep their values, but here is what I do to make the screen full screen:displaySurface = pygame.display.set_mode((400, 300), pygame.FULLSCREEN)This goes right under pygame.init() and replaces the other values they put in pygame.display.set_mode. There is often a 0, 32 after the size tuple and those two numbers are not important, they will default to what they need to be. second, in the game loop they write something about if event.quit:pygame.quit(). But this does not work with a keyboard. All that does is quit the screen if you can click on the little x at the top of the screen. Instead, make your keyboard loop look like this: for event in pygame.event.get():if event.type == KEYDOWN and event.key == K_ESCAPE: pygame.quit() sys.exit()Press escape to exit. Otherwise, hit alt-tab to get to your command prompt and hit ctrl C to kill the games operation.Third, when working with graphics, you need to call the update to your screen each game loop. This line looks like: pygame.display.update(). The tutorial puts in sys.exit() under pygame.quit() and says it is there because the ide they say for you to use crashes without sys.exit(). But the real reason why they need that sys.exit( ) is because there is this pesky video error when you call pygame.display.update() after pygame.quit(). To get around this there are two options:1. do what they say to do in the tutorial and do:pygame.quit()sys.exit()2. right proper code and make a variable above the while loop that then becomes False when you hit escape and call pygame.quit() at the bottom of the script.3. just ignore the video error because it really is not going to change how your code runs! URL: http://forum.audiogames.net/viewtopic.php?pid=192672#p192672 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested You cannot draw in half a pixel. Nothing can draw in half a pixel. Drawing in half a pixel is literally the same as turning on half a light bulb. This isnt even an analogy. Its the literal truth.The structures you are defining are much too complicated. There is no reason why you need queues at this point, or really ever. Your game will literally never have enough objects that need to tick that they cant handle the counter themselves. Your main loop should literally be this:sleep_for = 1/20.0 #1/20 is good enough, up this if you want while game_is_running: start_time = time.time() for i in ticking_objects: i.tick() duration = time.time()-start_time sleep_needed = sleep_for - duration if sleep_needed 0: time.sleep(sleep_needed)Objects which need to act every 3 frames or every 5 frames or whatever can maintain internal counters. In terms of efficiency, its the same. If you actually get to the point of needing the extra efficiency of variable ticks, keeping in mind that this actually comes with a higher long-term complexity in some ways, we can talk about how you write the data structure for it. The way youre doing it, presuming I understand your explanation, is actually just as slow if not slower (floating point comparison vs. integer comparison).And thats it. Make tickers a list, put objects that need to tick there. Im pretty sure this is what SoundRTS does but could be wrong; SoundRTS is borderline on the needs advanced strategies front.As for Pygame-Im now kinda recommending Pyglet. It makes sound easier and does all the stuff audiogame_engine does with event layering, etc. Its got a full set of tutorials. My recommendations are kinda a special case, though-I can churn out the parts of Pygame needed for audiogame-style input in a couple hours (and have) and personally have two different audio frameworks I wrote myself. In this case, a couple people I know also said [[wow]], great find, so take it for what its worth.And graphics? Not worth it. Youre not going to be able to approach anywhere near the quality that the sighted expect. It will be like audiogames: only those with an association to our community are going to want to do it. Against my better judgement, Im going to go here because it is at least interesting to learn. Just know that it is 99% likely not to matter long-term.So:Smooth graphics literally changes everything about how you write your game. Everything.To do it, you need to divorce the tick for graphics from the tick for gameplay. Id suggest looking at XNA tutorials, as they all do a good job of explaining this. Basically, your graphics ends up ticking at least 60 times a second. Your game doesnt, though. The smoothness doesnt come from half a pixel, it comes from moving an object 2 pixels per frame for 4 frames instead of 8 pixels in one frame every 4 frames. To use sequences, its like how (2, 2, 2, 2) is smoother than (0, 0, 0, 8).You do this by fundamentally changing how objects move about. Instead of moving an object in your game logic, you specify what its velocity should be. You can still move objects in the game logic, i.e. for teleportation. But for stuff like walking, you no longer do so. The graphics tick is responsible for updating position values. You do this by specifying velocity as 2-dimensional vectors of the form (magnitude*cos(theta), magnitude*sin(theta)), such that theta is radians counterclockwise f rom east. This will lead to some choppiness with collisions.To deal with it, you do what youre suggesting about scheduled ticks, you integrate with a physics engine, you learn about how to specify things in forces instead of velocities (basic physics knowledge and trigonometry are prerequisite requirements), you move about 50% of your code into callbacks that the physics engine calls when things collide, and then you fight with the fact that you personally cant see the difference. In truth, going to C/C++ at this point may be required; 2D games can most likely get away, but if you decide that now its time for 3D, youre screwed in Python. For smooth graphics, you probably also need a bunch of math I can be pretty sure you dont have for the simple reason that 90% to 99% of blind people never learn it. URL: http://forum.audiogames.net/viewtopic.php?pid=192677#p192677 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested A queue is basically a list or set what you had in your audiogame engine, in the scheduler.py file. (BTW, there is 2 lines of code missing in line 18, you need to have an else:task.elapsed=0 after the self.tasks.remove(task) or the repeat flag does not work).The second item I posted above is your audio game engine structure.Graphics are good for a lot of things:1. if you ever wish to work with sighted developers, they are going to have graphics, so it will be something you will see often.2. In order to read most of the pygame tutorials, I need to either skip over all the graphics, or run the examples in a way I can so I can learn all possible from them.I was deliberating the other day about changing to pyglet or staying with pygame and I still may do stuff in pyglet, but I think staying with the mainstream and supported product is better. I also couldnt figure out pyglets audio. I could make a sound play, but didnt get how to fiddle with all the values.I can also read pygames docs and there are tons of guides using pygame where as there is not much for pyglet. Pyglet is easier, but pygame has many other advantages.Also, when I wish to do more than basic audio, libaudioverse will be there! URL: http://forum.audiogames.net/viewtopic.php?pid=192679#p192679 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested No, I dont think it is. Audiogame_engine ticks regardless. Theres some stuff in there that lets you hook into timing, but the main loop doesnt. Ive abandoned Audiogame_engine to be honest; Im now going to use Pyglet. The thing with Pygame, for your use case: youre going to have to duplicate a lot of what Pyglet is doing for you. Im not sure that Pyame is more supported either, but its quite possible that Pyglet is aimed at a more advanced develope.Also, do be aware that Queue has a very, very specific definition. In the way youre using it you need to just say list. The long and the short of it is that queue implies a lot of things about what youre doing that you dont actually mean. URL: http://forum.audiogames.net/viewtopic.php?pid=192683#p192683 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Since this topic apparently is the Discuss Python Here! topic and I cant resist, let me add a few of my own issues here.Camlorn, or rather, all of you, would you mind helping me out iwth something? I would like to code a GNU Compiler for Python (GCP (correct me if Im wrong, but to my knowledge, there is no GNU compiler that has the initials GCP)), and I need a little help.Do you guys think you could provide me with a good, Ogreat, or excellent implementation of the argparse for a compiler? URL: http://forum.audiogames.net/viewtopic.php?pid=191575#p191575 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested You cant. Not in a time period less than 3 or 4 years. This is a project that people have earned doctorates with and its still not done. Grad students work on Pypy all the time, and the only real reason that Pypy works is because its a JIT (otherwise, it would be much too slow to actually be worth the gains). If I need to talk about this more, I will.The project youre looking for is Nuitka. This is actually a trick: it asks Python to implement the functionality, removes the Python main loop, and applies *some* optimizations. Also, I ran it on a real app once. 8 hours later (i.e. the next morning), it still hadnt finished running. I gave up at that point. Nuitka has been undergoing development for 2 years, minimum, and my understanding is that the guy doing it is a compiler expert.Going further than this is not really possible due to the nature of Python and languages like it: your code can self-modify at runtime, types arent fixed, class members arent fixed, functions are effectively garbage collected (really), functions can be assigned to other functions (you can replace sys.exit, if youre insane), and theres no actual language spec (problem: how do you be 100% compatible without a standard?). Even getting this far requires masters level computer science or higher; compilers are half programming and half mathematical proof. Some optimization A must be provably correct in something not dissimilar to the mathematical sense; you cannot test it on all inputs. Optimization A is usually not simple, though there are a very few low-hanging fruit like constant folding.I personally do not know of any programmer capable of even starting this project. I cannot name anyone except the biggest names in computer science. Doing this project is a topic of ongoing computer science research; being able to handle languages of this type efficiently would be a boon beyond belief. But at best, you still have to include an interpreter with your compiler (handling eval is fun), and at worst--say, because you dont know how to implement optimizations and do this as a learning project--its slower than the original language in the first place.But as usual, Im sure everyone is going to say Im wrong and well be beginning another game of disbelieve the Camlorn. To that end, know first that starting with the command line frontend is a mistake of epic proportions: once it compiles something, then worry about it. Argparse is literally the simplest part of the project; if you cant underestand it, stop now and save yourself a huge headache. Should you actually manage to produce a compiler for Python that can compile a significant subset of the language (say, significant enough that I can make an audiogame in it), Il l maintain your argparse interface for as long as you like. But, if you can make it across the giant gulf of conceptual lava in your way, youll look at argparse as the most trivial thing ever and wont need me. Ill also write everyone I know who is involved with academia, because they will probably want to descend from the heavens and bestow on to you the wonders of a degree in computer science (or at least a great many scholarships).I have been through this phase. It is an interesting phase and youll learn a lot from it. Leave it behind as soon as possible. This phase of learning to program yields no useful code. Take the knowledge of basic computer architecture, what you understand of compilers, etc. Use them for something, anything, else. Theyre worth a lot, but they arent worth a compiler. If its something you truly want to do one day, get into college for computer science as soo n as possible, make sure its a program with an emphasis on compiler and language design, and stick with it through at least a masters. URL: http://forum.audiogames.net/viewtopic.php?pid=191576#p191576 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Youre overcomplicating things tremendously. I think someone else needs to try to explain why threads are going to screw you in the end, but youre taking the molehill of ticks and turning it into a mountain. You can feel free to disbelieve me about threads, but Id bet literally anything that youll be back in two months with a failed project and the exact same conversation were having now. Possibly word-for-word, or at least post-for-post. Im having trouble finding an article that is at your level. I suspect this is because programmers at your level do not usually jump hard on the thread bandwagon and usually not just by going hey, look at the threading module-i.e. the tutorial or whatever has a chance to tell you about the problems. Ill try to be explicit about it at the end of this post.The delta is simply the time since the main loop of your game called tick last. It *can* be use d to make the game catch up. Or you can flat-out ignore it, pretend that it is always 1/20 or 1/30 or 1/60 or whatever, and write the whole game that way. As I said, nothing is wrong with the latter, especially in this case.Audiogame_engine screens are exactly like opening another window. Except that you dont re-import anything, you dont load a second Python interpreter, etc. Audiogame__engine just sends all input to the topmost screen on the ScreenStack, and thats it. Theres basically no performance hit for doing so, and the code that actually handles it is simpler than what youre posting. Larger, but simpler conceptually. Just subclass screen, override tick, and make use of self.keyboard_handler and self.mouse_handler to set up functions to be called when youve got input ready.A few things. First, never ever use AttributeError for initialization. __init__ is where youre supp osed to set everything to default values. Second, the delta is not the framerate: it is the time from the beginning of a tick call to the beginning of the next tick call. If your tick is taking more time than the framerate, your delta becomes larger than the framerate. Third, you do not wait framerate seconds, you wait framerate-last_tick_time seconds, Where you get last_tick_time as follows:start_time = time.time() tick() end_time = time.time() tick_time = end_time-start_time wait_time = framerate-tick_time if wait_time 0: time.sleep(wait_time)I do not think it really matters whether or not you use time.time() instead of time.clock(). In this case, it shouldnt matter much. Do note that the windows clocks are notorious for being imprecise, i.e. you may not be getting more than 50 ms precision on older systems. Again, this shouldnt matter much if at all for this case.So, threads.Youre looking at this tick thing and going but the thread API is so easy. I can just time.sleep whenever. And that statement is true, but only as far as that statement.When a program without threads runs and receives some input, it will always do the exact same thing if that input is the same. This is always true unless the processor melts, or something drastic like that. We can even argue such drastic cases as hard drives exploding count as input, but thats just arguing over inanities. You have nothing more than the basic programming problems. If your program bugs on some input, you can make it bug every time. You always know where the problem is, or at least how to cause the problem. Debugging is a simple process: cause the bug, fix the exception or explore with a debugger. In this case, you take two or three weeks at most to understand audiogame_engine or one of the numerous alternatives that do exactly the same thing. Youre then on top of the world, and nothing is left that will surprise you about your programs.Now, I could tell you the threading story, but Im going to just give an illuminating example, followed by a rewrite of the illuminating example to show the problem:import threading x = 0 def my_thread(): global x for i in xrange(50): x = x+1 t1 = threading.Thread(target = my_thread) t2 = threading.Thread(target = my_thread) t1.start() t2.start() t1.join() t2.join() print xThe answer is obviously 100, right?No.This will return a number between 0 and 100. The number will be different every time you run it. You will easily observe that addition operations are going missing. This is the simplest example that shows problems, and if youve looked around a lot, youll throw a lock in because thats super easy to do in this case. But see how nondeterministic it is? You know there is a bug because its not always printing 100. I made the number high on purpose, however. If you bring it down to 10, this program can and will run correctly sometimes.The specific reason why is because x = x+1 is actually 3 operations, and can be rewritten as follows:tmp = x x = tmp+1The third operation is tmp+1, but you cant put that on a line by itself. These operations are run in the order they are written
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Hello.Here is my opinion.A good program needs to only use threads in situations that are critical,like reading large amounts of data from Internet without blocking the mainprogram.But I say: Dont use threads.Why?Threads are difficult to debug and some types of threads can lock yourmain program dont letting the user close it.If you want to make side scrollers or pygame based games with AI, youdont need threads.Youll need a time counter, with time.time(), time.clock(),pygame.time.get_ticks() or whatever other similar functions exist. URL: http://forum.audiogames.net/viewtopic.php?pid=186428#p186428 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested OK, youve convinced me, no threads!!! LOLNow I need to figure out how to either use the module in audiogame_maker or create my own. URL: http://forum.audiogames.net/viewtopic.php?pid=186462#p186462 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested I *think* audiogame_engine will mix fine with Pygames sound stuff. There may be sdl issues; I am uncertain, as I obviously only used it with my own stack.Writing your own is actually a good idea, if you want to learn. Its a manageable project in terms of complexity and size. Id rate it at intermediate: youre at the point of understanding that functions are things like numbers too, that inheritance is a powerful thing, and that time.sleep causes so many problems and actually solves nothing.Best of luck, whatever you do. URL: http://forum.audiogames.net/viewtopic.php?pid=186468#p186468 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested OK, I took a look at audiogame_engine and I wish I knew about this before I got into pygame! LOL... It is basically a light-weight pygame.Now, I just need a game example to see how they work together with one another.I didnt understand everything, but I get that your main game loop pauses for something like 0.016 seconds each loop and then runs again. (I normally pause for 0.05 seconds and no one notices). But do you like keeping your own ticker vs keeping time.clock() or keeping your own ticker vs time.time() minus the last time.time()?I guess delta time is real-time in cases where your game logic makes the game run a little slower than the 0.1666 second pause. But wouldnt just using time.clock fix that? Or is time.clock impossibly slow?But really, if you made a couple little button smashers with libaudioverse and audiogame_engine, I would totally just use your audiogame_engine, it is much smaller than pygame. Or, you could crea te the same function calls as pygame and just substitute audiogame_engine as pygame instead. (Although the functionality of the calls looked a little different than pygames calls).But I would call this a wrapper around the SDL library rather than a full-blown game engine (engine to me is something like audiogame_engine.screen() to create the screen and I dont need to worry about it, or audiogame_engine.key1() for keydown events and key2 for key pressed events.But you may have that, I just didnt notice (I dont know enough about how audiogame_engine works to translate all the code to what it does).BTW, I keep refreshing the forum to see if libaudioverse is posted yet! URL: http://forum.audiogames.net/viewtopic.php?pid=186227#p186227 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Libaudioverse got delayed because the first week of school is awful, I missed the deadline and decided to go ahead and port the media player example to Python, and the blog post about it wont come out the way I want. I then decided that, since I was going to do it anyway, Id go ahead and do the major thing that would break backward compatibility (rename device to simulation and physical device index to device index). There is a reason I do not like setting deadlines. And do note that Ive said preview: this is not alpha quality, isnt supported on Linux and Mac, and will break horribly for at least some people.Mobs wait, but this does not mean the engine does. Mobs that wish to wait can do one of a few things, the simplest of which is count down an integer in their tick method. This is when you explicitly dont use threads: threads are for things that need to continuously run, not things that need to spend most or all of their time waiting. If you can provide a performance reason for wanting threads, we can talk about it on another topic; until then, my answer will always, always be dont. If you want me to go into why threads are so hard, Ill go find an article-it takes a good deal of writing to set things up before you knock them down hard.Audiogame_engine has a utility object that you can tick that handles scheduling things to happen in the future; the difference is that you specify the future in ticks, not seconds. It does indeed have input handling: see keyboard_handler and mouse_handler; all screens give you one. Its also got layering: pausing the game is as simple as making a pause screen and pushing it on top of the stack of screens; the pause screen simply sets itself not to forward events to things below it, which actually stops time until you pop it off. As I said, Audiogame_engine is basical ly exactly what Microsoft says to do in C# for XNA. Theyre far from the only one to advocate such approaches, however; many articles exist on the internet that show you how to make your own.The reason Audiogame_engine manages time is that a tick needs to happen in an instant, even if it doesnt. Youre simulating one infinitesimal bit of time, and so Audiogame_engine gives you the thing youre interested in: how long since the last one? This is called the delta. What your brother is referring to is this: if you specify speeds in velocities and know a bit about vectors, you can make it such that the game ticks as fast as the computer will let it and still have it come out right everywhere. This is particularly important for games that might slow down because of CPU constraints, but Id not worry about it just yet. I did calculate the delta for completeness, but Ive not yet had a project that needs it.Be v ery concerned about time.sleep calls. You should have exactly one in your entire program, and it should be exactly in the same place as Audiogame_engine puts it. If you do so, you dont need threads anymore.A few things to note: youre missing the half that handles input. Look at ScreenStack and Screen for a not-half-bad approach to managing state in your game, i.e. opening and closing minigames, inventories, and pause menus. I have yet to actually implement menu screens that just take menu item names, but when Libaudioverse is ready and I begin using the project again, those arent far behind. The reason Ive not been pushing it everywhere is because it is, indeed, missing good examples and docs; everything should have docstrings, however. Finally, tick speed is configurable when you make your MainLoop instance.See keyboard.py, mouse.py, and event_responder.py to understand how that part of it works. Sc reenStack and Screen are just a concrete implementation of the interface defined in event_responder.py aimed at having good state management that doesnt involve nesting if statements all day long. Its only 300 lines, which makes it about the size of any tic tac toe in the command prompt implementation Ive ever done. Im not surprised that youre having trouble with it, especially since this community advocates the nested if statements and polling approaches heavily. You seem to be at the point where you can benefit from understanding it. I do not believe that Pygame provides the higher-level primitives, but you could implement them on top of it instead if you wanted.And as for the name, well, I needed one. It was there. I will be adding more tuff to it, but its never going to be what most people think of as an engine. Perhaps I will rename it someday, if I can come up with something better. URL: http://forum.audiogames.net/viewtopic.php?pid=186254#p186254 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Libaudioverse got delayed because the first week of school is awful, I missed the deadline and decided to go ahead and port the media player example to Python, and the blog post about it wont come out the way I want. I then decided that, since I was going to do it anyway, Id go ahead and do the major thing that would break backward compatibility (rename device to simulation and physical device index to device index). There is a reason I do not like setting deadlines. And do note that Ive said preview: this is not alpha quality, isnt supported on Linux and Mac, and will break horribly for at least some people.Mobs wait, but this does not mean the engine does. Mobs that wish to wait can do one of a few things, the simplest of which is count down an integer in their tick method. This is when you explicitly dont use threads: threads are for things that need to continuously run, not things that need to spend most or all of their time waiting. If you can provide a performance reason for wanting threads, we can talk about it on another topic; until then, my answer will always, always be dont. If you want me to go into why threads are so hard, Ill go find an article-it takes a good deal of writing to set things up before you knock them down hard.Audiogame_engine has a utility object that you can tick that handles scheduling things to happen in the future; the difference is that you specify the future in ticks, not seconds. It does indeed have input handling: see keyboard_handler and mouse_handler; all screens give you one. Its also got layering: pausing the game is as simple as making a pause screen and pushing it on top of the stack of screens; the pause screen simply sets itself not to forward events to things below it, which actually stops time until you pop it off. As I said, Audiogame_engine is basical ly exactly what Microsoft says to do in C# for XNA. Theyre far from the only one to advocate such approaches, however; many articles exist on the internet that show you how to make your own.The reason Audiogame_engine manages time is that a tick needs to happen in an instant, even if it doesnt. Youre simulating one infinitesimal bit of time, and so Audiogame_engine gives you the thing youre interested in: how long since the last one? This is called the delta. What your brother is referring to is this: if you specify speeds in velocities and know a bit about vectors, you can make it such that the game ticks as fast as the computer will let it and still have it come out right everywhere. This is particularly important for games that might slow down because of CPU constraints, but Id not worry about it just yet. I did calculate the delta for completeness, but Ive not yet had a project that needs it.Be v ery concerned about time.sleep calls. You should have exactly one in your entire program, and it should be exactly in the same place as Audiogame_engine puts it. If you do so, you dont need threads anymore.A few things to note: youre missing the half that handles input. Look at ScreenStack and Screen for a not-half-bad approach to managing state in your game, i.e. opening and closing minigames, inventories, and pause menus. I have yet to actually implement menu screens that just take menu item names, but when Libaudioverse is ready and I begin using the project again, those arent far behind. The reason Ive not been pushing it everywhere is because it is, indeed, missing good examples and docs; everything should have docstrings, however. Finally, tick speed is configurable when you make your MainLoop instance.See keyboard.py, mouse.py, and event_responder.py to understand how that part of it works. Sc reenStack and Screen are just a concrete implementation of the interface defined in event_responder.py aimed at having good state management that doesnt involve nesting if statements all day long. Its only 300 lines, which makes it about the size of any tic tac toe in the command prompt implementation Ive ever done. Im not surprised that youre having trouble with it, especially since this community advocates the nested if statements and polling approaches heavily. You seem to be at the point where you can benefit from understanding it. I do not believe that Pygame provides the higher-level primitives, but you could implement them on top of it instead if you wanted.And as for the name, well, I needed one. It was there. I will be adding more stuff to it, but its never going to be what most people think of as an engine. Perhaps I will rename it someday, if I can come up with something better. URL: http://forum.audiogames.net/viewtopic.php?pid=186254#p186254 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested
Ive got 2 different ways of doing screens:1. bring out another screen with another window being stacked on top of the main window. This is really fast and what Ive got already. The downside is that it is a little annoying to have game-wide commands imported every time this happens. It is also a little slow. What I have been working out is using a scene attribute that changes to something like game1 or movement and when ever the screen changes, append the function that checks for all those keys after the global check.for example:current_scene = movementscenes_dict = {movement: functionObjectWithSceneMovement@080939, fight: functionWithFightingCommands@94847543}then in the main loop:while playing: k = global_keyconfig(current_key) if not k:Scene_class.scenes_dict[Scene_class.current_scene](current_key)This
is much faster and one really has more control over the screens.As for delta time, so it compares my game speed to the time.clock speed and counts how many should have happened in a time compared to how many did happen and makes adjustments accordingly?Really, threading is looking so much easier than this tick thing. Here is what I came up with:import time, randomclass Ticker(object): ticks has not been implemented yet. framerate is the amount of time the main loop rests before running again. def __init__(self, tick=0.6, framerate=60):self.tick = tickself.playing = Trueself.functions = []self.framerate = 1.0/framerate def wait(self, wait_time=0, name=g):try:
bsp; self.dict1[name] += self.framerateexcept AttributeError: self.dict1 = {} self.dict1[name] = self.frameratefinally: if self.dict1[name] = wait_time:return True def main_loop(self):while self.playing: [x() for x in self.functions] time.sleep(self.framerate)a = Ticker()def hello(): if a.wait(1, fred):print hello worlda.functions.remove(hello)a.functions.append(hello)a.mai
n_loop()
URL: http://forum.audiogames.net/viewtopic.php?pid=186331#p186331
___
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Threads are not necessary. Threads actually hurt. Threads will kill your productivity. Im not going to go into why because a quick Google search will bring up many, many articles about just why threads are bad. The secret to using threads is to use queues, at least in the very few cases you need them, and only have one thread on which all the work happens. The only reason that people really use threads these days is networking, because it allows placing blocking I/O in a place where it can do so in languages without good support for callback functions. The other reason-gaining extra performance from multicore systems-does not apply in Python unless 50% or so of your app is calling out to C code. Shared state between threads is horrible for reasons which become apparent as soon as you get past line 200 or so and start having bugs you cant reliably reproduce all over the place.Have a look at audiogame_engine. Its not super mature but works well enough for I3d, and I have no idea how well it plays with Pygames sound modules. But its my answer, and also the answer that many other people have come up with (actually, its almost exactly a port of how Microsoft tells you to do it with XNA). The reason I3d isnt open sourced is that Camlorn_audio sucks and is deprecated, but Im planning something in the near future with Libaudioverse that will use audiogame_engine (its my chosen platform for desktop games and game clients). Im not sure how clear it is, as a few places use some magic to make Sdl become friendly. But it should at least give you ideas.The general trick is to not wait. If you want something to happen in 5 seconds, you tel the main loop to call a function for you in 5 seconds, and then go on about your day. Typically, you achieve basic game logic by putting it in tick functions on the classes representing your objects, and register them with the main loop to be called once a heartbeat. Id strongly suggest reading some sighted game programming tutorials before continuing down this rabbit hole.Things that use this approach of ticking include all muds. As I recall, Diku does not even spawn a thread anywhere, and Id be willing to bet pretty much anything that Alter Aeon does not split the game logic across more than one thread. LPC doesnt have support for it, nor does unmodified Moo. I3d didnt use them for anything: input, waiting logic, physics simulation, etc. all run through tick functions on one thread. Some sighted games will split rendering the 1 polygons across multiple threads, but even there its discouraged for game logic, save in the few cases where every single enemy in a group of 1 needs to run really complicated AI logic individually. T wisted and Node.js exist so that network applications can run very efficiently on one core and with only one thread. The list goes on. Going into threading land is like going to Oz: all the rules you knew dont quite apply or apply in different ways.Id strongly suggest staying away from these until you understand why theyre useful. There are only two major reasons I can think of: the problem really cant run on one core or the problem is what is called embarrassingly parallelizable. In the latter case, its something like squaring 6 billion numbers: you can ask thread one to square the first billion, thread two to do the second, and so on. In this case, the threads dont know about each other, and thus you avoid literally all the problems with them. I suspect the examples you are seeing are for problems of this nature. URL: http://forum.audiogames.net/viewtopic.php?pid=186139#p186139 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Really? What is the bad part of python multithreading? From what Ive read, it is that it slows down things and accessing shared variables is something you need to be careful about (see the lock section above).Also, killing a daemon thread, if it is running a critical process, can be harmful.So, why is this bad for use in a combat situation? Running 45 threads on my computer took 5% of my CPU when running most any of the other audio games that are out take up something like 30%.Is using threading for mobs something that requires speed or a shared variable?I need to research more about these ticks, but after a few days with just researching them, Ive not found anything that explicitly stats that that multithreading is bad, not like global variables. In Java it is bad and in most other languages it is bad, but the threading module in python is really really easy to use and wont make your program faster, but it is sure not that program intensive, especially not for a single object, running on an engine.I think multithreading has just gotten a bad wrap from all the languages that dont handle it well and the abuse or misconception that it will increase performance. But frankly, a mob engine is kind of like what you are talking about about the billion numbers.I am going to research ticks and look at them closer, but I think ticks came from needing to run graphics.So, would you say to use time.clock() or use a class accessible timer that I create?X would add every 0.05 seconds or something like that and the mob functions would run every tick. (although ticks are too predictable IMO. URL: http://forum.audiogames.net/viewtopic.php?pid=186178#p186178 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Ticks are not too predictable. You can easily do 60 or 100 a second. You can, if you are good at math and adventurous, have the time between them vary. You can have the engine detect when its slow and tick faster to catch up, or make the time between ticks longer without slowing the game. But all you really need is the basics: tick 30-60 times a second, keeping the interval the same. Your players literally cant tell-its way too fast to be noticeable unless the engine gets under too much of a load to keep it up (in audiogame land, should this happen, its a bug). most games for the sighted do this, even multimillion dollar titles. If you want to learn more, you can find many, many books on game architecture.Actually doing this is a bit more difficult, and I strongly suggest reading over audiogame_engine. Audiogame_engine has a working implementation of a main loop and a bunch of other stuff you will eventually need. Ticking 60 times a second is not tick, wait 1/60th of a second, its time the tick and wait however much time is left in this 1/60th of a second fragment. In audiogame_engines case, the delta--the time since the last tick--is passed. But I never used it, and you can just shrug and ignore that part. All you need is time.time(), time.sleep(), and some basic arithmetic in a while loop. You can probably adapt the code to work with your stuff, and all the low-level bits and pieces are demonstrated therein.You seem to have misconceptions as regards what is fast. You will not need more than one thread for any single-player audiogame I can think of, and Swamp probably does-at most-one thread per map. You may choose to use them at some point, but do avoid them for now. Drawing polygons is actually a bad example in that its usually not even done on the CPU, but dra wing even one polygon takes a much longer time than updating one npcs state (if I had to guestimate, on the order of 100x-1000x, but the graphics card parallelizes automatically).Threads are amazingly easy to start in just about any language these days. But the problem here is that the entire game is shared state. Every thread will want to modify or read the world and, because its running with other threads, will not see it right. Consider a program that updates coordinates on your objects, running in a thread. A second thread can see some objects in new positions while others are still in old ones, read off coordinates with updated x values but not updated y values, or (what you want) read everything between updates. The solution is to throw a lock into the mix, but as soon as you start doing that you start losing any benefit at all. Fine-grained locking is notoriously hard to get right, and deadlocks are notoriously hard to deb ug. Having a global lock that every thread holds before it does stuff means you shouldnt have bothered in the first place.An embarrassingly parallelizable problem is a problem in which each thread may live in its own universe, sharing no state save a notification that it has completed its task. This is easy, and problems like this are definitely a good introduction. Every example I can think of for the threading and multiprocessing modules are in this category. Games are not embarrassingly parallelizable: every thread will need to touch everything at some point and to some extent. The documentation you are reading is not teaching you the difference: its assuming youre a good enough programmer to know when threads are, and are not, the solution; its purpose is to show you how they work from the perspective of someone who needs them. to that end, the examples are about teaching a programmer who knows threads how to use thread s in Python and not showing you or even touching on all the problems you get to deal with in real-world cases.threads deserve their bad reputation. They are the only way to solve a problem which is difficult for humans to think about in the first place, and the guarantees we cant make and still have fast computers make it even harder. In lower-level languages, its possible to see half-updated variables (as in, some of the bytes in your integer have been changed while others have yet to happen). Python doesnt let you quite have this problem because of the GIL, but the GIL keeps you from getting any performance boosts on tasks written purely in Python (excluding i/o) anyway. Nothing you are doing warrants putting yourself through this particular hell-and yes, Id really go that far in this case.Let me put it this way. Some of the largest web sites out there, handling thousands of concurrent users, run in one thread. ; This is the purpose of Node.js, Twisted, and a bunch of other stuff. Camlorn_audio has so many threading issues related to fine-grained locking that I couldnt fix them if I wanted, and I once spent 8 hours debugging a deadlock and wrote a 15-line comment explaining what I should never ever do if I wanted it to keep working.If you
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Ticks are not too predictable. You can easily do 60 or 100 a second. You can, if you are good at math and adventurous, have the time between them vary. You can have the engine detect when its slow and tick faster to catch up, or make the time between ticks longer without slowing the game. But all you really need is the basics: tick 30-60 times a second, keeping the interval the same. Your players literally cant tell-its way too fast to be noticeable unless the engine gets under too much of a load to keep it up (in audiogame land, should this happen, its a bug). most games for the sighted do this, even multimillion dollar titles. If you want to learn more, you can find many, many books on game architecture.Actually doing this is a bit more difficult, and I strongly suggest reading over audiogame_engine. Audiogame_engine has a working implementation of a main loop and a bunch of other stuff you will eventually need. Ticking 60 times a second is not tick, wait 1/60th of a second, its time the tick and wait however much time is left in this 1/60th of a second fragment. In audiogame_engines case, the delta--the time since the last tick--is passed. But I never used it, and you can just shrug and ignore that part. All you need is time.time(), time.sleep(), and some basic arithmetic in a while loop. You can probably adapt the code to work with your stuff, and all the low-level bits and pieces are demonstrated therein.You seem to have misconceptions as regards what is fast. You will not need more than one thread for any single-player audiogame I can think of, and Swamp probably does-at most-one thread per map. You may choose to use them at some point, but do avoid them for now. Drawing polygons is actually a bad example in that its usually not even done on the CPU, but dra wing even one polygon takes a much longer time than updating one npcs state (if I had to guestimate, on the order of 100x-1000x, but the graphics card parallelizes automatically).Threads are amazingly easy to start in just about any language these days. But the problem here is that the entire game is shared state. Every thread will want to modify or read the world and, because its running with other threads, will not see it right. Consider a program that updates coordinates on your objects, running in a thread. A second thread can see some objects in new positions while others are still in old ones, read off coordinates with updated x values but not updated y values, or (what you want) read everything between updates. The solution is to throw a lock into the mix, but as soon as you start doing that you start losing any benefit at all. Fine-grained locking is notoriously hard to get right, and deadlocks are notoriously hard to deb ug. Having a global lock that every thread holds before it does stuff means you shouldnt have bothered in the first place.An embarrassingly parallelizable problem is a problem in which each thread may live in its own universe, sharing no state save a notification that it has completed its task. This is easy, and problems like this are definitely a good introduction. Every example I can think of for the threading and multiprocessing modules are in this category. Games are not embarrassingly parallelizable: every thread will need to touch everything at some point and to some extent. The documentation you are reading is not teaching you the difference: its assuming youre a good enough programmer to know when threads are, and are not, the solution; its purpose is to show you how they work from the perspective of someone who needs them. to that end, the examples are about teaching a programmer who knows threads how to use thread s in Python and not showing you or even touching on all the problems you get to deal with in real-world cases.threads deserve their bad reputation. They are the only way to solve a problem which is difficult for humans to think about in the first place, and the guarantees we cant make and still have fast computers make it even harder. In lower-level languages, its possible to see half-updated variables (as in, some of the bytes in your integer have been changed while others have yet to happen). Python doesnt let you quite have this problem because of the GIL, but the GIL keeps you from getting any performance boosts on tasks written purely in Python (excluding i/o) anyway. Nothing you are doing warrants putting yourself through this particular hell-and yes, Id really go that far in this case.Let me put it this way. Some of the largest web sites out there, handling thousands of concurrent users, run in one thread. ; This is the purpose of Node.js, Twisted, and a bunch of other stuff. Camlorn_audio has so many threading issues related to fine-grained locking that I couldnt fix them if I wanted, and I once spent 8 hours debugging a deadlock and wrote a 15-line comment explaining what I should never ever do if I wanted it to keep working.If you
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Ticks are not too predictable. You can easily do 60 or 100 a second. You can, if you are good at math and adventurous, have the time between them vary. You can have the engine detect when its slow and tick faster to catch up, or make the time between ticks longer without slowing the game. But all you really need is the basics: tick 30-60 times a second, keeping the interval the same. Your players literally cant tell-its way too fast to be noticeable unless the engine gets under too much of a load to keep it up (in audiogame land, should this happen, its a bug). most games for the sighted do this, even multimillion dollar titles. If you want to learn more, you can find many, many books on game architecture.Actually doing this is a bit more difficult, and I strongly suggest reading over audiogame_engine. Audiogame_engine has a working implementation of a main loop and a bunch of other stuff you will eventually need. Ticking 60 times a second is not tick, wait 1/60th of a second, its time the tick and wait however much time is left in this 1/60th of a second fragment. In audiogame_engines case, the delta--the time since the last tick--is passed. But I never used it, and you can just shrug and ignore that part. All you need is time.time(), time.sleep(), and some basic arithmetic in a while loop. You can probably adapt the code to work with your stuff, and all the low-level bits and pieces are demonstrated therein.You seem to have misconceptions as regards what is fast. You will not need more than one thread for any single-player audiogame I can think of, and Swamp probably does-at most-one thread per map. You may choose to use them at some point, but do avoid them for now. Drawing polygons is actually a bad example in that its usually not even done on the CPU, but dra wing even one polygon takes a much longer time than updating one npcs state (if I had to guestimate, on the order of 100x-1000x, but the graphics card parallelizes automatically).Threads are amazingly easy to start in just about any language these days. But the problem here is that the entire game is shared state. Every thread will want to modify or read the world and, because its running with other threads, will not see it right. Consider a program that updates coordinates on your objects, running in a thread. A second thread can see some objects in new positions while others are still in old ones, read off coordinates with updated x values but not updated y values, or (what you want) read everything between updates. The solution is to throw a lock into the mix, but as soon as you start doing that you start losing any benefit at all. Fine-grained locking is notoriously hard to get right, and deadlocks are notoriously hard to deb ug. Having a global lock that every thread holds before it does stuff means you shouldnt have bothered in the first place.An embarrassingly parallelizable problem is a problem in which each thread may live in its own universe, sharing no state save a notification that it has completed its task. This is easy, and problems like this are definitely a good introduction. Every example I can think of for the threading and multiprocessing modules are in this category. Games are not embarrassingly parallelizable: every thread will need to touch everything at some point and to some extent. The documentation you are reading is not teaching you the difference: its assuming youre a good enough programmer to know when threads are, and are not, the solution; its purpose is to show you how they work from the perspective of someone who needs them. to that end, the examples are about teaching a programmer who knows threads how to use thread s in Python and not showing you or even touching on all the problems you get to deal with in real-world cases.threads deserve their bad reputation. They are the only way to solve a problem which is difficult for humans to think about in the first place, and the guarantees we cant make and still have fast computers make it even harder. In lower-level languages, its possible to see half-updated variables (as in, some of the bytes in your integer have been changed while others have yet to happen). Python doesnt let you quite have this problem because of the GIL, but the GIL keeps you from getting any performance boosts on tasks written purely in Python (excluding i/o) anyway. Nothing you are doing warrants putting yourself through this particular hell-and yes, Id really go that far in this case.Let me put it this way. Some of the largest web sites out there, handling thousands of concurrent users, run in one thread. ; This is the purpose of Node.js, Twisted, and a bunch of other stuff. Camlorn_audio has so many threading issues related to fine-grained locking that I couldnt fix them if I wanted, and I once spent 8 hours debugging a deadlock and wrote a 15-line comment explaining what I should never ever do if I wanted it to keep working.If you
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Well, what is a mob doing most of the time? waiting for its next step, waiting to respond, waiting for its next attack, it is a lot of waiting. I ran my 45 threads removing numbers from a a variable every random time between 1 and 5 seconds, and sending a print to the prompt. In reading what makes python slow, it says that doing a lot of if statements with non local variables, so basically anything with a dot in it, will significantly slow down productivity.In thinking about how I can do this kind of system, Im thinking that dicts are going to be everywhere and there will be a lot of if statements running from all the currently loaded creatures.My brother was saying that he uses something called delta time in the game engine he uses, but I was totally lost. I know about ticks, but didnt connect the two at all.So, is the little script above what you were saying? time.clock() - the_last_time_snapshot is an int that will eventually be like a 2 or something. So in a sense, my ticks are the built in clock. I can delay my game as much as I wish, so I think that using time.clock() wont be any more memory than implementing my own counter. What do you think? And, does each creature run off its own wait time? like one creature will attack every 2-5 seconds and another will be attacking every 1-3 seconds. In the tick games Ive played, all creatures attacked at the same speed.Ill look at audiogame engine now. URL: http://forum.audiogames.net/viewtopic.php?pid=186198#p186198 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested If you wish to make real-time combat like Swamp has or even for an ai in a side-scroller, in python, I dont think there is any way to do it other than by using threading. Many, many, many python applications use eather multiprocessing or multithreading, and both have their advantages and disadvantages, but IMO for games, you really need multithreading.So I am still not 100% on everything that has to do with threading, but here it goes:syntax:import threadingdef myfunkname(arg): print argmy_thread = threading.Thread(target=myfunkname, args=(myfunks arguments! With a comma,))The major functions in threading.Thread (The class you deal with for each thread but the main one).__init__the thing you call withmy_thread = threading.Thread(target=myfunkname, args=(my_arguments,))you need to put that extra , comma there for some reason...You can change it, you just need to putThread.__init__()right under your __init__(self, argu, men, ts):But dont, its too much work! run():like __init__, dont bother, although if you do mess with __init__, you will probably wish to modify it so you can run it properly.start()you call this for every start of a thread. After this function is called, your thread is on a roll and you can only stop it by the next functions!daemonI didnt forget the (), it is a poor little variable ... But it is not any little variable, it is a daemon!my_thread.daemon = Truemeans that if you exit the main thread, my_thread will die without any warning. So my_thread could be talking to his girlfrien d on the phone and if you press escape to close the game, my_thread will die! (So sad, it was getting a little racy )join()Dont use this like start! It is really not good practice, it is just what everyone does. It nullifies deamon and makes the main thread wait for it to finish. (well not the main thread, but the calling thread, but nvm about that).so if I said:my_thread.start()my_thread.join()I have to wait for my_thread to get off the phone before killing him, then whats the point? Hes already hung up, so you dont get to talk to the girl !...So, if you wish to treat your threads as royalty, usejoin()but imo, daemons are a lot better!Lock (acquire() and release())This is another cla ss like Thread, so it has its own functions! in yourfunk you will wish to create an object like:lock = threading.Lock()then use the acquire() and release() functions, sandwitching the access to the variable.locks are used for changing variables that many threads are changing.so if I have my variable:dinner = 100and my main thread (me), calls everyone to dinner, I would have:mommy_threaddaddy_threadmy_threadgirlfriend_thread #mmm...brother_threadNow if I just let them all eat at the same time, they would all be bumping into one another and grabbing food at the same time. In the real world this is generally what people do when the pizza arives, but in python this can be a bad thing. When all those threads grab at the variable at the same time, the pieces dont end up getting subtracted from dinner, so you get a loavs and fishes effect.dinner = 83mommy_threaddaddy_threadboth grab one piece when dinner is at 83dinner is now 82 and both mommy and daddy threads have a piece!Great if you are poor like me and need to feed all those people, but not-so-good when everyone is on a diet and can only have 1/5th of the dinner (oops, daddy_thread got 21 pieces while still eating his 1/5th of the 100 pieces!)This is really bad when you wish to have everyone write a letter to grandma!mommy would write Dear grandma, I went to the pool today...under it daddy wrote dear grandma, I hate swimming and mommy makes me go to the pool to swim with her...Although you see there is a problem in mommy and daddys relationship in the first 2 lines, once brother my_thread and girlfriend start writing their stuff randomly inbetween everyone elses lines, life becomes crazy and grandma will end up banging a hole in her wall with her head, trying to figure out who is having problems with who!So this is why there is lock!if we wish to have daddy write, he needs to put a lock on the letter so no one else can write to it while he is writing his bit.The code looks like:import threadingletter = []def writing_function(name, text): global letter lock = threading.Lock() lock.acquire() letter.append(Dear Grandma, this is %s and %s % (name, text)) lock.release()daddy_thread = threading.Thread(target=writing_function, args=(daddy, I hate going to the pool. When I stick my leg into the water, I just cant stop thinking about all the little kids who have peed in the water))mommy_thread = threading.Thread(target=writing_function, args=(mommy, I went to the pool today. It was so refreshing after a long day of work just to swim through the water.\nHope to see you soon\nMommy)) brother_thread = threading.Thread(target=writing_function, args=(brother, I just got a longbow in swamp and Ive been running through sub 2, killing all
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested If you wish to make real-time combat like Swamp has or even for an ai in a side-scroller, in python, I dont think there is any way to do it other than by using threading. Many, many, many python applications use eather multiprocessing or multithreading, and both have their advantages and disadvantages, but IMO for games, you really need multithreading.So I am still not 100% on everything that has to do with threading, but here it goes:syntax:import threadingdef myfunkname(arg): print argmy_thread = threading.Thread(target=myfunkname, args=(myfunks arguments! With a comma,))The major functions in threading.Thread (The class you deal with for each thread but the main one).__init__the thing you call withmy_thread = threading.Thread(target=myfunkname, args=(my_arguments,))you need to put that extra , comma there for some reason...You can change it, you just need to putThread.__init__()right under your __init__(self, argu, men, ts):But dont, its too much work! run():like __init__, dont bother, although if you do mess with __init__, you will probably wish to modify it so you can run it properly.start()you call this for every start of a thread. After this function is called, your thread is on a roll and you can only stop it by the next functions!daemonI didnt forget the (), it is a poor little variable ... But it is not any little variable, it is a daemon!my_thread.daemon = Truemeans that if you exit the main thread, my_thread will die without any warning. So my_thread could be talking to his girlfrien d on the phone and if you press escape to close the game, my_thread will die! (So sad, it was getting a little racy )join()Dont use this like start! It is really not good practice, it is just what everyone does. It nullifies daemon and makes the main thread wait for it to finish. (well not the main thread, but the calling thread, but nvm about that).so if I said:my_thread.start()my_thread.join()I have to wait for my_thread to get off the phone before killing him, then whats the point? Hes already hung up, so you dont get to talk to the girl !...So, if you wish to treat your threads as royalty, usejoin()but imo, daemons are a lot better!Lock (acquire() and release())This is another cla ss like Thread, so it has its own functions! in yourfunk you will wish to create an object like:lock = threading.Lock()then use the acquire() and release() functions, sandwiching the access to the variable.locks are used for changing variables that many threads are changing.so if I have my variable:dinner = 100and my main thread (me), calls everyone to dinner, I would have:mommy_threaddaddy_threadmy_threadgirlfriend_thread #mmm...brother_threadNow if I just let them all eat at the same time, they would all be bumping into one another and grabbing food at the same time. In the real world this is generally what people do when the pizza arrives, but in python this can be a bad thing. When all those threads grab at the variable at the same time, the pieces dont end up getting subtracted from dinner, so you get a loaves and fishes effect.dinner = 83mommy_threaddaddy_thread< br />both grab one piece when dinner is at 83dinner is now 82 and both mommy and daddy threads have a piece!Great if you are poor like me and need to feed all those people, but not-so-good when everyone is on a diet and can only have 1/5th of the dinner (oops, daddy_thread got 21 pieces while still eating his 1/5th of the 100 pieces!)This is also really bad when you wish to have everyone write a letter to grandma!mommy would write Dear grandma, I went to the pool today...under it daddy wrote dear grandma, I hate swimming and mommy makes me go to the pool to swim with her...Although you see there is a problem in mommy and daddys relationship in the first 2 lines, once brother my_thread and girlfriend start writing their stuff randomly in between everyone elses lines, life becomes crazy and grandma will end up banging a hole in her wall with her head, trying to figure out who is having problems with who!So t his is why there is lock!if we wish to have daddy write, he needs to put a lock on the letter so no one else can write to it while he is writing his bit.The code looks like:import threadingletter = []def writing_function(name, text): global letter lock = threading.Lock() lock.acquire() letter.append(Dear Grandma, this is %s and %s % (name, text)) lock.release()daddy_thread = threading.Thread(target=writing_function, args=(daddy, I hate going to the pool. When I stick my leg into the water, I just cant stop thinking about all the little kids who have peed in the water))mommy_thread = threading.Thread(target=writing_function, args=(mommy, I went to the pool today. It was so refreshing after a long day of work just to swim through the water.\nHope to see you soon\nMommy) )brother_thread = threading.Thread(target=writing_function, args=(brother, I just got a longbow in swamp and Ive been running throu
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested So I was thinking how you could do events without using the threading module.You would need to use the time.clock() function a lot as benchmarks.I replicated the threading.Timer functionality. It is used a little differently because I kind of bastardized the timer and threading classes, but the while loop is all controlled by you. You can press buttons and have another function take care of them. Does anyone have a better way to do this?class Thread(object): def __init__(self, name=None, function=None, args=()):#name is not used here. function is the name of the function you wish to run with the run() function and args are the args for that function.self.name = nameself.function = functionself.args = argsself.current_time = time.clock()#current_time is a set point in time, time.clock() doesn& #039;t update like normal. def run(self):self.function(*self.args) def wait(self, length):#Im basically saying below that if the moving clock time minus the snapshot of the clock we got above is greater than the length argument, then do the run functionif time.clock() - self.current_time = length: self.current_time = time.clock() self.run() return Trueelse: return False#the function that will run with the run functiondef hello(w): print hello %s % w#for the while statementplay = True#creating our object, we are saying hello is our function name and our arguments are ot;fredt = Thread(function=hello, args=[Fred])while play:#this will run the wait function every loop and return False unless the clock minus the static time are greater than the wait number if t.wait(2):play = False#Sleeping 5 milliseconds every loop makes our program take up something like 90% less CPU time.sleep(0.05)This could be used to randomly wait for a time between enemy attacks. URL: http://forum.audiogames.net/viewtopic.php?pid=185996#p185996 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested hay thomas.how can i get that thingy? the compiler i mean URL: http://forum.audiogames.net/viewtopic.php?pid=185822#p185822 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested pyinstaller is awesome! For quick testing of a game, nothing can beat typing:pyinstaller scripts/scriptname.pyand getting an exe in 30 seconds.py2exe you need to make a file that has all the info for what you wish the game folders to look like and whatnot. I would use py2exe for a full distribute and pyinstaller for testing.It is pretty easy to hit some lag time in python, load a 300 or 400 module package will take a second or so, cycling through 500 times in a for statement takes about 1 second with single level checks, but you can always go to c++ for everything intensive.see this code for example:import timedef main(): starttime = time.clock() for j in range(500):f = jif j == f: print yeselif j == s: print yes! endtime = time.clock() print starttime-endtimemain()to check the same thing in cython, change the range to xrange.There is about a 0.2 second difference.But accessible_output makes life worth the trouble!I have created a little module that you can import into your scripts that will make dealing with pygame super easy. Easy like:import pygame_scripts as pgdef main(): pg.screen(my test game) pg.speak(You are running through the forest! There is a dragon, press the space bar to kill it!) play = True num = 0 while play:n = pg.key2() #key1 is the normal intensive key check, but key2 is basicly rest till key input ; if n[0] == space: pg.speak(Great, you killed it!) play = Falseelse: pg.speak(hurry, the dragon will eat you!) num += 1if num 7: pg.speak(The dragon blows out a nice bit of flame right into your face... Oh, are you not pot-roast? Sorry...) play = Falsemain()#the key function returns a tupal (key_name, key_mods) key name is like space return f d and mods have numbers that I just use right now, but will add in as words later... URL: http://forum.audiogames.net/viewtopic.php?pid=185872#p185872 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested I am currently messing around with multithreading and that is fun! Does anyone have any good techniques for dealing with threads?I dont like the threadname.join() function because it freezes the program till that thread stops. I think daemon threads are what I should use, and just grab an instance each time the player fights a mob. I will avoid locks at all costs though, as locking threads would fill memory very fast. There is no garbage collection for dead threads and I dont know quite when they exit. I am going to write a script messing around more with this. But I hope to write another module that will do this junk for me.Has anyone already done such a thing? URL: http://forum.audiogames.net/viewtopic.php?pid=185873#p185873 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Why are you using threads? for a single player small game you dont even really need to. URL: http://forum.audiogames.net/viewtopic.php?pid=185878#p185878 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Why are you using threads? for a single player small game you dont even really need to. Also using print will obviously slow the program down by a large degree. URL: http://forum.audiogames.net/viewtopic.php?pid=185878#p185878 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested SoundRTS is only slow in the loading sounds part and its not Pygame.I think that the amount of sounds slows a bit the game to load it inmemory.One of the things that I dont like in BGT is that you need to createvarious data types to do a basic thing.I like Python but creating the panning system can be a bit harder (myneis not perfect but at least it is working). URL: http://forum.audiogames.net/viewtopic.php?pid=182187#p182187 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested SoundRTS is pygame. I have the source on my hard drive, now that its open source. The code is very unpythonic, so be warned if you decide to dive in: my 30-second glance shows at least 3 Python stylistic and best practice violations. This sounds like Im being pedantic, but its important to follow the best practices and style guide of your language if your language bothers to give you one (google python pep 8, follow it religiously, youll thank me later when you suddenly dont have to look up if thats a function and when people arent laughing at your code. The only concession I allow is 1 tab instead of 4 spaces, and obviously some of the alignment points are basically impossible for us).As for sounds, loading sounds into ram at game startup is slow in everything. Even C++. Even more so if its not .wav files--ogg and mp3 can easily take a while, not to mention expanding to twice or three times the size.And as for pan, if this is something you consider hard, then open source your panning module. The reason its easy in BGT and the reason its somewhat harder in other languages is because people write stuff and keep it to themselves. Since so many people have trouble with this and youve presumably got one, give it to the community. URL: http://forum.audiogames.net/viewtopic.php?pid=182203#p182203 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested I ported sound_positioning.bgt to Pygame. I dont know if the copy on this computer is the completed version, but I know that I do have a copy that works pretty much identically to the BGT version.(Disclaimer: other than mapping BGTs sound ranges to Pygames, I mostly just formatted Phillip Bennefalls code as Python.) URL: http://forum.audiogames.net/viewtopic.php?pid=182209#p182209 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Hello.In my game I load the sounds when I need it and they are freed frommemory when not used.I think Ill create a topic to share my panning code because I think someonecan have the same problem of creating a panning system for his game.Sometimes I think that I dont want to share the code because I dontknow trig and these other math stuff yet but I think when I share others can learn from my codeand I can learn by the others replyes and we can end with some code thatis even better.About Soundrts code I like the way theyve done it.Anyway, thanks for giving the Pep 8 information, Ill read it. URL: http://forum.audiogames.net/viewtopic.php?pid=182211#p182211 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested You dont want to throw sounds out unless you have to. The issues that can cause are complex, but basically boil down to hard disk I/O issues. If you want to make a cache, which is the right way, you should look at the weakref module, but dont throw them out when done.Basically what happens is, everything is fine until it gets to a computer with a slower hard drive or less CPU power. Alternatively, someone tries to make a game that wants to load 10 or 15 sounds at once for *immediate* playback, and the entire thing stalls because the hard drive just cant.There are 3 solutions to this.The first is to just load everything at game startup, the beginning of a level, or some other time. This first option works until you or someone using your code gets too big for ram, which almost never happens. The key here is that you dont want to duplicate sounds that are already loaded: you have to make info on where the sound i s panned separate from the sound itself. If you dont youre looking at each in-game sound from the same file taking as much ram as the size of the file or more if the file was encoded.The second option when the first becomes too slow is to load all sounds, but use something like the futures module, or some other multithreaded solution. In Python, this isnt complex at all so long as they dont need to share state (they dont). For most games, if they reach this point, its the third that you actually want and not this one.The third way is called a cache. Its like your browser cache in most respects, if youre familiar with that. Supposing that youre not handing out sound objects and are referring to sounds by file, the idea is that you load 20 or 30 or 50 and then stop. Pick a number, any number. When the user of the library requests a sound that isnt loaded and the cache is a s full as you allow, you kill one of the loaded ones and bring in the new one. My preferred strategy for this if I had to give one would be least used gets dropped; other options include least recently used, smallest, largest, etc. One of the things you can do is make cache size based on how much RAM its using: for a given sampling rate, its the size of the sample format (2 for 16-bit or 4 for 32-bit) times the sampling rate times the total time of audio in the cache.But where this last one really shines is this. If sounds are objects and not just one-off events (you want to support this because then you can move it without stopping it playing, among other things), then you can take advantage of the language. Each sound object containing panning info and etc, points at a sound data object. You can keep these data objects in a dict by file name and, when a new sound is requested, look it up there. The magic is that there is a type of dict in python called the WeakValueDictionary. When nothing else in the program is using the sound data object, it will automatically be removed from the dict. This means that, if the lookup fails, you just load and add a new one. No special code is needed for removal, and the game coder using the library is responsible for, say, not loading 500 hours of audio into ram at once.But sharing the files behind the scenes and not constantly reloading the files are both very, very important musts. URL: http://forum.audiogames.net/viewtopic.php?pid=182214#p182214 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Hello.Ive reread some posts and I think that my english caused a bit ofmisunderstanding.In the previous post I meant that Pygame is not responsible for the slowdown in the sound loading process.I tried to say that, but i forgot some words and it meant thatSoundRTS was not using Pygame.About the sound loading, Im thinking to load all the sounds at startupand use a dict to refer to the loaded sounds.But I have a question now: SDL_mixer will make duplicate memory for the sounds, orit only stores pointers for the sounds and use less memory, andmake the changes to the sound as necessary in the channels? URL: http://forum.audiogames.net/viewtopic.php?pid=182217#p182217 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Im not sure, as my familiarity with sdl_mixer is lacking. You may end up needing to create a duplicate when you actually want to play it, which is okay. The thing that you want to avoid is reloading sounds that are already loaded; if a copy is needed for playback, you can probably live with it.The sdl_mixer that Im thinking of is a C-only thing. If you mean Pygame, it separates them, as I recall. That is, channels are responsible for playing and sound objects hold the actual data. the disadvantage with Pygame is that youll have to work out a channel reuse strategy--the built-in ones are sufficient only for very basic things. URL: http://forum.audiogames.net/viewtopic.php?pid=182219#p182219 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Ive made games in Java and _javascript_ and learned my lesson about lag back when I tried to have IE5 update 80 images a frame. Other than using boatloads of transparent gradients, I dont see speed issues in interpreted languages becoming much of a problem (and for most of those, most of the work can be saved in images and reused, and thus lag disappears).In BGT, I only ever get lag when I have a ridiculous number of collision checks per frame, and even then I suspect theres some inefficiency in there somewhere I havent been able to track down. So far Ive done nothing sensitive enough that spreading out checks over multiple frames cant help.Yukionozawa did a speed comparison between HSP and BGT shortly after BGT became freeware. I remember BGT being slightly slower (but winning in a different test I dont remember). I wouldnt really expect a significant speed difference between BGT and Python, is what Im saying.< p>(Ill second Camlorn on the indentation thing: Im still focusing mostly on BGT just because its easier to continue with what Ive been using, but Ive had one eye on porting to Python if I get a game strong enough that I can support adding graphics, so Ive been using indentation and placing braces etc such that theyre easy to clean up programmatically. My number of unexpected end of file errors has dropped dramatically.) URL: http://forum.audiogames.net/viewtopic.php?pid=180553#p180553 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Modern _javascript_ does audio synthesis and is just-in-time compiled on some browsers--on a modern browser, doing that shouldnt be a problem.As for collision detection, yeah. This is one of those programmer knowledge thing. The specific optimization that youre looking for is a data structure called a spatial hash, but its so much easier not to bother and to use ODE or Box2d which implement it plus a bunch of other optimizations and stuff. URL: http://forum.audiogames.net/viewtopic.php?pid=180570#p180570 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested I was thinking in the general direction of a spatial hash myself after the first huge dose of this (it wasnt a spatial hash exactly because I tried to come up with it on my own). Then I decided that was too inconvenient and settled on the memory inefficient technique of using 3D arrays; the objects are still objects, just stored in each tile they overlap. This only works for fixed objects, of course, but 99% of objects are likely to be fixed in most games anyway. This will probably wind up pointless if I try to use Box2D (recreating physics from scratch is just tedious), but for now I think what Im working on can survive on aproximations.(But if I pick up Sonic again? Definitely moving to Box2D. Ive always suspected the original concept was just a physics simulator on a blue ball, then they turned the ball into a hedgehog.) URL: http://forum.audiogames.net/viewtopic.php?pid=180580#p180580 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Well, the thing with the physics simulators is that you dont have to use them as such. If you so choose, just plug in your shapes and ask if they collide. If you dont tick it, it doesnt simulate. This may not be true of Box2d, but it is true of ode and some others.What youre actually describing is voxels. In that case, converting the voxels to a trimesh and culling the triangles that form surfaces between voxels can quite possibly be efficient (even more so if you divide it into multiple trimeshes intelligently). If you are using Ode for collision and simulation, it looks like you have to do this (I havent tried) because Ode apparently has problems with flush edges. If you only want to use Ode for collision, make each voxel a 1x1x1 meter geom, and use their spatial hash (you will get multiple contact points when the player is on an edge but, because the simulation isnt being handled by Ode, its not going to literally explode). trying to make a sidescroller that is accessible and workable with Box2d being used for *all* simulation is on my to-do list, simply because it would be moving us away from the discrete tile approach. In addition, it can handle proper simulation of things like bullets; that is, objects that have velocities so high that they move multiple lengths in one tick. Perhaps even more fun, it can handle ricochet, though using this for gameplay purposes is probably not doable in a side-scroller (it might be in a first-person game, however). Also, that possibly means wall jumps.And this thread just went very off topic. URL: http://forum.audiogames.net/viewtopic.php?pid=180584#p180584 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
2014-07-12
Thread
AudioGames . net Forum — Development room : the terminator via Audiogames-reflector
Re: is coding in python easy? just interested yah tword, thats why im also dealing with BGT URL: http://forum.audiogames.net/viewtopic.php?pid=180514#p180514 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Python is fast enough that I seriously considered (and still am, in a way) doing my MMO project in it. Game load times is not a function of language in this case-I suspect that the Pygame games under discussion are not streaming and load all sounds at game startup, which will slow anyone and anything down. Do not assume that Python is the bottleneck until you know how to use the profiler and can prove it-and even then, it is more likely the algorithm and not the language. Should Python prove too slow for a specific algorithm--rare in this day and age--you can use ctypes and implement it in C/C++, whereupon it wont be anymore. The only reason I may drop it for my MMO project is because Ive decided to take the approach of brute forcing the problem, and am suddenly talking about allocating, copying, deallocating, and generally doing stuff with a million objects a second (I dont want to get too technical, but Python is fast enough for this too . Im leaving it for lack of frameworks that fit the model I want to work in, because writing and optimizing my own is going to take valuable time).As for Pythons easiness: compared to most other languages Ive worked with, Python will get complex things done the quickest in most cases (and the exceptional cases Im thinking of fall under the category of research into computer science and not everyday apps or games). The indentation habits it forms make you a more valuable programmer on sighted dev teams, and tbh youll end up wanting indentation in other languages too (its much more convenient than scrolling up 20 lines with your screen reader to count the braces). I dont have specific tutorials to link as its been literally years since I first learned to program, but there is an unbelievable amount of documentation on getting started with it--I strongly suggest a quick Google search.If your specific goal is an NVDA add-on, you want to learn Python 2.7. Python 3 is a rework of the language-its mostly the same, but it broke backward compatibility and has had the effect of splitting the community; were only just now seeing a merge. NVDA itself uses 2.7 and not 3. It is also worth noting that Python itself is easy, but NVDA add-ons are not: you will need enough skill to read the NVDA source, though you need not be able to actually build it yourself. NVDAs aAPI for add-ons is literally all of NVDA itself (as opposed to Jaws and WE which give you a predefined subset); there are consequently ways to replace literally everything. The downside is that the API is all of NVDA, so you have to do a bit of poking about in the source to figure out where what you want to work with is and how it works.@tward:Do you have any evidence of Python even approaching the point of being too slow for an Audiogame? The newer versions of SoundRTS ( this was one of those its the programmers fault for not knowing the difference between an array and a hash table and not putting the UI on a different thread than the networking) handles literally thousands of units with no problem. Theres a few of us who set up very long-running games--my particular favorite for performance testing the game is getting a large number of mages with summon dragon. This isnt the first time Ive seen you call out Python for slowness, so I figured Id ask. My personal opinion is that it could implement literally any Audiogame currently available, with no noticeable degradation of performance. URL: http://forum.audiogames.net/viewtopic.php?pid=180522#p180522 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Python is fast enough that I seriously considered (and still am, in a way) doing my MMO project in it. Game load times is not a function of language in this case-I suspect that the Pygame games under discussion are not streaming and load all sounds at game startup, which will slow anyone and anything down. Do not assume that Python is the bottleneck until you know how to use the profiler and can prove it-and even then, it is more likely the algorithm and not the language. Should Python prove too slow for a specific algorithm--rare in this day and age--you can use ctypes and implement it in C/C++, whereupon it wont be anymore. The only reason I may drop it for my MMO project is because Ive decided to take the approach of brute forcing the problem, and am suddenly talking about allocating, copying, deallocating, and generally doing stuff with a million objects a second (I dont want to get too technical, but Python is fast enough for this too . Im leaving it for lack of frameworks that fit the model I want to work in, because writing and optimizing my own is going to take valuable time).As for Pythons easiness: compared to most other languages Ive worked with, Python will get complex things done the quickest in most cases (and the exceptional cases Im thinking of fall under the category of research into computer science and not everyday apps or games). The indentation habits it forms make you a more valuable programmer on sighted dev teams, and tbh youll end up wanting indentation in other languages too (its much more convenient than scrolling up 20 lines with your screen reader to count the braces). I dont have specific tutorials to link as its been literally years since I first learned to program, but there is an unbelievable amount of documentation on getting started with it--I strongly suggest a quick Google search.If your specific goal is an NVDA add-on, you want to learn Python 2.7. Python 3 is a rework of the language-its mostly the same, but it broke backward compatibility and has had the effect of splitting the community; were only just now seeing a merge. NVDA itself uses 2.7 and not 3. It is also worth noting that Python itself is easy, but NVDA add-ons are not: you will need enough skill to read the NVDA source, though you need not be able to actually build it yourself. NVDAs aAPI for add-ons is literally all of NVDA itself (as opposed to Jaws and WE which give you a predefined subset); there are consequently ways to replace literally everything. The downside is that the API is all of NVDA, so you have to do a bit of poking about in the source to figure out where what you want to work with is and how it works.@tward:Do you have any evidence of Python even approaching the point of being too slow for an Audiogame? The newer versions of SoundRTS ( this was one of those its the programmers fault for not knowing the difference between an array and a hash table and not putting the UI on a different thread than the networking) handles literally thousands of units with no problem. Theres a few of us who set up very long-running games--my particular favorite for performance testing the game is getting a large number of mages with summon dragon. This isnt the first time Ive seen you call out Python for slowness, so I figured Id ask. My personal opinion is that it could implement literally any Audiogame currently available, with no noticeable degradation of performance.Edit: if you want to make redistributable packages, which Id not worry about for a while, you want Py2exe or Cx_freeze. No one uses Pyinstaller anymore. Beware, for here there be dragons-python makes this a bit harder than it has to be, so Id not worry about it for a while. URL: http://forum.audiogames.net/viewtopic.php?pid=180522#p180522 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Guilevi, well, honestly that is one of the major drawbacks to using Python for games. Its an interpreted language, and will never get the speed and efficiency of a native executable built using C or C++. If someone wants the simplicity of a language like Python they need to understand that it comes at a cost not having the performance and efficiency as a native language.URL: http://forum.audiogames.net/viewtopic.php?pid=178786#p178786 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested To be honest Ive noticed many pygame games are very unstable and have huge amounts of loading time on startup. I do have to say, though, that games like sound rts or soundmud have a ridiculously stable online gameplay which Ive never seen anywhere else besides maybe top speed or other small games.URL: http://forum.audiogames.net/viewtopic.php?pid=178685#p178685 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
2014-06-26
Thread
AudioGames . net Forum — Development room : the terminator via Audiogames-reflector
Re: is coding in python easy? just interested k thanks Thomas, i will learn with the official documantation. Aw! and, well can i make here a sidescroller?URL: http://forum.audiogames.net/viewtopic.php?pid=178376#p178376 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Terminator, I dont see any reason why you couldnt make a side-scroller in Python. However, you would have to understand a fair amount of the language and a good game API like Pygame or PySDL2 in order to be able to do that though.URL: http://forum.audiogames.net/viewtopic.php?pid=178461#p178461 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
2014-06-25
Thread
AudioGames . net Forum — Development room : the terminator via Audiogames-reflector
Re: is coding in python easy? just interested is there an easy way to just like learn the programming languaje?URL: http://forum.audiogames.net/viewtopic.php?pid=178291#p178291 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Terminator, well, there is lots of free documentation for Python. There is all of the official documentation athttp://docs.python.organd if you are a Bookshare member they have a few programming books for beginners in daisy format. There is also the book Learn Python the Hard Way which is available on line that is sort of a crash course in Python. It all depends on how much documentation and newbie friendly you want it to be.URL: http://forum.audiogames.net/viewtopic.php?pid=178314#p178314 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
2014-06-23
Thread
AudioGames . net Forum — Development room : the terminator via Audiogames-reflector
Re: is coding in python easy? just interested hay thomas.how can i get that thingy? the compiler i meanURL: http://forum.audiogames.net/viewtopic.php?pid=177988#p177988 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Terminator, the Pyinstaller script can be found athttp://www.pyinstaller.orgas is documentation on how to modify it to build your Python projects for various platforms, add modules, etc. Its not a compiler in the traditional sense the way a C++ compiler works, but byte compiles Python files into pyc files and then creates a special executable which is more or less a zipped folder of your pyc files and the Python runtime for redistribution.URL: http://forum.audiogames.net/viewtopic.php?pid=178006#p178006 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: is coding in python easy? just interested
Re: is coding in python easy? just interested Terminator, well a lot depends on what you are comparing Python too, but coming from a programmers point of view Python is fairly easy compared to the various flavors of the C language such as C, C++, Java, etc. It doesnt have a lot of the symbols and punctuation marks you have in other programming languages, and blocks of code are determined more by the formatting than any special syntactical rules. It doesnt require that you declare your variables before using them which saves time and makes Python much easier to work with in terms of writing code on the fly. So yes Id say Python is easy to learn and use comparatively speaking.As for where to get Python the latest python runtimes for your platform can always be found athttp://www.python.organd at this time there are two different versions. there is the older stable 2.7 release and version 3.3 for newer more up to date development. If you have Mac or Linux u sually a basic Python interpreter is already installed.As far as editing py files any text editor will do. You can use Windows Notepad on Windows, Gedit on Linux, or the default text editor on Mac. Basically, any text editor will work, and it doesnt have to be anything too fancy.As for compiling Python programs in to Windows *.exe files there are a number of different tools for this purpose. One tool I use is called Pyinstaller which is a script that compiles py files into pyc files, and then bundles them into an *.exe file for your platform.URL: http://forum.audiogames.net/viewtopic.php?pid=177849#p177849 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
is coding in python easy? just interested
2014-06-21
Thread
AudioGames . net Forum — Development room : the terminator via Audiogames-reflector
is coding in python easy? just interested hay folks i am interested in this python thing, and to see if its easy to code. I am needing an NVDA addon to vocaloid, because i can see how difficult is for us to change singers voices, and well thats why i am interested in python. So its easy or not? where can i get it? how i can use it? where i can edit .pi files? how to convert them in an executable?thancs!if you want to give me more n advanced help, you could add me [ a-t ] skype.raton.miguelito.glps.bye folks! aw and thanks again!URL: http://forum.audiogames.net/viewtopic.php?pid=177812#p177812 ___ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
