Re: frameworks to develop audiogames
C/C++ will outdo Purebasic for execution speed, simply because they benefit from over 30 years of research into optimizing compilers and at least a million dollars of invested money. Given the architecture of the modern microprocessor, C/C++ compilers will actually generate assembly that is faster than anything you can write yourself. Let me take this time to again remind everyone that execution speed is literally not a factor anymore, however.
Anything in C++ is going to be what you would classify as a setup nightmare. This is both a particular shortcoming of windows and not such an easy thing to do in the first place. Ironically, this is one thing that Linux typically makes very easy. Allegro and SFML are both on my "particularly bad" list, by which I mean that I couldn't ever get either to work in the first place (I've not touched Allegro in 5+ years).
I can say with a great deal of confidence that an object-orie
nted programming language with garbage collection is the fastest option. This argument has been had before, I'm not going to do it again here. Mostly because I've finally realized that unless you bother learning and developing a game in one, you won't ever believe me anyway. That is, the people who can be convinced don't need convincing. I'm just going to say that, if you Google it, you're going to find that most people share this viewpoint for projects where performance is not critical. performance is not critical for any Audiogame save perhaps MMOs, but I don't believe that it matters there (MMOs=intelligent architecture, not fast language. Fast language just shaves off a bit of the needed intelligence, and then you find that actually you needed that intelligent architecture and need to implement it in a language that makes you manually manage memory).
A full, complete Audiogame only using the Windows API
and DirectX would be around 5000-15000 lines. 500 of this would be reimplementation of the keyboard handling logic via any of several various methods, 1000 of this would be audio handling code possibly including a basic custom mixer, and the rest would be pretty standard game logic. The major contributions to code size here would actually be saving and loading resources (I'm assuming C/C++, so no easy serialization). Basic collision checks for a game that does not involve rotation and only uses boxes is about 30 lines. Basic collision checks for a game that does allow rotation and only uses boxes would be about 150 lines, assuming only the Windos API and DirectX plus the prerequisite knowledge of the mathematics. This code would include the needed matrix multiplication and formulation code, as well as the inverse computation (which is trivial because it's a rotation matrix). the biggest challenge to such an undertaking is twofold: the Wi
ndows API is huge, and the languages in which it might be reasonable to place this limitation upon oneself require that your code spend a ton of time error checking (no exceptions or logging, so if(x == error) everywhere) and managing memory (it's not uncommon to free an allocated pointer at 3 or 4 different places in a function). A good example of a sighted game that comes close to doing this is Cube, which is 7 kloc as I recall. I'm not sure that that number includes Enet.
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
