Jump to content

  • Log In with Google      Sign In   
  • Create Account


The Game Texture Loader


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
32 replies to this topic

#1 phantom   Moderators   -  Reputation: 6791

Like
0Likes
Like

Posted 24 July 2005 - 05:29 AM

So, I've got plans... great great plans and I'd like some feedback and what I've got thus far [grin] The basics is I plan to make a library which deals with loading textures and only loading textures. Infomation can be found here and I'll be updating it as and when I do things, however I'd like some feedback on my inital considerations. (This is also relivent) oh, and anyone who mentions SDL_Image will be shot for not reading the above links and the comments made [razz] [Edited by - _the_phantom_ on July 24, 2005 12:31:10 PM]

Sponsor:

#2 SpreeTree   Members   -  Reputation: 396

Like
0Likes
Like

Posted 24 July 2005 - 06:14 AM

Would this only be compatible with OpenGL or other API's too?

I suppose if the code was able to return pointers to simple RGBA values, which represent each pixel in the image, then it could be used by all API's. Is that what you are going for? That’s what my image library does, and while the memory taken is slightly more than it could be, it is quite flexible and used by both DirectX and OpenGL renderers.

It does defiantly seem like an interesting proposition, especially if you can keep it contained within one library.

By that, I mean, I have to use different libraries for loading different texture, so my current project requires jpeg lib, png lib etc. If I only needed to include GTL.lib (or whatever) then that would be a fantastic thing to use.

If on the other hand, your GTL used jpeglib and png lib, and I had to include them myself, I would be less likely to use it. Just my thoughts though.

What would be your standing on including gif images in the library also?

Sounds like a very worth while project and one I have often wondered why no-one else has done something similar.

Spree


#3 gumpy   Members   -  Reputation: 793

Like
0Likes
Like

Posted 24 July 2005 - 06:25 AM

your second link is broken.

This space for rent.

#4 phantom   Moderators   -  Reputation: 6791

Like
0Likes
Like

Posted 24 July 2005 - 06:30 AM

The plan is to make it API independant as possible, I dont see any good reason why it should favour one API over another.

As you say, its just going to be a case of passing a pointer to the values and telling you what format the data is in (RGBA, RGB, float, int, DXT compressed, whatever). Once you have that pointer you can do with it as you like.

Keeping it all in one library shouldnt be a huge problem, I'm a great fan of statically linked libs when the need arises and my last project was purely statically linked as well. So, it should have all the required decoding libs built in. Infact, if you are using an MS compiler it will be even easier as I always make a config.hpp file which will automatically insert pragmas to make the linker link to the correct library, so you'd just include GTL.hpp and it would work the rest out for you [grin]

Ofcourse, what with it being zlib based license wise there will be a source distro, so if poeple want to change/recompile it as a dll or whatever, they can.

GIF support is an option, however how common is it as a game image format? I cant say I've ever had need to use it myself, thus its exclusion from the inital format list...

edit: As to why no one has done it before.. well, they kinda have, however alot of projects start off as "I'll just do this" and kinda sprial from there, so they become a "jack of all trades, master of none" type thing. Me on the other hand, I'm too lazy to add features beyond what I need and I prefer to keep things focused as much as possible [smile]

#5 phantom   Moderators   -  Reputation: 6791

Like
0Likes
Like

Posted 24 July 2005 - 06:32 AM

Quote:
Original post by gumpy macdrunken
your second link is broken.


hmmm... so it is... the link is being mangled for some reason when I post (I just tried to edit it)... it only points to the journal entry below the one first linked to anyways, it was kinda a convinance link to explain why I was going off on this anyways...



#6 SpreeTree   Members   -  Reputation: 396

Like
0Likes
Like

Posted 24 July 2005 - 06:39 AM

Quote:
Original post by _the_phantom_
GIF support is an option, however how common is it as a game image format? I cant say I've ever had need to use it myself, thus its exclusion from the inital format list...


Well, I use it so its common enough for me ;)

Having said that, if it is open source would you be open to people submitting format classes that fit in with your libraries structure?

Spree

#7 phantom   Moderators   -  Reputation: 6791

Like
0Likes
Like

Posted 24 July 2005 - 06:44 AM

yeah, that wouldnt be a problem at all, once it does the job for me and its released into the wild others can do with as they please

#8 rick_appleton   Members   -  Reputation: 857

Like
0Likes
Like

Posted 24 July 2005 - 08:31 AM

Great idea, and I'd definately use it. Just give a shout if you need any help or any testing.

I would also suggest making the reading from file by using a callback function available. That way people who use zipfiles and such can also use this. libpng has a similar structure, as does libjpeg I believe.

#9 PnP Bios   Banned   -  Reputation: 490

Like
0Likes
Like

Posted 24 July 2005 - 08:40 AM

Phantom, your library would be a godsend for mine. I could incorperate yours as a standard implementation.

Tears of joy man, tears of freakin joy.
HxRender | Cornerstone SDL TutorialsCurrently picking on: Hedos, Programmer One

#10 phantom   Moderators   -  Reputation: 6791

Like
0Likes
Like

Posted 24 July 2005 - 09:49 AM

@rick_appleton
Yeah, thats a thought I'd had and you mentioning it just confirms it as a good idea [grin]

@PnP Bios
heh, so you'll be intrested in it then? [grin]

Hopefully I'll start work on the inital version of it this week if not tonight (awakeness permitting)

#11 barrysee   Members   -  Reputation: 133

Like
0Likes
Like

Posted 24 July 2005 - 10:09 AM

Save yourself the trouble.
http://www.imagemagick.org/Magick++/Documentation.html

#12 phantom   Moderators   -  Reputation: 6791

Like
0Likes
Like

Posted 24 July 2005 - 10:13 AM

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'.

#13 barrysee   Members   -  Reputation: 133

Like
0Likes
Like

Posted 24 July 2005 - 10:17 AM

Then try:
http://www.paintlib.de/paintlib/


#14 PnP Bios   Banned   -  Reputation: 490

Like
0Likes
Like

Posted 24 July 2005 - 10:29 AM

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?
HxRender | Cornerstone SDL TutorialsCurrently picking on: Hedos, Programmer One

#15 barrysee   Members   -  Reputation: 133

Like
0Likes
Like

Posted 24 July 2005 - 10:36 AM

Quote:
Original post by PnP Bios
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?


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.

#16 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

0Likes

Posted 24 July 2005 - 10:37 AM

good idea!

will it maybe be able to split large textures up like for example the popcap engine framework does?

#17 demonkoryu   Members   -  Reputation: 976

Like
0Likes
Like

Posted 24 July 2005 - 10:51 AM

Could you elaborate on your problem with the LGPL?


#18 Name_Unknown   Members   -  Reputation: 100

Like
0Likes
Like

Posted 24 July 2005 - 11:03 AM

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.



#19 dcosborn   Members   -  Reputation: 634

Like
0Likes
Like

Posted 24 July 2005 - 11:06 AM

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.

#20 phantom   Moderators   -  Reputation: 6791

Like
0Likes
Like

Posted 24 July 2005 - 11:06 AM

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS