• Advertisement
Sign in to follow this  

Unity The Game Texture Loader

This topic is 4387 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
@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)

Share this post


Link to post
Share on other sites
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'.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
good idea!

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
How funny , i did just a library to do that , fully opengl compatible.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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_SDL

SDL_Surface * GTL_LoadImage(const char * filename);

#else

void * 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! :-)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Now

  • Advertisement
  • Similar Content

    • By RoKabium Games
      Custom coffee mugs have arrived... More caffeine!
      Have a great weekend everyone! 
      #gamedev #indiedev #sama #caffeine
    • By Atwo Studios
       
      Hey guys,

      Anthony here from Atwo Studios bringing you some new updates for the new year!
      In this video I go over our game ROY, the new games and some general updates to the company!

      If you have not checked out ROY feel free to give it a try! Many people have said they enjoyed the game thus far!
      ROY: https://goo.gl/o6JJ5P
       
    • By Affgoo
      https://play.google.com/store/apps/details?id=com.NE.Alien
      still a lot of work to do, but its pretty stable  please let me know what you think <3
      Atlas Sentry is a game of destroy everything. Using your turret, simply swivel and shoot your way to victory, upgrading your weapons to unleash destruction on the variety of spaceships. The bigger your combo’s the more score you get! Earn silver as you play and then purchase new weapons and abilities to better deal with your enemy. Different enemies use different tactics and weapons, work out your own priorities in their destruction order. 

      Features: 
      **2 different game modes 
      **A level select mode with 20 difficult levels including a final boss, can you defeat it? **Arcade mode of endless destruction, how long will you last? 
      **High scores to compete against others, see who can take the top spot. 
       
    • By Chamferbox
      Chamferbox, a mini game asset store has just opened with some nice game assets, 
      Here you can find a free greek statue asset 

      Also check their dragon, zombie dragon and scorpion monster out:



      They're running the Grand Opening Sale, it's 30% off for all items, but for gamedev member, you can use this coupon code:
      GRANDOPEN
      to get 50% off prices What are you waiting for, go to
      http://chamferbox.com
      and get those models now!

      View full story
    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064

      View full story
  • Advertisement