• Announcements

GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Followers 0

32 posts in this topic

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]
0

Share on other sites
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
0

0

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]
0

Share on other sites
Quote:

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

0

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
0

Share on other sites
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
0

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

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

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)
0

Share on other sites
Save yourself the trouble.
http://www.imagemagick.org/Magick++/Documentation.html
0

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

Share on other sites
Then try:
http://www.paintlib.de/paintlib/
0

Share on other sites
Quote:
 Original post by barryseeThen 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?
0

Share on other sites
Quote:
Original post by PnP Bios
Quote:
 Original post by barryseeThen 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?

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

Share on other sites
good idea!

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

Share on other sites
Could you elaborate on your problem with the LGPL?
0

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.

0

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

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

Share on other sites
Quote:
 Original post by dcosbornSince 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]
0

Share on other sites
Quote:
 Original post by Name_UnknownHow 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.
0

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

Share on other sites
Quote:
 Original post by ketekHow 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.
0

Share on other sites
Quote:
 Original post by _the_phantom_@KonfusiusIts 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:

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

Create an account

Register a new account

Followers 0

• Similar Content

• Hey guys, posting my work in progress for Macho Cat here.

A very early prototype for Macho Cat. Everything is just placeholder for now
What is Macho Cat?
A silly little game where you scrub the macho cat with random objects found in trash and junkyard to please him
Gameplay feature?
-Cat scrubbin, lots of scrubbin
-Unlock moar objects in junkyard
-Funny, silly and easy
When will the game release?
December 2017 (estimate)
Interested to Beta test?
opneongame@gmail.com

• Hey all,

As the heading says I'm trying to get my head around Goal Objective Action Planning AI.  However I'm having some issues reverse engineering Brent Owens code line-by-line (mainly around the recursive graph building of the GOAPPlanner).  I'm assuming that reverse engineering this is the best way to get a comprehensive understanding... thoughts?

Does anyone know if an indepth explanation on this article (found here: https://gamedevelopment.tutsplus.com/tutorials/goal-oriented-action-planning-for-a-smarter-ai--cms-20793), or another article on this subject?

I'd gladly post my specific questions here (on this post, even), but not too sure how much I'm allowed to reference other sites...

Any pointers, help or comments would be greatly appreciated.

Sincerely,

Mike
• By E-gore
Hi all,
This is our (xDBAGames) first game
Called Iron Dome Legacy.
It is a Missile Command clone. In this game you control the Israeli "Iron Dome" anti missile defence system.
Features:
The player has limited amount of missiles. The Iron dome system is upgradable. The money is determined by the outcome of a level. The game is free. There are only rewarded ads. We tried to create a game that has some context to the daily life, but we are sure not trying to be political here.
I hope you could try this game, and we will appreciate any comments.
xDBAGames is a company of two programmers. That have no experience in the video game industry, but have a lot of passion for games.

• By UNNYHOG
Hello, Colleagues!

We have been working on our newest Fantasy style Gesture based MOBA game for a long time and it's releasing on Steam on July 26. Meanwhile you can already try it out by downloading our launcher from the website.

Any feedback is welcome here. Thank you.

If you don't want to play, I would love to share with you our teaser :

• So I am working on a mobile game.
It uses slides for a story, the slides are very large. Each slide is almost 2048*2048; the max texture loading size I am using for the game.

My problem is that Unity keeps each slide in the memory after it's loaded, even when it will show only once per game. This leads to the game crashing on older mobiles.
My idea was to destroy each object after it was shown using a coroutine, so it deletes the past slide and loads the next slide. This worked because instead of crashing on 23 slides it crashed on 48 slides.
After some profiling I realized that destroy() isn't clearing all the memory that a slide used.

What I want to do now is assign a limited amount of memory as a slide slot. Then I need some way to unload the slide from the slot, freeing the slot for the next slide; without Unity storing the slides in the memory.
Any ideas on how I would do this?

• 12
• 28
• 14
• 11
• 36