Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game @12Google deadlocks for an example of what happens if you get it wrong. Getting them right is very situation specific.The easiest way to use threads is when they don't share any state. So for example if you're fetching a bunch of web pages you might do one thread per web page. And in fact you can even find libraries that will make it easy, for example the Python multiprocessing module, which lets you do something alongb the lines of this:def process_webpage(url): # ... stuff return result processed = multiprocessing_pool.map(process_webpage, url_list_here)That's not exact because these days I primarily do C and Rust, but it's along the lines of how things go.The problem is that there's a ton of overhead to starting up something like that, enough that if the work you're doing isn't like 10-20 ms per work unit then you're wasting time. But more to the point the safe/easy approaches like that don't work for games because every thread is going to want to touch the whole game all at once. It requires a good bit of originality to rearrange your algorithms to be friendly to threads.But then you run into the fact that on a 2 core laptop running the OS and NVDA you don't get more than one core anyway, which means even if you use threads they're not running in parallel, they're just taking turns. So even if you do get it working, the people who benefit from it are the people who don't need it because they've got a powerful computer, and if you rely on it instead of making fast algorithms then no one with a cheap laptop can play it and you've just defeated yourself.Where threads show up more is e.g. a web server, which will do one thread per request (Django does this for example, but it's hidden from you). Or databases like Postgresql which will use divide and conquer approaches to run parts of the query in parallel. I deal with them a lot at work because part of work is a custom database and another part of work is an analysis engine that has to process millions of giant files a minute sometimes.If you were doing an online game you might do one thread per area. Getting objects between threads and making sure that areas don't have to read other areas that other threads own is a thing that's not so easy, but it's a good divide and conquer approach and an environment where one core won't do it (you've got physics, all your pplayers go to a different map, now you're running the equivalent of 20 games. One core isn't going to do it). But if your game is complex enough to justify that you'd probably not use Python first, and I don't think we currently have multithreaded online games save perhaps for doing the networking in the background, so the scale at which it matters is larger than you'd expect. URL: https://forum.audiogames.net/post/617246/#p617246 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game @14Ah, so I did. I'll fix that. URL: https://forum.audiogames.net/post/617293/#p617293 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game @13 I think in your code example you forgot to pass process_webpage to the map() call URL: https://forum.audiogames.net/post/617281/#p617281 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game @12Google deadlocks for an example of what happens if you get it wrong. Getting them right is very situation specific.The easiest way to use threads is when they don't share any state. So for example if you're fetching a bunch of web pages you might do one thread per web page. And in fact you can even find libraries that will make it easy, for example the Python multiprocessing module, which lets you do something alongb the lines of this:def process_webpage(url): # ... stuff return result processed = multiprocessing_pool.map(url_list_here)That's not exact because these days I primarily do C and Rust, but it's along the lines of how things go.The problem is that there's a ton of overhead to starting up something like that, enough that if the work you're doing isn't like 10-20 ms per work unit then you're wasting time. But more to the point the safe/easy approaches like that don't work for games because every thread is going to want to touch the whole game all at once. It requires a good bit of originality to rearrange your algorithms to be friendly to threads.But then you run into the fact that on a 2 core laptop running the OS and NVDA you don't get more than one core anyway, which means even if you use threads they're not running in parallel, they're just taking turns. So even if you do get it working, the people who benefit from it are the people who don't need it because they've got a powerful computer, and if you rely on it instead of making fast algorithms then no one with a cheap laptop can play it and you've just defeated yourself.Where threads show up more is e.g. a web server, which will do one thread per request (Django does this for example, but it's hidden from you). Or databases like Postgresql which will use divide and conquer approaches to run parts of the query in parallel. I deal with them a lot at work because part of work is a custom database and another part of work is an analysis engine that has to process millions of giant files a minute sometimes.If you were doing an online game you might do one thread per area. Getting objects between threads and making sure that areas don't have to read other areas that other threads own is a thing that's not so easy, but it's a good divide and conquer approach and an environment where one core won't do it (you've got physics, all your pplayers go to a different map, now you're running the equivalent of 20 games. One core isn't going to do it). But if your game is complex enough to justify that you'd probably not use Python first, and I don't think we currently have multithreaded online games save perhaps for doing the networking in the background, so the scale at which it matters is larger than you'd expect. URL: https://forum.audiogames.net/post/617246/#p617246 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game @camlorn, Any tips of using threads the correct way? I'm really interested to know what is the correct and the incorrect way of using them, From what i understand you are saying there are some ways the developer should and shouldn't use threads with. URL: https://forum.audiogames.net/post/617177/#p617177 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game I really thought the collision tutorial from a while back proved the point. Apparently not. Sigh.Threads are bad because if you use threads and you're even remotely new to programming, you've just taken your one problem, namely it being slow, and added a second one, namely being buggy. It took me something like 2 or 3 years to be competent at using threads and, at work, we've got a bunch of threading experts and the code reviews for threading stuff are always the most painful regardless of who wrote it. Just don't. Learn how to not write slow algorithms first. URL: https://forum.audiogames.net/post/617097/#p617097 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
2021-02-20
Thread
AudioGames . net Forum — Developers room : GrannyCheeseWheel via Audiogames-reflector
Re: Thoughts on possible developement of a racing game Came here to say basically this. URL: https://forum.audiogames.net/post/617095/#p617095 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game @Meatbag please stop going around telling new programmers that python is slow. python is plenty fast for a project like this. I'm not even a huge fan of python for application development, but I know for a fact that it can handle 90% of audio games out there, including this idea.others have tried to point out to you that python isn't the problem, but rather the algorithms and data structures used. if you don't use them well, then your program will be slow even if you programmed it with raw assembly, let alone C/C++.I don't want this to sound mean. I think you are probably very young, so it isn't your fault you don't know much about reasoning about space and time complexity in programs. however, you don't understand that the language/runtime isn't the problem when developing an audiogame like this, it is that you don't know how to write performant code. going around posting don't use python because it is slow, when others have pointed out to you multiple times that it is not the isssue is really unhelpful to other new programmers URL: https://forum.audiogames.net/post/617082/#p617082 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game unfortunitly yes, Python threads are kinda slower than the main thread if you are going to compair them, But however if you do a game with single thread for the whole thing, Then using python and using bgt is not really a difrent, It goes better when too many processes goes on where threading becomes better. URL: https://forum.audiogames.net/post/617040/#p617040 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game unfortunitly yes, Python threads are kinda slower than the main thread if you are going to compair them, But however if you do a game with single thread for the whole server, Then using python and using bgt is not really a difrent, It goes better when too many processes goes on where threading becomes better. URL: https://forum.audiogames.net/post/617040/#p617040 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game unfortunitly yes, Python threads are kinda slower than the main thread if you are going to compair them, But however if you do a online game with single thread for the whole server, Then using python and using bgt is not really a difrent, It goes better when too many processes goes on where threading becomes better. URL: https://forum.audiogames.net/post/617040/#p617040 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game many peapol online advice to not use threading or processing for some reason though URL: https://forum.audiogames.net/post/617038/#p617038 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game @5, Python isn't slow, Maybe slow compaired to c++/rust and those crazy speeding languages, But it's not vary slow, You still can do stuff with it even online, And if you got lagg or stuff there's modules like multiprocessing that may help, Tip, Don't ever put multiprocessing in a while loop, Or good luck crashing your computer.And also, You got something called cython which speeds up your python code by 25%. URL: https://forum.audiogames.net/post/617037/#p617037 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game @5, Python isn't slow, Maybe slow compaired to c++/rust and those crazy speeding languages, But it's not vary slow, You still can do stuff with it even online, And if you got lagg or stuff there's modules like multiprocessing that may help, Tip, Don't ever put multiprocessing in a while loop, Or good luck crashing your computer. URL: https://forum.audiogames.net/post/617037/#p617037 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game @5, Python isn't slow, Maybe slow compaired to c++ and those crazy speeding languages, But it's not vary slow, You still can do stuff with it even online, And if you got lagg or stuff there's modules like multiprocessing that may help, Tip, Don't ever put multiprocessing in a while loop, Or good luck crashing your computer. URL: https://forum.audiogames.net/post/617037/#p617037 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game do not use python if you can help it, you need a lot of work to get the game fast enough to play, doesn't mean python is slow but to make it fast enough to be playable you need a lot of work URL: https://forum.audiogames.net/post/617034/#p617034 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game OK. Well this will not have any video in it what soever. So it is good to know all these things. I will check out that lucia stuff I have been seeing. URL: https://forum.audiogames.net/post/617033/#p617033 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game python will be more than ok to handle this, And also, Switching from bgt to python is easy, At the least, Compaired to other languages like the c languages, And you also have lucia which has too many concepts taken from bgt, Although it's maybe a bit of broken, But it works, And about the compiled size, You can avoid this by just using a virtual invirement, Sorry broken spelling, But you get the meaning, And that way, You install all your stuff via pip and when you compile to exe theprogram will just use what you installed in the virtual invirement, And avoid stuff you installed for other projects for example. URL: https://forum.audiogames.net/post/617022/#p617022 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Thoughts on possible developement of a racing game
Re: Thoughts on possible developement of a racing game Very large... video games nowadays weight more than 100 Gigabytes, the Python interpreter is like 3 or 4 Megabytes in size, I'd recommend you don't worry about the size of an interpreter, but see which language suits you best for such a task. URL: https://forum.audiogames.net/post/617020/#p617020 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
