New login background

[Korrode]

The reason it works, (I've done this with other programs, not just EL) is because the client simply looks for the .bmp extension and loads that. It doesn't care "was it saved as a bmp".

Yeah i know ;p the extension is just part of the filename, and the software looks for a particular filename. The idea of extensions dictating the format of the file is traditionally very much a Windows thing. (tho it has bled over to other OS'es now.)

To most everything, an image file is an image file. The extension it was saved in is more of a matter of compression at time of saving than anything else.

Well i have to disagree.
An image file isn't just an image file.
A JPEG renderer cannot process a PNG, a GIF renderer cannot process a TIFF, IE6's PNG renderer cannot handle standard compliant PNG transparency, and a BMP renderer cannot process a JPEG.

The fact you've encountered many softwares that are capable of rendering many different image formats doesn't mean all software will be able to. Software can only render an image it has a library for (whether in-built or otherwise). All these 'non-specialized' formats are still very different.

Your theory would dictate that using jpeg compression anywhere within the client and just renaming to .bmp would work, but it doesn't. For example, try converting some of your meshes to jpegs and giving them a .bmp extension and try to use them... it doesn't work. The software strictly expects 8bit image data for meshes, and anything that's not 8bit renders incorrectly. (i did discover tho that 8bit PNG's can be renamed to .bmp and work).

The reason i ask for Windows users to test is to find out if the EL client itself does infact have JPEG and PNG decompression in-built or if when i ran it on Linux it was just using my system image rendering libraries... but no matter, i remembered EL uses SDL_image, which supports at minimum PNG, JPEG and TIFF.

[krayon]

But I am a * He * if that was directed to me

No I believe *she* was referring to your earlier comment:

Hopefully EndorVaeros can get the BMP version, put the text on, and shuv that up (although in a ZIP/TGZ/RAR/ACE/7z so it's not HUGE).

I think he will also have to make it 1024x1024 instead of 800x800

Download link is a nice big orange button under the advertisements.

http://www.sendspace.com/file/h3y9x8
http://www.sendspace.com/file/87zd9y
http://www.sendspace.com/file/f7bz0m

Until I have the proper contribution system operational, you can just upload directly to my server by going here:
  http://www.datapax.com.au/upload/

This is quicker and easier than signing up to a service as the above, and saves us all the pain of launching a browser, viewing their ads etc   Oh, and faster downloads too probably.

To most everything, an image file is an image file. The extension it was saved in is more of a matter of compression at time of saving than anything else.

Well i have to disagree.
An image file isn't just an image file.
A JPEG renderer cannot process a PNG, a GIF renderer cannot process a TIFF, IE6's PNG renderer cannot handle standard compliant PNG transparency, and a BMP renderer cannot process a JPEG.

Each piece of software MUST implement explicit support for any given format and usually even colour depths.  The reason you would notice this sort of behaviour is the generally the use of an library that supports loading many formats.

It's still up to the application however, to use the data it gets correctly and in the event that it (the application) is manipulating the data in any way, there's no guarantee the image will work as expected despite the library supporting the loading of it, ie the images in the "/meshes" sub directory.  EL uses SDL so it can LOAD a 24-bit PNG, but because the EL client devs expect SDL to give them 8-bit image data (note at this stage it's no longer a PNG or BMP etc, it's image data) they don't manipulate it correctly and therefore it doesn't render correctly.  This is in part their fault in that they should be checking the data meets their requirements (ie 8-bit) before blindly manipulating it.  If they did, instead you'd get an error saying "You're using a non 8-bit texture ... stop that".

NOTE: The above is an assumption as to what's going on (though completely plausible and likely to be the problem), I haven't actually looked at the client code related to this issue at this point

The reason i ask for Windows users to test is to fiind out if the EL client itself does infact have JPEG and PNG decompression in-built or if when i ran it on Linux it was just using my system image rendering libraries... but no matter, i remembered EL uses SDL_image, which supports at minimum PNG, JPEG and TIFF.

Yes, it does indeed.  Moving forward I will probably change the client to look for files with various extensions (both gzipped and not) that it has support for.  I will also investigate why it insists on 8 bit for textures in the meshes directory