Re: the slowness of bgt
Re: the slowness of bgt There are tons of tutorials on C++. There's one at cplusplus.com -- the tutorial I learned it from was that one, in fact. It teaches C++11 (or C++0x, not precisely sure). Its a good starter though -- you don't need to learn C++14, C++17 or C++20 until you've gotten pretty good at C++11. C++11 is a good starting point anyway. The only issue with cplusplus.com is that they get some things in their reference wrong, or fail to mention important details in their. Its also a closed site and not a community wiki like cppreference is. I generally avoid it for reference material because they're still stuck on C++11 and don't acknowledge C++14/17/20, whereas cppreference.com does, as well as for the reasons above. I've generally found cppreference.com more accurate for reference material. Don't try learning from the site as a beginner though -- its not designed for that. URL: https://forum.audiogames.net/post/506549/#p506549 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt There are tons of tutorials on C++. There's one at cplusplus.com -- the tutorial I learned it from was that one, in fact. It teaches C++11 (or C++0x, not precisely sure). Its a good starter though -- you don't need to learn C++14, C++17 or C++20 until you've gotten pretty good at C++11. C++11 is a good starting point anyway. URL: https://forum.audiogames.net/post/506549/#p506549 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt Hi Guys,I was just wondering where I can learn more about some of these programming languages you have mentioned here. I found material on Python, more than enough to get me started in learning it I think. However, are there any tutorials here that have to do with C++, BGT, or any others that you've mentioned. I am looking to possibly learn how to develop some games of my own as I have some ideas that I would like to try and see if I can put to use. Any help would be awesome. URL: https://forum.audiogames.net/post/506546/#p506546 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @61yeah but so the thing is. You're supposed to preload your art assets up front. This isn't even about 30MS of audio latency at the end of the day, from a programming perspective. Even if your game takes 10 times longer to load you're still going to run out of ram by loading too many sounds long before the user runs out of patience. URL: https://forum.audiogames.net/post/506506/#p506506 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt camlorn wrote:@55This thread never had a question and this is an internet forum. What's the problem with it going off topic, especially when it's still sort of on topic?The main thing I'm struggling to understand is, does the op actually have slowness in his game and rather than search for a syntactical reason for it, got angry with BGT and thinks PB is better because it handles his unoptimized coding practices better? Perhaps I'm still holding out hope that this is the case, for a couple reasons. First if you don't know anything about coding, you have literally no concept of how breakable or optimizable (is that even a word?) code can be. Also, I like to see the good side in everything and don't like to accept that people post stuff like this just to see where the dirt flies. But maybe I'm wrong.In any case Post 4 did have some takeaway value for me. You can't get accurate timing measurements by doing a naive test. If I hadn't read that, I would've tried that myself if I ever had a reason to do so. Now I know not to bother, or I can do research if I feel like I need to know more. But after that, I didn't quite know what I was supposed to be taking from it.Yes things go off topic. I didn't have a problem with the posts about C++ and other languages and how they work. I didn't really get any of it, but the drift seemed logical if not a little sudden. I'm not a dev though, so I'm not meant to understand when things go that way. But when the whole 2 vs 30 ms thing came up, which is something I do understand well since audio production is my primary hobby, and is imho a far less interesting or technical topic since it needs context to have any use, I became concerned about where the thread was going. On one side we have people discussing technical jargon way over my head, but on the other we're debating the value of the millisecond, the basic glue that holds most game designs together, with bassless claims being made without context. Totally the opposite, and there's not really a link in the middle, to my perception, which says hey, this all amounts to one big idea. I leave this thread wondering what the point was.My first idea is to spend a few weeks learning BGT and some other language well enough to load and play sounds to see if I can find any sort of case where the difference in load times matters to me. But even then I wouldn't be doing myself any favors. If I did manage to code things in such a way that I notice a concrete difference, previous experience with games tells me I'm probably doing it wrong and my rationale tells me that's not the first thing you should be doing with a language, it's probably the last actually and only reserved for a script you don't intend to use, or at best, you save for demonstrations of how not to do things. But let's say I hypothetically ran into a real issue with load times in my game. My first reaction in such a case is to find those who have made the same mistakes I am hypothetically making so I can learn something, so I was perhaps hoping to see that in this thread. But perhaps you're right. This question, if that's what it was ever intended to be, is too trivial and I'm reading things incorrectly. I won't argue the point. URL: https://forum.audiogames.net/post/506385/#p506385 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt now watch the op not say anything and just make a topic for the hell of it and sitting back watching the drama fest go on...well at least there's a lot of constructive discussion in this topic too i guess. URL: https://forum.audiogames.net/post/506382/#p506382 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @58, oh no, I did mean 30 seconds sometimes. ATA8 ACS-4 (INCITS 529-2018) indicates that a disk can take up to 30 seconds to complete the HYBRID CHANGE BY LBA RANGE and HYBRID EVICT commands. A disk can also take an unusually long time to identify itself through the IDENTIFY DEVICE command too. However, none of these cases, I suspect, are very common in modern disk controllers. But I'm getting into hardware territory, which is so off-topic and can become so technical that this room might not be very qualified for that kind of discussion, especially considering the majority of the audience. I'd be happy to chat about it sometime though, in PMs or so, or even in another topic, but definitely not in this one. This discussion needs to end -- we're beating a dead horse now; hell, we've probably beaten it so hard, then trampled over it so much, that its probably six feet under. URL: https://forum.audiogames.net/post/506358/#p506358 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @58, oh no, I did mean 30 seconds sometimes. ATA8 ACS-4 (INCITS 529-2018) indicates that a disk can take up to 30 seconds to complete the HYBRID CHANGE BY LBA RANGE and HYBRID EVICT commands. A disk can also take an unusually long time to identify itself through the IDENTIFY DEVICE command too. However, none of these cases, I suspect, are very common in modern disk controllers. But I'm getting into hardware territory, which is so off-topic and can become so technical that this room might not be very qualified for that kind of discussion. URL: https://forum.audiogames.net/post/506358/#p506358 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @55This thread never had a question and this is an internet forum. What's the problem with it going off topic, especially when it's still sort of on topic?@56Hopefully you meant 30 MS, though it is actually quite possible for a disk to take 30 seconds as well, and I have the unfortunate pleasure of having been the one on call when that started happening (it ended at Google Cloud support and a I told you so moment to someone who did something hacky because they wanted to win a political argument--not a fun day). URL: https://forum.audiogames.net/post/506353/#p506353 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @55This thread never had a question and this is an internet forum. What's the problem with it going off topic, especially when it's still sort of on topic?@57Hopefully you meant 30 MS, though it is actually quite possible for a disk to take 30 seconds as well, and I have the unfortunate pleasure of having been the one on call when that started happening (it ended at Google Cloud support and a I told you so moment to someone who did something hacky because they wanted to win a political argument--not a fun day). URL: https://forum.audiogames.net/post/506353/#p506353 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
2020-03-04
Thread
AudioGames . net Forum — Developers room : Jaidon Of the Caribbean via Audiogames-reflector
Re: the slowness of bgt I mean, I think I can throw a disc pretty far. I can throw a 5 pound shot put ball about 7 metres. So I think I can throw a disc further. Rory has this habit of going about telling people how great pure basic is, and providing 0.0.000..0 pieces of evidence. As I said, i'll stick to python for now. I also agree in this statement that this topic has become a battleground, about who thinks this language is better, or productivity over speed. Has anyone thought of merging the two? Judging a programme on its productivity, and how fast it can achieve that productivity? In the car world, this is called, Horsepower. Or how quickly an engine can do work. Let me give you a story. My friend was going on to me, about how he was a tech guy. He's a tech whiz, blah blah blah! I knew he was an idiot, and I asked him, what's python? He goes, Whah!? I asked, what's HTML? He says it again. Then I asked him, what's Java. He says, Minecraft. Then, I asked him, what's C and C++? He goes, stop asking me these questions like you have the answers. I told him, yeah of course. I don't be bumping my gumb like you do. I told him, There all programming languages. The guy goges, I knows nothing about programming. That's why he joined the IT club. The next day he says, he's the best in the I.T club. He's better thaan most people. Today I asked my friends, what do you do in that I . T club? He says, we faught robots yesterday! Every group won, accept the guy who doesn't know what HTML is. Also, the guy knows that all of those things are programming languages. The point I'm trying to make is, by you guys quarreling about who's language is better and productivity versus speed, you now sound like the idiot who doesn't knoww what HTML is. Well, at least you try to back up your points, but we as developers should be bashing our brains trying to come up with the most effective scripts together. Not against each other. A bit of competetion here and there is ok, but A large chunk of this topic is devs bashing each other. Example Ivan. URL: https://forum.audiogames.net/post/506352/#p506352 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @55, definitely right on all of your points. Regarding load times, I'd just like to point out that a disk can take up to 30 seconds to respond to an IO request, if not longer. This is one of those flaws that post 4 pointed out -- a sound might take far longer than usual to load because the place your loading it from may not be ready (i.e. the disk may be busy), the disk may not even be spun up, and so on. There are far more accurate ways of benchmarking; this is definitely not one of them. (Side note: I'm not one to trust benchmarks as far as I can throw them. They depend on so many factors that they're far too unreliable for my taste. Plus, most benchmarks that I've seen don't reflect the actual environment that the application is subjected to in production.) URL: https://forum.audiogames.net/post/506344/#p506344 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @55, definitely right on all of your points. Regarding load times, I'd just like to point out that a disk can take up to 30 seconds to respond to an IO request, if not longer. This is one of those flaws that post 4 pointed out -- a sound make take far longer than usual to load because the place your loading it from may not be ready (i.e. the disk may be busy), the disk may not even be spun up, and so on. There are far more accurate ways of benchmarking; this is definitely not one of them. URL: https://forum.audiogames.net/post/506344/#p506344 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt I'm not a coder. I dabble in a few code-related things but still struggle with basic concepts, so I'm largely a player of games and don't much care about the language. Therefore I'm not the target audience here and probably not in this room in general, but I feel like this thread has devolved and isn't very productive so I want to offer my insight. Take it or leave it.rory-games wrote:Pure basic: *loads step sound in 2 ms*bgt: *loads step sound in like 20-30ms*No example code to prove it, no description of the methodology used to test it.@4 seems to be an appropriate answer based on the limited information we at first got.camlorn wrote:2ms vs 30ms is within the margin of error for anything doing disk I/O. Purebasic is faster in the general case because it's basically C, but the above benchmark isn't useful and may actually come out with BGT as the winner if ran properly.There are something like 4 or 5 levels between you and the disk. As one concrete example, one of these is the page cache, which uses supposedly unused ram to keep files loaded in memory in case another program tries to read them after, which means that it matters which program ran first.There are also something like 4 or 5 kinds of timers provided by the operating system, some of which can't even give values at a resolution higher than 1MS and which make basically no guarantees to accuracy, up to give me the literal number of clock cycles this took.I could go on for a while, but if you're timing anything more complicated than a math loop you need an absurd amount of control over the environment, and if you're timing a math loop some compilers will just go "hey, the result of this is never used, so let's not do the work" and then it'll take 0ms or some other value way less than it should because it's not doing work you think it's doing. That said I don't think either BGT or Purebasic is complicated enough to be doing that level of optimization, but C++ and anything that uses LLVM internally certainly does.From this point I would've expected this to be acknowledged but it instead devolved into which programming language has the best performance for OS development and is 2 ms vs 30 ms important? And to my perhaps shallow mind, the whole idea of load times in BGT being slow, which the op was initially talking about, became irrelevant. I wouldn't know if it's a real issue, I would suspect not since the BGT games I play don't feel laggy but what do I know? The point is that now we're just comparing 2 ms to 30 ms for the sake of comparing 2 ms to 30 ms without context, and in this comparison context is everything.Can you tell the difference when loading sounds? As other people have said, loading sounds is normally done before gameplay, so I'm not sure what the op is taking issue with here. Some games take minutes to load, so the difference between 2 and 30 ms is negligible. And hey your computer might just be working a little faster one day than on another day, because a background service is or isn't running. It's at best a curiosity reserved for computer geeks.On the other hand, if an enemy is firing a machine gun and for some reason each bullet in BGT waits 30 ms to play the sound while in PB it takes only 2 MS, that, might, be noticeable depending on the other sounds around and the other factors in the game. A more extreme case is when two sounds are played on top of one another. You could definitely hear the difference between 2 and 30 ms then. IN fact, you can easily hear differences between fractions of an ms if you do that. If you play two sounds on top of each other, but in one case you delay the second copy by 0.5 ms and in the other case you delay the second one by 0.6 ms, you'll know they're different. Easily. But do the same with 30.5 and 30.6 and you probably won't; the changes are less audible the higher you go.So does 28 ms actually make a practical difference? It's a big fat depends. But without at least preliminary code or methodology of testing or some detail on what the op is trying to do, we can only speculate, and that speculation has lead us well off track. This is precisely why making claims without evidence is a bad thing.If the op is reading this, I would encourage them to find more objective, less persuasive means to communicate. Drilling a point with persuasion has its place in marketting, public speaking and other fields. Not coding or science. Simply stating X is sooo slow because it takes 15 times longer to do a task than Y doesn't prove the inefficiency of X. At best, it shows a vague objective difference which might not even be valid if post 4 is correct. At worst, it creates confusion, misinformation, and useless banter, especially if you can't make a case for why it actually matters for game development. If you're simply concerned about speed and shy away from one language because it's slow, that's your call, but the general opinion I"m reading is that pro
Re: the slowness of bgt
Re: the slowness of bgt Liam wrote:33: Lol. No you can't tell the difference between that short of a time span. That's ridiculous.Agreed with Liam. I'd like you to record you playing Manamon at Hanja Village and play that speedy reaction game in the arcade. When you hear the sound, respond 2 to 28 ms later. Can't do it? Exactly. No human can do that. URL: https://forum.audiogames.net/post/506222/#p506222 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @52If you read what I've written on the topic, you will find that I have listed out at least 10 reasons why the benchmark is flawed in this thread already, and that my procedure for actually being able to notice requires spending around $1000 on hardware. URL: https://forum.audiogames.net/post/506193/#p506193 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @camlorn, I have no doubt that you can notice 30 ms delay when using keyboard to trigger your sound.However, the OP only specifies that he tested the delay by launching a program which automatically loaded and played the sound, without the user doing anything.Again I say, impossible. URL: https://forum.audiogames.net/post/506183/#p506183 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @50Yeah; in general stay away from sighted game dev as a job. Though I suspect you've already worked that out. URL: https://forum.audiogames.net/post/506064/#p506064 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt I wish there was a way to work with unity completely programatically. if so I would be all over that. I've missed out on a couple paid opportunities because of it URL: https://forum.audiogames.net/post/506058/#p506058 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
2020-03-03
Thread
AudioGames . net Forum — Developers room : Jaidon Of the Caribbean via Audiogames-reflector
Re: the slowness of bgt As said, the 28 MS will be maibnly noticed by sighted gammers. Its called ghosting. The longer it takes for a colour to change, the less clean it looks. It can also fuck up your game. Experienced this when I tried COD on my friend's low-end phone. URL: https://forum.audiogames.net/post/506039/#p506039 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @47I want to write audiogame unity. I honestly truly don't know why. I started one in Electron, proved the concept, then realized that (for the third time) audiogames are pointless without good audio which lead into Synthizer as a thing, thus sorta derailing that project.I sort of want to do it in Python now, since Synthizer existing will make the WebAudio story not necessary. Grab WX, write an equivalent to the Django ORM, and autogenerate forms off it. Unity is so not the programming. Unity is the editors and the tooling that you just get for free without having to code them yourself. URL: https://forum.audiogames.net/post/506028/#p506028 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt 45:I want to work in unity in the worst way. Monogame alone is not cutting it. URL: https://forum.audiogames.net/post/506025/#p506025 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt Actually to follow that up with how to notice 30MS:It's not that 30MS is going to be "O wow that's obviously 30MS". it's that 30MS is going to feel mushy for lack of a better word. If you're playing a music keyboard then, at least to me, it actually feels like the keyboard itself has changed the textures of the keys. it's a very strange feeling. It's not obviously late, but it can feel very obviously off, if that makes any sense. Rhythms and stuff come out weird when you hear it playing back to you and stuff. Someone listening will hear it right. But because you're pressing the keys you can kinda tell. It feels like slurring or something. Very hard to put into words, but when I talk to my music friend and latency has come up, he's noticed it too.Also, in the specific case of stuff with a button you can hit the button hard and compare the output to the button--you can tell that the other sound is 30MS late in that case because the sound and the button will sound not right on top of each other. URL: https://forum.audiogames.net/post/506015/#p506015 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @40Sighted people like C/C++ because they're fast enough that you can manipulate literally 10 individual triangles, doing stuff with them 60 times a second, and streaming them to your graphics card and ultimately as pixels at gigabits per second down the cable to your monitor. Your HDMI cable is orders of magnitude faster than your home internet (I'd say anywhere from 10 to 1000 times depending on your home internet).To put it in perspective, Synthizer (my 3d audio project) needs C/C++ because synthesizing one source with HRTF uses more mathematical operations per second than any audiogame needs to simulate the entire game. And you're not going to just be using one source, you're going to use like 32 or more of them. I would estimate that for most people synthizer comes out to half a CPU core in common usage, but optimized to hell and back in C/C++ to get that low, and with a slight chance of inline assembly before it's over.Your graphics card, which you kinda sorta need C/C++ to talk to efficiently, is anywhere from 2 to 10 times more powerful than your CPU at minimum, and the highest ones are even more powerful still. Sighted games will use all of that computational power, and also take all your CPU's resources. Before you ask "why don't we use them as CPUs" it's complicated and gets into a whole discussion about CPU architectures, but suffice it to say that graphics cards can't just do general purpose stuff.If you were ever fully sighted, you'd have experienced what it's like when you look at a sighted game and can tell it's not the real world. Your eye has multiple millions of pixels worth of input, and you have two of them. We, and many indie devs, get to shrug and not care because of the nature of what we're doing, but sighted people infinitely reach for the more and more realistic looking world, and that costs them more computing power. They're almost there though, believe it or not, so that might change.But even then, a lot of sighted people actually use C#. This isn't because C# is particularly good or bad, but because it turns out that if you have a lot of smart people you can be Unity and make C# fast while also providing everything the aspiring sighted game dev could ever want. SO it's not like it's C/C++ or nothing--just like there's OpenALSoft or (maybe) Synthizer or whatever, there's the equivalent things for sighted people doing graphics.You will also find that almost any language is less verbose than Java. Also Java is requiring things like check for the end of the file, but they do it via exceptions, and if you're not checking those conditions now then you'll have to down the road.@43 @4430 MS is noticeable. It's hard to notice if you're not doing something like music, and the problem with that test is that just opening the exe is going to take longer than the 30MS, but if you have all of the following you can tell:1. The sound needs to be triggered by user input, say hitting enter.2. The audio backend that your program uses needs to have near zero latency. This is possible in something like Reaper, but takes doing in game development tooling (typical latencies are anywhere from 10 to 50 ms).3. The computer it's running on needs to have good enough audio drivers for 2. Not all do; you either need very modern Windows 10 on the right laptop, or something supporting Asio.4. The keyboard needs to be near zero latency. This includes the driver, the keyboard hardware itself, and the message loop of the receiving program.5. The program needs to be running at realtime priority. This is doable via the right APIs, but because that priority is so high that it actually begins preempting OS services and can freeze your machine, it's not just trivial to do it.6. Windows defender, etc, all need to be off, otherwise they might interfere.7. Any other background software that's taking system resources needs to be off, otherwise latencies below 20MS in the audio chain are going to crackle when those programs preempt the test program.Practically to have even a chance in hell of running this test, you need to be a musician with rather expensive hardware. However I think it's worth noting that if your synth is at 800 words a minute, it's doing a word every 70MS. Audio latency adds up fast, and the first little bit is actually more noticeable than the rest--going from 50 to 70MS is not nearly so bad as going form 2 to 30 MS.But none of this matters because you should be loading your audio assets ahead of time, not on every call, and so the 30MS penalty isn't going to be there; and the latency of even synthizer in my wildest dreams won't be below 20 ms anyway because you can't require your users to have high-end musician-grade hardware. URL: https://forum.audiogames.net/post/506013/#p506013 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @43, he might notice the 28 MS delay but only if we put queues in it. But the 2 MS delay? No way. URL: https://forum.audiogames.net/post/505966/#p505966 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @43, the mind is incapable of that. I can tell that there's a delay of, say, between 20 to 50 MS in audio when I'mmonirong myself. But when it comes to program execution... the mind is incapable of that kind of measurement because that's nothing to queue it to let it know anything's happening until its already done. URL: https://forum.audiogames.net/post/505966/#p505966 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt I'm just gonna chime in here.@33 says that they can tell the difference between 2 and 30 milliseconds. I say we put it to the test.1. We write 2 PB programs, one that loads a file ASAP and one that hesitates for 28 ms (the difference between PB and BGT).2. We compile the programs and give him the EXEs named program1 and program2.3. We ask him which one is 30 and which one is 2 ms and see if he can answer correctly.4, Optional. We write the program in a multitude of other languages, repeating steps 1 - 3 and see if he can answer them correctly.Now, obviously this is not a 100% fool-proof solution. The programs could be extended. to include a 60 and a 90 ms delay to decrease the chances of a guess leading to a correct answer. URL: https://forum.audiogames.net/post/505928/#p505928 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt I'm just gonna chime in here.@33 says that they can tell the difference between 2 and 30 milliseconds. I say we put it to the test.1. We write 2 PB programs, one that loads a file ASAP and one that hesitates for 28 ms (the difference between PB and BGT).2. We compile the programs and give him the EXEs named program1 and program2.3. We ask him which one is 30 and which one is 2 ms and see if he can answer correctly.4, Optional. We write the program in a multitude of other languages, repeating steps 1 - 3 and see if he can answer them correctly.Now, obviously this is not a 100% fool-proof solution. The programs could be extended. to include a 60 and a 90 ms delay to decrease the chances of a guess leading to a correct answer.Also, OP fails to account for compilation time for both the languages, but I feel like that is implicit. URL: https://forum.audiogames.net/post/505928/#p505928 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt I'm just gonna chime in here.@33 says that they can tell the difference between 2 and 30 milliseconds. I say we put it to the test.1. We write 2 PB programs, one that loads a file ASAP and one that hesitates for 28 ms (the difference between PB and BGT).2. We compile the programs and give him the EXEs named program1 and program2.3. We ask him which one is 30 and which one is 2 ms and see if hhe can answer correctly.4, Optional. We write the program in a multitude of other languages, repeating steps 1 - 3 and see if he can answer them correctly.Now, obviously this is not a 100% fool-proof solution. The programs could be extended. to include a 60 and a 90 ms delay to decrease the chances of a guess leading to a correct answer.Also, OP fails to account for compilation time for both the languages, but I feel like that is implicit. URL: https://forum.audiogames.net/post/505928/#p505928 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @40, typically C is used by game developers (especially AAA games) because it gives them not only maximum performance but allows them to dig into the really low-level stuff too. For example, a mainstream game might use the computational features of a GPU, or might need to load absolutely massive assets, and that kind of stuff just can't be done in Python with reasonable performance. The overhead of Python is extremely huge, and on a console that overhead is intolerable. Plus, most AAA games are written to run on consoles too, where memory is scarce, and so most AAA games have custom memory allocators explicitly designed for this environment. EA, for example, has a really good paper that they wrote in 2005-2007 that explains why, back then, the C++ standard library was not good for game development. That may still be true to this day. An example of their complaints was that if they created an std::vector with no items, it would still allocate memory. That was unacceptable to them -- they needed their memory usage as tightly controlled as possible, especially on consoles. I can try and dig up the paper if you like. So, since the STL wasn't good for them, they wrote a custom version of it, EASTL, that had all from the STL that they needed but explicitly designed for game development. (I can't get it to link to anything I write with it, sadly. But that's another story.)There are some very, very good game development libraries for C; SDL2, in particular, is very, very good. Combine that with a bit of OpenGL, FMOD or OpenAL (or any other audio library of your choice), and a screen reader library and you've got a full game development stack for games in general that can be fully accessible. SDL will handle force feedback, some of the graphics needs, creating and destroying windows, input, events, and so on, all for you, so long as you ask it for that. (Text input is not fully automatic, though, so you still need to handle the storage and such by yourself.) URL: https://forum.audiogames.net/post/505925/#p505925 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt I have no real problem with terminal games, in fact I quite like the cmd and powershell and use them for quite a lot. But Rorrys games were just the same sort of thing in a terminal, over, and over. But if you look in the general room, you'll see he's moving away from that. Now, can we get back to the topic at hand? URL: https://forum.audiogames.net/post/505914/#p505914 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt So this brings up a good point about C in general. Are there reasons people choose it over an object oriented language like Java or Python for game creation? From personal experience (not game making related), there are a lot of things that I like that C does, but C is just really complicated to get into at first. C handles file i/o way better imo than Java does, requiring far less code to get what you need to do done. You do however have to manually check for the end as file, but it's much more managable than Java. But for stuff like games, I'm curious what would be a good reason for choosing it over Python which has its own game libraries. Does C have these as well, and if so, does the speed of the language make a noticable difference? URL: https://forum.audiogames.net/post/505909/#p505909 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt So this brings up a good point about C in general. Are there reasons people choose it over an object oriented language like Java or Python for game creation? From personal experience (not game making related), there are a lot of things that I like that C does, but C is just really complicated to get into at first. First off, C forles file i/o way better imo than Java does, requiring far less code to get what you need to do done. You do however have to manually check for the end as file, but it's much more managable than Java. But for stuff like games, I'm curious what would be a good reason for choosing it over Python which has its own game libraries. Does C have these as well, and if so, does the speed of the language make a noticable difference? URL: https://forum.audiogames.net/post/505909/#p505909 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @36The level of conversation you're talking about not liking is maybe half as deep as the conversations I have at work every day. There is this idea around here that the way you make a game is you go get BGT and the rest will fall into place. In reality games are one of the hardest places to learn to program anyway, the community took years to even begin to contemplate open source because everyone treated their tiny trigonometry libraries or whatever like trade secrets, people are both trapped in proprietary solutions and ignoring the literally hundreds of thousands of game making tutorials for the sighted that could explain things even when they're not, and those of us who are really experienced programmers don't bother because there's both no money and a 100% guarantee that just releasing something will lead to drama of one sort or another.If you want this to be fixed, convince someone to write a book on how to do Shades of Doom. Hell, convince someone to write a book on how to do Space Invaders. There are no resources for anything, and that does include BGT and PB. I'm glad to see that the community is finally beginning to fumble its way into open source, and I'm hopeful that this will undo the years and years of failing to collaborate and living inside proprietary languages. I think it's also worth noting that while I for example could write a book on this stuff, I wouldn't use BGT for it for the simple fact that by the time you know enough to turn around and produce the resources we're lacking, you've probably outgrown BGT by miles anyway.I've started fumbling my way toward a game. But I'm doing it in spite of the community and because I'm frustrated that there's nothing I'd want to play these days and very little hope that anyone is going to do anything really complicated and quality anytime soon. A long time ago I thought the path was audiogames.net, but then I watched the rampant piracy, things like the thread in off topic where someone posts something that counts as malware and everyone gets busy debating whether that's bad, the code theft, the "but why isn't this free? I don't have $5 and it's morally wrong of you to want me to pay for it", apparently now even the "someone trans posts asking for help and we find out that audiogames.net is homophobic" thread which i really didn't expect. Don't get mad at developers for not being as helpful as you want, start realizing that as communities go, this community isn't really such a great one when you're asking yourself whether you want to pour man-months worth of effort into a project for what is effectively no money when compared with a professional programmer salary.@38If you mean what's wrong with making terminal games, nothing. If you mean what makes them hard to make from BGT, my understanding is that BGT can't write to the terminal out of the box and needs help with third party packages. URL: https://forum.audiogames.net/post/505907/#p505907 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt And yet, I still haven't understood what's the issue with terminal games. Could someone explain it to me? URL: https://forum.audiogames.net/post/505895/#p505895 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt The only way you can tell that kind of difference is if you're experiencing it all the time. Like, I can see being able to slightly tell the difference if that's the amount of audio lag you have, but even then it might not be noticeable. But loading a game, which you don't do all the time, it really doesn't matter. Be patient. URL: https://forum.audiogames.net/post/505888/#p505888 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt THe only way you can tell that kind of difference is if you're experiencing it all the time. Like, I can see being able to slightly tell the difference if that's the amount of audio lag you have, but even then it might not be noticeable. But loading a game, which you don't do all the time, it really doesn't matter. Be patient. URL: https://forum.audiogames.net/post/505888/#p505888 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt I think I'm going to have to side with 35 on this one; if you seriously can tell the difference, you're biohacked. You don't belong on this forum; you're clearly out of a straight up SciFi trhiller franchise... I dunno, the matrix? Resident Evil? URL: https://forum.audiogames.net/post/505866/#p505866 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt 33: Lol. No you can't tell the difference between that short of a time span. That's ridiculous. URL: https://forum.audiogames.net/post/505857/#p505857 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @32, understandable. There's always going to be workarounds though, or people wouldn't write about finding huge stacks of atari2600 games. Clearly they were valuable to someone. If that story doesn't inspire you a bit, try this one on for size. Why do we even bother to grab up roms of stuff that isn't sold anymore mainstream wise? Why do we keep emulators kicking around? The fact is that when something is truly valuable, someone somewhere's going to try and find a way to relive it to some degree or another. Need further proof? Ask this couple of gamers; I hope they're living it up good! URL: https://forum.audiogames.net/post/505852/#p505852 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt yeah, simpicity isn't a complaint for me. Also, FYI I can tell the different between 2 and 30 ms so. URL: https://forum.audiogames.net/post/505850/#p505850 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt I personally have no problem with extreme simplicity. In fact, I indorse it. Like you, Nocturnus, I couldn't code my way out of a cardboard box, but I would love to make games that people enjoy. My problem with BGT is continued compatibility. Call me a pessimist, but I see BGT not working with the latest version of Windows in 2030 given the rate at which it's updated. So many good games are just going to stop working entirely. Some of those games are open sourced so they could be rewritten in something more modern, but a good majority of games made in BGT are close sourced and way too big to be rewritten. I seriously doubt Aaron Baker is going to rewrite all his games in a modern programing language, and I wouldn't blame him if he didn't because there's no way he could do that alone given his busy schedule. Even if he could do it alone, it wouldn't be worth it because the hole process would just stress him out. That's my complaint with BGT. Not because it's simple, but because it's aging. URL: https://forum.audiogames.net/post/505839/#p505839 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt Best post in this whole freaking topic? 27. Thirty's not far behind, either. Thumbs up. The rest of you hurt my head. You know what's worse than not knowing how to program? Not knowing how to program but still being able to tell that there's a bunch of wanabes spewing forth spurious nonsensical dribble akin to abstract philosophical junk so verbose it's less important than dehydrated toejam.Have you ever stopped to read half the stuff you guys write out here? Post 27 was perhaps the most cohesive and coherent thing I've read in this particular room. It was well organized, thought out, inclusive to anyone who should chance upon it and was written with no need to jump into massive amounts of complexity just to convey a point, with a bit of jokularity thrown in on the side!I stress again, I'm no programmer. What I say you can probably go ahead and roast and toast with minimal effort if you're able to pull a line of code out of your textbooks for that particular purpose. You'll code me away in any and every language! PERIOD! What I am good at, is understanding what I do know versus what I don't know. I can tell you that I'll more than likely remember the information in post 17 if anyone should chance to ask me how on earth to develop a simple hello world program. What I fail to understand is the why, and that's what I feel so many of you out here don't focus on.I just read a post out here that suggest you shouldn't focus on performance over productivity and that for that reason you should shye away from more complex languages. Said poster also believes you shouldn't stick to something like BGT because performance over productivity, arguing that simplicity here gives the user less control and thus hinders productivity. Do you know why that doesn't make any sense? People are looking for something simple to program in so as to minimize the amount of work that has to go into the product and focus on the product itself! What does that actually mean? Almost everyone out here who is out here is out here because they want games and a quick way to produce them!I'm a lot of things, musician included. I understand that computer programming, much like many other things in this world, is an art. When I was advised by hackers to go play chess, learn a martial art, write a journal, cook a few different things, involve myself in friendly debates, yada yada yada, I began to understand one thing concretely. You don't program overnight. NO! Not, really! Programming involves so many more steps than just surface knowledge! I could probably read all of Dardar's tutorials and not learn how to program efficiently in python because I'm still not equipped with about a hundred other things and a checklist with which to organize them.Patience, problem solving skills and a willingness to persevere until one has the right answer and not just a mixup of good or bad answers, blocking against boredom, loss of curiosity, inability to recognize errors because one does not pay attention to careful details... I could go on and on, but the fact is that no matter how much more I throw in, that this is how art works. It does not exist like some sort of materialistic box with fancy things inside you can just pull out and smash together and call a soup, anymore than you could call it an orchestral piece worth listening to. I see posts in here and on other topics in this room where people throw out numbers, lines of code and phrases and other jargon they think everyone should just, flat out understand, then wield a whip of condescension they're ready and willing to use at a moment's notice when they feel they can on someone who they know or rightly guess is weaker than them in an area rather than picking them up.In short, many of you in here are quick to dismiss BGT as a possible solution that minimizes the problem of performance over productivity while chiding those who use it because they would rather be developing games rather than trying to figure out how those games work. If you're going to make blanket statements like that, either teach those you deem your oponents how to code efficiently by showing them why code works the way it works and the logic behind it, or admit to yourself and to them that you probably don't know as much as you think you do, rather than just telling them it works that way and if they don't understand it they need to pack it up and go to blazes! This seriously is one room I wouldn't recommend to anyone who is trying to start out, as I've come across enough topics out here to showcase this elitist and toxic mindset of who's ideas are better and who's just don't fit the ticket, all for reasons that conflict with one another! You can tell me that it's universally acceptible to stop developing games in any language when games in said language are not being developed in said language and there are no people playing them! Until then? Post 27 is living proof
Re: the slowness of bgt
Re: the slowness of bgt @28I was actually the one that made the CP server CLI, and for that matter gave BGT the ability to read from and write to stdout/stderr. Boredom called, and we were considering the many different ways one might run a BGT server under both windows and wine with minimal blood loss. My first idea was to use a virtual frame buffer to swallow runtimes, but that wouldn't be as seamless as I would like. Thus other solutions were explored.Anyway, it comes down to some winapi console functions, look for WriteConsoleA and ReadConsoleA. If I remember correctly, you'll then need to compile your program and switch the value located in the optional header's subsystem field from windows GUI to windows character. Write it out and you should be presented with a console.@29Most definitely in the case of modern languages, though in my post I was referring to BGT. In other languages I'd let a thread pool do the work for me. URL: https://forum.audiogames.net/post/505784/#p505784 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @28I was actually the one that made the CP server CLI, and for that matter gave BGT the ability to read from and write to stdout/stderr. Bordom called, and we were considering the many different ways one might run a BGT server under both windows and wine with minimal blood loss. My first idea was to use a virtual frame buffer to swallow runtimes, but that wouldn't be as seamless as I would like. Thus other solutions were explored.Anyway, it comes down to some winapi console functions, look for WriteConsoleA and ReadConsoleA. If I remember correctly, you'll then need to compile your program and switch the value located in the optional header's subsystem field from windows GUI to windows character. Write it out and you should be presented with a console.@29Most definitely in the case of modern languages, though in my post I was referring to BGT. In other languages I'd let a thread pool do the work for me. URL: https://forum.audiogames.net/post/505784/#p505784 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @20All fair points and accurate, but this discussion was about games, though I guess it isn't now. But I was addressing it from that perspective.I will say though that while you're right that people won't need to i.e. use variadic parameter packs, things like the rule of 3 and the rule of 5 (which I have to look up myself when I head in that direction) and the gotchas around virtual vs non-virtual base classes are pretty bad, just to provide some examples. I think that anyone who is still in BGT all the time, or who is debating between BGT and PB, is probably not quite ready for the levels of insanity even basic C++ has to offer. Even if you know you should only learn a subset, there's still no particularly good way to figure out what that subset should be.There's a very nice subset of C++ post 2011 and now post 2020, where a lot of the problems are getting solved, and I can even go so far as to say that I find some of it very pleasant to use; but you still have to know about the other stuff fairly quickly. There's just too much surface area. I can't in good conscience tell people to use it if they're still learning to program in the slightest,.It's very catch 22. You can either use C, which has so little abstraction that it's hard to do anything safely, or C++, which is C++.@27You can effectively make loading assets take 0 time with threads. I'm hoping that Synthizer will get to a point of being able to just do this behind the scenes as it's a little hard to get right, but we shall see. Sighted games take forever to load because of graphics-related stuff primarily. URL: https://forum.audiogames.net/post/505774/#p505774 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt Plenty of good things were in the cmd. TTCom. The crazy party server, all though I don't know how pragma pulled off a terminal bgt script. Yes, Rorys games were nothing impressive, in fact, mostly lacking of that, but everyone has to start somewhere. Especially when learning a new language. Rory had quite a few bgt games, witch were nothing great either but they did have classes, used the soundpool, maps, etc. So rory isn't unwilling to learn. He's simply starting with a new language. When I moved from python to go, I didn't start making games right away, and I still haven't, but I'm trying to get better with the language. URL: https://forum.audiogames.net/post/505759/#p505759 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt
Why not just own it?Yes, I used to develop games that ran in the console. At least I took the time to create and present something to the public, quite a big hurtle for some.No shame in making text-based projects as long as they're balanced. Gameplay is gameplay, regardless of whether it happens to require textual input, the arrow keys, a gyroscope or your dog. I had a lot of fun with titles such as run for president and destination mars, timeless classics that have subpar work in the sound department.Plus, everyone starts somewhere. It doesn't really matter, as long as you're learning and enjoying yourself in the process. Anyone who acts as if their introduction to programming was picking up a compiler one sunny day and hopping into the magnificent world of game development is clearly suffering from a loose screw or two. For the record Ivan was not doing this.I'd call that far preferable to the "well you have no right to talk because you aren't any better", tu quoque response that usually signals the abrupt halt or outright death of productive conversation.Back to the original topic. I'm in full agreement with Camlorn's main point, performance in this context doesn't really matter unless it's something your users begin to notice.I used the following script to time and load a 4.2KB step.oggvoid main() {
int time;
sound step;
timer t;
step.load("step.ogg");
time = t.elapsed;
alert("time", "The sound took "+time+" MS to load");
}Replacing "step.ogg" with differently sized and encoded files resulted in what I would come to expect... Ultimately nothing noticeable. Crazy party, for example, has somewhere nearing 1600 OGG encoded files. At that point you have a two/three second delay when opening the program. If this is a serious issue for you, it shouldn't be, but write a preload system that starts with the assets you need. Make a logo that can be skipped only when said assets can be used. If you think a second or two is bad, try loading up MK, or most any popular game on steam for that matter.
URL: https://forum.audiogames.net/post/505736/#p505736
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt
Why not just own it?Yes, I used to develop games that ran in the console. At least I took the time to create and present something to the public, quite a big hurtle for some.No shame in making text-based projects as long as they're balanced. Gameplay is gameplay, regardless of whether it happens to require textual input, the arrow keys, a gyroscope or your dog. I had a lot of fun with titles such as run for president and destination mars, timeless classics that have subpar work in the sound department.Plus, everyone starts somewhere. It doesn't really matter, as long as you're learning and enjoying yourself in the process. Anyone who acts as if their introduction to programming was picking up a compiler one sunny day and hopping into the magnificent world of game development is clearly suffering from a loose screw or two. For the record Ivan was not doing this.I'd call that far preferable to the "well you have no right to talk because you aren't any better", tu quoque response that usually signals the abrupt halt or outright death of productive conversation.Back to the original topic. I'm in full agreement with Camlorn's main point, performance in this context doesn't really matter unless it's something your users begin to notice.I used the following script to time and load a 4.2KB step.oggvoid main() {
int time;
sound step;
timer t;
step.load("step.ogg");
time = t.elapsed;
alert("time", "The sound took "+time+" MS to load");
}Replacing "step.ogg" with differently sized and encoded files resulted in what I would come to expect... Ultimately nothing noticeable. Crazy party, for example, has somewhere nearing 1600 ogg encoded files. At that point you have a two/three second delay when opening the program. If this is a serious issue for you, it shouldn't be, but write a preload system that starts with the assets you need. Make a logo that can be skipped only when said assets have loaded. If you think a second or two is bad, try most any popular game on steam.
URL: https://forum.audiogames.net/post/505736/#p505736
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt Yeah seriously Ivan. Rory's games may not be the most amazing titles out there, but as people have said before, you have no room to say anything. You know why? Because you release the same game all the time, just with a new paint job. At least Rory makes something different every time. Until you can either accept that and stop being a total jackass, you might want to reconsider saying anything more in this topic before you make yourself look even more stupid than you already look. URL: https://forum.audiogames.net/post/505658/#p505658 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt Post 11, you have no room to talk. Like, at all. You do realize that you contributed to a large amount of drama on this forum, right? So what if the OP is not making the next block buster. So what if his games were all in the terminal up til now. Should he improve? Of course! Will he if you continue to badger him pretty much any time he tries to post? I doubt it.Would you like everyone else to slander you every time you try and provide assistance or give input? Trust me, we can. You provided enough ammunition at this point. Will we, though? No, because doing that will get us nowhere. I'm sure that all on here would agree with me when I say this: If you got nothing constructive to say, keep your mouth shut and continue scrolling past this page. Personally, I'm sick of seeing the same crap flying towards OP from your direction, and I'm sure others are, too. URL: https://forum.audiogames.net/post/505626/#p505626 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @ Rory: Hallelujah! Preach! Psych, no! It's just by 28, fricking, milliseconds. If you're going to judge by speed between the two languages, and you're unable to provide evidence, it's likely that you are the one causing the speed decrease due to bad structured code that makes the program take a little longer to discern it. So think, before using speed as an excuse to switch languages. URL: https://forum.audiogames.net/post/505602/#p505602 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
2020-03-02
Thread
AudioGames . net Forum — Developers room : Jaidon Of the Caribbean via Audiogames-reflector
Re: the slowness of bgt @Ethin, that hello world programme confused the shit out of me, but maybe if I took the time to sit down, apply myself, or listen to an audio tutorial, I'd probably grasp it.@Rory, why didn't you make a topic about the slowness of my metabolic system? ! Ivan, why must you continue with this terminal game childish, immature rubbish? At least Rory's games try to be different from each other. All your games pretty much resemble each other. At least the online ones, but one thing's for sure. Your development process is always the same. URL: https://forum.audiogames.net/post/505512/#p505512 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt To further step away from the ever-blooming BGT yes or no discussions:Whenever you blow out random numbers into the world and compare them to other random numbers, scientists will laugh at you and don't take you for granted at all. Try supporting them with the code you used to measure the speed comparison you mentioned and things will look different. In most cases, the real speed penalty is the programmer in front of the screen, and its very likely that some of rather high latency results from inefficient code rather than the compiler/language used. That said, it might also be the case that the code under the AngelScript engine might be the problem here, but we cannot know without a single line of code. For now, those numbers are just a shot in the dark, at least in my eyes. URL: https://forum.audiogames.net/post/505499/#p505499 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt oh for god sake @11, give it a bloody rest! I've already said time and time again that I've moved away from terminal games! What's your big deal! URL: https://forum.audiogames.net/post/505490/#p505490 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt camlorn wrote:@18I don't know that I agree that productivity is highly subjective, no. There are a number of objective measures that you could use for it and there are people who spend a lot of time researching it, but it's not my area of expertise so i can't quote studies or anything offhand at the moment.Fair enough. I can probably find those on my own though.Camlorn wrote:However, please provide a non-theoretical example of where the control you keep mentioning matters for an audiogame? Have you done a practical, completed project that could only be done in C/C++? Has someone actually hit some sort of issue where only C/C++ and the headaches of manual memory management can solve it?Crypto, for one. OS development, for another. Plus, I wasn't just talking about audiogames either; I was talking about programming in general. I guarantee you that most of the people who write audio games in Python will be using Python for various other projects. That's fine, but I don't think anyone should restrict themselves to a single language like Python. C/C++ is generally a good language to know anyway.Camlorn wrote:If I was going to put forward an objective measure of productivity, I would propose that more productive methods of software engineering are those which allow the programmer to think about less things. C/C++ adds a hell of a lot to think about. If you don't need what C/C++ offers, then you're probably losing quite a bit of time by having chosen to try to use it. Even some high-frequency stock traders, the kind who rent computers near the stock exchanges because of the speed of light, use other tools.This is a very fair point. I personally don't agree with many of the decisions regarding either language, such as layering on compatibility layer after compatibility layer, standard after standard, and not removing dated stuff, for both compilers and the language itself. Do I think that C++ is an absolute mess? Yep, certainly do. However, I respect the language for what it has brought into the world, and will continue to use it because while it may be a mess, its also a very practical language. Most of the really obscure features are used only in very unique circumstances, so a learner of the language doesn't need to learn those. Memory management is something I think everyone should learn, because if you don't then your stuck in a world where you think that everything regarding memory is handled automatically for you. The problem with that assumption is in areas like security, you must manage memory yourself; the GC (or whatever mechanism your using to clean up memory that's automatic in nature) shouldn't be trusted because you have no idea when it'll run. That's one reason I've always been wary of cryptography in Python. Rust alleviates the headaches of memory management a bit, though you can still drop down and allocate memory yourself if you so desire. Plus, manual memory management is a good way of saving memory usage (yes, I know that we have computers with GB or even TB of memory, but that doesn't mean you should just allocate willy-nilly). Irrespective of how much memory you have, its always to be conservative. That is definitely something OS development has blasted into my head, and its something I'm happy to use.Camlorn wrote:I've watched you follow my trajectory for a long time and, like me in the C/C++ is amazing phase that I went through in 2014 or so, I doubt anything I can say will convince you right now. But I'd honestly put money on you making a high-paying career around it over the next few years, then being yet another voice on the internet trying to explain to people how they really shouldn't be trying to use it unless they really need it for their project.Nope, I went through that a year or so, if not earlier, ago. I'm now in the "Rust is awesome phase" but am realistic enough to know that I can't do everything I'd like in Rust, and when that happens I turn to languages like Go, D, or C/C++. Sometimes I'll go with Python, and Python works amazingly well, but I'm not going to make every project in Python. For me, some projects I make are learning opportunities I'd like to dive into, and for that I might use C/C++ or Rust to see how things work and what happens. I get what your saying, and I'm definitely not going to use C/C++ for everything; I do prefer the safety Rust offers. URL: https://forum.audiogames.net/post/505467/#p505467 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt camlorn wrote:@18I don't know that I agree that productivity is highly subjective, no. There are a number of objective measures that you could use for it and there are people who spend a lot of time researching it, but it's not my area of expertise so i can't quote studies or anything offhand at the moment.Fair enough. I can probably find those on my own though.Camlorn wrote:However, please provide a non-theoretical example of where the control you keep mentioning matters for an audiogame? Have you done a practical, completed project that could only be done in C/C++? Has someone actually hit some sort of issue where only C/C++ and the headaches of manual memory management can solve it?Crypto, for one. OS development, for another. Plus, I wasn't just talking about audiogames either; I was talking about programming in general. I guarantee you that most of the people who write audio games in Python will be using Python for various other projects. That's fine, but I don't think anyone should restrict themselves to a single language like Python. C/C++ is generally a good language to know anyway.Camlorn wrote:If I was going to put forward an objective measure of productivity, I would propose that more productive methods of software engineering are those which allow the programmer to think about less things. C/C++ adds a hell of a lot to think about. If you don't need what C/C++ offers, then you're probably losing quite a bit of time by having chosen to try to use it. Even some high-frequency stock traders, the kind who rent computers near the stock exchanges because of the speed of light, use other tools.This is a very fair point. I personally don't agree with many of the decisions regarding either language, such as layering on compatibility layer after compatibility layer, standard after standard, and not removing dated stuff, for both compilers and the language itself. Do I think that C++ is an absolute mess? Yep, certainly do. However, I respect the language for what it has brought into the world, and will continue to use it because while it may be a mess, its also a very practical language. Most of the really confusing/obscure features of the language -- for example, most vexing parse, alternate operator tokens, keyword redefinition, placement new, bitfields, etc. -- are used only in very unique circumstances, so a learner of the language doesn't need to learn those. Memory management is something I think everyone should learn, because if you don't then your stuck in a world where you think that everything regarding memory is handled automatically for you. The problem with that assumption is in areas like security, you must manage memory yourself; the GC (or whatever mechanism your using to clean up memory that's automatic in nature) shouldn't be trusted because you have no idea when it'll run. That's one reason I've always been wary of cryptography in Python. Rust alleviates the headaches of memory management a bit, though you can still drop down and allocate memory yourself if you so desire. Plus, manual memory management is a good way of saving memory usage (yes, I know that we have computers with GB or even TB of memory, but that doesn't mean you should just allocate willy-nilly). Irrespective of how much memory you have, its always to be conservative. That is definitely something OS development has blasted into my head, and its something I'm happy to use.Camlorn wrote:I've watched you follow my trajectory for a long time and, like me in the C/C++ is amazing phase that I went through in 2014 or so, I doubt anything I can say will convince you right now. But I'd honestly put money on you making a high-paying career around it over the next few years, then being yet another voice on the internet trying to explain to people how they really shouldn't be trying to use it unless they really need it for their project.Nope, I went through that a year or so, if not earlier, ago. I'm now in the "Rust is awesome phase" but am realistic enough to know that I can't do everything I'd like in Rust, and when that happens I turn to languages like Go, D, or C/C++. Sometimes I'll go with Python, and Python works amazingly well, but I'm not going to make every project in Python. For me, some projects I make are learning opportunities I'd like to dive into, and for that I might use C/C++ or Rust to see how things work and what happens. I get what your saying, and I'm definitely not going to use C/C++ for everything; I do prefer the safety Rust offers. URL: https://forum.audiogames.net/post/505467/#p505467 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt camlorn wrote:@18I don't know that I agree that productivity is highly subjective, no. There are a number of objective measures that you could use for it and there are people who spend a lot of time researching it, but it's not my area of expertise so i can't quote studies or anything offhand at the moment.Fair enough. I can probably find those on my own though.Camlorn wrote:However, please provide a non-theoretical example of where the control you keep mentioning matters for an audiogame? Have you done a practical, completed project that could only be done in C/C++? Has someone actually hit some sort of issue where only C/C++ and the headaches of manual memory management can solve it?Crypto, for one. OS development, for another. Plus, I wasn't just talking about audiogames either; I was talking about programming in general. I guarantee you that most of the people who write audio games in Python will be using Python for various other projects. That's fine, but I don't think anyone should restrict themselves to a single language like Python. C/C++ is generally a good language to know anyway.Camlorn wrote:If I was going to put forward an objective measure of productivity, I would propose that more productive methods of software engineering are those which allow the programmer to think about less things. C/C++ adds a hell of a lot to think about. If you don't need what C/C++ offers, then you're probably losing quite a bit of time by having chosen to try to use it. Even some high-frequency stock traders, the kind who rent computers near the stock exchanges because of the speed of light, use other tools.This is a very fair point. I personally don't agree with many of the decisions regarding either language, such as layering on compatibility layer after compatibility layer, standard after standard, and not removing dated stuff, for both compilers and the language itself. Do I think that C++ is an absolute mess? Yep, certainly do. However, I respect the language for what it has brought into the world, and will continue to use it because while it may be a mess, its also a very practical language. Most of the really confusing/obscure features of the language -- for example, most vexing parse, alternate operator tokens, keyword redefinition, placement new, bitfields, etc. -- are used only in very unique circumstances, so a learner of the language doesn't need to learn those. Memory management is something I think everyone should learn, because if you don't then your stuck in a world where you think that everything regarding memory is handled automatically for you. The problem with that assumption is in areas like security, you must manage memory yourself; the GC (or whatever mechanism your using to clean up memory that's automatic in nature) shouldn't be trusted because you have no idea when it'll run. That's one reason I've always been wary of cryptography in Python. Rust alleviates the headaches of memory management a bit, though you can still drop down and allocate memory yourself if you so desire. Plus, manual memory management is a good way of saving memory usage (yes, I know that we have computers with GB or even TB of memory, but that doesn't mean you should just allocate willy-nilly).Camlorn wrote:I've watched you follow my trajectory for a long time and, like me in the C/C++ is amazing phase that I went through in 2014 or so, I doubt anything I can say will convince you right now. But I'd honestly put money on you making a high-paying career around it over the next few years, then being yet another voice on the internet trying to explain to people how they really shouldn't be trying to use it unless they really need it for their project.Nope, I went through that a year or so, if not earlier, ago. I'm now in the "Rust is awesome phase" but am realistic enough to know that I can't do everything I'd like in Rust, and when that happens I turn to languages like Go, D, or C/C++. Sometimes I'll go with Python, and Python works amazingly well, but I'm not going to make every project in Python. For me, some projects I make are learning opportunities I'd like to dive into, and for that I might use C/C++ or Rust to see how things work and what happens. I get what your saying, and I'm definitely not going to use C/C++ for everything; I do prefer the safety Rust offers. URL: https://forum.audiogames.net/post/505467/#p505467 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @18I don't know that I agree that productivity is highly subjective, no. There are a number of objective measures that you could use for it and there are people who spend a lot of time researching it, but it's not my area of expertise so i can't quote studies or anything offhand at the moment.However, please provide a non-theoretical example of where the control you keep mentioning matters for an audiogame? Have you done a practical, completed project that could only be done in C/C++? Has someone actually hit some sort of issue where only C/C++ and the headaches of manual memory management can solve it?If I was going to put forward an objective measure of productivity, I would propose that more productive methods of software engineering are those which allow the programmer to think about less things. C/C++ adds a hell of a lot to think about. If you don't need what C/C++ offers, then you're probably losing quite a bit of time by having chosen to try to use it. Even some high-frequency stock traders, the kind who rent computers near the stock exchanges because of the speed of light, use other tools.I've watched you follow my trajectory for a long time and, like me in the C/C++ is amazing phase that I went through in 2014 or so, I doubt anything I can say will convince you right now. But I'd honestly put money on you making a high-paying career around it over the next few years, then being yet another voice on the internet trying to explain to people how they really shouldn't be trying to use it unless they really need it for their project. URL: https://forum.audiogames.net/post/505464/#p505464 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt
@17, nope. This is hello world in C:#include
int main() {
printf("Hello world!\n");
return 0;
}And this is the same result in C++:#include
int main() {
std::cout << "Hello world!" << std::endl;
return 0;
}You can also write the exact same C code as above in C++ too. You just might run into some problems (e.g. youcan't name a variable "namespace", "class", etc.) though the same applies to C. Or you can do this too:// Call printf the "C++" way
#include
int main() {
std::printf("Hello world!\n");
return 0;
}You should really check out RosettaCodes categories for C and C++ if you want to see how to do various things in C/C++. You can alternatively check out their tasks and draft tasks.@16, I disagree with one part of your post. You say that "There is some enjoyment in using it but again productivity vs performance." While I agree that you should focus more on productivity than performance, you can steadily and happily achieve both in both languages. I prefer not only to have productivity and performance in my code, but I also prefer the control as well. You just can't get as much control in Python as you can in C/C++. This isn't to say I'm power-hungry, per see; I just prefer the lower-level languages whenever possible because I personally feel more productive in those languages. Python certainly is fun to write in though sometimes. Plus, isn't productivity highly subjective?
URL: https://forum.audiogames.net/post/505441/#p505441
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt
@17, nope. This is hello world in C:#include
int main() {
printf("Hello world!\n");
return 0;
}And this is the same result in C++:#include
int main() {
std::cout << "Hello world!" << std::endl;
return 0;
}You can also write the exact same C code as above in C++ too. You just might run into some problems (e.g. youcan't name a variable "namespace", "class", etc.) though the same applies to C. Or you can do this too:// Call printf the "C++" way
#include
int main() {
std::printf("Hello world!\n");
return 0;
}You should really check out RosettaCodes categories for C and C++ if you want to see how to do various things in C/C++. You can alternatively check out their tasks and draft tasks.@16, I disagree with one part of your post. You say that "There is some enjoyment in using it but again productivity vs performance." While I agree that you should focus more on productivity than performance, you can steadily and happily achieve both in both languages. I prefer not only to have productivity and performance in my code, but I also prefer the control as well. You just can't get as much control in Python as you can in C/C++. This isn't to say I'm power-hungry, per see; I just prefer the lower-level languages whenever possible because I personally feel more productive in those languages. Python certainly is fun to write in though sometimes. Plus, isn't productivity highly subjective? Who's to say someone can't feel productive in, say, assembly language? I know many OS developers who enjoy writing assembly language on a forum I frequent. I even know a member of that same forum who (still) writes code in machine language because higher-level languages feel too abstract for them.Of course, I'll acknowledge that some languages, like BGT, are just ones you should avoid. Some languages are old, dead or dated, and its just not worth working in them because though you may feel productive, your code has a medium to high risk of failing to work.
URL: https://forum.audiogames.net/post/505441/#p505441
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt
@17, nope. This is hello world in C:#include
int main() {
printf("Hello world!\n");
return 0;
}And this is the same result in C++:#include
int main() {
std::cout << "Hello world!" << std::endl;
return 0;
}You can also write the exact same C code as above in C++ too. You just might run into some problems (e.g. youcan't name a variable "namespace", "class", etc.) though the same applies to C. Or you can do this too:// Call printf the "C++" way
#include
int main() {
std::printf("Hello world!\n");
return 0;
}You should really check out RosettaCodes categories for C and C++ if you want to see how to do various things in C/C++. You can alternatively check out their tasks and draft tasks.@16, I disagree with one part of your post. You say that "There is some enjoyment in using it but again productivity vs performance." While I agree that you should focus more on productivity than performance, you can steadily and happily achieve both in both languages. I prefer not only to have productivity and performance in my code, but I also prefer the control as well. You just can't get as much control in Python as you can in C/C++. This isn't to say I'm power-hungry, per see; I just prefer the lower-level languages whenever possible because I personally feel more productive in those languages. Python certainly is fun to write in though sometimes. Plus, isn't productivity highly subjective? Who's to say someone can't feel productive in, say, assembly language? I know many OS developers who enjoy writing assembly language on a forum I frequent. I even know a member of that same forum who (still) writes code in machine language because higher-level languages feel too abstract for them.
URL: https://forum.audiogames.net/post/505441/#p505441
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt
@17, nope. This is hello world in C:#include
int main() {
printf("Hello world!\n");
return 0;
}And this is the same result in C++:#include
int main() {
std::cout << "Hello world!" << std::endl;
return 0;
}You can also write the exact same C code as above in C++ too. You just might run into some problems (e.g. youcan't name a variable "namespace", "class", etc.) though the same applies to C. Or you can do this too:// Call printf the "C++" way
#include
int main() {
std::printf("Hello world!\n");
return 0;
}You should really check out RosettaCodes categories for C ad C++ if you want to see how to do various things in C/C++. You can alternatively check out their tasks and draft tasks.@16, I disagree with one part of your post. You say that "There is some enjoyment in using it but again productivity vs performance." While I agree that you should focus more on productivity than performance, you can steadily and happily achieve both in both languages. I prefer not only to have productivity and performance in my code, but I also prefer the control as well. You just can't get as much control in Python as you can C/C++. This isn't to say I'm power-hungry, per see; I just prefer the lower-level languages whenever possible because I personally pefer more productivein those languages. Python certainly is fun to write in though sometimes. Plus, isn't productivity highly subjective?
URL: https://forum.audiogames.net/post/505441/#p505441
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
2020-03-01
Thread
AudioGames . net Forum — Developers room : mechaSkyGuardian via Audiogames-reflector
Re: the slowness of bgt If I could understand the language of C++ I would actually try working in it. But even a simple hello world program takes a lot to make URL: https://forum.audiogames.net/post/505418/#p505418 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @15I shy away from C/C++. There is some enjoyment in using it but again productivity vs performance. But if you're going to use PB you might as well save yourself the $90, learn how to install SDL and one of the screen reader speech wrappers, and skip the PB phase. URL: https://forum.audiogames.net/post/505409/#p505409 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @14, true that. Not really sure why so many people on here shy away from C/C++. I, myself, really enjoy working in it. Add Rust to that list and I'm golden. URL: https://forum.audiogames.net/post/505408/#p505408 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt Moving from one commercial but abandoned product to another commercial but as of yet not abandoned product just punts the problem down the road.If you are paying for your programming language and aren't in some very specialized domain like custom microcontrollers, you're being ripped off.Also PureBasic *is* C with different syntax. If you want to play with raw pointers, deal with segfaults, and not have a garbage collector, you can just go use C with SDL. It's free and you can at least get help with StackOverflow when things inevitably break because you chose something fast at the cost of programmer productivity.It's probably already clear by now from other posts I've made since returning, but half the community's focus is on performance, and that's very annoying. Your productivity, not performance, is what gets projects finished. If you're in the position of having a finished project that you need to make faster somehow, that's a good problem to have; by contrast, a fast but unfinished project is pointless. URL: https://forum.audiogames.net/post/505395/#p505395 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt @11 I mean, pragma did it. URL: https://forum.audiogames.net/post/505352/#p505352 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt I'm gonna give my opinion on BGT now since this is what the topic is about. If you guys are willing to sacrifice support for other platforms as well as future versions of Windows when BGT finally kicks the bucket, and if you're also prepared to accept the fact that for the short amount of time you'll be using BGT every single program you make from here on out will be flagged by every antivirus on the net for being malicious, then go right ahead and keep using BGT. Oh, and before anyone comes on here and tells me they don't care about my opinion like you did with Rory, you may as well save your energy because I really don't care what you think either. URL: https://forum.audiogames.net/post/505350/#p505350 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt Someone will have to show us how to write console games in bgt so we can make better games than OP.Oh wait a sec...you can make console apps in python! Don't use BGT everyone, because python can output to the terminal so we can have terminal based games!Oh wait... no one cares.Continue to use bgt... URL: https://forum.audiogames.net/post/505329/#p505329 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt Someone will have to show us how to write console games in bgt so we can make better games than OP.Oh wait a sec...you can make console apps in python! Don't use BGT everyone, because python can output to the terminal so we can have termminal based gakmes!Oh wait... no one cares.Continue to use bgt... URL: https://forum.audiogames.net/post/505329/#p505329 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt Please someone enlighten me to as why this topic exists? Cool, you figured something out. Do we care? Most people, probably don't. It's like 28 ms. Now if we were doing speed of something like ruby or python to something like c or c++, that would be a big difference, and maybe, maybe something worth posting a topic about. Note the maybe there. We know some languages are faster than others. And I guess, you do now too? URL: https://forum.audiogames.net/post/505310/#p505310 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt I am not going to leave bgt, if you dont like it, just stop useing it and keap your observations for your self, peaple hoo will stik to bgt will just ignore your topick, pointless... URL: https://forum.audiogames.net/post/505274/#p505274 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt I am not going to leave bgt, iff you dont like it, just stop useing it and keap your observations for your self, peaple hoo will stik to bgt will just ignore your topick, pointless... URL: https://forum.audiogames.net/post/505274/#p505274 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt I mean, people in glass houses shouldn't throw stones. When switching away from BGT for the reasoning that most people here do, I probably wouldn't choose PB as my replacement language for several reasons. It's still not really what I'd consider a mainstream language, because the language itself is commercial and it's basically BGT with a more generalized feature set. Every language is useful for different things to different people including BGT and PB, but honestly we already have enough reasoning not to use BGT, and so those that stick with it won't be swayed by this random observation. URL: https://forum.audiogames.net/post/505221/#p505221 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt I really don't know what the point of this topic is other than to shit on people who use a certain scripting engine.Oh guys don't use BGT I use PB it's much much much much better so fuck man don't code any games in bgt!Haha! URL: https://forum.audiogames.net/post/505207/#p505207 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
2020-02-29
Thread
AudioGames . net Forum — Developers room : manamon_player via Audiogames-reflector
Re: the slowness of bgt just for 28 ms? URL: https://forum.audiogames.net/post/505197/#p505197 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt The question is, do I care? When I worked with the language, it was fast enough to meet my needs. Just because other languages may be faster does not necessarily make my choice bad. If you are going to convince us not to use something, speed should be your last argument. After all, can I tell the difference between 2 and 30 ms? URL: https://forum.audiogames.net/post/505194/#p505194 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt 2ms vs 30ms is within the margin of error for anything doing disk I/O. Purebasic is faster in the general case because it's basically C, but the above benchmark isn't useful and may actually come out with BGT as the winner if ran properly.There are something like 4 or 5 levels between you and the disk. As one concrete example, one of these is the page cache, which uses supposedly unused ram to keep files loaded in memory in case another program tries to read them after, which means that it matters which program ran first.There are also something like 4 or 5 kinds of timers provided by the operating system, some of which can't even give values at a resolution higher than 1MS and which make basically no guarantees to accuracy, up to give me the literal number of clock cycles this took.I could go on for a while, but if you're timing anything more complicated than a math loop you need an absurd amount of control over the environment, and if you're timing a math loop some compilers will just go "hey, the result of this is never used, so let's not do the work" and then it'll take 0ms or some other value way less than it should because it's not doing work you think it's doing. That said I don't think either BGT or Purebasic is complicated enough to be doing that level of optimization, but C++ and anything that uses LLVM internally certainly does.I also agree that the community shouldn't be using BGT--though in all honesty my criticisms also apply to PureBasic--but this isn't accurate without a lot of specialized methodology or a whole lot bigger of a difference in the numbers. URL: https://forum.audiogames.net/post/505178/#p505178 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt 2ms is much faster though URL: https://forum.audiogames.net/post/505175/#p505175 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: the slowness of bgt
Re: the slowness of bgt 30 MS really isn't that slow. I agree though; I don't really think things should continue to be developed in BGT. That's not to say I won't still play said games; I just don't think BGT should continue to be used regularly. URL: https://forum.audiogames.net/post/505172/#p505172 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
the slowness of bgt
the slowness of bgt I just realized how slow it is! it does stuff so slow, I couldn't believe it. I can perform loops in , say, pure basic, that I would never dream of doing in bgt. It loads stuff slow, it handles stuff slow, it's just, slow. don't use it! trust me! check out another language and you'll see exactly what I mean.Pure basic: *loads step sound in 2 ms*bgt: *loads step sound in like 20-30ms* URL: https://forum.audiogames.net/post/505171/#p505171 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
