Welcome Guest ( Log In | Register )

[ Big| Medium| Small] -



Post new topic Reply to topic  [ 13 posts ] 
    Fustel
  Wed May 26, 2010 11:32 am
uh...!?!
Member


Location: near Bordeaux - France
BDR Layer Version: 1.3 for RMVX
By: Fustel

Introduction
This script allow the display of multiple maps in a single map scene. The extra map are considered layers shown over the base map.
The best usage I found for it, and for naw, is the show/hide building roofs, while preserving what is inside the building. This is not a redrawing of the building interior. This is 'really' a multi-layered map.

Features
  • Multi-layered maps
  • Show / Hide each layer individually or as a whole
  • Select the layer management method
  • Make all the changes now, or ready them for the next map to load

Screenshots
Roof Removal


Demo
Roof removal


Script
Expand to see the code.


Instructions
  • Copy the script in the 'Materials' section, as it fully overwrite the main methods
  • Create layers for your base maps. Each layer may be any size, and generally includes many transparent tiles
  • Link base map and layer map through the BDR::Layer::Layer constant. This constant is a hash with the following structure
    • key = base map ID
    • data = array of arrays. each sub-array defines a layer with the following structure
      • [0] = layer ID (used for show/hide and future features). MUST be unique
      • [1] = layer map ID.
      • [2] = layer z value. The higher this value, the closer to the player the layer is. Remeber the following:
        • Base map is at z=0
        • Special effects (weathe, pictures, etc...) are at z=50
        • Map brightness is at z*100
      • [3] = visibility of the layer at map loading time (true / false)
      • [4] (optional, default=0) X position of layer map in main map
      • [5] (optional, default=0) Y position of layer map in main map
  • Set the default layer management method, if necessary through the BDR::Layer::Method constant
    • 1 = Viewport repositionning (the default one in the script)
    • 2 = Viewport offset
    • 3 = Tilemap offset
  • Show a layer by invoking: '$scene.show_layer(<layer ID>)
  • Show all layers by invoking: '$scene.show_layer
  • Hide a layer by invoking: '$scene.hide_layer(<layer ID>)
  • Hide all layers by invoking: '$scene.hide_layer
  • Prepare layers to be displayed on next map by invoking (only listed layers will be visible): '$scene.show_layers_on_next_map([<layer_ids>])'
  • Change the display method with: '$game_system.bdr_layer_method = <n>'
  • Set the display method for the next map with: '$game_sustem.bdr_layer_method_on_next_map = <n>'


FAQ

Compatibility
No issue known.

Credits and Thanks
All done by myself
Also, if I remember well, Dargor was working on something similar called 'Map Layers'; but I couldn't dind the reference.

Author's Notes
This is the first step to a full layered map, with player transition from layer to layer, each beeing a 'real map', not just a display thing.
It is intended as a test; so use & abuse it, and tell me if yoy nitice any stress (CPU, meory, internal ressource).

v1.1
The layer maps need not anymore to be the same size as the base map.
Technically, the viewport is now re-positioned instead of the tilemap.

v1.2
  • Corrected a bug when reentering a map with layers
  • Allow the showing/hiding of all layers in a single call
  • Introduced the management method

v1.3
  • dynamically (script) select the displayrd layers for the next map
  • dynamically (script) select the display method
  • method can alos be set to take effect only on next map
  • bugs fixed
    • save / load visibility flag
    • bad display at first graphic update when returning from a scene (menu & others...)

Terms and Conditions
You may not use this in a commercial game without my explicit permission.
You may not post this script anywhere without my explict permission.
You must give me credit.


Last edited by Fustel on Mon Jan 24, 2011 9:03 pm, edited 4 times in total.

Top Top
Profile      
 

    Pokémaniac
  Wed May 26, 2010 12:30 pm
User avatar
Awesome Bro


Location: Australia
This works nicely, but a fade-in fade-out roof would be even nicer.


Top Top
Profile      
 

    BlueScope
  Wed May 26, 2010 12:32 pm
The Third Man
User avatar



Location: Germany
The roof example reminded me about a solution for that very same problem I tried to find once... I ended up having pictures that dispose themselves when the person walks underneath them, essentially creating an almost entirely automated (obviously, you need to initialize the images) handler of self-hiding roofs. I think it's resource-friendlier than your method on the system side... of course you get relatively more filesize (I thought about having kind of an auto-roof creation from tiled pictures, which would downright minimize the filesize to not a bit more), however, I never got around to do it.
EDIT: It's also transparency-compatible ^^

But yeah... I don't want to create the impression that this script is for roofs only... I especially see the purpose in circumventing VX' donkey default mapping possibilities. I doubt it'll get more people to use VX though, sadly...

So, let's skip to the suggestion part... your scripting is comparatively outstanding, even though there's the totally undistinguishable 'BDR' in there everywhere... other than that, practical suggestions:
- handling the map layers via map names would be more confident in my opinion... it should be perfectly possible and would ease working with layers greatly.
- supporting smaller maps to overlay bigger maps would be pretty handy... especially for stuff like that hut, where a 17x13 map is perfectly sufficient in theory. Now I don't know for sure how much trouble that means, but in theory, it should be as easy as shifting the layers by x*32 and y*32 pixels, while x and y are either in your array, if you keep it, or in the map name.

I thought Ihad some more, but I either forgot them while writing this or overestimated my improvement suggestions XD

Keep up the good work!

_________________
Image

If you have a slightly positive memory of my Power Shift contest game,
you might be interested in this development screenshot...
More info about that soon!


Top Top
Profile      
 

    Fustel
  Wed May 26, 2010 3:27 pm
uh...!?!
Member


Location: near Bordeaux - France
BlueScope wrote:
....even though there's the totally undistinguishable 'BDR' in there everywhere..

I don't know why.... but I was expecting this one.... :wink:

BlueScope wrote:
- handling the map layers via map names would be more confident in my opinion... it should be perfectly possible and would ease working with layers greatly.

Map name are more often changed than map ID. Think about maintainance.

BlueScope wrote:
- supporting smaller maps to overlay bigger maps would be pretty handy... especially for stuff like that hut, where a 17x13 map is perfectly sufficient in theory. Now I don't know for sure how much trouble that means, but in theory, it should be as easy as shifting the layers by x*32 and y*32 pixels, while x and y are either in your array, if you keep it, or in the map name.

Already tried it.... but a smaller map repeats drawing itself over and over the bigger one. It is hard-voded in the Tilemap class for, I think, map looping management.
Unless I also do something about the viewport....mmm...no, that mean we also have to manage the viewport position during update... forget it. Layer map HAVE to be the same size as the base map... for now...

As I said, roof management is only one the things we can do with layers. And this is only the first step to something else....


Top Top
Profile      
 

    BlueScope
  Wed May 26, 2010 3:56 pm
The Third Man
User avatar



Location: Germany
Well, you put the BDR there, so take it! :haha:

As for the map name, I think you misunderstood me... I don't mean store the maps by name instead of ID in the script (that indeed would be pretty stupid to do, agreed) - I mean put the layering management in the map name. Something like this:
Expand to see the code.

That translates to "Super-Town is the second layer for the 34th map set" - assuming you don't plan on using the seperate maps as, well, seperate maps, but only in the corresponding packages (but I think your current script assumes that as well).
After writing the following paragraph (yay time travelling), I realize it's probably better to include the map IDs of the map to layer in the base map's name. I'd elaborate further, but you're a pretty smart guy, so you should be able to figure it out... and also, work is over for today... yay freetime! ^^

And yeah, the repeating issue you talked about sounds a bit like in-the-way... however, a Tilemap rewrite should solve it, no? I remember looking for some, but couldn't find any... maybe that's changed in the meantime, but if not, it'd be a good reason (for you XD ) to make one, right? ^^ I really think it'd be worth trying to fiddle with it... (think resource weight reduced, reusuability, ...)

_________________
Image

If you have a slightly positive memory of my Power Shift contest game,
you might be interested in this development screenshot...
More info about that soon!


Top Top
Profile      
 

    Fustel
  Wed May 26, 2010 4:23 pm
uh...!?!
Member


Location: near Bordeaux - France
Including the layers in the map name sitll doesn't apeal to me.
  • It means the name have a meaning (not semantically acceptable)
  • It means parsing the name... and I don't like parsing name, especially with multiple parameters for each layer
  • Try & imagine a HUD displaying the map name...

As for the smaller map usage. Tilemap, although it have a Ruby interface, is a built-in class; and if you explain me how to rewrite a built-in class, I'd be eager to do it :tongue:
I also imagined (during my 'weight-management-time' :blush: ) a way to use viewport sizing & positioning. But I am not sure of whait it will do with looping map, and especially with the Player navigating from layer to layer (THIS is the big idea...).
So, for now, I keep the 'layer MUST be the same size as the base map' principle.


Top Top
Profile      
 

    BlueScope
  Wed May 26, 2010 4:28 pm
The Third Man
User avatar



Location: Germany
Yeah, I see where you're coming from in all points...

Regarding the Tilemap rewrite, I know it's a built-in class and therefore written in C. That doesn't mean, however, that you can't simply recreate it in Ruby, as in start with class Tilemap; end and go from there, trying to get all methods you need rewritten. Not knowing what they're called is arguably a difficulty, but as it's been done for RMXP a few times, you should be able to get an idea from there... even though they hardly have anything in common.

_________________
Image

If you have a slightly positive memory of my Power Shift contest game,
you might be interested in this development screenshot...
More info about that soon!


Top Top
Profile      
 

    Fustel
  Wed May 26, 2010 4:44 pm
uh...!?!
Member


Location: near Bordeaux - France
In fact, I know at least ONE thing they have not in common. VX Tilemap gors directly to the hardware, while XP used standard Windows canvas. I know this becouse my magnifying software (you know I am near-blind, didn't you) enlarges XP windowed game, but not VX one.
And moreover, I am ABSOLUTELY a C-unlover... I am one of those old-time Pascal & Delphi-er :heart:

Someone ???


Top Top
Profile      
 

    Chalupa
  Thu May 27, 2010 6:54 pm
"Et tu, Brute?"
User avatar
Member

Fustel wrote:
This scrit allow the display of multiple maps...


Sorry, but this is the one thing about this post that bugs me. If it's supposed to be a script, then well done. Fantastic. If it's a scrit, then I'm not sure what to think if it. I've never heard of a scirt.

~Its a typo, everyone makes them and in no way warrants that kind of behavior.

_________________
Image


Top Top
Profile      
 

    Fustel
  Thu May 27, 2010 8:20 pm
uh...!?!
Member


Location: near Bordeaux - France
Chalupa wrote:
Fustel wrote:
This scrit allow the display of multiple maps...


Sorry, but this is the one thing about this post that bugs me. If it's supposed to be a script, then well done. Fantastic. If it's a scrit, then I'm not sure what to think if it. I've never heard of a scirt.



What kind of choice do I have but to answer..... Ooops... :blush:


Top Top
Profile      
 

    Fustel
  Tue Jun 15, 2010 9:24 pm
uh...!?!
Member


Location: near Bordeaux - France
Due to unanimous plebicite, as well as to the fact the (soon-to-be-released ???) full multi-layered map won't have exactly the same structure as this restricted layered one, v1.1 is up.

The only upgrade (but not the least) is about the layer size. You can now make layers of ANY size. Not the base map one anymore.

Enjoy.


Top Top
Profile      
 

    Fustel
  Fri Nov 05, 2010 10:17 am
uh...!?!
Member


Location: near Bordeaux - France
Back to BDR Layer....
Trying to use it in a new project, a couple of issues appear.

1/ The nned to hide/show all layers in one call. This is done with show_layer and, hide_layer, without any argument.
2/ An ENORMOUS bug when re-entering a map with layers. This is corrected.
3/ An annoying issue for which I still do not have any precise explanation. It just happened the method I used to manage the layers (moving its Viewport around) doen't work in this project. After some experiments, I implement a nex method, using the Viewport offset. Which in turn didn't work with the demo. Thus I implemented the 3 methods I found, allowing everybody to choose which one to use. But if anyone has a clear explanation about Viewport.rect, Viewport.ox (and oy) and Tilemap.ox (and oy), PLEEAAASSSSEEEE enlight us.....


Top Top
Profile      
 

    Fustel
  Mon Jan 24, 2011 9:12 pm
uh...!?!
Member


Location: near Bordeaux - France
After using and abusing the script myself (in a grant vintage project soon to come...), I noticesd some bugs & flaws that are corected in this version. See the Notes and Instructions on the may post for more details


Top Top
Profile      
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 


Who is online

Users browsing this forum: No users and 23 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

We are an independent, not-for-profit game making community.
Homepage
Board Index
About Us
Downloadable Games
Free Browser Games
Games in Development
RPG Maker Support
Game Maker Support
Construct 2 Support
HBGames the eZine
Advanced RPG Maker
Site Announcements
Powered by phpBB © phpBB Group