I’ll try your plugin out tomorrow when I’m off from work btw. Some easy to understand instructions or guidelines for said parameter(s) would also be very helpful for us non-programmers. 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. I also hope that this message was formulated okay enoughĮDIT: 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 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? 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).īut 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". 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). 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). Performance difference is quite dependent of target machine. Generally parallax mapping will consume more memory and bandwidth on 1st load, but it has less need of computing. (Writing this late at night but I hope I formulated myself okay enough)Ĭlick to expand.Hi and yes message was formulated okay enough! So I might as well ask some follow-up questions that I've been pondering. 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. Three layers is more than enough for me who usually only use two. I'm a fan of your previous plugins so I'll be sure to give this new one a spin as well. (Writing this late at night but I hope I formulated myself okay you, for your quick response. But the larger maps can be up to ~90x90 (4320x4320 pixels per image layer). My smallest maps are around ~40x40 (1920x1920 pixels per image layer), which is probably fine. 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. 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.Īnd like I said, I usually only use two layers (background, foreground) and no tiles whatsoever. 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. Is this correct, incorrect or does it maybe depend on the size of the image and plugin used?Īlso, regarding 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: Up until now however, I've always been told the opposite which makes me curious. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |