Messages

Oh, I just saw that you use "Flash". i overlooked that. It gives a more accurate answer to question 3.
Well then, save as PNG with an alpha channel (for the reasons I mentionned in question 1), and import it into AGS the same way. Problem solved.

Hello, your question contains three questions :
1) How does the file format affect the quality of the sprite?
2) Why does my image look smoother with JPG?
3) How do I avoid dirty pixels on the outline of my sprite?

About Question 1) :
  - never use JPG, try not to use Gif. JPG is not suited for sprite-based games, because it compresses the image. It means that it introduces "errors" (the final pixels don't have exactly the same color as the original pixels when you createde the image). That's a lot of random hazard. Gif is limited to 256 colors, it's not so cool nowadays.
  - try to use BMP or PNG: BMP is fine but it's not compressed (the files can become quite large quickly). I'd recommend PNG, because it has lossless compression: that means the files are smaller but it doesn't intriduce errors in the image. All good.

About question 2) :
You said "the image looks smoother as JPG than PNG". Well, that's just coincidental. Since JPG intriduces errors, that causes some edges to look less sharp. But if you want images to look smooth, that's not the right way of doing it. You should make them look smoother in your drawing tool, and THEN when they look exactly the way you look, you should save them in the proper file format (I still recommmend PNG).

About question 3): if I understood your issue well, that's a typical beginner's mistake with AGS: When you work on your image in your drawing tool, do you have a colored background behind it? (e.g. pink, white, black, etc.?).
If yes, then it's very likely that some of your pixels on the outline of your sprite are not 100% the same color as your background color. You cannot see it with your bare eye, but those pixels are "almost pink" or "almost black" but not "exactly pink" or "exactly black". Then when you import the sprite into AGS, everything that is not exactly the same color as the background color is not turned "transparent", it keeps its color. Hence the dirty pixels.

[(s2 would be some sort of transparency mask for s1)]

[AGS 3.3.0]
I'm struggling with a paradigm that doesn't seem to have a straightforward solution in AGS.

- I have a sprite s1 (it has some transparent pixels, i.e. a custom shape).
- I have another sprite s2 that also has alpha: I use only for its shape.

I want s1 to be "recut" with the shape of s2: Its transparent bits should remain transparent, but the non-transparent bits should become transparent if s2 is transparent in that location. (s2 would be some sort of transparency mask for s1).

I thought I was a smart guy by doing CopyTransparencyMask of s2 over s1... what I didn't anticipate, though, is that the alpha channels are not additive -- that means everything transparent in s2 becomes transparent in s1, and that's cool,  BUT everything that was transparent in s1 becomes pink. Dang.

Is there a simple way to do that? Or am I doomed to process the sprites pixel by pixel??? I've scripted that solution already but I don't reach sufficent performance rates.

Please add funky animated sperms as cannonballs.

No way! Do not confuse randomness and bad taste!

BALLISTIC NIPPLES

[imgzoom]http://24.media.tumblr.com/a8da59039c040d9b78303a69da5476a6/tumblr_n3vnxnFhgf1tsfksfo1_1280.png[/imgzoom]



DEAL WITH IT.

Two updates:
1) I just added a shield for Fremont. And I bet this time nobody can go past it!
2) I just added a minigame so you all better start practicing your Gorilla skills to beat it : https://www.youtube.com/watch?v=UDc3ZEKl-Wc

The AGS Awards ceremony is the best example: it's not a game, it's a chatroom. And its rocks.

As usual: Spent 30 minutes trying to find the solution. Found the solution 1 minute after posting.

The resolution was wrong in the sriptes' properties (except the very first one for some reason). When I re-imported them while troubleshooting, I did "re-import from source", so that kept the wrong setting.  SOLVED.

[AGS 3.3.0 stable]

I just started a mockup game from the VerbCoin template, and changed its resolution to suit my needs (I don't think it's the cause of the issue but I'd rather mention it).
- when the character is not walking, he's at normal size.
- When the character is walking, the walk cycle gets scaled up (x2). That shouldn't happen!

To be sure that wasn't caused by the initial resolution change  (I know it's rarely a good idea to do that after importing some assets), I created a brand new room, re-imported all sprites, recreated the walk view.
But the issue is still there. I suspect it's caused by some general setting, but I wouldn't know which one.

"I'm not a robot, I'm a UNICORN"

(kudos for those who get the reference)

Don't you find it amazing how an OSD game has such a high power of confusion and randomness even when it's made by someone else than icey_games and yet the confusion is not cast on purpose? That's why OSD is so unique!

*Thrivaldi Sign Of Approval*
(but Fremont always has some kind of shield )

I was sort-of hoping you guys wouldn't read that post beofre the game release, that would have been a nice surprise for you (well yes it doesn't make much sense after posting that screenshot).

It's true, Fremont doesn't have a shield there. I got lazy when fitting the sprite... Worse: in the game files, he's called cThrivaldi. Shame on me!

Another guest star!
Say hello to Heroine's Quest's Fremont, the mediocre bridge-keeper!

Every serious AGS-er should recognize the threat that this rabbit represents

Add a score for rapid cutting- you see where this is going!

Good idea. I'll see what I can do!

OK so I've just added a feature that allows Dennis to cut any element present in the set in two with his giant sword. Samurai style!
Fully-destroyable set.

The only problem now is... It's SO pleasurable and fun to cut trees, lamp posts, bushes and rabbits, that I can't stop doing it and the progress of the project is very slow

In the meantime I found the cause and it's really really stupid : DrawImage fails on backgrounds (with weird side effects) when you didn't explicitly set a background image for your room. I assumed the engine would just generate a black image. It doesn't. Any attempt to use the result of Room.GetDrawingSurfaceFromBackground() creates unpredictable effects.





==============
On a different topic :
Reupload of version 1.1 : http://www.adventuregamestudio.co.uk/forums/index.php?topic=50356.msg636486336#msg636486336

[PROBLEM 1: The game crashes with following error:]

I'm using the stable build of 3.3.0 : Build 3.3.0.1156

The following scenario is extremely easy to reproduce.

1) Create a 32-bit game
2) import a sprite with alpha into it
3) in your room's or module's repeatedly[_execute_always], put the following code :

Code: ags

  int MYSPRITE = 6; //whatever sprite slot was given for the sprite.
                    //We assume the sprite is larger than 20x20
  DrawingSurface* ds = Room.GetDrawingSurfaceForBackground();
  ds.DrawImage(0, 0, MYSPRITE , 0, 20, 20);
  ds.Release();

PROBLEM 1: The game crashes with following error:

An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x00000000 ; program pointer is +1004, ACI version 3.3.0.1156, gtags (6,37)

This is fixed by using "DrawImage" with a transparency of 1 instead of 0. That's a lame hack but it works.

PROBLEM 2: Corrupted sprite drawn

Even after the hack described above, no image gets drawn. Just a pattern of vertical stripes. That drawing has the expected size (20x20 in the example above).


Please note that I tried in both DX5 and D3D9. But I have an old notebook running XP, with an integrated chipset, so I'm not sure how much is hardware-accelerated and how much is software in the process. Anyway it looks like a wrong pointer gets involved in the process, inside the Engine.



SOLUTION: your room must have a background set in the editor. If there's no background, AGS doesn't create an image for it, neither a surface, therefore any attempt to draw onto that surface creates unexpected issues.

OK found it. The character was stuck outside a walkable area, so it couldn't move, so "moving" was always false.

I've recycled this old empty thread for a new purpose so I'm bumping it. Apologies if it confuses the mods.

It turns out that jerakeen's ParticleSystemManager has issues with 3.3.0 (see the "blue cups" bug reported by AGD2, that I also encountered).

If someone manages to solve that one...

EDIT: the module has no issues.