A question about anti-aliasing and 32- and 16-bit color

[GarageGothic]

This is mostly meant as a question for CJ, but other people may have some views as well:

Which of these two is most likely to happen:

1) AGS supporting in-engine edge-anti-aliasing of 16-bit sprites (possibly with one of those filters used in ScummVM)?

2) AGS supporting anti-aliasing of scaled 32-bit characters using alpha channels?

Currently, the choice is between the edges looking bad in 16 bit and the whole character looking bad when scaled in 32-bit. I'm *THIS* close to abandoning 32-bit color altogether, in part because of this, in part because of size/performance. Any kind of answer, no matter how hazy, would be a great help in making up my mind.

[scotch]

This was confusing to me, until I remembered the different meanings antialiasing has in AGS... the alpha channel on sprites is usually used for antialiasing the edges, and that's what most people think of as antialiasing, then there is also "scaling antialiasing", which I think is confusing. Sprite filtering, similar to the term "texture filtering" in 3d graphics, would be better imo.
But you're basically asking for both to work together, right?  I think that's more likely to be implemented than scummvm type graphics filters, could be slow... but no slower than the alternative.

I'm hoping AGS will have a 3d hardware mode in the future, making all these graphical things so simple, but that's a long way off if it happens at all.

[strazer]

Sprite filtering, similar to the term "texture filtering" in 3d graphics, would be better imo.

I agree.

[Snarky]

I guess it depends on what your background is, but don't you think "smooth/high quality sprite scaling" would be a more understandable term?

I don't think GG asked about it in the first place, but I would quite like to see some graphics filters to stretch the screen over higher resolutions, like in ScummVM.

[strazer]

high quality sprite scaling

Yeah, that's even better. No misunderstanding there.

[Pumaman]

Yeah, perhaps the "Anti-alias scaled sprites" option in Setup should be renamed to "smooth scaled sprites" so as to avoid confusion.

AGS supporting in-engine edge-anti-aliasing of 16-bit sprites (possibly with one of those filters used in ScummVM)?

Automatic edge anti-aliasing would be too processor intensive to pull off in 2D, unfortunately.

Whole screen filtering (like ScummVM does) would be possible in future -- it's something that has been discussed several times before. Basically, the conclusion was that it's difficult to find a filter that can be used in AGS, due to the various licensing terms.

AGS supporting anti-aliasing of scaled 32-bit characters using alpha channels?

This would be more likely to happen.

[GarageGothic]

Thanks to everyone for your replies.

It seems that I'll better stick to 32-bit for now, despite the size (would it be possible to have an option to import backgrounds and non-alpha sprites in 16-bit to save space?).

BTW, I agree with everyone's view that the "anti-alias scaled sprites" option should be renamed.

[scotch]

I wonder about compression in AGS, I understand it's not such a big thing for people making games in lower resolutions but I'm working at 800x600x32bit, just one of my backgrounds using PCX compression is 3.25mb, at that rate just the backgrounds would be around 150mb in the end. Now of course I don't know how things work within AGS but in the limited programming I've done loading image data from compressed formats is almost as easy as loading uncompressed data when using something like DevIL.Ã,  Some 3d games save their data in compressed formats, sometimes even slowish ones like PNG, and it doesn't take too long to load the textures, so I think it's workable.

I played with a plugin that loads external jpg backgrounds and draws them (in AGSE_PRESCREENDRAW) placed over a blank background in AGS (which is compressed to almost nothing with AGS's RLE).Ã,  It wasn't hard to make but you still have AGS drawing whatever blank background you put in there which is a few FPS drop and you still need to get the hotspots and all placed in the editor, without a background in there to guide you.Ã,  So it's less than ideal.Ã,  By the way, that same background in acceptable jpg quality is 350kb.

If there are no patent issues I think JPEG2000 would be the best format to support, it gets better compression than png in lossless mode for people who want that, and better compression than jpg in lossy mode for people who need small filesize, I can get down to 250kb in that.  But jpg would be fine.

Perhaps I could write an editor plugin that allows you to use an external background within the editor... I haven't looked at that.

For sprites I have no idea what would be possible... I know JS is looking like it'll end up having a 100mb exe file 98% of which is sprites.  Zips up well of course.

[Pumaman]

What sort of size room files are you getting? How does the AGS compression compare to PCX?

AGS uses a GIF-style compression method, which should yield better results than PCX (though not as good as jpeg/png).

PNG or JPEG support for compressing backgrounds internally would probably be possible now; back when AGS was first written there were no decent libraries to do so, but times have changed. However, the current compression method shouldn't be too bad.

[faggc]

What sort of size room files are you getting? How does the AGS compression compare to PCX?

AGS uses a GIF-style compression method, which should yield better results than PCX (though not as good as jpeg/png).

PNG or JPEG support for compressing backgrounds internally would probably be possible now; back when AGS was first written there were no decent libraries to do so, but times have changed. However, the current compression method shouldn't be too bad.

And what about the question made by scotch related to sprites? Since AGS suport GIF compression, is it possible to have the option to compress sprites in the exe? The default option should be "do not compress sprites" (good for slow computers). This could help a lot for HI-RES games.

[scotch]

I made a mistake looking at the size of the first background in PCX, it was saved at 1024x768 rather than 800x600.

I put the background into AGS, scaled down to 800x600.
Bare game, no rooms - 1.20mb
One test room, 32 bit - 3.80mb
I am not sure what the overhead of creating a bare room would be aside from the background, but I expect most of that is the background.
However that is a scrolling room, I expect an average one would be about 2/3 the size.

2mb per background I could live with I suppose.  If you ever support 1024x768 it would jump up quite a bit again, I know that isn't planned for now. Some compression would still be nice, in jpg that 800x600 scrolling room is 200kb (70% quality, enough for me), over 10 times smaller.

Just for comparison, PCX would appear to be around the same for compressing my kind of background as AGS's compression, that background ends up as 2.12mb at the correct size in pcx.

If there is compression there'd need to be lossy and lossless modes, jpg would play hell with most low res styles, and png isn't very good at compressing my kind of background.

[Pumaman]

And what about the question made by scotch related to sprites? Since AGS suport GIF compression, is it possible to have the option to compress sprites in the exe? The default option should be "do not compress sprites" (good for slow computers). This could help a lot for HI-RES games.

Sprite compression has been discussed several times in the past. Basically, because sprites are dynamically loaded as necessary in the game, the performance hit of having to decompress them would probably cause more problems than it would be worth.

However, a very simple PCX-style compression could be added to sprites as an experiment, but it's not a priority right now.

2mb per background I could live with I suppose.  If you ever support 1024x768 it would jump up quite a bit again, I know that isn't planned for now. Some compression would still be nice, in jpg that 800x600 scrolling room is 200kb (70% quality, enough for me), over 10 times smaller.

I would be wary about incorporating any lossy image formats into AGS, since whenever the room is re-saved the image would be re-saved, and you'd lose some quality each time. PNG support looks like the most likely candidate for an alternate compression method.

AGS's current background compression algorithm was designed for 8-bit backgrounds, so in a way it's not surprising that it doesn't work particualrly well with hi-colour images.

[scotch]

I don't see why you'd need to recompress, surely the editor can notice that the background has already been compressed and leave it alone  (Personally, I wouldn't mind if there was just an option not to save a background in the game and have it use an external background file).

Png would be ok, I find it's much slower to load and save than jpg, and is still more suited to line art than fully shaded graphics, but if you support one compression format that should be it.  Gets my test bg down to 1.2mb, which is acceptable.

[Kweepa]

I would be wary about incorporating any lossy image formats into AGS, since whenever the room is re-saved the image would be re-saved, and you'd lose some quality each time. PNG support looks like the most likely candidate for an alternate compression method.

I think the only way that lossy backgrounds could work would be
- if the game author loads a bmp, it is compressed to a png in the room file
- if the game author loads a png or jpg, it is just stored as-is in the room file
So the editor never compresses to a lossy format, but game sizes are kept low even if the game author decides to use bmps as the source format.

Steve

[scotch]

Or alternatively, things are kept as they are in the room.crm files that the editor uses, and everything is compressed wih the desired settings and put into the exe at compile time, keeping the originals intact.

[Pumaman]

I don't see why you'd need to recompress, surely the editor can notice that the background has already been compressed and leave it alone (Personally, I wouldn't mind if there was just an option not to save a background in the game and have it use an external background file).

Well yes, that would of course be possible to do; it'd just require a bit of extra work.

Anyway, I really don't want to add too many image formats to the engine, but if there was to be one extra one, would people prefer JPEG or PNG?

[strazer]

PNG

[scotch]

JPG personally The current system already compresses the kinds of image that PNG is good at fairly well.  Not that PNG isn't a lot better at some things... but JPG would add more versatility and PNG decompression is quite a bit slower, noticeable lag loading a large png even on my 2.6ghz system, I'd guess the jpg version is 1/4 of the time to load.
It would have to be optional of course, if it was jpg, png could completely replace the current system.

[Kweepa]

JPG personally The current system already compresses the kinds of image that PNG is good at fairly well.

Agreed. I don't foresee a need for JPG in AGS myself, but then I'm not in the market for better compression anyway.

Not that PNG isn't a lot better at some things... but JPG would add more versatility and PNG decompression is quite a bit slower, noticeable lag loading a large png even on my 2.6ghz system, I'd guess the jpg version is 1/4 of the time to load.

I'm pretty sure jpg is slower *decompression* - it's probably faster because the bottleneck is getting the compressed data off the hard drive, and the png is much larger than the jpg.

[scotch]

well I'm sure that is a part of it, but png is rather slower to encode and to decode, I have two 1mb images here, the png still takes longer, and the png is lower resolution.  Neither are too long to wait anyway, just a small thing in jpgs favour.