Sign in to follow this  
Followers 0
PnP Bios

@SDL users, use OpenGL

92 posts in this topic

Quote:
Original post by PnP Bios
I registered it under LGPL with source forge. I hope that is good enough.


I think LGPL is the right choice since SDL is LGPL as well.
0

Share this post


Link to post
Share on other sites
Hey all! I'm here to add in my 2 cents [smile].

@PnP: sorry I haven't gotten back to you about this - I've moved back to college and do not have internet in my apt. - I'm in the library now :(.

Anyways I have a quite bit to say -

1. I used to think that starting out with SDL would be the best thing for a beginner. It basically does everything for you - so why not use it? You can concentrate on the game task in hand rather easily.

Now you may have read the word *used*, I know think that SDL is a dead end path for beginners (am I spelling that right - looks werid :/ ). Now this is coming from someone who has strongly advocated and has dedicated a large portion of time learning and using SDL, so that is not an empty statement.

I feel this way because once you are ready to move on to bigger projects that most likely will not use SDL, you really have no knowledge. Using SDL is a double edged sword - everything is easier, but you have no idea of the true inner workings of everything.

This is something I have come to realize over the past few days. I've been working on a game engine that most people would probabally deem 'nearly impossible' coming from someone as myself - but nevertheless its going good. bascially the engine is a plugin based that lets you choose what you want to use. I do not want to go talking about my stuff b/c this is not my thread, but you get the idea.

Now this is all revelant to SDL because when I was always using SDL - I would get input by using the SDL function to return the 256 array of keys. Thats it! Now, in my engine - I cannot simply do that, so I had to learn how to get input - which I asked about the mouse and keyboard in one forum if you remember.

The same pretty much goes for everything else - I had made some nice libraries for SDL and stuff - but its only good for SDL! Now that I am in non-SDL environments - none of that code is any good - neither is the majority of the experience learned making them.

2. Now with that said - If I would have began with let's say Win32 OpenGl - I would have a better understanding of everything that SDl so convinelty hid from me. Instead of having to learn this new stuff since I let SDL take care of it for me, I could have already known most of it by no choosing SDL. I'm not saying I reget starting with SDL - its just that if you have BIG plans, such as myself - taking the SDL route really is a dead end. Thus I agree with Rob [wink], we're on the same page buddy!

3. Ok now with that little monologue said [lol] time to move on to something...err I can't really remember what I was goign to say...anyways PnP goodjob! I will download this new version and try to get back to you. I try to make at least one library trip a day - that's why I'm not active anymote posting :(. best of luck and great work!

- Drew
0

Share this post


Link to post
Share on other sites
It's just my choice, but I don't think the LPGL is the best license for such a small library. It basically forces users to use it as a DLL. For larger libraries this isn't much of a problem because the overhead is small. But for a small library, you'll end up with a huge DLL with most of it having nothing to do with the library itself. A license that allows static linking always has my prefference.
You could go for something as liberal as the zlib, MIT or BSD license (which is pretty much what you initially said). Something less liberal but that still (from what I understand) allows static linking is the MPL or the Jabber PL.

If you have some time, you might want to read up on some licenses on http://opensource.org/licenses/index.php
0

Share this post


Link to post
Share on other sites
couple of quick comments;

Firstly, I'm with the above poster, LGPL is a tad too restrictive for what the library is ment todo, personally i'm a fan of zlib for stuff like this as really it only makes sense to statically link things like this in.

Secondly, i've taken a quick shifty at the code and I'd like to point out you dont need to include windows.h in your hxRender.h file as that file doesnt touch windows functions, instead include it in the source file with an include guard to stop it including on non-windows plaforms.

Finally, I'm not so sure about those statically allocated arrays of 256 values, i cant help feel you'd be better off with either a dynamically allocated system (which ofcourse would require an init function to set it up, maybe include it in the setupwindow function?). Can I ask how you arrived at that number?
Also, as apoint of reference, if you are using a 'bool' shouldnt to be setting the value to 'false' not '0' in your setupwindow function?

Aside from those minor issues I quite like it, if I ever get a chance then I might well use it to setup a 2D example of how to use my windowing framework [grin]
0

Share this post


Link to post
Share on other sites
Ok, then what license should I use then? I... don't think I like pure GPL, I want people to be able to use it commercialy.

I'd rather go with public domain or gift ware... All I want is credit where credit is due. For me and for you guys.

_the_phantom, once I get a good distribution method, stuff like that will be easy enough to add.
0

Share this post


Link to post
Share on other sites
i'd go with zlib, basically its still yours, people can change it but should always say where the orignal came from and they can use it for what they like.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by _the_phantom_
i'd go with zlib, basically its still yours, people can change it but should always say where the orignal came from and they can use it for what they like.


I'll have to look into that then. thanks.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by _the_phantom_
i'd go with zlib, basically its still yours, people can change it but should always say where the orignal came from and they can use it for what they like.


as long (at least technically) as he copyrights it. If he doesn't copyright the lib, then anyone can take the lib exactly as he provided it, close it, and sell it as a commercial product without having to credit anyone. That's what public domain means. It belongs to everybody and everybody can do whatever they want with it, no rules.
0

Share this post


Link to post
Share on other sites
what is wrong with using SDL for input? or letting it do the system initialisation stuff? the sound should also be enough for the first beginner games.
the video part is simple and slow, yes. but really, it is so basic, that it wouldn't hurt much to switch to openGL (/whatever) - as long, as you designed your code properly...
0

Share this post


Link to post
Share on other sites
the thing that worries me about these "3d 2d libraries" is efficency. can your library really stuff my "surfaces" into vertex arrays, display lists, keep GL calls to a minimum, sort by texture, etc? because if you dont do any of these, you might find software actually running faster then hardware, at least on some systems.
0

Share this post


Link to post
Share on other sites
Here is the current, classic BLITing function in hxRender.


// Function: hxBlitSurface
// Author: Joel Longanecker
// Version: 1.5
// Description: This is the core function. This draws the object on the screen.
// Chages: blend color has been removed. It has been moved to its own function
void hxBlitSurface(hxSurface *source, hxRect sRect, hxRect dRect)
{
float sx;
float sy;
float sw;
float sh;

sx = (float)sRect.x/(float)source->wPad;
sy = (float)sRect.y/(float)source->hPad;
sw = (float)(sRect.x+sRect.w)/(float)source->wPad;
sh = (float)(sRect.y+sRect.h)/(float)source->hPad;

glBindTexture(GL_TEXTURE_2D, hxiTexList[source->texID]);

glBegin(GL_QUADS);

glTexCoord2f(sx, sy); glVertex2i(dRect.x, dRect.y);
glTexCoord2f(sw, sy); glVertex2i(dRect.x + dRect.w, dRect.y);
glTexCoord2f(sw, sh); glVertex2i(dRect.x + dRect.w, dRect.y + dRect.h);
glTexCoord2f(sx, sh); glVertex2i(dRect.x, dRect.y + dRect.h);

glEnd();

return;
}


0

Share this post


Link to post
Share on other sites
For the record - each has its place. I use SDL for input and for windowing and OpenGL for rendering. OpenGL is not an SDL replacement and should not be viewed as one.
0

Share this post


Link to post
Share on other sites
Firstly, well done PnP Bios for writing this and making it available. Incidentally I found some time recently to clean up my attempt at a similar library. I'd be ready to release it but I've been considering removing the SDL dependency, or at least separating it out so that you can use it with anything that gives you the appropriate OpenGL setup.

I'd also recommend the zlib license. That way you keep the copyright but people can use the library pretty much as they please.

I'd also not worry about the vertex arrays vs. glBegin/glEnd argument. In response to similar criticism and benchmarks posted on the thread about my library, I added a little buffering class to my library that batches up sprite drawing requests and then does them all in one go. I found absolutely no difference whatsoever on my (admittedly slow) hardware, and software rendering doesn't come close to either method. That's not to say that others won't notice a difference, so I'm gonna keep the functionality. But the main point is that even the glBegin/glEnd approach totally destroys SDL's DirectDraw-based approach in terms of performance, especially when you're looking at any sort of blending. It's like arguing about the difference between C++ and ASM when you've just moved from javascript. The one exception might be if you used a different texture for every blit.
0

Share this post


Link to post
Share on other sites
I am currently working on translating this into pascal, to be compatible with Delphi and Kylix. Perhaps, it might be added to the JEDI-SDL package.
0

Share this post


Link to post
Share on other sites
I had to do a few of things to get it to compile on my machine:
1) #include <cstring> in hxSDL.cpp
2) #include <cstdlib> in hxrender.cpp
3) add

#ifndef NULL
#define NULL 0L
#endif
in hxrender.cpp
4) change #include <sdl.h> to #include <SDL.h>, some filesystems are case sensitive(such as the ones commonly used with linux)
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Roboguy
I had to do a few of things to get it to compile on my machine:
1) #include <cstring> in hxSDL.cpp
2) #include <cstdlib> in hxrender.cpp
3) add

#ifndef NULL
#define NULL 0L
#endif
in hxrender.cpp
4) change #include <sdl.h> to #include <SDL.h>, some filesystems are case sensitive(such as the ones commonly used with linux)


um, what compiler are you using?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by PnP Bios
Quote:
Original post by Roboguy
I had to do a few of things to get it to compile on my machine:
1) #include <cstring> in hxSDL.cpp
2) #include <cstdlib> in hxrender.cpp
3) add

#ifndef NULL
#define NULL 0L
#endif
in hxrender.cpp
4) change #include <sdl.h> to #include <SDL.h>, some filesystems are case sensitive(such as the ones commonly used with linux)


um, what compiler are you using?
GCC 3.3, I said you should define NULL just in case they try to compile with gcc instead of g++(gcc doesn't define it, g++ does). As for the other things(except 4, that is only required for case-sensitive filesystems, but I recommend you do change it), they would probably be required no matter what machine you compile it on
0

Share this post


Link to post
Share on other sites
Roboguy, will do.

I found a free wiki to use as a documentation site. As soon as I get a template going, I'll set you guys loose on it.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Spudder
I've got a Linux version (static lib) if anyone wants to use it - available from here


You built the whole thing as one library?
Not what I had in mind, but, if it works..

Can I build static libraries for linux (.a files) using dev-c++?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by PnP Bios
Can I build static libraries for linux (.a files) using dev-c++?
Probably, if it comes with ar(the UNIX archiving program which makes .a files). Also, you'll need the header files in addition to the library file for it to work. This is how you would make an archive with ar(if your using ar.exe, change 'ar' to 'ar.exe'):
ar lib<library name>.a <object files>

it should work on linux, assuming the object files are in the right format(OSX doesn't use the same format, but I can compile an OSX one for you). If it doesn't you could try using the gcc that comes with cygwin
0

Share this post


Link to post
Share on other sites
From my experience compiling static libs with Dev-C++ for use under Linux has it problems, all I did was compile the source files into object files then archive them into an .a file. You still need to link to any third party libs like SDL with this file though.
0

Share this post


Link to post
Share on other sites
Trying to compile under Linux....I'll give a quick summary of changes I had to make.

hxrender.cpp
Changed gl/gl.h to GL/gl.h and gl/glu.h to GL/glu.h
Include cstdlib

In hxiNextPowerOfTwo the pow(2, i) is ambiguous, and becasue i is an integer I just changed pow(2, i) to 1 << i

hxSDL.cpp:
Changed sdl.h to SDL.h
Included cstring

hxUtility.cpp:
Changed gl/gl.h to GL/gl.h and gl/glu.h to GL/glu.h
Added cstring

hxrender.h:
Removed extra code after #endif ignored but produces a warning on GCC.

Since these are .cpp files I changed the C headers to C++ style (cmath instead of math.h etc.)
I might have forgotten a change though...
I also made a very very basic Makefile and put it in a tarball. If you want it online I'll be glad to send it to you.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Cherez
Trying to compile under Linux....I'll give a quick summary of changes I had to make.

hxrender.cpp
Changed gl/gl.h to GL/gl.h and gl/glu.h to GL/glu.h
Include cstdlib

In hxiNextPowerOfTwo the pow(2, i) is ambiguous, and becasue i is an integer I just changed pow(2, i) to 1 << i

hxSDL.cpp:
Changed sdl.h to SDL.h
Included cstring

hxUtility.cpp:
Changed gl/gl.h to GL/gl.h and gl/glu.h to GL/glu.h
Added cstring

hxrender.h:
Removed extra code after #endif ignored but produces a warning on GCC.

Since these are .cpp files I changed the C headers to C++ style (cmath instead of math.h etc.)
I might have forgotten a change though...
I also made a very very basic Makefile and put it in a tarball. If you want it online I'll be glad to send it to you.


It seems like a bunch of people have made ports for this. Everybody who has made a port, or significant changes to the library, email them to me as zipped attachments.

pnpbios at hotmail dot com

I will post them all on my web site, get everything compatable with the zlib license, and make it so we can vote on who want's which port.

I'm glad to see so many people excited about this.

I am going to do some more work on the wiki today, like build a function template and stuff. It looks like this one is also flexable enough to handle tutorials as well as function explinations.
0

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 0