Looking for the ”best” parallax mapping plugin

Discussion in 'Javascript/Plugin Support' started by Parallax Panda, Apr 16, 2019.

  1. Parallax Panda

    Parallax Panda Got into VxAce ~2014 and never stopped... Veteran

    Messages:
    636
    Likes Received:
    1,001
    Location:
    Fukuoka, Japan
    First Language:
    Swedish
    Primarily Uses:
    VNM
    I’ve done some parallax mapping before but after many plugin creators have left (or gone into hibernation?), I’m no longer sure which plugin to use for parallax mapping.

    Since the engine will keep updating, using something that’ll not get updated anymore isn’t a good idea. Worse even of the plugin haven’t even been updated to match the current version of MV.

    Out of all the parallax mapping related plugins I can think of it’s only Yanfly’s ”Region Restrictions” and Kadokawa’s ”Foreground.js” plugins that I feel are future proof right now. But then again, I’ve not kept myself updated so there might be something else out there that I’ve missed?

    So what’sthe best plugin to use to parallax map in MV in 2019 - and is the ”best” option actually a good one?
     
    #1
  2. OcRam

    OcRam Servant of the Universe Veteran

    Messages:
    281
    Likes Received:
    345
    Location:
    Void
    First Language:
    Finnish
    Primarily Uses:
    RMMV
    Hi,

    Region Restrictions is good -plugin and I have just released layering -plugin. Don't know if it fits your needs, but if you want to check it out click this link https://forums.rpgmakerweb.com/index.php?threads/ocram-layers.107999/.

    I try to check all of my plugin threads at least once in month (or more often) if you are wondering about support. But can't see in future, for example a lot of things can happen in 5 years. But as long as I'm healthy and this community is alive I do my best for support.
     
    #2
  3. Parallax Panda

    Parallax Panda Got into VxAce ~2014 and never stopped... Veteran

    Messages:
    636
    Likes Received:
    1,001
    Location:
    Fukuoka, Japan
    First Language:
    Swedish
    Primarily Uses:
    VNM
    @OcRam
    Thank you, for your quick response. I'm a fan of your previous plugins so I'll be sure to give this new one a spin as well. Three layers is more than enough for me who usually only use two. On that note, since you made this plugin you obviously have some insight into how MV draws graphics and what load this might put on the CPU/GPU/RAM. So I might as well ask some follow-up questions that I've been pondering.

    I like parallax mapping, as my alias might suggest, but I also like to make large maps, and till this day I'm still unsure of how viable parallax mapping is compared to MV's built in tile-mapping (the mapping you do in the editor) when it comes to performance.

    While I'm not much of a programmer myself and therefore don't understand exactly what they're talking about, it almost sounds like parallax mapping might put less strain on your computer in this old thread: https://forums.rpgmakerweb.com/index.php?threads/parallax-mapping.88338/ Up until now however, I've always been told the opposite which makes me curious. Is this correct, incorrect or does it maybe depend on the size of the image and plugin used?

    Also, regarding performance. Would you say your plugins is more efficient compared to my current solution (normal parallax image with an "!" before the filename for the background and Kadokawa's "Foregroun.js" plugin for an overlay layer)? If there is no big difference in performance your plugin does provide more layers and possibilities which is a good thing. I'm also using previously mentioned Region Restrictions plugin by Yanfly, but I think I'd have to use that with your plugin as well so I don't think it's relevant to the performance.

    And like I said, I usually only use two layers (background, foreground) and no tiles whatsoever. Water or animated tiles is done by placing one or several events with large(!) graphics and give them a custom move route for the animation sequence. My smallest maps are around ~40x40 (1920x1920 pixels per image layer), which is probably fine. But the larger maps can be up to ~90x90 (4320x4320 pixels per image layer)... how would your plugin handle that?

    (Writing this late at night but I hope I formulated myself okay enough)
     
    #3
  4. OcRam

    OcRam Servant of the Universe Veteran

    Messages:
    281
    Likes Received:
    345
    Location:
    Void
    First Language:
    Finnish
    Primarily Uses:
    RMMV
    Hi and yes message was formulated okay enough!

    Generally parallax mapping will consume more memory and bandwidth on 1st load, but it has less need of computing. Performance difference is quite dependent of target machine.

    I took a look at this "foreground.js" -plugin and it seems it is more efficient (ATM) because it also uses TilingSprite -class (the normal way to do parallax mapping in RMMV), but only 1 times (my plugin has total of 5 different layers >> 2 of them for run-time sprites). But this doesn't mean my plugin is 5 times slower and if you use ALL of it's layers it might be ~1.1 to 3 times heavier than foreground.js (depending on target machine). For example on my computer I didn't notice ANY difference (used built-in FPS meter (F2) and it was 60 fps all the time with all layers stuffed full).

    But if you want I could try to do Parallax mapping optimization plugin parameter, which will disable normal tiling totally, this would make it even faster than "foreground.js".

    I also hope that this message was formulated okay enough :kaoslp:

    EDIT: Already tested this parallax mapping optimization and it will give significant speed-up on large/huge maps (since we don't event try to draw any tiles)!
     
    Last edited: Apr 17, 2019
    #4
  5. Sleepy Kitten Games

    Sleepy Kitten Games Veteran Veteran

    Messages:
    422
    Likes Received:
    184
    First Language:
    English
    Primarily Uses:
    RMMV
    Personally I swear by QMap and QMovement. QMap comes with an editor that lets you handle collision/restrictions based on what's on the map, instead of having to base it off of regions.
    Granted, I'm not sure how many tilesets would be okayed for use in QMap, since the mapping isn't being done directly in the RPG Maker editor. (Though, technically, making maps in GIMP or Photoshop also counts as the maps not being made in RPG Maker, doesn't it?) It probably depends on the EULA of the tileset, but I'm not an authority on the matter.
     
    #5
    Parallax Panda likes this.
  6. OcRam

    OcRam Servant of the Universe Veteran

    Messages:
    281
    Likes Received:
    345
    Location:
    Void
    First Language:
    Finnish
    Primarily Uses:
    RMMV
    Actually now that you said it, it is better to handle collisions/restrictions what's on the map (at least I would parallax this way). And I've gotta advertise that: You can do it either way in OcRam_Layers -plugin :wink:
     
    #6
  7. Sleepy Kitten Games

    Sleepy Kitten Games Veteran Veteran

    Messages:
    422
    Likes Received:
    184
    First Language:
    English
    Primarily Uses:
    RMMV
    Yeah, though QMap lets you define collision object-by-object. As in, place a tree on the map, the QMap editor lets you define collision for that tree. (And it lets you have the same object have different "layers" based off of where the player stands - ie, you walk behind a tree and it's above you, you walk in front of the tree and it's below you)
     
    #7
    Parallax Panda likes this.
  8. Parallax Panda

    Parallax Panda Got into VxAce ~2014 and never stopped... Veteran

    Messages:
    636
    Likes Received:
    1,001
    Location:
    Fukuoka, Japan
    First Language:
    Swedish
    Primarily Uses:
    VNM
    @OcRam
    So if you’re preloading a lot of the heavier map images (I don’t know of a preloadeing plugin that’s up to date though), even a large parallax map wouldn’t necessarily be so heavy, correct?

    It would be very interesting and useful to have an optimization parameter since performance is the biggest drawback that I see can happen with parallax mapping. Some easy to understand instructions or guidelines for said parameter(s) would also be very helpful for us non-programmers.

    I’ll try your plugin out tomorrow when I’m off from work btw. I’ve not gotten to it yet but I’m very excited to see what it can do and how the compabillity is with other plugins (Yanfly library, Terrax lightning etc).

    @GameFire
    If I’m not mistaken QMap and QMovement is made by @Quxios ? They do look like nice plugins for sure, but the problem I see with them is that it seems like Quxios haven’t logged in since April 14 2018. Thus I’d assume he has left the community and his plugins are all unsupported (and possibly not up to date) - which is a huge liabillity (no matter how fancy they are).
     
    #8
  9. Sleepy Kitten Games

    Sleepy Kitten Games Veteran Veteran

    Messages:
    422
    Likes Received:
    184
    First Language:
    English
    Primarily Uses:
    RMMV
    Actually, the plugins still work for me on the current version of RPG Maker MV (1.6.2).
    But yes, Quxios has decided to leave the RPG Maker community. Luckily, out of the plugins of theirs that I am using, most of them do work. The only ones that don't are QUpdate and QEventSave.
     
    #9
    Parallax Panda likes this.
  10. OcRam

    OcRam Servant of the Universe Veteran

    Messages:
    281
    Likes Received:
    345
    Location:
    Void
    First Language:
    Finnish
    Primarily Uses:
    RMMV
    Well if you pre-load maps then 1st load issue can fixed (partially) but it still consumes more memory. But on desktop computer you can't notice the difference on memory usage (just few Mb per map).

    I actually tested 100 x 100 maps both ways (tile mapping vs. parallax mapping (with 4800px * 4800px picture)). And parallax mapping gave small lag spike on 1st load, but after that it was just as fast as tile mapped map. On both maps I used all layers in my plugin and got 60 fps all the time (after 1st load). (AMD-FX 8350, 16 Gb RAM, GeForce GTX 960)

    EDIT: Oh... and just letting you know that I have released v1.02 of my layers -plugin. And I'll try to do help section how to use this plugin in parallax mapping.
     
    #10
    Parallax Panda likes this.
  11. Parallax Panda

    Parallax Panda Got into VxAce ~2014 and never stopped... Veteran

    Messages:
    636
    Likes Received:
    1,001
    Location:
    Fukuoka, Japan
    First Language:
    Swedish
    Primarily Uses:
    VNM
    @GameFire
    Well that's good to know. I'm interesting in his audio plugin for other reasons myself. Not sure if I'm willing to gamble on his pixel movement and collision plugins though since that's potentially game breaking if they at some point would break, and game development takes a long time so I have to think 1-3 years into the future.

    The audio plugin would be welcome but not vital so worst case scenario I could just drop it if it stopped working.

    @OcRam
    Nice, I doubt I'd be using larger maps than 100x100 but I guess I'll look around for a "preload plugin" if it could make things a bit smoother. I'll also be testing your parallax plugin today with the maps I've already got.
     
    #11
    OcRam likes this.
  12. Sleepy Kitten Games

    Sleepy Kitten Games Veteran Veteran

    Messages:
    422
    Likes Received:
    184
    First Language:
    English
    Primarily Uses:
    RMMV
    You don't have to use pixel movement with QMovement. There's settings in the plugin that let you still use the 48x48 grid movement MV has.
     
    #12
  13. Parallax Panda

    Parallax Panda Got into VxAce ~2014 and never stopped... Veteran

    Messages:
    636
    Likes Received:
    1,001
    Location:
    Fukuoka, Japan
    First Language:
    Swedish
    Primarily Uses:
    VNM
    @GameFire
    Isn't it made for pixel movement though? if it just uses the normal 48x48 collisions then what's the point?
     
    #13
  14. Padramyr

    Padramyr Veteran Veteran

    Messages:
    91
    Likes Received:
    75
    Location:
    Germany
    First Language:
    German
    Primarily Uses:
    RMMV
    @Parallax Panda I learned some time ago that you shouldn't update your MV as long as you're working on a project. The reason for that is what you're fearing: Plugins that don't work as intended anymore. As long as you use the same version of the program throughout development there shouldn't be any problems as plugins can't break that way. The only thing that can happen is that you encounter a bug within the plugin but then you can ask for help on the forums even if the plugin was abandoned.
    I know for myself that it's sometimes hard to not update the program when there are great new features or other interesting updates. But you should ask yourself whether it's better to hope that the plugins won't break when you upgrade to a new MV version or to go without the new features until the development is completed.
     
    #14
  15. Parallax Panda

    Parallax Panda Got into VxAce ~2014 and never stopped... Veteran

    Messages:
    636
    Likes Received:
    1,001
    Location:
    Fukuoka, Japan
    First Language:
    Swedish
    Primarily Uses:
    VNM
    @Padramyr
    I agree in general but there are exceptions where it's still better to update. For example when the new version fixes bugs withing the engine itself or increases performance or something that'll benefit your game a lot.

    You do risk breaking plugins and if you have a lot of them (and a lot are abandoned) this can be a huge concern. But if you don't use that many plugins and the ones you use are still supported it's probably not a bad idea to upgrade the engine if the update has something worthwhile to offer your project. Worst case you might have to wait a week or month for all your plugins to get updates as well.
     
    #15
    Padramyr likes this.
  16. Padramyr

    Padramyr Veteran Veteran

    Messages:
    91
    Likes Received:
    75
    Location:
    Germany
    First Language:
    German
    Primarily Uses:
    RMMV
    That's why I tend to keep the plugins at a low then you have less to worry about - and that's also why I started to learn JS :guffaw:
    But yeah, at some point one really needs to weigh between updating and risking to break plugins or to not update. Can be a really hard decision. I totally understand if you want to have plugins that are still supported - I think everyone wants that. And I also agree with you examples. I just wanted to state out that it's possible to avoid breaking plugins. I guess you already knew that (I just wanted to make sure :p ) but it's possible that new people reading this thread weren't aware of the reason for plugins breaking :)
     
    #16
    Parallax Panda likes this.
  17. Sleepy Kitten Games

    Sleepy Kitten Games Veteran Veteran

    Messages:
    422
    Likes Received:
    184
    First Language:
    English
    Primarily Uses:
    RMMV
    @Parallax Panda Yes, it was created for pixel movement. However, I'd guess some people wanted the capabilities of QMovement (defining colliders, the ability to use QABS or QMap or QPathfind or QSight or QM+CollisionMap, smarter collision checking, and so on) without it being necessary to use pixel-based movement.
    However, like I said, the Quxios plugins still work just fine for me with the exception of two.
     
    #17
    Parallax Panda likes this.
  18. phamtruong1992

    phamtruong1992 Mage Art - Green Dragon Veteran

    Messages:
    146
    Likes Received:
    180
    Location:
    South Asia
    First Language:
    English
    Primarily Uses:
    RMMV
    What if we make super large maps, like the pixel count would be up to like 10.000x10.000 or 20.000x20.000? Can normal pc's handle that smoothly? Not that i want to make that large of maps but I'd like my game to have higher resolution, so a normal map would be really high resolution.
     
    #18

Share This Page