Messages

Yup. It uses photoshop's Layer Mask From Transparency feature and posterizes the resultant mask. If you put posterize's levels all the way down it should do exactly what you want. (My example's at 4 levels or so.)

Super cool. Thanks!!!

c:\123

Try somewhere else, try on your Desktop or in My Documents. Even better: try in "Program Files (x86)", as it has been suggested.
Try as administrator.

anyone knows about a plugin or library

By the way, I'm about to answer a question you didn't ask, but it'll also help you if you're more familiar with AGS terms in the future:
- Plugins are external to AGS and most of them are made in C++. They're usually for "super" features, mostly fast graphics and 3D. That would be waaaaay overkill for what you're looking for.
- Modules could be what you call "libraries", that is: pieces of code written directly in AGS scripting language. Except in the AGS world we like to keep it simple and the "library" would most likely fit in a single module, and wouldn't really be a library anymore .

For example, you could decide to release your copy-protection as a module after you're finished fine-tuning it (don't forget to credit Snarky obvisouly ).

actually its not in AGS

Uh oh....

You mean the white parts are the background, and the black parts are on a separate layer? If yes, then with some fiddling that would be the ultimate tool I've been looking for to remove all rogue pixels that are not fully opaque or fully transparent.

Looks very interesting indeed. I hope you will take advatnage of the fact that the character sprite is so small to make some larger backgrounds from time to time.

A new version with some fixes including this one would be great

You should track them down (even though they've almost disappeared) and then harass them until they release the source code I'm only half-joking. At this stage I'm sure they'd be very happy to give away the trouble to a community that would be eager to fix the bugs. That indie game is way too valuable (from the fans perspective) to become an abandonware.

Like everyone else I'd like to see more of that mouse

It's always possible that there is a bug in the AGS version, beta-testing is often where some weaknesses show up, even for great games/remakes -- since only professional games can afford the army of beta-testers needed.
I'd recommend sending a PM directly to the game makers (I mean, the guys who made the AGS version, not to Lucasarts! lol)

Alright so I never managed to find out what's wrong in my script, but it's definitely not something wrong with AGS, or with this specific portion of script. The issue is more tricky and lies somewhere else (as I said, probably in RepExec).

Therefore, no need to investigate further here. I made a dirty hacky workaround using "Character.Follow".

I could be wrong but, what if r.Walk was blocking. As long as player starts walking first, he should carry on walking when r starts right?
Then you wouldn't need the waitseconds command, he would just way 'wut' when he reaches his destination.

I agree. But none of those combinations seem to work.
I suspect something fishy, like another piece of code somewhere else (in RepExec) doing a blocking r.Walk in my back.

Something unrelated to the question you asked, but very important: will you sue the regular perspective as seen in the colored rendering of your scene, or will you use the axonometric perspective seen in the B&W version? If you use the axonometric one, everything is fine. Otherwise, with the other perspective, you'll need to draw a much larger sprite, because the character will be very close to the camera if he walks to in the foreground of the room.

4) only finally scale down the sprite to 50% its size (to create smooth-lines-but-not-too-smooth) and draw the details manually
Then again this possible workflow might be completely inappropriate since I don't know what resolution you're aiming.

I'm a little confused by what you mean by scaling down and then drawing details manually?

Will you want to keep all the black lines in your final sprite? If yes, the workflow I suggested doesn't suit your needs. I can't really see how you could keep all those one-pixel-thick lines without manually drawing them on each sprite.
My personal philosophy is always that there should be a process as automated and repetitive as possible, with each step as simple as possible.
Therefore maybe you could draw your psrites in a way that, after you scan them, all you have to do is apply that kind of photoshop filters, possibly several filters (to clean up the result each time more), and only then start coloring or applying other effects.

There si nothing wrong with the perspective, but you fell in the usual trap that beginner scene composers fall into :
Your perspective is a basic perspective that uses one single vanishing point. That's perfect for regular art, but that can become tricky in a 2D video game : Because it means that if the character walks at the bottom of the screen, he will be much, much closer to the camera than he is when he's up against the back wall.
Therefore, when the character is at the bottom of the image, he should be scaled almost 4x compared to the upper part of the image. Try it yourself: go to the scaling properties of the walk area, and make it scale from 200% to 50%. you'll see that the character has the right size compared to the furniture, no matter where he stands.

The problem is that he will look ugly! Because an upscaled character looks ugly.

There are two workarounds/hacks:
1) forbid the player to walk too far down at the bottom of the screen. Allow him to walk only in a small horizontal band of floor.  Hide the bottom of the scene (and the character's feet) with some foreground objects that also act as walkbehinds.
OR
2) redraw your scene to use a perspective like a,b or c on this picture. (At the moment your perspective is more like d or e) . This way the character always has the same size, wherever he walks.

My personal goal is original King's Quest style graphics enhanced for a better resolution. So I would like to keep things more cartoony, but colors and shading very simple. So 320x* and etc. would not be a good starting point to scale up from since the views need a larger surface area to composite the scenes. I even went as far as 1024x768, but the scaling system is hard to judge

I didn't quite understand what final resolution you're targetting. Are you planning on using the existing backgrounds "as-is", scale them up, and then draw more-detailed character sprites?
You must decide what resolution you target because it will condition everything, from your drawing workflow to some technical things (such as programming). Keep in mind that you cannot change an AGS game's resolution after you've started it.
Nowadays, 640x480 and 800x600 are obsolete for hi-res. Even that has become too low. So either yous tick to 320x200, or you scale it up using proper pixel filters such as hq3x.

1) I sketch an animated sequence on paper with a simple lightbox and scan in the frames.
2) I trace it with graphics gale because it has pixel perfect precision with its smooth line tool.
I noticed, that this takes alot of time. The tracing I mean.

Yes, tracing is very long. But I can see that you also have a concern for anti-alisaing (smooth lines).
Maybe you could:
1)  color your drawings directly on the paper (at least the base colors, using 3 or 4 colors),
2) scan them at twice the resolution( e.g. if your final sprite is 100x100, start off with a 200x200 scan),
3) apply basic filters to quickly fix the colors (e.g. "posterize", contrast, etc.) and remove any rogue pixels (no smooth lines!!! your psrites should be as sharp as possible)
4) only finally scale down the sprite to 50% its size (to create smooth-lines-but-not-too-smooth) and draw the details manually
Then again this possible workflow might be completely inappropriate since I don't know what resolution you're aiming.

My other question is about smooth animation.I noticed that when moving a single static image in a walk, in the editor when the game is launched to test, it is very jumpy. Very uncomfortable to look at. I figured, as soon as I have more frames for a walk cycle, it will be more pleasing to look at. I wanted an opinion on how I could implement any techniques to make sure that I calculate for a smooth animation.

The thing with animations is that adding frames does not necessarily make it more smooth. What makes an animation smooth is to draw frames only for important positions. Every quick move inbetween important positions doesn't need a frame.
A typical example: In a side walkcycle, the most important frames are the ones where the character throws his leg forward, because he's quick in doing that, and then he's much slower to bring his body forward just above his foot.
If you miss that frame with the leg fully strecthed forward, then no matter how many intermediate frames you draw, the animation will look clunky. However if you have all the important frames, even very few frames can fool the eye and look fluid.

There is something very weird: player still walks first if I put the r.Walk instruction BEFORE player.Walk
They are both on a walk area.
I'll try to fiddle with eBlock and eNonBlock, but I'm quite pessimistic.

@anasabdin I'm just trying to make them walk simultaneously -- the "Say" instruction is just for after they finish walking.

Are you saying the player walks 100 pixels to the left, and only after they got there, r starts walking?

Yes, that's what happens. I'll try your suggestion.

Sorry for digging up an old thread, but this module is rather useful, yet I found a bug.
This bug seems to have been introduced after an unfortunate last-minute modification.

Current code :

Code: ags

static function Caterpillar::Set(int spot, Character* name) {
 
  // If 'name' is already at 'spot' or is the player, do nothing
  int n;
  while (n < NMAX) {
    if (name == follower[n] || name == player) {return;}
    n++;
  }
  // If 'name' is null, remove current character from 'spot'
  if (name == null) {
    ...
    follower[spot] = null;
  }
...

As you can see, the function is broken. The end-used is supposed to use "null" value for parameter "name" in order to remove that value from array "follower".
But before "if (name == null)" occurs, there is that loop which does "if (name == follower[n] ...) {return;}". If name==null, then name==follower[n] can be true! Therefore you never get to reach if (name == null)

Unless I'm overlooking something obvious, the correct code should be :

Code: ags

static function Caterpillar::Set(int spot, Character* name) {
 
  // If 'name' is already at 'spot' or is the player, do nothing
  if (name != null) { // !!!!!!!!!!!!!!!!!!!
      int n;
      while (n < NMAX) {
        if (name == follower[n] || name == player) {return;}
        n++;
      }
  }                   //!!!!!!!!!!!!!!!!!!!!
  // If 'name' is null, remove current character from 'spot'
  if (name == null) {
    if (follower[spot] != null) { // !!!!!!!!!!!!!!!!
      follower[spot].StopMoving();
      follower[spot].Solid = originalsolid[spot];
    }                            //!!!!!!!!!!!!!!!!!!!
    follower[spot] = null;
  }...

Apprently, after all these years, I still have issues managing non-blocking events.
In the code below, why does "player" walk THEN r walks??? (and player says "wut?" at the same time as r starts walking)  Shouldn't they be walking simultaneously?

Code: ags

    //"WaitSeconds" is a conveninent function from the Tween module but I could as well do "Wait(200);"

    // Note: this code is triggered by an Interaction event on "r".
    r.SetWalkSpeed(r.WalkSpeedX*3, r.WalkSpeedY);
    Wait(1);
    player.Walk(player.x - 100, player.y, eNoBlock);
    r.Walk(r.x - 200, r.y, eNoBlock);
    WaitSeconds(2.0); 
    player.Say("wut?");

[@Theresagamer :]

@Theresagamer : My advice: Start your game using a TEMPLATE.

Beginners often start off using the AGS bare game, and then they realize they'd like all the small commodities such as a custom "Save" window, a proper "Quit" button, a custom gui (e.g. : right-click to watch an object, left-click to interact...), etc. But then they've already started making the game and don't want to start over, it's too late.

Pro-tip: If you don't know what template to use or where to find it, first try to find the name of the template matching the gameplay you have on mind (e.g. "BASS" template, "9-verb coin", etc.).

Still a bad idea; using text for checks like that is inherently unreliable, and your code will break as soon as you want to translate your game

I agree with Khris, I think it's bad design to use the Text value when the goal is to check the identity of the actual button/control. But it's ok for a small, quick project, provided it won't be translated.
My own concern would be to test that the control is actually a button before doing anything with it (just in case the gui grows bigger and gets more controls, some of them not being buttons):

Code: ags

Button *btn = control.AsButton;
if (btn!=null)
{
  ...
}