Ok, I have decided some things about my library. I am going to break it up into 2 distinct libraries. hxRender, and hxUtil, and I am going to make it purely OpenGL. Why would I do a thing like this? -It will cut down on dependencies big time. -Make it more accessable for people who might not like SDL. -Dynamically linkable release version. Why break it up into 2 libraries? -Well, it just makes more sense, If I only update the utilities, why bother updating the core? If I only make an enhancement to the core, why bother updating the utilities? -Easier to make it dynamically linkable. I won't make any serious changes until I get some comminity input. I'm writing this for you guys after all.

PnP: How would you plan to do Window Initialization without SDL? There are other cross-platform libraries like GLFW and GLUT which will do Window Initialization, so I guess you could probably just rip out the code from GLFW, because it has the zlib license that lets you do bascically anything with it. Coding it yourself with #ifdefs would probably be a pain...

I think it sounds like a good idea though. This way, if someone decides they're going to stop using OpenGL w/SDL, they could still use the hxRenderer. Or for people who were never using SDL in the first place, they could try out your engine without needing to worry about SDL.

If you want to do this, I would say go ahead. However, I can imagine the amount of extra coding you would need to do if you would still want to have functions for Loading Images without the help of another library.

I can understand both your views on SDL, but why *wouldn't* you want to use SDL? It takes care of all the main window creation as well as allowing you to keep your library portable. In respect to the amount of code, using SDL will save you a minimum of 40% of the amount of code an OpenGL program would.

I know this because I am working on my game engine and I have made my framework SDL. Using OpenGL via SDL is a lot more efficient and is a lot less of work. Plus you do not need to have to worry about all the windows specific code. Take a look at the first couple of NeHe lessons, 6-10, at all the code.

If you used a SDL framework, not only would you eliminate more than half of that code, you would not have to worry about checking the HDCs,HGLRCs,HINSTANCEs, and callback functions.

Anything you can do in pure OpenGL you can do a lot faster with less code in SDL/OGL. If you need proof I can show you [wink]. I just recently ported 7 of NeHe's lessons to use my framework and if you were to compare the two end products, you couldn't tell them apart. I know NeHe's stuff is easy, so I ported GameTutorial's BSP Collision 3 tutorial to my framework. The only problem I had with that process was that I had to unlink one of the default libraries so it would link correctly, other than that it was good!

If you visit my web page, you can have a look at the demos and compare them to the OpenGL ones. Now I have not used your library yet, nor do I have any freaking clue what it does, but I know you will be only adding work for yourself if you choose to go to windows OpenGL.

As for breaking it down into two libraries, I strongly suggest that. In my game engine now, I have about 10 main components. At first I had everything in one .dll. When it came to updating or testing, it was a pain to work with. By breaking it down, it is more work, but in the long run, you will save yourself lots of headaches. Not only that, the end user can choose what they want to use. Options are always nice.

If you are set on making your library less dependent, I suggest you make two versions, as you go along and develop them, if you like the OGL better, than choose it. If you find that the SDL is more attractive, than choose that one. That way, you can at least see both before committing to one. After seeing OpenGL then seeing it with SDL, I know SDL has won my vote. Whatever your decision, good luck!

P.S. Where can I get your library?

[edit] Sorry about the long paragraph =) [/edit]

[Edited by - Drew_Benton on December 18, 2004 5:08:21 PM]

Thanks for the support, Drew, and Wryzy. You can download my library from my home page. The link is in my sig.

I suppose I will just have to keep it as an addon to SDL. And thats fine with me. I wonder if it would be agreeable to #pragma the .lib files in one of my headers. If I do all this, you would have to externaly link to 6 static libs.

sdl.lib, sdlmain.lib, opengl32.lib glu32.lib hxRender.lib hxUtil.lib.

Is there an easier way to do this?

Quote: Original post by PnP Bios
I suppose I will just have to keep it as an addon to SDL. And thats fine with me. I wonder if it would be agreeable to #pragma the .lib files in one of my headers. If I do all this, you would have to externaly link to 6 static libs.
sdl.lib, sdlmain.lib, opengl32.lib glu32.lib hxRender.lib hxUtil.lib.Is there an easier way to do this?

When you use SDl or OpenGL, you must link those libs statically. As for your own libs, the same goes. There is a way so you do not need any libs, and use the .dll with the headerfile, but I have been unable to get it to work with classes.

Here is an example of how one of my headerfiles is:



That way, the user just has to include the header file as well the the OpenGL header files. I did not put on the OpenGL header files b/c for each user, it could reside somewhere else. However, the libs 99.99% of the time will reside in the default location, so it is safe that way.

Make a mention in your documentation that when you use your class, all the necessary lib's are linked, you just have include the header file.

That little trick I picked up recently from a tutorial. They had done that format of linking libs, and it is quite handy. I only wish there was a way to unlink a library the same way...

Anyways, best of luck! I will be looking at your library sometime soon.

the same basic trick is used by boost to select the right lib when linking, this includes static vs dynamic linking as well

btw, is there any reason why you couldnt have two versions based on the same core around? one which interfaces with SDL and one which is stand alone?

Drew, no classes were harmed/used in the making of this library. It is about as pure C as you can get. If I ever figure

Well, Mr. Phantom... I have no idea how to do that. You are basicly telling me that I should support two different versions, or should I have a third library that handles all of the cross over stuff....

wait... thats a good idea...
hxRender
hxUtil
hxSDL

ok then. thanks!