Re: About C#. Keys
WPF. In a game. Seriously? What kind of BS advice is that? When your playing a game you don't want full-on GUI event loops running. You want all of that integrated. If possible, you want the game framework to provide you the tools necessary to draw 2D or 3D GUIs, and you want the framework to allow you to intercept particular events to make those GUIs accessible. You never want to ever start another GUI loop alongside your games update loops. That will hold your update loops until the GUI terminates, which usually never happends until you want to exit a program. WPF was *not* designed to be used that way. No normal GUI system was designed to be used that way, and getting a game framework to meld with a GUI framework that wasn't specifically designed with gaming in mind is only going to give you headaches and rages because your code malfunctions.
@Rastislav Kiss, have you ever developed an actual audio game in C#? Clearly not. Here's some actual information that will aid people in developing C# audio game frameworks in any language:
* Either use events, signals and slots, or whatever you can to make your game as asynchronous as possible. Try to avoid callbacks; callbacks can get ugly, very, very fast. Then again, events, signals and such can also get ugly really fast, so be careful about nesting them and all that.
* Do not, under any circumstance, use a full GUI event loop in your game. Ever. Only do that before the main game loop takes over (i.e. a registration dialog before the game has even been initialized and such). Even then, try to meld that into the game itself. Avoid GUI loops if possible; they complicate things and can really fuck your project up. Modern game frameworks have replacements for GUI loops that are strictly designed to be rendered in a game.
* Don't try and divide your code into "windows" and such. That just won't work.
* Your game will always have a central method that's usually called 'update()' or something like that. That is your central "event loop", where all the magic happens. Branch out from there.
All of this goes for any game being developed in any programming language. Unlike some in this topic, there *are actually* game frameworks for C#. Guys, before you say that there is not something in a particular language, do your homework. A particular place to find game-related stuff are in locations like https://awesome.re, and its links. In particular, pay attention to the various back-end, front-end, and programming language sections of that page. And yes, I, unlike people like Rastislav Kiss, actually do know what I'm talking about regarding developing games in C# and C++; I've made prototypes using game frameworks, and have done a hell of a lot of research on this very topic. I have helped write games in C++ (and then aided in the rewriting of them in Python). I think my knowledge, and references, can be trusted. In C# you do have game frameworks; frameworks like MonoGame, CocosSharp, Duality, and others. In C++, you do, also, have frameworks; in particular, bs::framework, Acid, Allegro, SFML, SDL, and so on.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
