API independence - ideas
Author
Hi to everyone!
Major problem, about designing 3D engine, is API independence. All graphics APIs have their own Meshes, Textures, Materials, etc classes. When I got thru several, popular game engines (for instance Ogre or irrlicht), I saw, that their defining own Interfaces for this stuff, and then implement it, for DirectX, OpenGL, and so on. Now, this, I think is the common way, to deal with it, right? Correct me If I'm wrong. (I mean, seriously, thats not an irony)
Now, I got this idea, to solve this quite diffrently. Now, as I said previously, every API has its own graphic stuff classes. So maybe instead of, writting our own interfaces and implementing once again those classes, we can use unique id's?
I mean...
// or using System.UInt32 = TextureID or whatever language you use, bla bla
typedef int TextureID;
TextureID = IRenderer.Load("C:\Texture\Path\file.jpg");
Now, we don't care if it's directx, opengl, or whateverYouImagineAPI. All we need is just an Id. Real object, is stored somewheres in renderers manager.
That's just a simple idea, I'm curious, what do you think about it. Also, I'll be glad, If you can give general overwiev of dealing with API independence?
Thanks in advance!
This is the same thing: you're basically describing the classic way of having OOP in C, which is also the basic principle of OpenGL driver-independence. At the end of day, you still have an interface (except that now, instead of having member functions cleanly set up in a class, you have non-member functions which take an integer) and you still have to implement that interface for every API (except that instead of inheritance, you have to do something that's more clever behind the scenes to fetch the appropriate data and process it).
Achieving API independence by creating an additional abstraction can be done, but it takes a large amount of work, as well as a lot of insight and experience to get right. Good design practice would force you to use API-specific code in only a handful of well-delimited places that you can then refactor to work with another API. API-independence is only a problem if your API-dependent code is spread all over the place, which shouldn't be the case if you're careful.
Achieving API independence by creating an additional abstraction can be done, but it takes a large amount of work, as well as a lot of insight and experience to get right. Good design practice would force you to use API-specific code in only a handful of well-delimited places that you can then refactor to work with another API. API-independence is only a problem if your API-dependent code is spread all over the place, which shouldn't be the case if you're careful.
Quote:Original post by ishikawa-san
// or using System.UInt32 = TextureID or whatever language you use, bla bla
typedef int TextureID;
TextureID = IRenderer.Load("C:\Texture\Path\file.jpg");
This approach is known as handles. Win32 API is built entirely on this concept.
Note that a problem occurs if application somehow corrupts the handles. There's absolutely nothing whatsoever preventing you from guessing or deliberately changing the value of TextureID.
Historically, this led to deliberate abuse. Once it was determined that a certain system always behaves in same way, users started making assumptions about the values of handles.
Quote:Also, I'll be glad, If you can give general overwiev of dealing with API independence?
Lots and lots of hands-on, real-world experience with each and every API you want to abstract, by actually using those APIs to implement tasks you want to abstract.
This is why in Java world frameworks are dime-a-dozen. Everyone who learns a few basic patterns (usually Singleton and, uhm, that other one) writes their own framework, trying to out-abstract all others. End result is a bunch of half-assed frameworks that barely, but not entirely fulfill author's own needs, and nothing else whatsoever.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement