Quote:
Original post by Kazade
Quote:
Original post by ravyne2001
That's the common approach, but one of OpenGL's strengths is its increadable portability which is, at least in part, attributed to its C language roots. It will be a trade-off either way, a design decision. But I do have a method of defining both C and C++ APIs conditionally with no real maintainance overhead. It might be worth considering, at least. I can explain in more detail later.
I strongly feel that we shouldn't try to do both, we should keep it simple. We can create object oriented maths classes that implicitly cast to arrays of floats for passing into the gl*fv functions. I think this is a far nicer approach.
I'm not sure how strongly I feel about this. The main benefit of having a C API is that the lib will be available
everywhere that OpenGL is. The difficulty of developing the C API for the lib would be developing a naming scheme for all the functions that is consistant and not too verbose. The C API also has to compensate for the lack of operator and function overloading that the C++ API would have available.
I have implimented this style of API before for an RGB 5.6.5 color class. There's no maintainance or performance overhead in doing so, and my approach exposes only the C++ API when compiling as C++ and only the C API when compiling as C. As I mentioned, naming the C API functions was the biggest hurdle by far. Its really less difficult and complicated than it sounds.
I guess its a matter of deciding whether or not to support C at all. If we want to support C, then we have to, if we don't want to support C, then there's no point.
Quote:
Original post by Kazade
Quote:
Original post by ravyne2001
Image loading*:
We have to give some thought to this, as others have stated DevIL is a library devoted to this kind of thing. I'm not sure its worth duplicating the effort. Perhaps it would be better just using DevIL for the model loading and fonts.
That certainly may be the case. It would also be possible to use DevIL as the back-end of one of the loaders. So lets say, for instance, that there are BMP, PCX, and DevIL loaders, where the DevIL loader supports all formats supported by DevIL. It sounds redundant, but the idea I have here is that the image-loading system is still extensible, without extending DevIL itself.
Quote:
Original post by Kazade
Quote:
Original post by ravyne2001
Model loading*:
- IFS
- MS3D/Blender
- Quake 3(?)
- Collada(?)
Hmm, OK, let's slow down a little. I agree that there should be some (extensible) model loading. But let's not try and support everything from the offset. One step at a time. I think OBJ and COLLADA would be a good start. When that's done we'll move onto MS3D. But perhaps that should be the extent of the core model loading (this isn't to say people can't add others).
I think IFS should definately be in. If you're not familiar with it, its basically the simplest 3D format there is; little more than an indexed triangle-list on a disk. While it has increadibly limited use for games, its value is simplicity and the fact that there is an entire CDs worth of freely usable models available, from very low to very high polygon counts. Its perfect for beginners -- a format they can
easily understand and tons of freely usable content. Its the simplest way from A to B where A is initializing GL and B is getting a model on screen.
I looked at the .OBJ format spec too. Implimenting the common subset looks easy enough, and it supports materials, normals, etc. But supporting things like curves and surfaces will probably be a little more complicated. Do you aim to support the complete format?
Quake3 is a popular format for use in games, and the format is well documented with source available for reference.
Collada is relatively complex actually, XML-based, and never really intended to be used on the front-end. Its designed for interchanging models between modeling packages and other back-end tools primarily. It would introduce a dependancy on an XML parser as well... Its a really cool format that supports everything under the sun, but I'm not sure if its worth the trouble (which is why I put the question mark after it.)
BTW, if we support model loading, don't we need a Mesh object?
Quote:
Original post by Kazade
Quote:
Original post by ravyne2001
General:
Could you explain this in a bit more detail?
I've seen a handful of simple examples around the net. The basic idea is to take all the OpenGL functions and wrap it up in a simple class. Generally it could hide all the various permutations of the C API methods, ie rather than glDoStuff_f(float f) and glDoStuff_d(double x) there would just be gl.DoStuff(x), rather than initializing GL manually, you could just instantiate a GL object and pass it some construction params, other things could be encapsulated in their own classes as well perhaps: VBOs, FBOs, Rendering Contexts.
I'm not sure if that goes beyond the scope of what we're trying to accomplish, or even if its a good idea. Just a thought to throw out there.
Quote:
Original post by Kazade
Quote:
Original post by ravyne2001
Taby mentioned a tiled rendering system, which would be a nice addition. I've not done it myself, but I know it can be a pain to set up.
I'm worried we are heading towards specific stuff here, I'd prefer if we focused on general classes that everyone will need and use (for now).
Yeah, on second thought maybe that would be better addressed by a nehe tutorial, rather than the lib.
Quote:
Original post by Kazade
Quote:
Original post by ravyne2001
On more of a general Project Administration note:
- Project home (I see you already have a google code page up)
- Source control (not sure what google code uses, I like SVN)
- Documentation (I like Doxygen)
- Coding standards (I suggest to follow, or base upon, OpenGL/GLSL standards)
- Dev platforms (MS VC++ 7.x, 8.x, latest GCC 3.x, 4.x)
- Get involved with the NeHe people
Yes the Google code thing uses SVN. Doxygen is my choice too (it's just plain brilliant), regarding coding standards, yes I'll come up with something solid in black and white before we do too much.
Dev platforms. I will be developing on GCC + Code::Blocks (because I don't have a Windows machine) however all code should be cross-compiler and cross-platform (just as OpenGL is)
By "NeHe people" do you mean the Nehedev team? or the Nehe community? if you refer to the former... well I AM a member of that team so job done [wink]
Seems we're on pretty much the same page here. I'm not too familiar with Google code, how does it compare to say, SourceForge? I'm not set on one over the other, I'm just curious how they compare on a features-to-features level.
I'm primarily on Windows, Visual Studio 2005 professional, and I'm familiar with Cygwin and make files, so I should well be able to make sure that my code is safe for GCC. I typically compile under very strict error/warning settings anyhow (level 4, warnings as errors, with portability checks.)
By NeHe people, I generally mean the group of volunteers who are working to give the NeHe content a facelift.
[Edited by - ravyne2001 on April 20, 2007 4:26:57 PM]
