Mittens 2018 will be in Boston this September. There are three spaces left, so check out the thread for details!

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - Crimson Wizard

Pages: [1] 2 3 ... 403
There are other ways to do this.

1) You may create a dummy character for background, set the image to it, and then change Character.Scaling property. You may need to use Timers for that to control speed of change (Look for the SetTimer in the manual).

2) You may simply draw an image on the room background using DrawingSurface, and change it in size gradually.
Check for the DrawingSurface and DrawingSurface.DrawImage in the manual.
Code: Adventure Game Studio
  1. DrawingSurface *ds = Room.GetDrawingSurfaceForBackground();
  2. ds.DrawImage(-zoom_step, -zoom_step, SPRITE_NUMBER, 0, Game.SpriteWidth[SPRITE_NUMBER] + zoom_step * 2, Game.SpriteHeight[SPRITE_NUMBER] + zoom_step * 2);
  3. ds.Release();
SPRITE_NUMBER is the number of sprite which has your background image.
zoom_step is a variable that you need to change by timer.

Editor Development / Re: SOLVED: View loop displacement
« on: Yesterday at 16:40 »
Could you please move this to Editor development? Looks like a bug report.

it was better if I could do it as an object, and then put it in a layer below, so that underneath me the background and I could give it a setsize, and the objects above could be seen, pity that you can not level the objects

You can level objects using Baseline property.
The lower Baseline is, the "farther" object is drawn.
Try setting Baseline to 1, then object will always be behind anything else.

If you are calling it using QuitGame(1), then you cannot change it, it uses a built-in GUI.

You will have to create your own Quit dialog GUI, set it up like you want, then show it on screen normally, like you do with the options menu, and script reactions to pressing Yes/No buttons.

I will be frank, the code that I see on your pic is pretty weird.

You first draw the tree sprite onto room-sized surface in original size, then resize the surface... I think that means that not only width and height of the tree will be changed, but its X and Y will also change (final tree image may get shifted away from the position you wanted).
Also, I cannot make any sense out of adding propScale to the surface's sizes. If that's really is a scale factor, then it's wrong, so that's probably not the scale factor, but the final tree size?? or not....

By the way, the Baseline calculation is also wrong. You are using original coordinates propY and Game.SpriteHeight to calculate its position, but they are no longer applicable to the final resized image. You should be multiplying these values by the image scale factor (see below).

If you look for the DrawImage article in the manual, you will see that it has optional width and height parameters. They let you resize an image when you are drawing it.
So the resizing code could probably look like this:
Code: Adventure Game Studio
  1. int scale ... // assuming you calculated scale somehow
  2. int orig_width = Game.SpriteWidth[prop[i]];
  3. int orig_height = Game.SpriteHeight[prop[i]];
  4. int final_width = orig_width * scale;
  5. int final_height = orig_height * scale;
  6. EnvPropSurface[i] = EnvProp[i].GetDrawingSurface();
  7. EnvPropSurface[i].DrawImage(propX[i], propY[i], prop[i], 0, final_width, final_height);
  8. EnvPropSurface[i].Release();
In such case there is no need to resize large dynamic sprite, and also prop coordinates stay the same.

Alright, that said, if we still stick to your formulas, then to calculate the "block" object position you need to know following:
1) The size and position of Blocking area relative to the original sprite's size. This you have to define yourself, because only you know it, and you draw these sprites.
Let's call these OrigBlockX, OrigBlockY, OrigBlockWidth and OrigBlockHeight.
2) The size and position of Blocking area relative to the resized sprite. For these you need to multiply previous values by the same factor you are using to resize the sprite.

Since you are resizing whole final image, then every coordinate has to be resized as well:
Code: Adventure Game Studio
  1. // The scale factor is a relation between final size of large dynamic sprite and its original size
  2. // (normally I'd suggest to use Room.Width and Room.Height here instead of literal numbers)
  3. float ScaleX = IntToFloat(propScale[i] + EnvProp[i].Width) / 1920.0;
  4. float ScaleY = IntToFloat(propScale[i] + EnvProp[i].Height) / 1080.0;
  5. ScaledBlockX = FloatToInt(IntToFloat(OrigBlockX * ScaleX));
  6. ScaledBlockY = FloatToInt(IntToFloat(OrigBlockY * ScaleY));
  7. ScaledBlockWidth = FloatToInt(IntToFloat(OrigBlockWidth * ScaleX));
  8. ScaledBlockHeight = FloatToInt(IntToFloat(OrigBlockHeight * ScaleY));
Again, these coordinates are positions of the blocking area related to the resized sprite's local coordinates. This is not final.

How to find the position of the blocking rectangle in the room:
Code: Adventure Game Studio
  1. // This is where your resized tree is actually positioned in the room
  2. int RealPropX = object[i].X + FloatToInt(IntToFloat(propX[i] * ScaleX));
  3. int RealPropY = object[i].Y + FloatToInt(IntToFloat(propY[i] * ScaleY));
  4. // So, and the blocking object rectangle will be
  5. int BlockRoomX = RealPropX + ScaledBlockX;
  6. int BlockRoomY = RealPropY + ScaledBlockY;
  7. int BlockRoomWidth = ScaledBlockWidth;
  8. int BlockRoomHeight = ScaledBlockHeight;

EDIT: Realized a bit later, but we may actually skip ScaledBlockWidth/Height part and do following:
Code: Adventure Game Studio
  1. float ScaleX = IntToFloat(propScale[i] + EnvProp[i].Width) / 1920.0;
  2. float ScaleY = IntToFloat(propScale[i] + EnvProp[i].Height) / 1080.0;
  4. int BlockRoomX = object[i].X + FloatToInt(IntToFloat((propX[i] + OrigBlockX) * ScaleX));
  5. int BlockRoomY = object[i].Y + FloatToInt(IntToFloat((propY[i] + OrigBlockY) * ScaleY));
  6. int BlockRoomWidth = FloatToInt(IntToFloat(OrigBlockWidth * ScaleX));
  7. int BlockRoomHeight = FloatToInt(IntToFloat(OrigBlockHeight * ScaleY));
That should give identical results.

NOTE: the actual Baseline formula is also:
Code: Adventure Game Studio
  1. int RealPropY = object[i].Y + FloatToInt(IntToFloat(propY[i] * ScaleY));
  2. int RealPropHeight = FloatToInt(IntToFloat(Game.SpriteHeight(prop[i]) * ScaleY));
  3. object[i].Baseline = object[i].Y - Room.Height + RealPropY + RealPropHeight);

Now, I have to admit that I did not test all this, but only figured in my head. So I cannot 100% guarantee that's correct. I'd need to have actual test game on my computer to experiment with.
In any case, I strongly advise to clarify the resizing code you are using. Especially since you say yourself that you do not know the reason behind some formula. Because as you progress further this situation will only worsen...

1. What is the most structured way to set up a game. Wanna avoid to get messy.

Uh... this is the kind of question that requires writing an essay.
Everyone will have their own answer to this, but I don't think any answer will help you much anyway, such things come only with personal experience.

From the top of my head: best organization comes from splitting big things into small.
Split game assets by subfolders (in project tree and sprites window). Split game script into script modules; if you can logically separate a part of gameplay, code it in a separate module.
If you are making uncommon scenes, or minigames, create separate test games to work on them first, then copy them to your main game when they are ready - that will simplify testing, and also give you an idea of how to organize script better.

On general workflow: when creating some scene, try to write it down in plain human language first. Explain what is happening in detail, what kind of objects are there, how they interact with each other. Having clear descriptiong will help to begin coding.

2. I wanna make a starting screen.
Wanna have a screen for the "labelname", then one for starting. Wanna add there some text before game.

Make a room with either text drawn right on background, or GUI with a text label. Each room has a "Show player character" property. Set it to 'false' for this room (and every similar room where you don't want your character to appear on screen).

3. I want to integrate a overview map with a single point moving, like in monkey island.

I think easiest way is to make a room for map, switch your character's view for this particular room to a smallish sprite, and draw thin walkable areas representing roads.

As an alternative, I think it may be possible to utilize KeyListener module here, that lets you know how long a key was held down, etc:

It basically does same thing as Snarky's code is doing, but hides a part of implementation, so your script may look like:
Code: Adventure Game Studio
  1. #define KEY_REPEAT_THRESHOLD 120 // how long to wait before next scroll, in milliseconds
  3. function repeatedly_execute()
  4. {
  5.   if (gPanel.Visible)
  6.   {
  7.      if (KeyListener.IsKeyDown[eKeyUpArrow] && KeyListener.KeyDownTime[eKeyUpArrow] > KEY_REPEAT_THRESHOLD)
  8.      {
  9.         if (lstSaveGamesList.SelectedIndex < lstSaveGamesList.ItemCount - 1)
  10.            lstSaveGamesList.SelectedIndex--;
  11.      }
  12.      if (KeyListener.IsKeyDown[eKeyDownArrow] && KeyListener.KeyDownTime[eKeyDownArrow] > KEY_REPEAT_THRESHOLD)
  13.      {
  14.         if (lstSaveGamesList.SelectedIndex < 0)
  15.            lstSaveGamesList.SelectedIndex++;
  16.      }
  17.    }
  18. }

BTW, speaking of the artistic style and its connection to gameplay.
Check these couple of minutes in the video:

Add spoiler tag for Hidden:

First player sees something "purple" in the window of a house.
Then he enters the house, and sees a picture of a family, where the daughter is drawn in purple color.
Player immediately makes a connection.
I think that is as simplistic as genius.

I don't mind it that much, because it also sounds weird. Though the human sounds like that too, which does make it less ominous (laugh)

Yes, I mean protagonist's voice mainly, it makes my ears hurt :/.

I actually like the visuals, this is the kind of gfx style, with lack of detail, that made old games so captivating IMO. Everything you see on screen is an element of gameplay, and nothing but that.

Now, sounds is a different thing...

UPD: I decided to watch the Let's play video here:

And frankly, while visuals may be a good choice, the choice to replicate old-computer speaker producing voice is terrible, IMO. Very annoying and immersion breaking.

Hey guys as of today I happen to update my Win 10 PC and now as I will open AGS it will stop responding and crash itself. Any help?

Just to clarify, are you talking about running AGS Editor, or AGS games on the actual Windows computer, or running them in Wineskin on Mac? Because originally this thread was about problems running AGS game on Mac.

Oh, I forgot that Walk is non-blocking by default, and this means that event was triggering over and over again, contrary to intention.

Maybe there is simply no walkable area there?
Try checking that, or tell character to ignore areas
Code: Adventure Game Studio
  1. cElle.Walk(200, 420, eBlock, eAnywhere);

Even if I was to use smaller sprites, a trees trunk would always be part of the image so..

Ohhh right, I did not realize that, sorry, this means you probably cannot do this with same object anyway.

or do you mean making new objects on top of the ones with dynamic sprites (like new small box objects just to cover the same as the parts I want blocked)?

No, but now when you said this, I am beginning to think that's the only way, except for scripting custom blocking/pathfinding.

You do not need to check for "tries", that unnecessarily complicates it.

Code: Adventure Game Studio
  1. function room_LeaveLeft()
  2. {
  3.   if(player.HasInventory(iCita))
  4.   {
  5.     player.ChangeRoom(5,  730,  400, eDirectionLeft);
  6.   }
  7.   else
  8.   {
  9.     cElle.Think("I should probably find and take my meds first.");
  10.     cElle.Walk(200, 420);
  11.   }
  12. }

This way she will keep telling that she needs meds, and walk away from the edge.

Sorry, I realized what the problem may be and edited my original reply, looks like too late. Please read it again :)

Also, now time for me to look dumb lol, I have no idea what event it's connected to (or what that means). What I posted is the only thing in my room script file. Am I missing something?

I meant, what event did you click on to create that function on the event pane in the room editor
Add spoiler tag for Hidden:

If I remember correctly, the "walk of edge" event is run endlessly while player is standing behind one. The solution is usually to move character away a bit from the edge, if you are not leaving room immediately.

wow :) ok work but crash maybe I have to assign the new character while I open his inventory, of the type as player?

No, I think it should work without that.
When it crashed, what was the error message?
Are you sure you put correct ID?

thanks to everyone, or I was thinking of creating a second inventory and when you talk to a character while you say goodbye, you add an inventory object (piece i card) but only in that second inventory, so that you can then make the combinations to finish the mission

could I also do it this way? create a second inventory and how can I do?

In AGS a Character may have only one inventory, but you can use second "dummy" Character for second inventory. That dummy character will never be shown anywhere, but you may access its inventory and display it on screen just like you do with real character.
You can create multiple different inventories that way.

When you have InventoryWindow in the editor, there is a property called "CharacterID". Put an ID of dummy character there to display its inventory.

Hi, what about detecting part if the image for blocking height/width like I posted above with the image, considering the transparent object ius the whole screen and I need a particular part blocked,  how can I calculate that?

The problem really is not only how to calculate it, but how to apply. Because you cannot define a blocking rectangle with all 4 points, only width and height, and blocking area will start always at object's (X,Y), so it cannot be covering whole room.

This is why I kept suggesting making smaller dynamic sprites, exactly enough to draw an object. That should not be too hard to do, you know original sprite size, and necessary scaling.

If you still insist on having very large dynamic sprites, you will have to draw an object aligned to its left-bottom corner, which corresponds to object's origin.

Pages: [1] 2 3 ... 403