Messages

And always remember, even if you utilize the middle button/wheel functions, make the game playable without them, as some people (like me) don't have a 3-button/wheel mouse.

Hmmm can it be coded so that upon importing a sprite:

[Crappy pseudo code]
RLESprite=RLECompress(Sprite);
if (Size(RLESprite)>=Size(Sprite)) Store(Sprite);
else Store(RLESPrite);
[/Crappy pseudo code]

But then I think it's probably not worth the effort and the currently implementation is fine already.

Yeah that's a good solution too.

Because it DID support GIF, only was that it was removed.

The reason was that the GIF decoder used was quite buggy, which could crash the editor or generate other strange effects, so the easiest way to fix it was to remove it. As I mentioned before, no matter what file format you use for import, the game file size will be the same, so there're no point to waste time to re-implement it.

Of course, it would be cool if the editor supports animated gif import which would be an easy way for multiple sprite importing. But I think because of the patent (I think it's expired now or soon to be expired in most part of the world) on LZW compression and CJ probably took his time for more important featurs (and work and life!) so nothing was done on it yet.

Heh, this and the maze part are those that I like most. They lengthen the game too.

1. AMD K6-2 600MHz
2. PCI S3 Savage4 with 32MB DRAM
3. 512MB
4. M$ DOS V6.22
5. Nope
6. My genit.... WAIT! Nothing in the computer I think.

And no, I'm not kidding, I'm serious.

EDITEDIT: But now I see Andail has moved it to the crit lounge...

[Fe]to <-- Really? I think Andail had just commited a sin now for breaking teh rules![/Fe]

I think RLE may help (PCX uses RLE), but may not work out good for sprites with large variations of colours (eg. gradient filled hicolour sprites, photorealistic sprites, etc.). I still think it's worth a try adding RLE compression on sprites as it probably don't affect much on performance and should help in reducing game sizes in most cases.

A tablet is something you take if you're sick or want to enhance some of your parameters for a short period (e.g. artistic skill in this case).

What a coincidence! The Artistic Enhancer tablet (commonly called Artigra) looks very much like the yellow thingie in teh Counterfeit banner!

If you just want integer roots you don't need a plugin.

http://www.agsforums.com/yabb/index.php?board=10;action=display;threadid=9250

Always remember, don't use plugins unless you REALLY need to, as they break compatibilities.

Edit: Hm, I've just realised that any key pressed after the FlushKeyPressed call would be ignored too...Ok, forget it then.

Right, that's my point, the problem was that it recognizes the key pressed BEFORE the sequence.
As I mentioned before, I had fixed my problem with some messy codes, but a function like this can still be handy.

I disagree with the use of BMPs for AGS import because theyare excessively large.

Well, the size is the same after import, so there're no problem using BMP as import unless you're low on disk space for storing the working files.

hey freind just a quick one, on your map drawing, North should be pointing...North. I think its like that on all maps. Looks interesting.

Heh no, this is just a misconception. We incorporated many exercises of north not pointing "upwards" in our books.

[just before]

Hmmm I don't know if there're easy ways to do this currently but seems that similar function was not provided with V2.6SP1 (with which I had to do some messy scriptings to get past this).

The problem is this:
When a game is "not in control" (eg. while running blocking functions) the function on_key_pressed() (either global or room ones) won't be executed, this is okay and is the expected behaviour.

However if the player pressed a key just before the (series of) blocking sequence (eg. a cutscene), it's possible that the key pressed got recognized, but the on_key_pressed() function would be execute afterwards, which may not be desired sometimes. (Eg. In a game, the player accidentally pressed TAB before a cutscene started, it's possible that the inventory GUI would pop up after the cutscene, which is not always expected).

So, I suggest adding a new function: FlushKeyPressed(), which the game designers can put it in wherever suitable places (eg. at the end of a long animation), which will clear the currently pressed key, to prevent the on_key_pressed() function triggered for some reasons.


EDIT: Oops! How f00lish I am! I clicked the wrong forum and didn't notice. Please move this to the tech forum.

Just use 0, if I remember right, the FALSE constant name should be all in CAPS (if it's really predefined, I can't remember).

If you know more about her, you know she's serious.

[whatever]

Did you put something like:

import function interface_click(whatever);

in the script header or on top of a room script?

In that case, remember the number and type of characters for that function (in this case teh "whatever") MUST match the one defined in the global script.

In the global script, the function interface_click() accepts two parameters of type int, so that import line should be something like:

import function interface_click(int gui, int button);

Check whether the number and type of parameters match this.

[GOD]

Please don't. The forums are for everybodies, and our GOD kindly pay for it. If you continue posting like this, you would probably be banned soon.

Moreover, that's NOT only 23 posts a day, as there're many posts before you registered in the beginners tech. forum.

with... colour?

you may have a point!
I'd be surprised if anyone read the forum rulz though, {u'd have to be crazy }

This is not a correct attitude I'm afraid, you SHOULD really read the rules on what, where and when to (and not to) post something.