Using pictures to display parts of your map

[Tsukihime]

So I was thinking, why not take a picture and then draw it over a certain part of the map? Then you'll have so much more freedom over how you want your game to look.


Now, what happens if you separate your pictures into different layers? Now you have layered mapping.


Take it a step further: be able to turn on and off pictures.


Doesn't that sound cool?

 

[Susan]

That does sound interesting. A few things that popped into my head :

- You may need to write your own 'Fix Pictures' script so that the 'maps' will not be displayed inappropriately.

- Collision problem. Being able to display different pictures means that the 'maps' may not be uniform. Short of using events as collisions that are triggered when certain pictures show up, I don't think there is a dynamic situation to the collision issue at the moment.

- How do you intend to implement the on and off pictures script differently from the 'Show Pictures' and 'Erase Picture' commands already available?

 

[Tsukihime]

1. We can just use the existing "fix picture" scripts available, though I'm not sure if they are actually pictures in the game, or separate pictures that you have no direct control over from events.


Anyways I've finished such a script now so I'll probably just use that lol


2. We start with basics: using a picture for visual purposes. This is what many people are doing when they do "parallax mapping".


Collision can come later. Though, speaking of collision, there was a script written by Cidiomar which does provide image-based collision checks (with proper alpha checks). I don't have much interest in this problem at the moment, but you can check it out if you want here


3. I don't, which is what makes it so simple.

 

[Susan]

Is it something like your Overlay Maps script? That is a pretty useful script in and of itself.

The Collision script you have linked here is very interesting. Utilizing it would mean having to create different 'maps' for walls and impassable objects.

Well, I suggested writing your own 'Fix Pictures' script due to possible incompatibility problems. The same goes for collision. I will try to test it out later on though.

 

[Tsukihime]

Here's the script: http://himeworks.com/2014/11/picture-anchors/


I've added a bunch of pictures to show how it works.

It is simple by design and should be compatible with all scripts.


Notice a few things


1. Everything is evented. Your picture uses the default show picture command


2. You can therefore erase pictures, allowing you to hide or show pictures as needed.


3. You can change the picture dynamically using "move" picture command. Need to make it bigger? Just run an event.


4. Layering is based on picture ID. Higher ID's appear above lower ID's


This script simply specifies where the picture should be positioned. Therefore, if you had scripts for animating pictures, or various picture editing effects, they can all be used.


While I decided to add some extra functionality, the relevant functionality to this topic is the map anchors

Is it something like your Overlay Maps script? That is a pretty useful script in and of itself.

It is different from overlay maps. That one uses actual maps and combines them together, allowing you to have real-time information from other maps show on the screen. This is not possible with pictures because if you decided to swap tiles for example on a different map, your pictures wouldn't reflect it. You also wouldn't be able to have moving events or other animations on each layer.

 

[??????]

@Tsuki - I wrote up a similar script - one to use images as layers on my map.

Anyway, I wrote a small region movement restriction script to go along with it (both not released). It basically uses region tags and passibility? flags.

I then went a step further and cached the passability for the 'tiles' that had already been waked on by the current character as the calculation was a little heavy on processing.

 

[Tsukihime]

Here is a common problem that the picture anchors resolve: tunnel vision.


By default, you can already achieve tunnel vision using pictures.


Just create a black picture and cut a shape out of it.

Doesn't have to be a circle. Could be a heart. Or two circles if you want to simulate binoculars.


But then you start running into problems once you reach the side or corner of the map, because the picture is anchored to the screen! You then realize that the picture doesn't actually follow the player, but instead the screen.


By simply anchoring the picture to the player, you can now walk into the side or corners without worry about the picture not following you.

 

[Engr. Adiktuzmiko]

I have a script for that on some of my projects, I use them mostly for showing more objects/layers without parallaxing.


As far as anchors go, I made it to be able to anchor to either a specific part of the map or to the character or events.


It's really handy, though I've yet to even fully utilize it (I actually mostly use it right now as the graphics handler of my projectile script)

 

[Celianna]

By simply anchoring the picture to the player, you can now walk into the side or corners without worry about the picture not following you.

People have been getting around this issue by making the picture larger than the actual screensize. So they make a picture that is twice the size that you see on screen, so that when the player walks to the edge of a map, the picture still follows.

 

[GrandmaDeb]

I guess I am a bit confused about whether we are adding a new capability here, or smoothing out an old one?


I mean, with "fogs" and "pictures" and "parallaxes" we have had images both over and under the player. They move in various ways, either with the player or with the map (which we call fixed, as in fixed to the map movement.)


I have seen games in which completely hand drawn backgrounds (like, line drawn images line a coloring book) were the roads and scenery. I have seen games in which the overhead mapping elements were pictures. Where fogs added sunlight or "flashlights" as you are saying.


And you are saying the "step further" is turning on and off pictures.This is what OriginalWij's Multiple Parallaxed Layers for VX did - you could change opacity on each layer. He used it to have map areas concealed by a blackout that faded out when you entered the area.


I don't think it supported picture rotation or anything. And of course there are newer RPG Maker VX/Ace scripts that folks use for their parallax mapping....


I guess what I am asking is: Is this a new parallax mapping script? (an alternative- which is always great, of course) Or are we adding functions? Because I'm not understanding that part. Thanks! (It is early in the morning!) [=

 

[Tsukihime]

People have been getting around this issue by making the picture larger than the actual screensize. So they make a picture that is twice the size that you see on screen, so that when the player walks to the edge of a map, the picture still follows.

Is this in VX? I tried it in Ace and the picture is anchored to the offset that you set it at.


I'm using a screen size of 544x416 with a picture that's 1088x832

I guess I am a bit confused about whether we are adding a new capability here, or smoothing out an old one?


I mean, with "fogs" and "pictures" and "parallaxes" we have had images both over and under the player. They move in various ways, either with the player or with the map (which we call fixed, as in fixed to the map movement.)


I have seen games in which completely hand drawn backgrounds (like, line drawn images line a coloring book) were the roads and scenery. I have seen games in which the overhead mapping elements were pictures. Where fogs added sunlight or "flashlights" as you are saying.


And you are saying the "step further" is turning on and off pictures.This is what OriginalWij's Multiple Parallaxed Layers for VX did - you could change opacity on each layer. He used it to have map areas concealed by a blackout that faded out when you entered the area.


I don't think it supported picture rotation or anything. And of course there are newer RPG Maker VX/Ace scripts that folks use for their parallax mapping....


I guess what I am asking is: Is this a new parallax mapping script? (an alternative- which is always great, of course) Or are we adding functions? Because I'm not understanding that part. Thanks! (It is early in the morning!) [=

Parallax mapping is an application of using anchored pictures (whether it used RPG Maker's event pictures or not). They can be used for decoration, animation, HUD's, and all sorts of other things that we have probably already seen before.


This isn't a new idea. What I'm doing here is re-visiting the idea of what it means to use a picture to show parts of your map, since over the past few months I've seen several requests involving showing or hiding or changing parts of the map but didn't see too many suggestions about using a picture or controlling a picture.


Looking around at a few parallax mapping options, I saw one factor that may have contributed to this: they were hardcoded for the most part. You had your "fog" layer or "sunlight" layer or "ground" layer, but those were your only options. And of course, you could control them. With a switch. Or a variable. Or maybe a script call.


These aren't limitations. There are good reasons why you might want to disable certain layers across all maps with a single switch.


There were some scripts that allowed you to have "unlimited layers" by using filenames for your images, which would be read by the engine and loaded up for the appropriate maps.


Granted, the only ones I've looked at are the ones that came up when I ran a search on "rpgmaker parallax mapping" which included Yami, originalWij, modern algebra, and Vindaca. It looks like Engr and Dekita both have their own image layers but those didn't come up, so I imagine there's more out there that I didn't see.


As for capabilities, what I'm adding is the ability to treat any picture in your game as an event picture. If it's already been done before, I'd like to see what kind of things other solutions provide.


For example, by changing properties over time, we can create animations without having to get into complicated scripting:

 

[Engr. Adiktuzmiko]

Is this in VX? I tried it in Ace and the picture is anchored to the offset that you set it at.


I'm using a screen size of 544x416 with a picture that's 1088x832

I've helped someone (somehow on a thread here months ago) to do that actually in Ace. It involves moving the picture to the player's current X/Y every few frames using a parallel process event. If you use an image that is the same size as the window, then if you move to the right, the image will have blank parts on the left and so on, which is why you need an image that is double the size of the map.

 

[Tsukihime]

I've helped someone (somehow on a thread here months ago) to do that actually in Ace. It involves moving the picture to the player's current X/Y every few frames using a parallel process event. If you use an image that is the same size as the window, then if you move to the right, the image will have blank parts on the left and so on, which is why you need an image that is double the size of the map.

Oh I see, that makes sense then. I was under the impression that having a large picture would be enough to solve the screen-not-moving problem.


The picture has to be larger either way since if the picture moves with the character, then having it the size of the screen wouldn't work if the picture goes outside of the screen. Double each dimension would be a safe size to use as long as the picture is centered around the current camera target.