Jump to content
Eternal Lands Official Forums
Sign in to follow this  
KarenRei

Windows texture loading

Recommended Posts

To any windows users who still have texture problems with eye candy:

 

I was going to put in debugging statements, but considering that your systems are different, it's probably best that you do this manually. So, here are some instructions to try and solve this problem.

 

1) Edit eye_candy/eye_candy.cpp

2) Modify the first push_texture statement to be your *full path* to that particular texture, using *double backslashes*. This means something like push_texture("c:\\games\\eternallands\\textures\\16x16\\simple.png"). Run and igure out whether that gives you an error or not on *that particular texture*.

3) Modify the first push_texture to be your full path, using *forward slashes*. This means something like push_texture("c:/games/eternallands/textures/16x16/simple.png"). Run like above.

4) Modify the first push_texture to be your *relative path*, using *double backslashes*. This means something lik e push_texture(".\\textures\\16x16\\simple.png").

5) Let me know what, if anything, worked. If it failed, give me the error message.

 

If *none* of these worked for you, try this in push_texture:

 

FILE* fp = fopen(filename.c_str(), "rb");
if (fp == NULL)
 log_error("Cannot even open " + filename + "!");
else
 fclose(fp);

Edited by KarenRei

Share this post


Link to post
Share on other sites

I have done all the steps and also the last resort, it still outputs the same.

The conclusion after testing various paths is that Windows _hates_ \...\ being used... this results in a merged path aswell as missing chars in the path. I also tried using mixtures of them, no good result at all. Also tried without the "." in \texture and /texture... I tried pretty much all logical combinations. The proper paths end up with Load error, the others with \ as I said merged and became corrupted so they of course didn't load aswell.

 

The last resort code didn't give any output, so fp /= NULL.

Share this post


Link to post
Share on other sites

Could you post your output, please? Thanks.

 

Ed: I just had an idea. How did you install SDL_image? On any linux-based binary package system, PNG support will be built into SDL_image, but I imagine that it might not be on Windows. Also, from the README:

 

SDL_image 1.2

The latest version of this library is available from:
SDL_image Homepage

This is a simple library to load images of various formats as SDL surfaces.
This library supports BMP, PNM (PPM/PGM/PBM), XPM, LBM, PCX, GIF, JPEG, PNG,
TGA, and TIFF formats.

API:
#include "SDL_image.h"

	SDL_Surface *IMG_Load(const char *file);
or
	SDL_Surface *IMG_Load_RW(SDL_RWops *src, int freesrc);
or
	SDL_Surface *IMG_LoadTyped_RW(SDL_RWops *src, int freesrc, char *type);

where type is a string specifying the format (i.e. "PNG" or "pcx").
Note that IMG_Load_RW cannot load TGA images.

To create a surface from an XPM image included in C source, use:

	SDL_Surface *IMG_ReadXPMFromArray(char **xpm);

An example program 'showimage' is included, with source in showimage.c

JPEG support requires the JPEG library:
IJG Homepage
PNG support requires the PNG library:
PNG Homepage
 and the Zlib library:
Zlib Homepage
TIFF support requires the TIFF library:
SGI TIFF FTP Site

This library is under the GNU Library General Public License, see the file
"COPYING" for details.  Certain image loaders may be under a different
license, see the individual image loader source files for details.

 

Again, on a linux system, these will typically be depdencies of the SDL_image package. On Windows, perhaps not.

Edited by KarenRei

Share this post


Link to post
Share on other sites

2) Modify the first push_texture statement to be your *full path* to that particular texture, using *backslashes*. This means something like push_texture("c:\games\eternallands\textures\16x16\simple.png"). Run and igure out whether that gives you an error or not on *that particular texture*.

4) Modify the first push_texture to be your *relative path*, using *backslashes*. This means something lik e push_texture(".\textures\16x16\simple.png").

Hrm... I doubt that will work as expected, since those are escape characters... this means you're trying to load "C:gamesternallands exturesx16simple.png" or ". exturesx16simple.png". (Unfortunately, some of the characters are missing, I know, they don't seem to copy over.)

Edited by crusadingknight

Share this post


Link to post
Share on other sites

Could you post your output, please? Thanks.

 

Ed: I just had an idea. How did you install SDL_image? On any linux-based binary package system, PNG support will be built into SDL_image, but I imagine that it might not be on Windows. Also, from the README:

 

...

 

Again, on a linux system, these will typically be depdencies of the SDL_image package. On Windows, perhaps not.

 

The output? Well It's just as crusadingknight said, those went bananas and "corrupt"... I have tried with double slashes too and still can't load... And as I said there is no output except for the usual:

"ERROR: Cannot load texture '.\textures\16x16/flare1.png'." And alike... I have tried all kinds of variations of this and direct path specific to my comp only.

 

How the SDL_image is installed? It's linked as a SDL_image.lib and has a few includes .h. I wouldn't call it an install, not in Windows.

 

And btw I just got PNG_SCREENSHOT to work, so I can at least create a png file from client, which means that libpng.lib and it's includes are working like they should.

 

So maybe it's about using SDL_image, isn't it possible to use the libpng instead? Or does that readme mean that for png projects you actually need more libraries, such as zlib and libpng?

 

Ent: Doesn't make any other output than the other cannot load textures. But I would probably say that after trying all combinations, that it's about the client not being able to read the png files properly rather than actually finding them. We did allready try that fp == NULL thing, which means that it at least has got a file opened. So the path is not the problem it seems, it's the loading of pngs.

Edited by Beaverhunter

Share this post


Link to post
Share on other sites

 

How the SDL_image is installed? It's linked as a SDL_image.lib and has a few includes .h. I wouldn't call it an install, not in Windows.

 

And btw I just got PNG_SCREENSHOT to work, so I can at least create a png file from client, which means that libpng.lib and it's includes are working like they should.

 

So maybe it's about using SDL_image, isn't it possible to use the libpng instead? Or does that readme mean that for png projects you actually need more libraries, such as zlib and libpng?

 

I'm on Windows and textures load for me without a problem... BUT:

 

When I look at the library dependencies, the SDL_image I have requires libpng12, while for PNG_SCREENSHOT I have libpng13 linked in. Luckly I have libpng12 available on one of 'PATH's so the client still loads. I also have zlib available for ZLIB support.

 

Maybe it's the same case with you? Try copying libpng12 and zlib dlls to client directory as see what happens ;)

Share this post


Link to post
Share on other sites

 

I'm on Windows and textures load for me without a problem... BUT:

 

When I look at the library dependencies, the SDL_image I have requires libpng12, while for PNG_SCREENSHOT I have libpng13 linked in. Luckly I have libpng12 available on one of 'PATH's so the client still loads. I also have zlib available for ZLIB support.

 

Maybe it's the same case with you? Try copying libpng12 and zlib dlls to client directory as see what happens ;)

 

Hmm yes that could be it, I have actually had problems compiling the libpng library... or well the dll file that is, so I do not have a libpng.dll... I hate those damn libraries that need compiling by the user and that includes projects that fails to compile with fatal errors... Ffs its so annoying.

 

Edit:

Oki, so damn tired of compling the libraries myself so I searched directly for them on the internet, and I found the dlls!!!! Both a libpng12.dll and a libpng13.dll... Downloaded them from DLL-dump and free-DLLs or something like that. I put them into the EL folder and bam!!! IT WORKS!

I currently have 3 libpng dlls in EL folder and linking 2 libpng libs... so this is quite messy just to get png working....But I'll check later on what I can do to optimize the file count in EL folder without having something not working. Currently it's a mess.

Thanks for the tip Kindar_Naar!

I was expecting the client to output some error if it couldn't find dlls it needed.... Maybe someone can fix so it does? Cause the client gave no clue on what it really needed.

For KarenRei: Back to work on some real stuff now;)

Edited by Beaverhunter

Share this post


Link to post
Share on other sites

 

I'm on Windows and textures load for me without a problem... BUT:

 

When I look at the library dependencies, the SDL_image I have requires libpng12, while for PNG_SCREENSHOT I have libpng13 linked in. Luckly I have libpng12 available on one of 'PATH's so the client still loads. I also have zlib available for ZLIB support.

 

Maybe it's the same case with you? Try copying libpng12 and zlib dlls to client directory as see what happens ;)

 

Hmm yes that could be it, I have actually had problems compiling the libpng library... or well the dll file that is, so I do not have a libpng.dll... I hate those damn libraries that need compiling by the user and that includes projects that fails to compile with fatal errors... Ffs its so annoying.

Avoiding excess libraries and issues is why in the past we have been avoiding using things like SDL_image, to help keep thesize of the distribution down and avoid unneeded .dll's

Share this post


Link to post
Share on other sites

You have to use two files if you want transparency with bitmaps; it's extra work. Plus they're huge, and thus increase distro size and slow down loading (about 7 times the file size if you want transparency -- would have increased EL's size by 6 additional megs). That's why I used pngs.

Share this post


Link to post
Share on other sites

You have to use two files if you want transparency with bitmaps; it's extra work. Plus they're huge, and thus increase distro size and slow down loading (about 7 times the file size if you want transparency -- would have increased EL's size by 6 additional megs). That's why I used pngs.

 

True, when it comes to arguing about file size, bitmap arguers can kind of never win. And currently as I understand ELC use a seperate alpha solution and applies it to the bmp. The ideal solution should be to use pngs all over, but maybe now when it's feature freeze, we shouldn't start on a conversion like this.

Should we do it after new client release? Is it worth it? Are there any other solutions possible? Any other format like png but maybe even more optimized? Make our own format?:P

 

Will the zlib solution to map loading be implemented by client release in May?

Edited by Beaverhunter

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×