Re: About C#. Keys
OK... I'll happily respond to you one by one:
@jonikster, I condemn you, as you put it, because you have shown yourself incapable of making your own decisions and deciding what you will use for quite literally anything. Even now, such a behavioral pattern continues, and after the twentieth topic you posted that asked the same thing as your previous nineteen, that incapability only further cemented itself in my mind. You refuse to do your own research, refuse to try libraries that I have recommended, refuse to try libraries that programmers who have programmed far longer than I have have recommended... right now most of them have given up. And I lose hope every day that you will actually learn what we've told you because this pattern continues. It doesn't help that you listen to people like Rastislav Kiss, who have shown themselves to exhibit similar behavioral patterns to your own, with the only difference being that Rastislav Kiss is extremely stubborn and always considers himself to be right, while never considering another programmers point of view unless that programmer agrees with him on a part of a previous statement he's made. It doesn't help that, of course, he gives you misinformation.
@Rastislav Kiss: OK, Eurofly uses a GUI loop... not cool. If using a GUI loop is so wonderful and nice, then why doesn't every video game use one? Hmm?
As one of the major contributors to dMNB and DMPA's source code, I can tell you that nowhere did we use a GUI event loop anywhere. Nowhere! Like I said in post nine, you don't use a full GUI event loop in a game alongside a game event loop -- it will only result in frustration. I have been programming since I was thirteen, a time of 6 years or so, and in every game I've helped make and in every prototype I've worked with, I have never seen a full GUI event loop employed in a game unless strictly required. And that strict requirement was only employed under particularly controlled circumstances, and it usually resulted in the entire game halting while the GUI did its own processing, only resuming after the GUI event loop had terminated. You, as someone who clearly has never developed any game containing any form of graphical content (or someone who just doesn't know what their talking about), are in no position to give game development advice regarding matters such as this. As someone who has employed such technologies, however, I am in a perfect position to give such advice, while leaving a game that you make open to the possibility of 2D or 3D content later on, if you wish to add it. That is why I gave my advice in post nine. There is only one -- and only one -- GUI framework that I know of that makes it possible to solidly and safely combine GUI, OpenGL/Vulkan and 3D technologies. That is QT. and the only reason that works is because QT only has two types of event loops -- QCoreApplication and QApplication. It deliberately separates the two so that you can run a QCoreApplication in a full 3D video game for command-line parameter processing, for instance. And even then, that doesn't work very well. GUI frameworks are *not designed for* gaming. .Even if you were to post a question like this on Stack Overflow (something like, perhaps, "Is it a good idea to use a GUI event loop to make a game?" Or, "Is it safe to use an event GUI loop alongside a game event loop?" You'd get a similar response -- No, use your game frameworks GUI primitives, don't use a full GUI event loop, and if your framework doesn't provide one, make your own.)
@nuno69, true. Though I suppose AGK can be considered one... either way, just because there isn't an "audio game development kit" in languages like Python, C# or C++ doesn't mean you can't make an audio game using a video game framework (which is definitely a good idea).
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
