GLBasic, 2008/2009 plans

[Kitty Hello]

A few things to set straight here:
BMP - raw data+header. Up to 32 bits (4 bytes) for one pixel.
JPG - can compress very small, but might have artefacts.
PNG - something like zipped bmp. No quality loss, great acceptance in any program, quite small, no loss
GIF - can compress with RLE (worse than zip) but is limited to 256 colors! The license thing has been dropped now.

What you might safe when using JPG is what you gain in .exe size when I include JPG support. Thus, I dropped it.

[Kuron]

GIF is lossless, i.e. no artefacts.

Yes/No.  Technically (data wise) LZW is a lossless compression, but GIF is not a lossless format.  With the visual quality of GIF images, the artifacts can be worse than what they are in JPG due to the limited palette.  Like JPG, with GIF, you can adjust the dithering/algorithims used to keep the artifacts at a minimum.

[Kuron]

if you have to reduce color content BEFORE saving that image as a GIF

That was my point, you pretty much have to unless you are targeting archaic or obscure platforms.  Any artwork I get or textures I grab with a camera or scanner are true color  

PNG to the rescue

Amen!

It is the 21st century.  The GIF format is almost 22 years old and serves no purpose today.  If you load an 8bit gif it is handled as 24/32bit (depending on your graphics card), not to mention loading slower than a 24bit BMP.  There is no benefit.  The only reason it is still around is because Microsoft has such trouble figuring out how to implement support for PNG transparency in IE.  I hate having to use GIFs on my site because of the darn IE users.

[Hemlos]

Hemlos:  For Windows, you could use the API to load those formats.  GIF and JPG are useless for gaming due to the compression artifacts.  PNG would be nice, but ONLY if the alpha channel is supported.

If you read my request, it is due to complimenting the netwebget command, not for gaming.

And PNG is already implemented.

Regardless of artifacts and compression rates, netwebget retireves a file and saves it to the name you want.

You can use netwebget to retireve XML outputs, realtime maps, and if gif89 is implemented...then we could have animated graphics....this would be nice instead of having to layer bmp/png's

It would also be nice to be able to build a gif89 with glbasic.

About using the APi, i looked into it, and i cant figgure it out.

[Kuron]

About using the APi, i looked into it, and i cant figgure it out.

If you look at Planet Source Code, you will find literally hundreds of examples of using the API to load GIFs.

[Hemlos]

Arg Kuron youre going to make me do it? im gonna turn it into a sharware library if i have to.

Edit:
Search plant source code: gif89 in c++: No records found matching your search.
Search plant source code: gif in c++: convert gif to bmp, and other code to breakdown the gif

but none of the 4 codes listed show how to implement them into drawing them in opengl with glbasic.

[Kuron]

Your search criteria could be better.  There are examples for using the API for loading animated GIFs and custom loaders for animated GIF.

Alternatives are read up on the format at Wotsit.org and write your own loader, or use any of the numerous third-party DLLs that will load GIFs.

[Hemlos]

This is GLBasic, what you're talking about is a bit off-base(ic), and out of my league.
I was just making another addition, suggestion, for the year ahead as the topic suggests.
The idea is to compliment the NETWEBGET command, to give NETWEBGET more power, inherently, innately, fore; GLBASIC Editor is expanding in versatility....as it has been for 8 years.

Adding the ability for glbasic to view jpg and gif, would compliment the internet functions, thus adding a whole new dimension to GLBasic's power, and a bit more net-savvy.

[Kuron]

I was just offering some suggestions in the event that Gernot doesn't implement GIF support.

[Moru]

We already had the discussion about JPG-support half a year ago. Since it will make the exe-file much bigger it's a no. We don't want bigger exefiles since it's supposed to be run on small computers/PDA´s too. If you want GIF and JPG support it has to be done with external DLL´s or similar

[Kitty Hello]

Next version will be a big update. Due to the WIZ support there will be a new setup required. New features will include natural number (integer, no floating points) support. This is very convenient for GP2X/WIZ programming, since they don't have an Floating Point Unit. Thus, the speedup will be quite immense when you use them carefully. You will be able to mix strings/naturals and floats, as you expect.
So, in order to prepare this, you can use the postfix "_N" e.g. and replace that with "#" later.
I might have to change the READLONG and other functions. No big deal, though.

[doimus]

Is there going to be full 3D support for WIZ, since it does have proper hardware acceleration?

[Kitty Hello]

when there's a driver, yes. Of course.

[Ian Price]

Cool beans

[bigsofty]

Next version will be a big update. Due to the WIZ support there will be a new setup required. New features will include natural number (integer, no floating points) support. This is very convenient for GP2X/WIZ programming, since they don't have an Floating Point Unit. Thus, the speedup will be quite immense when you use them carefully. You will be able to mix strings/naturals and floats, as you expect.
So, in order to prepare this, you can use the postfix "_N" e.g. and replace that with "#" later.
I might have to change the READLONG and other functions. No big deal, though.

Hehe, this will suit me, I've always found that using floats in situation that require integers, rather disconcerting!