Check whether a specific tile is a star marked

[RedolentGalaxy9]

As the title suggest, I need to check whether a tile, let's say at position x, y in tile coordinates on the current map, is marked by a star. Of course, I want to check this through scripting and not eventing. 

For example are tree crowns in VXA marked by a star by default. I attached a picture showing this. 

I've tried searching for this, but I didn't find a good thread about it. 


Thank you for your answer.

 

[Bex]

Yeah sure that should be possible, just dont have that special command at hand and would sugest a look into the script call equivalents pinned thread, but not sure if its in there.


Or than to ask like you did with this thread .


What are you trying to do? This could help to provide also maybe different solution possibilities.

 

[RedolentGalaxy9]

Thank you for the fast answer, and sorry for a slightly slower response.

I've been writing a script that lets the player shoot projectiles outside of battle. These projectiles may activate switches, thus making a good tool for interesting puzzles. Although the projectiles are working when it comes to drawing their sprites, activating switches and so on, there's one thing I'm bugged out about, namely it's being drawn over star marked tiles, e.g. trees.

The problem arise in the fact that I'm not changing the tiles to a tile with a projectile, but rather I'm just drawing a (projectile) sprite over the tiles.


I've tried using sprite blend types to get rid of this problem, but to no avail. In this case the only thing that happened (out of the ordinary) was that the projectile became pitch black. I tried blend type 1 (normal), 2 (additive) and 3 (subtractive). I used it through @projectile_sprite.blend_type = x, where @projectile_sprite is the sprite for the projectile and x was either 1, 2 or 3.


Since this didn't work I moved to another approach, namely to not draw the projectile if a tile is star marked.



I first tried checking the second layer of tiles to see whether it was non-zero or not. If it was non-zero, don't draw the projectile. This solved the problem, but gave rise to a new problem, namely now the projectile is not drawn if it's something on the second layer of tiles, e.g. a flower. The lines of codes for this check is:



if $game_map.tile_id(*next_tile, 2) != 0


   *don't draw projectile code goes here*


end

Here "next_tile" is an array containing the coordinates (in tiles) of the next tile the projectile is going to be drawn upon.

Since this didn't work I decided that checking whether "next_tile" is star marked or not. I tried several ways, most notable examples are below:


if $game_map.tileset.flags[$game_map.tile_id(*next_tile, 2)] >= 1000 && 0x10 == 0
   *don't draw projectile code goes here*
end


This gave rise to the same problem as above for whatever reason. It's my first time working with "0x10"-stuff so I'm not entirely sure how they work. A similar if statement may be found the function "check_passage" in the class "Game_Map".

Another way I tried is by defining an entirely new function in the class "Game_Map", and calling this function to see whether a tile is star marked or not:


class Game_Map
  def rg9_check_start_tile(x, y)
    star_tile = false
    all_tiles(x, y).each do |tile_id|
      flag = tileset.flags[tile_id]
      star_tile = true if flag & 0x10 != 0
    end # do
    return star_tile
  end # def


end # class


Don't mind the "rg9_"-part of the function name. I use it do distinguish between aliased functions and my own functions. Anyway, what I find to be weird is that the if statement "if flag & 0x10 != 0" is exactly the same one as in the function "check_passage" in the class "Game_Map", that checks there whether a tile is star marked or not. Changing "0x10 != 0" to "0x10 == 0" might solve it, but I can't try this until later tonight (I'm writing this at work, lol).

Sorry for long post, and I greatly appreciate a solution to this.

 

[RedolentGalaxy9]

I forgot to mention, but I solved it in another way. More specifically, by using regions.

 

[Bex]

Iam no Scripter and i dont have much Time right now will read properly other Time, but i believe there is a Z Value in rpgmaker, which determines


whats shown ontop of what.


Pictures are normaly a higher Z Value than the Map and less than Textboxes.


And is your Bullet Sprite an Event or did i read correct and its a Scriptet sprite on a Bitmap or something like that?


If Scripted you need a Script knowledge person to help with implementing the correct Z Value.


Or adding a Demo Map with this Function.  I just experimented with such stuff in a 4dir shooter a little.

 

[Sixth]

You can simply set the viewport of your projectile sprites to the @viewport1 found in Spriteset_Map, and set their z value to 100.


The projectile sprites than will appear exactly like a normal priority leveled character on the map, so above everything which is set to "Below Characters" or "Same as Characters", but below everything which is set to "Above Characters". That is regarding the character VS projectile appearance.


And the tilemap VS projectile would be the same as for all characters, so tiles with a star flag would hide the projectiles like you want.


If your projectiles are not made in the mentioned class, you will need to allow access to that class instance in Scene_Map, and through that, assign the viewport to your projectile sprites.


You don't have to meddle with complicated logic to get any tile flags or region IDs, just do the above and it will do what you want.

 

[mlogan]

I've moved this thread to Script Requests. Please be sure to post your threads in the correct forum next time. Thank you.

 

[RedolentGalaxy9]

Sorry for posting this question in the wrong place..

I haven't tried setting it in viewport yet because I will need to rewrite quite some code to do that, but can't I just set the sprite's z-value to 100? I have tried doing just that and that didn't work. I think what I'm asking is what makes viewport special?

 

[Sixth]

The game's screen is layered by viewports.


Viewports are layered by sprites.


A sprite without a viewport will act as if it got it's own separate viewport.


This means that if you set it's Z value, the sprite will be moved above or below other viewports, not above or below other sprites (although the latter will happen regardless, because the layer of viewports is a higher priority).


It is kinda hard to explain this without a graphical example, unfortunately.


But here is a direct example:


You got 3 viewports:


@viewport1 # Z = 0
@viewport2 # Z = 100
@viewport3 # Z = 200


And 4 sprites:


@sprite1 # Z = 10, viewport = @viewport1
@sprite2 # Z = 450, viewport = @viewport2
@sprite3 # Z = 200, viewport = @viewport2
@sprite4 # Z = 100, viewport = @viewport3


In this example, the sprites will show up like this:


@sprite4 is on top of the others because it's viewport got the highest Z value, even though the sprite's Z value is not the highest among the sprites.


@sprite1 will show up below the others, because it's viewport got the lowest Z value. The sprite's Z value is also the lowest in this case, but that doesn't matter here.


@sprite2 and @sprite3 will show up between the other two, because their viewport is between the 2 other viewports. Even though @sprite2 got the highest Z value, it will not be displayed on top of all the other sprites because of it's viewport association. 


@sprite2 is displayed on top of @sprite3 because they are on the same viewport and @sprite2 got higher Z value than @sprite3. 


So, as you can see, the Z level of viewports is a higher priority in layering than the Z level of sprites. 


The Z level of sprites matter only if they are on the same viewport.


And the final factor:


If there are more than one sprites/viewports with the same Z level, the ones created later will appear on top of the older ones.


In your situation, you create a sprite without a viewport, which means you will never be able to achieve what you want, because the sprites related to your issue got their own viewport (@viewport1 from the map spriteset). Whatever you do, your sprites will either be above or below those tiles, and will never change their Z position.


You can not solve this without setting the viewport of your sprites to the same as the viewport for those related sprites, at least not without executing unnecessary extra calculations, but doing that is actually harder than simply assigning the correct viewport to your sprites, not to mention that doing that would cost more time to execute.


Never do workarounds if you are coding, always do what you want properly, otherwise you will end up with messy and performance dropping codes all around your script(s).

 

[RedolentGalaxy9]

Ah okay. I think I understand how viewports work. Thank you. Now, how do I set a sprite to a viewport (in my case @viewport1)? As of now I have generated a sprite from the Sprite class, i.e. something in style with:

class GenerateSprite < Sprite
def initialize(filename)
super()
self.bitmap = Bitmap.new(filename)
end
end

@projectile = GenerateSprite.new(file)

 

[Sixth]

You do that the opposite way, you set the viewport of the sprite.
So, first, you need the viewport (you have that already if you want to use @viewport1).
Than you need to make the sprite, and assign it's viewport.

You don't really need to make a new class for making a sprite, you can do this:

@sprite = Sprite.new(@viewport1)
@sprite.bitmap = Cache.system("filename")

The bitmap part is just an example, you can set the bitmap how you want, but I do recommend using the cache for it, especially if you plan to use that bitmap a lot of times in your game.
If you create the sprite yourself, the Sprite class takes an optional argument for setting it's viewport, so you can use that argument.
If you already have a sprite, but want to change it's viewport, you can do so easily with this:

@sprite.viewport = @viewport1

Of course, if you plan to have a more specific class for some extra calculations, effects, update things, and such, it is indeed a good idea to make it a new class, and do all the new methods inside of it, that makes it more modular and reusable.

Just don't forget that any graphical objects you make must be disposed properly to avoid memory leaks and/or random crashes.

 

[RedolentGalaxy9]

Thank you so much for your fast answers, even though I have not been so active the last couple of months. I will try to start working with it again regularly. Thank you.

Anyway, I have been working with sprites in RPG Maker VX Ace previously, but I have never used Cache.system. However, I have been very careful to make sure that my sprites have been properly disposed of whenever they are not used anymore. Would it make a difference in performance if I used Cache.system instead? Do I still need to dispose of sprites if I use Cache.system? Could you explain quickly what the main differences are between Cache.system and the way I used to generate sprites?

Sorry for going a little off topic.

 

[RedolentGalaxy9]

Nevermind my last questions. I think I understand them already. Sorry for being rusty. My next question is then how I should reach the instance viewport variables (@viewport 1 - 3). They reside in the class Spriteset_Map, and it is called in the class Scene_Map through @spriteset = Spriteset_Map.new. Do you think it would be a good idea to generate my sprites in the class Scene_Map, and then make a new function in the class Spriteset_Map which returns the viewport variables?

 

[Sixth]

If you need your sprites on the map, there is no need to put them anywhere but in the Spriteset_Map class, because you want them to use the viewports created in that class. This way you get easy access to the viewports you need.
The spriteset is easily accessible from the Scene_Map class anyway (without doing anything for it), so there is no downside of putting your sprites there.

I know, you wrote that you don't need an answer to the previous question, but regardless, I will leave this here, maybe it will help someone who finds it later.

Spoiler

The Cache.system is just an example I used. The Cache module have more built-in methods, but you can also make your own ones there if needed.
The example I used would only search for images stored in the project's "Graphics/System/" folder, but that is not the reason I suggested using the cache.

The Cache module will only make a new bitmap, if there is no such bitmap made yet. If there is already one with the same folder path and filename, it will just use that one instead of making new ones every time you call for it.
This is only useful if you use these bitmaps a lot of times.
It is also worth noting that if you use the Cache module, and if you call dispose on the bitmap later, all sprites using the same bitmap will get their bitmaps disposed as well. To remedy this (in case you need), you can clone the bitmap, and each one will be treated as a separate bitmap. No idea if cloning a bitmap or making a new one is quicker though, never really tested it.
It is not necessary to dispose the bitmaps made with the Cache module, because you have a reference to them in the module still, even if the sprites using them are disposed already. However, depending on what you do with your sprites, it might be better to get rid of unnecessary bitmaps at least on scene changes to avoid overloading the RAM with unused images (VX Ace's engine can only take around 1GB of RAM, after that, chances are high that it will crash).
There is really no rule for when to dispose bitmaps, it all depends on what you do with them. Unused bitmaps will get garbage collected sooner or later automatically anyway.

From my experience, the only reason to keep bitmaps in the cache is when you want to animate them. If you would always dispose and recreate them in this case, you would get a severe FPS drop (creating bitmaps is a resource consuming thing to do, especially if you do it repeatedly). Even in this case, you should dispose them when you no longer need them.
For example, if you would animate the title screen with some cool looking images. You make your image frames, and animate them using your script. You should not dispose the bitmaps used for the title animation(s) while the player is on the title screen. But when the player starts the game, there is no point in leaving them undisposed (they would just take the memory away from actually useful stuffs), so you should get rid of them then.

You might also want to keep the in the cache if they are used very often. Like the iconset, for example, or some very common projectile images (like in shooter games, tons of bullets could use the same bitmap, so it's better to leave these bitmaps in the cache to save some FPS).