The Game Texture Loader

Engines and Middleware Programming Unity

Started by _the_phantom_ July 24, 2005 11:29 AM

31 comments, last by Rob Loach 18 years, 3 months ago

11,263

Author

July 24, 2005 05:09 PM

Quote:Original post by dcosborn
Since its going to be such a simple library, it shouldn't be a problem to write it in C for maximum usability.

I'm not a C programmer [smile]
For example, the dispatching system to id images types vs there decoders will probably be held in an std::map.

That said, a C interface probably would be possible to it, it would have to wrap calls into the namespace and hide any C++ related stuff, but it should be do able, consider it on my 'todo' list [smile]

_the_phantom_

11,263

Author

July 24, 2005 05:14 PM

Quote:Original post by Name_Unknown
How is this better than Devil? You only said SDL_image :-)

hehe, I only mentioned the SDL thing because I've noticed that often whenever people present a problem something SDL related is mentioned, so I thought I'd by pass it [grin]

For me, the plus' over DevIL are;
- its free free (zlib)
- the interface is going to be better (imo ofcourse)

Quote:
For me textures are part of my material system, I can reuse textures but they are always bound to a state as well, and the actual loading of the texture is the trivial part. The hard part is the management of the state, the texture environment, making sure things get set on/off correctly, and determing how to use that texture on a particular object. If your library will solve that nicely than you are a golden buddha.

I think you are expecting too much from it, its going to simply for loading and presenting data, anything else is in the domain of an engine, which this doesnt pretend to be.

ketek

132

July 24, 2005 06:02 PM

How funny , i did just a library to do that , fully opengl compatible.

Gorax

202

July 25, 2005 06:34 AM

Quote:Original post by ketek
How funny , i did just a library to do that , fully opengl compatible.

I wrote mine a while ago, then re-wrote it a few times to make it more generic. Unlike _the_phantom_'s however, it's written in C, and the structure I use doesn't store the mipmaps, and it sticks to basic data formats (RGB, BGR, RGBA).

I've currently implemented the following:
- BMP reading (24-bit only, since I'm rather lazy)
- PNG reading (most of which code I ripped from some tutorial somewhere, with quite a few modifications so I can get the relevant information from the file)
- JPEG reading (thanks to a *lot* of fiddling with IJG's JPEG library)
- XYF reading (my own image format that uses zlib compression (works slightly better than PNGs if there's more repeated data, otherwise it's slightly worse))

I can add others fairly easily, since I made all of the image loading code independent (so you can use the bitmap loading code without the rest of it). I must say that it's really great when you can load any image with a single line of code, but when you play with code you barely understand (like IJG's library), it does get a little annoying when your program dies for no good reason (all fixed now though, hence the 'fiddling' comment).

As for the C/C++ interaction, you can always use something like this:

struct Texture {  #ifdef __cplusplus__  public:    Texture();    ~Texture();    //insert other functions as necessary    //depending on how you want to make it, you could make the variables public,  //even if it is against the OOP way of thinking ;)  private:  #endif  //insert data as necessary};#ifndef __cplusplus__typedef struct Texture Texture;//so you use 'Texture' as a type in C#endif//insert C function definitions here

The only major problem with this is there's a lot of redundant calls made, regardless of how you do it.

Koshmaar

989

July 25, 2005 04:03 PM

Quote:Original post by _the_phantom_
@Konfusius
Its a personal thing I guess, but I just dont like it, I figure if something is free then make it free, thus my personal prefence for the zlib license. Unless there is a really good reason to have something as a DLL I prefer to compile things into my apps as well, so the LGPL focing you to either give away everything or dynamic link puts too much restraint on how I can compile my programs.
It could be fine for everyone else, but I dont like it so I prefer to avoid it and the GPL in favour of what I consider 'more free' licenses such as zlib.

Generally, I also prefer static libs to DLLs.
However, in one library I write, I decided to use LGPL, even though that lib in most cases will be statically linked.

Why? Well, AFAIK, author is free while deciding on license, and he can say:

- "I choose license X"

or

- "I choose license X but without rule Y"

Sure, then this question arises: "So, why do you use license X and then say that it's without rule Y, wouldn't it be better just to say: license K?".
As you said, "Its a personal thing" :-) also, IMHO LGPL is more familiar amongst programmers. So, in my case it looks like this:

- "I choose license GNU LGPL but you aren't forced to link dynamically"

I hope it's legal, what do you say...? If it's, then there aren't any more problems with LGPL, you know... :-)

--------------------

Btw, _the_phantom_, if that library could be configured to load .pngs, and only .pngs (probably by #ifdefing other "codecs" in code), and it could spit out newly created SDL_Surface with that image, without the need to convert it manually, then I would be the second person to use it (first would be you ;-)).

You know, SDL is rather widely used library, and with such function you could create decent competition to SDL_Image. Imagine sth like this:

#ifdef GTL_USE_SDLSDL_Surface * GTL_LoadImage(const char * filename);#elsevoid * GTL_LoadImage(const char * filename);#endif

So, in order to compile with SDL support, one would uncomment #define GTL_USE_SDL and recompile whole lib. Voila! :-)

Personal homepage | SDL_Config | Ninja Cat and Zombie Dinosaurs - free original browser game

_the_phantom_

11,263

Author

July 25, 2005 09:25 PM

On the license thing, well you could use the LGPL like that, I think a couple of libs have done and some dont care if you statically link anyways, however using zlib (which isnt really unknown, PHP uses it for example) makes it clear and the license text is about 10 lines at least, heh

So, I'll be sticking with zlib myself, but the fact that it is 'free free' means you dont have any restrictions on its usage.

The image format things will be basically as you say, it'll require a recompile to add/remove image loader code and #ifdef seem like the most likely way to handle it.

As for the SDL surface, well I could add it as part of the whole C-layer (remember, this is natively going to be a C++ library) so again consider it on the 'todo' list, as to if I do it or someone else will be another matter, but everything will be well documented so it shouldnt be a bother [smile]

HellRiZZer

308

July 25, 2005 09:36 PM

How about using a FreeImage Open Source project (http://freeimage.sourceforge.net)? It has more than enough texture formats as well as being portable to Linux, Windows and MacOS.

I use it and still have no complains.

" Do we need us? "Ionware Productions - Games and Game Tools Development

_the_phantom_

11,263

Author

July 25, 2005 11:15 PM

Aside from the interface the fact it decompressed DDS and appears to have no support for mipmaps and/or cubmap'd DDS images rules it out of the equation

*waves hand in the general direction of his journal for a slightly fleshed out version of the above*

nprz

692

July 31, 2005 04:45 AM

Looks pretty good. I'd like to check it out when you get it working. I am sure I could throw out what I have now and use yours. [grin]

ketek

132

July 31, 2005 05:02 AM

Ok, about one month ago i finished my texture manager for my projects
this piece of software loads bmp,pcx,tga,raw(sgi), jpeg nad png ( this 2 with the use of third part library ), its more than a loader , it handels everything a texture needs to have , and puts into a pool , where you can address the single textures with some invoking functions .
My deal is this i can give you the entire code for it for two reasons , first it would be a strong test 'rally ' for this library, second , software give waway for the community , to learn ( no pun intended ) , and to use without reinveniting the wheel , only enhance it.

The Game Texture Loader

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

The Game Texture Loader

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines