Messages

I wish I could help out.

Selmiak is right: you can! What can you do? Scripting? Music? Sound effects? etc.

[@Amelie]

In the meantime I've continued working a little bit.
Apparently, nobody but me liked my 3 "naive" Indy's, so I tried a more realistic one. It's the best I can do without completely ripping off the FoY face (the one on the far right).



@Amelie, I tried to send you a PM on the AGS forums, but your settings forbid it. I also tried to send you an email to: s****t*******@yahoo.com but I suspect that's an address you don't consult often.

[not compatible]

I recommend changing the screenshot.

Updated screenshot :

What is the scanlines.txt for, and with that question, why do you output it as a txt with raw ints instead of a binary file? That way the player is not wondering what this text file is and if they should read it.

Wooops! That was meant for debugging only! Now I understand why the demo game suddenly got so slow!
It's just a matter of commenting out the line calling the function dumping of the text file.

I wonder if it works well with animated background or water

It's not compatible with animated backgrounds. Animated backgrounds are evil anyway!

[Bakgrounds: 20% complete]

Hi Indy fans!

We are pleased to announce that we're making progress!

Bakgrounds: 20% complete (considering the many backgrounds we need to draw, that's good!)
Music: 50% complete (we have some nice genuine themes to play, for your ears' delight!)

We're still looking for background artists, scripters, animators and musicians.
Come on, it's the holidays! You can draw while you're on the beach!

But where is the mirror on the screenshot you posted? Is it the golden stone? If so, what does it reflect?

Just run the demo already!
There are 5 mirrors, just not on the screnshot (yes, I know, that's silly)

Well done, Monsieur; I never thought I'd need mirrors. Now I will put them everywhere!

Thanks!

Nice idea. Why is the file a .0 extension and not a .scm?

That's because when you type "module_1.0" in the export field of AGS, it considers that ".0" is the extension, and doesn't add ".scm" at the end. Don't blame me

Also, there's a typo in 'int GetSlot', you wrote 'mabient' instead of 'ambient'.

Does that prevent the module from working? I'm pretty sure I exported it straight from the demo!

And ambient is spelled with an 'e', not an 'a'

Oh well, I spelt it with an "e" almost everywhere, so I'll live with it.  Blame the English language, that puts an "a" to "ambiance", but an "e" to "ambient". Makes no sense!!!111!!!11

Cool!
You should add "BASS" in the thread title, to optimize later researches.

[IMPORTANT NOTE :]

IMPORTANT NOTE :
- This module was created before late_repeatedly_execute_always was introduced
- If you replace repeatedly_execute_always with late_repeatedly_execute_always it should procude better results (no latency in character frame mirrored)

This allows you to create small mirrors in your game very quickly.

FEATURES:
- three types of symmetry: front/back (the mirror is facing you), left/right (the mirror is turned 90° from your viewpoint), none (the character is repalced with any character of your choosing, allowing upside-down symmetry of any crazy idea you have).
- you can choose the opacity of the mirror: 0.0 means it reflects perfectly. 1.0 means it doesn't reflect anything.
- Custom-shaped mirrors : just pick a sprite as a mask and your mirror can have any shape. It also uses alpha (you can have cracks in your mirrors, a soft outline, etc.).
- Attenuation: when the player moves away from the mirror, his reflection becomes less and less visible.
- Moving reflection : you can make the character's reflection move around to simulate a moving mirror (water surface, etc.)
HOW TO USE
- See the demo game and the header script. It's as simple as possible : choose an object as the mirror, another object as its symmetry center, and a region to trigger it on or off when the player walks on it.

KNOWN ISSUES
- [version 1.x only] [It's quite slow. It's meant for small mirrors. I'd say no more than 200x100 pixels reflecting simultaneously.
- [version 1.x only] There are tiny rendering bugs (sometimes the mirrored image is late one frame, or sometimes it's not aligned properly -- but the player won't really notice). Those will be fixed in next version.
- It only reflects the player character. It doesn't reflect any object or animated background or anything else. But it's easy to tweak the module and make it reflect one or several NPCs.

HISTORY
- 2013: uploaded version 1.x which work with per-pixel computation (allows shaders)
- 31 july 2014 : uploaded version 2.0 which drops the whole per-pixel thing and uses standard AGS characters as the reflection.

>>> DOWNLOAD 1.1 (obsolete, per-pixel computation) <<< (sources + compiled demo game)
>>> DOWNLOAD 2.0 (faster, more reliable) <<< (sources + compiled demo game)

Also you might like the private jokes for point-n-click lovers in the demo


==================

UPDATE: You know the way you always learn new things in AGS scripts?
Well, you'll notice that my module uses the following silly technique to get sprites Width and Height :

Code: ags

      //not the actual code in the module
      DynamicSprite* s sprite= DynamicSprite.CreateFromExistingSprite(something.Graphic);
      int width=s.Width;
      int height=s.Height;

Well, feel free to replace it with this, which will be much faster and memory-savy:

Code: ags

      width = Game.SpriteWidth[something.Graphic];
      height = Game.SpriteHeight[something.Graphic];

<off contest>
There have been 2 insults about spandex in a row... Is that an OceanSpirit insults contest?
</off contest>

You wouldn't know intelligence if it came around to your house for dinner wearing a name tag, whispered it's name in your ear and smacked you across the face with an IQ test!

At least I know when to use properly "it's" and "its"!

============

You're like a T-Rex trying to reach for its sword!

Oh my god the issue was so freakin simple, I can't believe it.

Adding perspective_correction_y to x_in_char was just enough to target the correct pixel in the character sprite without any change. It was making sure that the distance between the char and the bottom of the mirror was taken in account. Therefore the character sprite was rendered into the mask as if the character wasn't moving (that was my problem).

But I had to add ANOTHER perspective_correction_y to make sure that when the character walks away from the mirror, then the reflection moves up symmetrically.

All I had to do was to change

Code: AGS

y_in_char = y_in_char +perspective_correction_y;

to

Code: AGS

y_in_char = y_in_char +2*perspective_correction_y;

...As always, that was a silly case of "I've been looking at this script for too long".

Hurray!
There's a nice little Mirrors module coming.

My smartphone is more expensive than your smartphone :p

I'd beat you even at angry birds!

------------------------

How do you expect to stick your sword into my heart with that lazy eye?

[M. OUXX]

I think M. OUXX had no question: he just points out that the manual does not (but should) say that whenever you pass the coordinates of a transparent pixel to GetPixel, it returns the value -1.
Once the user learns it, (s)he no longer wonders what value (naively the pink value) he should check for in order to know whether the pixel he's looking at is transparent or not.

Exactly. I was expecting pink. Or the top-left color. I had to debug to find out that GetPixel was actually returning -1. And I had to search the forums to learn that "-1" was known as macro COLOR_TRANSPARENT.

The perspective correction should alter that fixed offset, but only does so on the x-axis.

Why do you say that?
Two lines below the lines, you quoted, I add perspective_correction_y to y_in_char.

Earlier you said:

No matter how perspective_correction_y varies, the final value of  y_on_screen stays the same

But I can't see why y_on_screen should depend on perspective_correction_y at all. There's no operation that would refer these two variables at once.

Hmmmm... I don't understand and I don't see how to explain further.

Imagine this algorithm as this :
- I choose a sort of "window" on the screen, that goes from (x,y) to (x+data[mir_index].width, y+data[mir_index].height).
- I iterate within that rectangular window using i and j.
- At any given time, the screen coordinate of the pixel being drawn is: (x+i, y+j). That's the same as (x_on_screen, y_on_screen)

Now, you want to decide what color must be drawn at (x_on_screen, y_on_screen):
- If I was just copying the source sprite to the top-left corner of my window, I'd pick the pixel at (x_in_char, y_in_char) ...with x_in_char=i and y_in_char=j.
- Now imagine I want to copy the source sprite in the exact place where the playable character is standing : I'd use x_in_char=i+(x_on_screen-player.left), y_in_char=j+(y_on_screen-player.top). (note: player.left and player.top don't exist in AGS, they need to be calculated from player.x and player.y).
- Now imagine you want to copy the source sprite 10 pixels higher than where the player is standing. I'd use x_in_char=i+(x_on_screen-player.left), y_in_char=j+(y_on_screen-player.top+10). You see? I'm not changing y_on_screen, but by increasing y_in_char I make the sprite being rendered higher on-screen. It's all shifted upwards.
- Now imagine you replace this "+10" with perspective_correction_y. If you need to know, it's calculated on the distance between the player and a given point on the screen. The more the player walk away from that point, the more perspective_correction_y increases.
=>  The consequence should be that the copied sprite gets drawn "higher" on-screen. But it's not. The algorithm works OK, which means when the player walks left and right, then the copied sprite follows left and right -- but when the player also walks up and down, even though perspective_correction_y changed accordingly, then the copied sprite moves left and right but stays on the same horizontal line.

Where are the codes that set/modify the values of perspective_correction_x/y?
They're just used in the attached script but there is no indication on how they're changed.

They're calculated once before the loop.
The thing is, it doesn't really matter, because as I said I can see in Status.Text (on-screen) that the value is varying correctly; As you can see I dump perspective_correction_y into Status.Text right in the middle of the loop, where it's critical that the value is correct. And it is correct.

shouldn't you be setting x_on_screen instead of x_in_char?

The principle of the algorithm is that I start from the pixel on-screen, and calculate what pixel in the character sprite it should display. Therefore, x_on_screen (resp. y_on_screen) must always be x+i (resp. y+j).
But I can change the calculations of x_in_char/y_in_char to pick a different pixel from the character sprite. That's where the corrections steps in.

I made a guess that a Monsieur wouldn't use the American Google, and turns out I was right!

I didn't bother linking "my" Google because I thought "why would they do something about Roswell just for France?"

The manual doesn't say that "GetPixel()" returns -1 (constant COLOR_TRANSPARENT) on transparent pixels, even in a 32-bits game.

On a side note, that also answers the question: "how the hell do I know if a pixel is transparent, considering the top-left corner of the image is not necessarily pink in the images I import?".

[perspective correction]

OK, I'm sorry to post that here, but I'm going crazy over this.
It must be something obvious, but I keep looking at that script and fail to spot the obvious mistake.

It's a script to render a character onto a background pixel by pixel, with a little twist: there's also a surface used as a mask, to decide if the pixel is copied.

i and j iterate on every pixel of the mask surface, and then I look up what pixel from the character should be drawn (only if both the pixel from the mask and the pixel from the character are non-transparent). The pixel matching (i,j) in the "mask" surface has coordinates (x_on_char, y_on_char) in the character sprite.

There's also a perspective correction: E.g. depending on where "player" is standing, y_on_char gets altered by perspective_correction_y.

That's about it.
Here's the script: (I'm hiding it because it's full of unnecessary bullshit)

Spoiler

Code: AGS

  int color_char;
  int color_mirror;
  DrawingSurface* ds_mirror = data[mir_index].obj_spr.GetDrawingSurface();
  
  int i=0; int j=0;
   while (j<data[mir_index].height) //iterate on every pixel row in the mirror object
  {
    i=0;
    
   while (i<data[mir_index].width) //iterate on every pixel column in the mirror object   
    {
      color_mirror = ds_mirror.GetPixel(i, j);
      if (color_mirror!=data[mir_index].TRANSP_COLOR)
      {
        /*
        #define x_on_screen   x+i
        #define y_on_screen   y+j

        #define  x_correction  (-data[mir_index].x_offset) 
        #define  y_correction  (-data[mir_index].y_offset) 
        */
        
        int x_on_screen =  x+i;
        int y_on_screen = y+j;
        
        x_in_char = x_on_screen-frameData.x;
        y_in_char = y_on_screen-frameData.y;

        if (frameData.flipped)
          x_in_char = frameData.w - x_in_char;
          
        x_in_char = x_in_char /*+x_correction*/ +perspective_correction_x;
        y_in_char = y_in_char /*+y_correction*/ +perspective_correction_y/*+ofs*/;

        //Status.Text=String.Format("persp=%d",perspective_correction_y);//DEBUG
        
        if (     x_in_char>=0 && x_in_char<frameData.w 
              && y_in_char>=0 && y_in_char<frameData.h)
        {

          color_char = char_ds.GetPixel(x_in_char, y_in_char);
          
          if (     color_char!=frameData.TRANSP_COLOR )
          {
            ds.DrawingColor = color_char;
            ds.DrawPixel(x_on_screen,   y_on_screen);
          }
        }
        
      }
      
      i++;
    }
    j++;
  }

[close]

But now, here's the problem:
The script works OK, except perspective_correction_y doesn't seem to change.

As you can see, in the loop I even display its value into "status.Text". Thanks to that, I can see that when the character moves around, the value of perspective_correction_y increases and decreases as expected...
...BUT the rendered pixels stay in the same place on the screen. No matter how perspective_correction_y varies, the final value of  y_on_screen stays the same. The rendered character copy stays on the same horizontal line.

Where do I screw up the overwriting of my variables values? Or do I have two variables cancelling each other? I just fail to see it... It's driving me mad

Today's Google Doodle is a point n' click!

I didn't check what technology they used (HTML5?) but it's quite impressive.

We are delighted to announce that we have 3 new beautiful backgrounds ready!
-- and 3 more on the way, thanks to Christian (the maker of Pizza Nostra) who's lending us a hand!