Silly and quick question: Does GLBasic not allow the use of JPEG/JPG files when using the LoadSprite/LoadBMP commands?
I've got an image in JPG format and it doesn't display. The same image in .PNG format works fine. The name of the file is exactly the same, as is the pathway, it's only the format that changes.
No, JPG doesn't work
http://www.glbasic.com/forum/index.php?topic=2103.msg17083#msg17083
Cheers chaps. :)
I did do a search, but it brought up mainly German stuff and didn't seem to bring up that piece at all - must have missed it.
Perhaps the documents should reflect that only .BMP and .PNG are supported?
Ahm - sorry Ian, but my (german) docs DO reflect that. Have a look under tutorials - graphics(2D) for the explanation of sprites. There is mentioned that all graphics loaded in GLB can only be BMPs, with the only exception of PNGs.
That's the problem with docs. They are quite bloated now and not all information is everywhere where you need it :/
Quote from: amarliani on 2009-May-20
Ahm - sorry Ian, but my (german) docs DO reflect that. Have a look under tutorials - graphics(2D) for the explanation of sprites. There is mentioned that all graphics loaded in GLB can only be BMPs, with the only exception of PNGs.
But as I don't read German, I don't read German docs hence me not knowing this. ;)
I've never needed JPEG before (in a GLB program), having always used .PNG and .BMP, so I was surprised that JPEG wasn't supported. I've never used a coding language in the last 10years that didn't support it tbh. It's not a great deal, but my image in .JPEG format was about 50kb and the .PNG was over 500kb and the quality difference was minimal, virtually identical on GP2X. Memory and file-size matters on these small handhelds (even with SDHD cards).
Won't PNG and JPG use the same amount of memory after unpacking? Mabe JPG will even use more since it needs another decoding library?
It'll still use the same amount of RAM once loaded into a machine, whatever the image format, however memory card space for these images is what I was talking about - the difference is 10x with just one image - I want to use at least 10 images, which makes a a very big difference - 1/2Mb to 5Mb.
You could use uncompressed images and then compress them with shoebox (shoebox does compress files, right?)
Other method is to drop colours from your images. You could drop down to 256 colors without anybody really noticing.
That's how it's done in current DS development studios for example. Most of the image data is either compressed (lossless) or colour-reduced. Playstation 2 textures were sometimes even 16 colour. Not bad for a 2001 "next-gen" system, eh?
EDIT: One thing I just remembered... I have noticed sometimes that GLB won't display heavily compressed PNG files (ie. level 9 compression in GIMP). When lowering the compression level, everything worked fine.
TBH it's not worth the (minimal) hassle. All I wanted to know really was if GLB supported JPEG and I got my answer. I'll do something else instead...
Cheers Ocean, but like I said, it's not a big deal and I've got another idea instead :)
Right, sorry to drag this old one up again, but...
I know Gernot stated that .PNG was "the way to go", this was obviously before the iPod/iTouch compilation was possible.
Now that we can use those machines, wouldn't support of JPEG format be beneficial? After all, the iPod etc. were designed for storage of things like photos etc. Viewing them via the iPod is OK, but what if you want to manipulate them? GLBasic could be used for an app to view and do this.
There was a demo over on GP32X that used GLB to scroll photos (in .PNG) format on Wiz that used them like an iPod. It was excellent. However, users won't convert JPEG to .PNG to use this viewer, so it's effectively dead. :(
I don't know if it's a licensing issue with regard to the JPEG format, but it's a format that is used in EVERY digital device that deals with images and it really shouldn't be missing from GLB (IMHO). It really is very useful and could add another string to the bow.
It also happens that BattleCards could do with JPEG support ;)
Oh my.
Good. I'll add it to my ToDo.
I think thats OK :)
QuoteThat's the problem with docs. They are quite bloated now and not all information is everywhere where you need it :/
There is always my online documents - everything is where I want it to be there :)
OK, next update features JPEG support. :giveup:
Nifty!
One step closer to GLB_Webbrowser() !
Ian, this should be your next project (forget the roof tiles) :P
QuoteIan, this should be your next project (forget the roof tiles)
Um... No. Actually, I'm not even sure what you mean :S
Nice one Gernot :)