Messages

BUMP: everyone ded?

Sprites are converted to raw bitmaps when you import them in project.
To compress them enable "Compiler / Compress the sprite file" in the general settings.

Alright. But I hope it's lossless compression.

Hi,

I know it has been explained numerious times, but I can't seem to find the information.
Suppose I have many sprites that would take very little space if they were RLE-compressed.
What would be the best way to reduce my game size? Does it work if I import .PNG files for sprites, or are they immediately converted to whatever format by AGS?

Thanks a lot for all the hard work.

[int TrashMet=0;]

Let's recap :

int TrashMet=0; // <-- This should be a GLOBAL variable! Ask if you don't know how to do
... //your dialog stuff
TrashMet+=1;
if (TrashMet==1);  //removed the semicolon
{
    dTrashConversation.Start();
}

I suppose you want dTrashConversation to start only the first time?

[Tuesday the 8th]

I'd like to request a time extension. There are elections this weekend in my country, and it's going to be totally frantic until Sunday and even a few days after.
Could we extend from Tuesday the 8th to Sunday the 13th? Pleeeeze.

At first I thought it said "RobCo", I thought it was a Fallout adventure game.

Still a work in progress.

Selmiak, of all the people, how do you NOT know the color depth of "the game I'm working on"?

You can get inspiration from the BMP 2.0 module which allows some reading and writing from several AGS color spaces (just throwing my two cents, please ignore if it doesn't contain any helpful function)

[EDIT: I've found what AGS does incorrectly]

I've been running some tests, and AGS definitely fails with those 24-bits BMP's it generated by itself.
However if I generate them with my BMP 2.0 module (which can be found in the forums and does all the encoding brute-force when using the eBmpString mode), then the import works properly afterwards.

It might point to the fact that there's something wrong with the way AGS encodes BMP files.

EDIT: I've found what AGS does incorrectly: When using DynamicSprite.SaveAsFile, it turns indexed color 255,0,255 (magic pink) into 255,1,255 (dirty pink)... Hence ruining the magic pink (the fact that the first sprite worked was just a "lucky" mistake on my side). So the issue has nothing to do with "Quick Import Sprites", but instead is caused by the way AGS approximates RGB values when saving 24bpp files.

So the problem is not AGS's importing but the exact format of the file. BMP's don't support layers though, are the files all saved as BMPs?

Yes, they are.

- I first made an 8-bit game to generate my palette cycling, then did a "SaveScreenshot" on each frame, which generated BMP files. It generates 8bpp BMP files.
- I created another AGS game (32 bits) which opens these BMP files and saves them back again. I suppose it generates 32bpp files. EDIT: I've just opened them with a Hex editor and I noticed that they're actually 24bpp. But I wouldn't expect that to mess up the import process.
- It's when I then import these BMP files into the 32-bits game that the issue happens: The first one is OK, the following ones (quick import) miss the pink transparency.

BURNT OUT

"When one Prozac is not enough"

Billbis, "leave as-is" uses Magic Pink for transparency, as opposed to picking another color I guess. The option for "no transparency" is called exactly that.

I can't confirm this; I imported a sprite using leave as-is, then quick imported two more. All had their pink parts become transparent in-game just fine (3.2.1)

Dammit.
µCould you try with 3.3.4, just in case?

I didn't understand your reply.
My first import is & 32-bit BMP with no alpha channel, but some parts with "regular" colors, and some other parts that are only made of magic pink. therefore, the parts with colors are opaque, and the parts with magic pink are transparent.

So the palette cycling is not visible yet?

No. I've made it and still working on exporting it.

[HERE]

So I've read HERE that when you do a "quick import sprites", it re-uses the setting you used the last time you did a regular sprite import.

So I did this:
- first I imported a sprite the regular way, and left transparency "as-is". This sprite is a bmp file (no alpha) in a 32-bits game, and has pink (transparent) parts.
- I ran the game to check that once used as an object's graphic, the transparent part was, well... transparent, as expected.
- I imported a second sprite using "quick import", added that sprite into a view after the first sprite, and did a "SetView" and "Animate" on the in-game object.
- The first sprite still has transparent parts, but the second sprite's pink parts appear pink on screen instead of transparent.

So, how to I import a whole bunch of sprites with the same transparency settings?

:'(

From the Wiki:

Two good choices of such programmes are Deluxe Paint ][ Enhanced (DP2E) and Grafx 2, as they're 8-bit pixel graphics editors and they won't do foolish things automatically (like "friendly" sorting and trimming your palette, merging slots with similar colours, dithering you images, etc.).

Anyway, if one seriously need to use 8-bit images use only real 8-bit editors.

That's precisely the ones I'm using, but as I explained in another thread, my issue is then to render the palette cycling in a 32-bit game, which means "exporting" it first. I'm on the verge of succeeding.

I'm expriencing extreme frustration right now, because my original file is on a different computer (to which I won't have access until tomorrow) and right now I'm stuck with two files: One imported by AGS, with the palette messed up, and the other one saved by Photoshop, with the palette automatically rearranged (a.k.a messed up). So both files are useless. JUST LEAVE MY PALETTE ALONE, YOU M*TH*RF*CK*RS. Pssssh.

SON OF A ....!!! I've thouroughly searched the game options, but I never noticed that there were additional settings in that submenu.

As per the palette-display script: Thanks a lot! I guessed that you had written something like that after viewing your picture. That'll surely come handy.