Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


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

#21 phantom   Moderators   -  Reputation: 7394

Like
0Likes
Like

Posted 24 July 2005 - 11:09 AM

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]

Sponsor:

#22 phantom   Moderators   -  Reputation: 7394

Like
0Likes
Like

Posted 24 July 2005 - 11:14 AM

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.

#23 ketek   Members   -  Reputation: 132

Like
0Likes
Like

Posted 24 July 2005 - 12:02 PM

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


#24 Gorax   Members   -  Reputation: 206

Like
0Likes
Like

Posted 25 July 2005 - 12: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.

#25 Koshmaar   Members   -  Reputation: 939

Like
0Likes
Like

Posted 25 July 2005 - 10:03 AM

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

#26 phantom   Moderators   -  Reputation: 7394

Like
0Likes
Like

Posted 25 July 2005 - 03: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]

#27 HellRiZZer   Members   -  Reputation: 308

Like
0Likes
Like

Posted 25 July 2005 - 03: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.

#28 phantom   Moderators   -  Reputation: 7394

Like
0Likes
Like

Posted 25 July 2005 - 05: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*

#29 nprz   Members   -  Reputation: 691

Like
0Likes
Like

Posted 30 July 2005 - 10:45 PM

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]

#30 ketek   Members   -  Reputation: 132

Like
0Likes
Like

Posted 30 July 2005 - 11:02 PM

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.


#31 mirex   Members   -  Reputation: 100

Like
0Likes
Like

Posted 03 August 2005 - 02:28 AM

I've made one image library too; it loads BMP, CEL, RGB (SGI), TGA, JPG, PPM, PSD, DDS (Direct X) and some more (JPG is supported through jpeglib); called Biturn bitmap library, and it was programmed for easy use with OpenGl and such ... can convert image to different pixel depths too. Called Biturn Bitmap lib, only bad thing is that its not tested much and currently its compiled only for win32. Here: http://mirex.mypage.sk/FILES/bbl_041117.rar

#32 Thrawn80   Members   -  Reputation: 140

Like
0Likes
Like

Posted 18 December 2005 - 02:18 PM

Hi all,

I've read all the replies to phantom's post. I guess the question of re-inventing the wheel is pretty generic. Sometimes I'll just wanna write some coz I simply want to learn the ups and downs of writing it, gaining the maximum experience compared to pure reading and learning.

I initially intended to write my own image loader as well (not to reinvent the wheel, but to do it as an exercise). But seeing all the juice that different free sources can provide, I'm rather tempted to just pick one and use it.

Even if i should pick one... I'll pick the one with a straight-forward, understandable methods and easy-to-use method calls. I guess this is where GTL could be useful..

:P

Back to the point of reinventing the wheel ... I guess it's all up to individual desires and its limits. For eg, I may be willing to write a game engine's event handlers but I'll leave the loading of bitmaps to GDI's LoadImage() ... I guess it's a different focus for everyone :P



#33 Rob Loach   Moderators   -  Reputation: 1500

Like
0Likes
Like

Posted 15 January 2006 - 09:25 PM

I just checked out the GTL CVS and it seems that you didn't include GameTextureLoader.cpp in /src. Might be missing some other stuff in /src/internals as well.

Although I have no way to test it out, here is the beginnings to Game Texture Loader bindings for .NET:


#region License
/*
Copyright ©2006 Rob Loach All rights reserved.

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
a ppreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
*/

#endregion License

using System;
using System.Runtime.InteropServices;
using System.Security;

namespace GtlDotNet
{
/// <summary>
/// The Game Texture Loader bindings for .NET, implementing GTL Beta 1-1 (Dec 05)
/// </summary>
/// <remarks>The Game Texture Loader is very much just as it says, a library for loading texture formats commonly used in games.</remarks>
[SuppressUnmanagedCodeSecurityAttribute()]
public sealed class Gtl
{
#region Constants
/// <summary>
/// GTL's native library archive.
/// </summary>
private const string GTL_NATIVE_LIBRARY = "gametextureloader";

/// <summary>
/// Specifies the calling convention.
/// </summary>
private const CallingConvention CALLING_CONVENTION = CallingConvention.Cdecl;
#endregion Constants

#region Constructors
/// <summary>
/// Private constructor - disallows instantiation
/// </summary>
private Gtl()
{
}
#endregion Constructors

#region Public Functions
/// <summary>
/// Loads a texture from the given filename. The GTL will use the file extension (everything after the final . (dot) in the file name) to select the loader.
/// </summary>
/// <param name="filename"></param>
/// <returns>A struct which contains read online formation about the image and a pointer to the image data.</returns>
[DllImport(GTL_NATIVE_LIBRARY, CallingConvention=CALLING_CONVENTION), SuppressUnmanagedCodeSecurity]
public static extern Image LoadTexture(string filename);

/// <summary>
/// Loads a texture from the given filename. The GTL will use the given FileType value to select the loader to use.
/// </summary>
/// <param name="filename"></param>
/// <param name="val"></param>
/// <returns>A struct which contains read online formation about the image and a pointer to the image data.</returns>
[DllImport(GTL_NATIVE_LIBRARY, CallingConvention=CALLING_CONVENTION), SuppressUnmanagedCodeSecurity]
public static extern Image LoadTexture(string filename, FileTypes val);

/// <summary>
/// Loads a texture from the given PhysFS file handle using the specified type to select the loader to use.
/// </summary>
/// <param name="file"></param>
/// <param name="val"></param>
/// <returns>A struct which contains read online formation about the image and a pointer to the image data.</returns>
[DllImport(GTL_NATIVE_LIBRARY, CallingConvention=CALLING_CONVENTION), SuppressUnmanagedCodeSecurity]
public static extern Image LoadTexture(IntPtr file, FileTypes val);

/// <summary>
/// Loads a texture from the given PhysFS file handle using the filename provided to work out what type the image is to select the loader to use.
/// </summary>
/// <param name="file"></param>
/// <param name="filename"></param>
/// <returns>A struct which contains read online formation about the image and a pointer to the image data.</returns>
[DllImport(GTL_NATIVE_LIBRARY, CallingConvention=CALLING_CONVENTION), SuppressUnmanagedCodeSecurity]
public static extern Image LoadTexture(IntPtr file, string filename);

/// <summary>
/// Returns the width of the image at the given mipmap level
/// </summary>
/// <remarks>The image number isnt required as the library assumes all images have the same dimensions (true of DDS images)</remarks>
/// <param name="img"></param>
/// <param name="mipmaplvl"></param>
/// <returns>Width of the imageat the requested mipmap level</returns>
[DllImport(GTL_NATIVE_LIBRARY, CallingConvention=CALLING_CONVENTION), SuppressUnmanagedCodeSecurity]
public static extern int getWidth(ref Image img, int mipmaplvl);

/// <summary>
/// Returns the height of the image at the given mipmap level
/// </summary>
/// <remarks>The image number isnt required as the library assumes all images have the same dimensions (true of DDS images)</remarks>
/// <param name="img"></param>
/// <param name="mipmaplvl"></param>
/// <returns>Height of the image at the requested mipmap level</returns>
[DllImport(GTL_NATIVE_LIBRARY, CallingConvention=CALLING_CONVENTION), SuppressUnmanagedCodeSecurity]
public static extern int getHeight(ref Image img, int mipmaplvl);

/// <summary>
/// Retieves the depth of the image at the given mipmap level
/// </summary>
/// <remarks>The image number isnt required as the library assumes all images have the same dimensions (true of DDS images)
/// <p>2D images will return a depth of 1</p></remarks>
/// <param name="img"></param>
/// <param name="mipmaplvl"></param>
/// <returns>depth of the image at the requested mipmap level</returns>
[DllImport(GTL_NATIVE_LIBRARY, CallingConvention=CALLING_CONVENTION), SuppressUnmanagedCodeSecurity]
public static extern int getDepth(ref Image img, int mipmaplvl);

/// <summary>
/// Retieves the size in bytes of the image at the given mipmap level
/// </summary>
/// <remarks>The image number isnt required as the library assumes all images have the same dimensions (true of DDS images)
/// <p>The function correctly works out the size for DXTn compressed data</p></remarks>
/// <param name="img"></param>
/// <param name="mipmaplvl"></param>
/// <returns>The size in bytes of the image at the given mipmap level</returns>
[DllImport(GTL_NATIVE_LIBRARY, CallingConvention=CALLING_CONVENTION), SuppressUnmanagedCodeSecurity]
public static extern int getSize(ref Image img, int mipmaplvl);

/// <summary>
/// Returns a pointer to the start of the image data for the requested image and mipmap level of a given Image object.
/// </summary>
/// <remarks>This function doesnt to any checking as to the validity of the image number nor the mipmap level, this is left to the user</remarks>
/// <param name="img"></param>
/// <param name="imgnumber"></param>
/// <param name="mipmaplvl"></param>
/// <returns>A pointer to the start of the image data</returns>
[DllImport(GTL_NATIVE_LIBRARY, CallingConvention=CALLING_CONVENTION), SuppressUnmanagedCodeSecurity]
public static extern string getData(ref Image img, int imgnumber, int mipmaplvl);
#endregion Public Functions

#region Public Enums
#region ImgFormat
/// <summary>
/// Enums for image and file type identification
/// </summary>
public enum ImgFormat
{
FORMAT_NONE = 0,
FORMAT_RGB,
FORMAT_BGR,
FORMAT_RGBA,
FORMAT_BGRA,
FORMAT_ABGR,
FORMAT_DXT1,
FORMAT_DXT2,
FORMAT_DXT3,
FORMAT_DXT4,
FORMAT_DXT5,
FORMAT_3DC,
}
#endregion ImgFormat

#region FileTypes
/// <summary>
/// Used to tell the loader which file type you want to use. Also used internally in the registering of loaders on start up.
/// </summary>
public enum FileTypes
{
TYPE_BMP = 1,
TYPE_JPG,
TYPE_TGA,
TYPE_PNG,
TYPE_DDS,
}
#endregion FileTypes
#endregion Public Enums

#region Public Structs
#region Image
/// <summary>
/// This struct provides a way of wrapping all of the image infomation into one place
/// </summary>
[StructLayout(LayoutKind.Sequential, Pack=4)]
private struct Image
{
int height_;
int width_;
int depth_;
int colourdepth_;
ImgFormat format_;
int numImages_;
int numMipMaps_;
IntPtr imgdata_;
}
#endregion Image
#endregion Public Structs
}

}




Rob Loach [Website] [Projects] [Contact]




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