@SDL users, use OpenGL
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.
Author
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.
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.
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...
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...
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.
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 functionvoid 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;}
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
