Save yourself the trouble.
http://www.imagemagick.org/Magick++/Documentation.html
The Game Texture Loader
oh yes, I forgotten about that one, I've just looked at it and frankly the first page you linked to validates my concerns with mention of containers and other things which simply arent needed for something just designed to load images.
Infact, the opening statement of the page describes it as a C++ interface to the ImageMagick image processing library, so its hardly going to be small now is it.
The term 'overkill' springs to mind, now if you need all those functions then go use it, however I dont and I dont need all those 'features'.
Infact, the opening statement of the page describes it as a C++ interface to the ImageMagick image processing library, so its hardly going to be small now is it.
The term 'overkill' springs to mind, now if you need all those functions then go use it, however I dont and I dont need all those 'features'.
Quote:Original post by barrysee
Then try:
http://www.paintlib.de/paintlib/
License is to restrictive. Consider this, if you create a library, not a program using it, how do you make sure that the end programer sticks the notice in the about box?
Quote:Original post by PnP BiosQuote:Original post by barrysee
Then try:
http://www.paintlib.de/paintlib/
License is to restrictive. Consider this, if you create a library, not a program using it, how do you make sure that the end programer sticks the notice in the about box?
You might want to actually read the license agreement.
http://www.paintlib.de/paintlib/copyright.html
Too restrictive?
Quote:1# Do whatever you want with paintlib. Just don't come running to me with a lawyer if something goes wrong.
Sure there may be small differences in your plans and the other alternatives out there. Surely you will find things wrong with each one and justify your need to work on your particular project. That's your own perogative, and if it makes you happy, that's fine. I wasn't trying to stop anyone, I'm just showing you that it's somewhat reinventing the wheel. There are some viable alternatives out there. It would be easiest if you just kept to one graphic format for your program to where you could use a library specifically for that.. only that kind of library will be the lightest.
good idea!
will it maybe be able to split large textures up like for example the popcap engine framework does?
will it maybe be able to split large textures up like for example the popcap engine framework does?
How is this better than Devil? You only said SDL_image :-)
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.
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.
Since its going to be such a simple library, it shouldn't be a problem to write it in C for maximum portability. Just a suggestion so that people like me could use it. If you want to you could always write a C++ layer on top of it. Also, provide a streaming interface of some sort, like that found in libpng so that the input data can be retrieved from a user-defined source.
I wont claim that its not a slight wheel reinvention, the fact I dont plan to write all the decoding routines myself does offset that somewhat.
anyways, paintlib is closer to the mark, however its still too verbose in its way of doing things. The fact you have to create objects to move data in and out of seems abit daft to me, what is 3 lines in that code could well be reduced to one line in mine (be it the class or struct system).
As with before, saving and manipulation isnt needed either, nor can I see a sane way to work the things DDS textures support into it, i could probably be hacked with the psd layers stuff, but thats what it would be, a hack.
@AP
Not really, no. The idea is to load and present the data + infomation about it, what you do with the data after that is upto you and I would argue that any manipulation by cutting it up etc is in the domain of an engine, not an image loader.
@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.
anyways, paintlib is closer to the mark, however its still too verbose in its way of doing things. The fact you have to create objects to move data in and out of seems abit daft to me, what is 3 lines in that code could well be reduced to one line in mine (be it the class or struct system).
As with before, saving and manipulation isnt needed either, nor can I see a sane way to work the things DDS textures support into it, i could probably be hacked with the psd layers stuff, but thats what it would be, a hack.
@AP
Not really, no. The idea is to load and present the data + infomation about it, what you do with the data after that is upto you and I would argue that any manipulation by cutting it up etc is in the domain of an engine, not an image loader.
@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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement