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
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 pointThe 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
Show Posts
It's hot like an Duke Nuke Forever premiere 
