Joined: Jun 2009
Posts: 452
|
Ok, so there's like ten million APIs for coding games. However, none of them are good enough.
The reason is this: When coding games, no system is isolated. Integration is essential. So, I present - my own perfect imaginary low-level game framework:
Some basic principles 1. In modules, so if you don't need Internet access, it wouldn't waste space 2. Although unrelated modules are independent, modules obviously can have dependencies. So, for instance, the Video and Image modules could depend on the Graphics module 3. The API would be object-oriented. It could be written in C, provided that bindings available for object-oriented languages are available. 4. The API must support at least the following file formats: BMP, PNG, WAV, OGG and OGV. Other formats can be supported, such as MIDI, MP3 and WEBM, but are optional. 5. Rendering to window, to control and to image(texture?) must be supported. 6. Cross-platform: WinAPI, WPF, Xlib, GTK+, Qt, Cocoa. 7. The audio API must have optional streaming(but also the option of loading all at once), playing(once or looping), pausing, resuming, stopping, fading in, fading out, mixing, volume control, ability to select only parts of the sound to be played, capacity of detecting how long the sound file is, panning, and - very important - seeking(both in streaming and non-streaming). SDL_Mixer has no streaming support in some cases. 8. The audio API would provide both 2D and 3D audio support. 9. The video API would also provide playing with optional looping, pausing, resuming, stopping, seeking, etc. 10. I haven't used shaders and audio post-effects in the past, but apparently they are important, so the API should provide first-class support for these. 11. Video and animated images should have first class support. 12. The API must be designed for extreme efficiency and speed, and take advantage of hardware acceleration if available.
So, a simple hello world in my perfect API(in C++):
#include <awesome-api/all>
using namespace awesome::Core; using namespace awesome::Graphics; using namespace awesome::Image; using namespace awesome::Fonts;
int main(int argc, char* argv[]) {
GameWindow window("Hello World!", 800, 600, 32, false); //Title, Width, Height, Bpp, Fullscreen WindowGraphicsContext ctx(window); ctx.EnableDoubleBuffering(true);
Image img("image.png", false); //Second parameter means explicitly disable support for animations(APNG, in this case) even if they are supported
Matrix& projection = ctx.ProjectionMatrix(); projection.ToIdentity(); projection.Multiply(OrthographicMatrix(0.0f, 800, 600, 0.0f, -1.0f, 1.0f)); //To be honest, I mostly copied the two lines above from an SDL+OpenGL tutorial
ctx.TransformMatrix().ToIdentity(); //Reset all transformations
//Here I'll make it similar to OpenGL because not everything in OpenGL sucks ctx.Begin(); //We could use the long way, but the API would include some utilities to simplify common usages //An even more simplified version(DrawImageRect) would be provided, taking away the whole "BottomLeft" stuff //but in this case, this is provided to show the flexibility of the API. DrawUtils::DrawRect(ctx, img.BottomLeft(), img.BottomRight(), img.TopRight(), img.TopLeft(), Rectangle(Vertex3(0,0,0), Vertex3(800, 600,0))); ctx.End(); ctx.SwapBuffers();
ctx.Dispose(); window.Dispose();
return 0;
}
At this point, the API is quite conventional. What makes it different?
1. Contexts: Having many contexts at the same time. Then one'd just apply the functions(begin, end, etc.) to a different context and it'd "just work". OpenGL isn't very context-friendly, since you can only have one active context at any given time. 2. Unification: Using base classes such as Drawable, the same functions could be applied to colors, static images, animated images, text, other graphical contexts and even movies. In OpenGL, this part is notably bad. Even with existent libraries available(such as DevIL). Try rendering a GStreamer movie in an OpenGL cube. Really, I'll be very interested in example code if you can show me. 3. Render to textures: Because of contexts and unification, this is as simple as rendering to the screen. 4. Video as just another resource: Ability to pick a video and just render it to a cube like it was a texture is important. 5. Draw context to context: A variant of render to textures.
This is my imaginary perfect low-level game API. If something like this already exists, I'd be happy to use it. It could be in C++, Java or .NET provided that it had all the simplicity and features I described.
|