>BTW, c# is also a virtual-machine language, so it is times slower than native C/C++. No, it's not actually. it's compiled down to MSIL, (if I remember correctly), which gets put through JIT.
On 1/12/2011 11:22 AM, Lex wrote:
12.01.2011 19:55, Littlefield, Tyler пишет:first, though python is nice and amazing and all, high-end 3-d/sound intensive games will not be written in it; the language for that is c/c++ or c#.While I agree that C/C++ is the language for the core stuff (like collisions/physics/object movement etc), I don't agree that python is not fast enough to serve game logic. Many games use it (Eve Online mmorpg,, Battle Field 2, Freedom Force - to name few of them). Remember also, that audio game is mutch cheaper in CPU resources to waste, because you needn't compute all that skeletal animation, dynamic lighting, rag dolling, realistic physics (audio game requires little of it) polygon visibility checks etc. BTW, c# is also a virtual-machine language, so it is times slower than native C/C++.This is because Python is a lot slower than all three of these, where you need to squeeze in 60 frames per second.You needn't run 60 fps for audio game. 20-25 times a second is more than enough for audio. 60 FPS is required to draw all that fancy effects, calculate particles and so on.So while Python may be really nice for small games (such as your pingpong project), it is not-so-nice for games that are running at 60 frames a second, and must render and do all of their updating within that set time.My point is that python is also nice when you do your heavy calculations in C++, and let the python to do the rest, which is proved by real projects I wrote about above.Now, on a similar note, you mentioned directX or openAl. I will let you know that this will be a pain, and suggest a way to solve the problem. First, you will want to write a sound class, which the user and the rest of the engine can use as an API. This class will be for wrapping everhting up, if you go this route. So you will check the platform, if it is Linux, you will use openAl in your functions, if not, DX. In c/c++ this can be done with a simple #ifdef ... #else ... #endif, but I will warn you, the code does and will get messy doing that. IIRC, OpenAl is cross-platform, so you may just want to make an API around that that will be called from within your engine.If one wants to support different sound APIs by whatever reason, Simpler way is to make an abstract base class (interface) for all engine code to use, and implement subclasses for each supported APIs. Then make a factory function which checks OS/config file/whatever you want and returns an appropriate real object matching sound system interface. Sorry if I explained the concept badly, English isn't my mother language.Lex __________View the list's information and change your settings at //www.freelists.org/list/programmingblind
-- Thanks, Ty __________View the list's information and change your settings at //www.freelists.org/list/programmingblind
