Man, since MV was released i was hoping for a Mode 7 plugin to be released. Thank you very much!
I'll be also waiting to work on looping maps. :3
Ultra Mode 7 [RMMV & RMMZ]
● ARCHIVED · READ-ONLY
-
-
@Crasher TN I'll get to it eventually. :) I'm just a bit busy with King of Booze 2 right now so I barely have time for MV.
-
this is pure awesomeness i can use this for my cutscenes and world map view thanks bro!
-
@bblizzard I've found in your plugin a weird bug. When using it, if you transport your player to another map from the Mode 7 map, the sprites from characters and events will not show. It happens in your demo (without any plugins) and in my own project too.
This bug only affects those maps that are not using the Ultra Mode 7 notetags, since once you return to the Mode 7 map, the sprites and event graphics will be showed again.
Thanks in advance!
UPDATE: Also, I have issues too with RAM usage in maps that are 256x256 large, and only using B,C,D, and E Tilesets (since in my own project, I'm not using the A autotiles to create the world map).
Maybe this is related somehow with what @Espilonarge said, about loading each tile in every step you make with the character. -
I'll definitely look into all those issues. I'm putting together a list and will have a go at it when I have some free time.
I most likely made a mistake with map setup and probably didn't reset some variables which would explain the weird sprite behavior. -
When you said you were using a "pixel movement" plugin, you just made me remember something I ran in to a while back so I did another test and may have found the likely suspect to what's causing the FPS issue.Hm, the RAM usage thing is weird. I'm obviously reusing cached textures (I didn't touch the texture loading code). Each vertex has 11 floats that it uses which is 44 bytes per vertex. A tile consists of 4 quads or more accurately 8 triangles which means there are 24 vertices per tile. If you have a 256x256 map, that's 44 bytes * 24 vertices * 256 * 256 which is still only about 17 MB of RAM. The code is optimized by the default MV code already to use tiles for other layers only where they are needed so requiring any more than 20-30 MB for all vertices is unexpected. Since this isn't a classical tilemap, I can't actually do the rendering the same way as vanilla MV with a fixed amount of vertices, because the amount changes depending on camera direction and angle. But I think that things should drop when I optimize the code to display less vertices at the same time. The spike of over 300 MB is still weird though.
Are you using any special event options that could cause the events to appear in the sky? I do need to check the vehicles since they might contain custom positioning code. Keep in mind that using edge-cases like a 90° angle or more does invite possible issues that aren't just visual problems, but also logical ones. Looking at the map from below can't be supported, because the depth-buffer is better left unused (for performance and other reasons).
The "complex" version that I uses mainly has support for curved rendering, some custom code for adjusting the parallax and is modified to support the pixel movement I use in my game. https://gyazo.com/00fc385931acbca88b855093dfe62da6 It's not very different in terms of rendering, most of the differences are in the positioning code for sprites.
* I made a clean map and set it to 256x256. I then made a small island of tiles. The FPS stayed stable.
* I increased the island to around 50x50, the FPS stayed stable.
* I increased the island to around 1/2th of the map and the FPS started to stutter.
* I proceeded to cover the map with the same tile and that's when the FPS become a slideshow.
The only plugin I've ever seen with this exact kind of behavior happen before is QMovement by Quxios. Their plugin uses specialized bounding-boxes to prevent movement but on fairly large and/or complex maps (256x256 or larger through manipulation of the maps json file) this can start causing FPS drops and it's made only worse when using plugins such as Galv's Layer Graphics and MOG's Weather EX. It's also possible to turn on the visibility of the bounding-boxes, however, this comes at a performance cost by revealing them on screen (which makes the game highly unplayable while in this state).
The only difference between their plugin and yours is that theirs causes the FPS to drop near-permanently when this happens even without any movement, yours however only causes the FPS to drop upon movement (which leads me to believe it's related more to how the "camera" moves to reveal tiles and their passibility rather than just when the character is moving around).
As for the floating events, this is only happening when the set angle exceeds 65-70 degrees. There are no special events that make changes or calls to the plugin and no changes were made to the plugin or MV, only what's been set in the maps Note box (in the screenshot, it was set to <UltraMode7_Pitch:83> when this happened and tested with higher/lower values). There are also no other plugins in the list that could conflict with your plugin when doing these tests. Again, they aren't appearing in the same x-y coordinates but are still organized in the same layout they were placed (those are the exact same NPC events you placed on the demo map). The quirk about the floating events bug is that the higher the Mode7's angle value, the closer they are to the ground and as you move around, their position moves at around "twice" the speed of the direction you move in (for every tile you move, their position moves two tiles in the same direction). I'm guessing the plugin doesn't have a proper hide/cull graphics function after a set distance (or the code is mishandling the way MV "hides" them) and the way they move at 2/1 tiles around the map when this happens leads me to believe a miscalculation is happening somewhere in the plugins code to their actual positioning.
Regarding the visible vehicles in the top-left corner of the map, the only thing I can suggest for this is to put in a small disclaimer that people need to set them to "None" by default in the Systems tab of their games settings and only make them appear with the "Change Vehicle Image..." command in an event when needed (until the issue is resolved). -
huh, well i wasn't expecting to actually ever find a script that had mode 7 for MV, i'll have to try this one. hopefully it's what im looking for
-
When you said you were using a "pixel movement" plugin, you just made me remember something I ran in to a while back so I did another test and may have found the likely suspect to what's causing the FPS issue.
* I made a clean map and set it to 256x256. I then made a small island of tiles. The FPS stayed stable.
* I increased the island to around 50x50, the FPS stayed stable.
* I increased the island to around 1/2th of the map and the FPS started to stutter.
* I proceeded to cover the map with the same tile and that's when the FPS become a slideshow.
The only plugin I've ever seen with this exact kind of behavior happen before is QMovement by Quxios. Their plugin uses specialized bounding-boxes to prevent movement but on fairly large and/or complex maps (256x256 or larger through manipulation of the maps json file) this can start causing FPS drops and it's made only worse when using plugins such as Galv's Layer Graphics and MOG's Weather EX. It's also possible to turn on the visibility of the bounding-boxes, however, this comes at a performance cost by revealing them on screen (which makes the game highly unplayable while in this state).
The only difference between their plugin and yours is that theirs causes the FPS to drop near-permanently when this happens even without any movement, yours however only causes the FPS to drop upon movement (which leads me to believe it's related more to how the "camera" moves to reveal tiles and their passibility rather than just when the character is moving around).
Hm, I did the code in a very specific way that doesn't require any recalculation when moving. The only change is the transformation matrix, but that procedure is has a constant complexity and is completely unaffected by map size. I probably made a mistake somewhere else. The primary thing I can think of is all the offline data that I don't send to the GPU, it would explain a few things. But on the other hand, default MV uses that same offline data.
I do need to recheck how I did autotiles, because I definitely should avoid reuploading new vertices if I can just process them in the shader depending on a timer. I'll look into this.
As for the floating events, this is only happening when the set angle exceeds 65-70 degrees. There are no special events that make changes or calls to the plugin and no changes were made to the plugin or MV, only what's been set in the maps Note box (in the screenshot, it was set to <UltraMode7_Pitch:83> when this happened and tested with higher/lower values). There are also no other plugins in the list that could conflict with your plugin when doing these tests. Again, they aren't appearing in the same x-y coordinates but are still organized in the same layout they were placed (those are the exact same NPC events you placed on the demo map). The quirk about the floating events bug is that the higher the Mode7's angle value, the closer they are to the ground and as you move around, their position moves at around "twice" the speed of the direction you move in (for every tile you move, their position moves two tiles in the same direction). I'm guessing the plugin doesn't have a proper hide/cull graphics function after a set distance (or the code is mishandling the way MV "hides" them) and the way they move at 2/1 tiles around the map when this happens leads me to believe a miscalculation is happening somewhere in the plugins code to their actual positioning.
That's true, I didn't turn on any culling. It's probably just a calculation mistake or I didn't take proper care of an edge case.
Regarding the visible vehicles in the top-left corner of the map, the only thing I can suggest for this is to put in a small disclaimer that people need to set them to "None" by default in the Systems tab of their games settings and only make them appear with the "Change Vehicle Image..." command in an event when needed (until the issue is resolved).
Nah, I'll add proper support for it. xD It's really not a big deal. -
Well this is pretty much all i've been looking for, it doesn't lag at all with 200 events. thanks.
im no expert, but is there any possibility of making a second higher layer to the ground through regions or something? like a hill. -
Mode7 is based on the SNES's ability to display and/or rotate a flat set of tiles at an angle, it was never designed however to create actual 3D plains or in the context of what you want, hills and mountain ranges with elevated/lowered surfaces. You would require either an actual 3D based plugin that can manipulate terrain data to give raised/lowered terrain sections (similar to FPLE) or something that could apply a form of tessellation/bump-mapping/height map effect to the terrain (H-Mode7 does this but it never got transitioned over to MV).im no expert, but is there any possibility of making a second higher layer to the ground through regions or something? like a hill.
-
Well, technically height maps could be implemented relatively easily since even though the original SNES Mode 7 isn't 3D, this script is. It would just need to load the file, upload it to the shader and change the shader code to offset pixels depending on the height map. But I would like to keep this script "simple" and not overdo it with features. More features mean more potential issues with other scripts. Now that a base Mode 7 script exists, I'm sure somebody will create mods and plugins for it. xD
-
Yes, good way of thinking. Right now what I can say is when I tried on my project I immediately found a glitch on my maps using the "smooth camera" plugin from Galv, for some reason the camera would just stay at some corner of the screen and never move.More features mean more potential issues with other scripts
I also can't see any of my events if I'm not on a "classic map" with tileset and use a parallaxe plugin (can't find a way to make them re appear even by switching OFF some plugins.)
Of course I'm not expecting the plugin to work with parallax-maps (yet ?^u^?) so I didn't put the tag in those maps and only tried on tileset based map (cool render by the way, very promising), the thing is... The glitch happens even on a parallax map that doesn't have any “mode7 tag” on it.
Would be best to totally turn the plugin OFF when we don't call it, this way we could only use it sparingly on some very specific maps.
(Don’t hesitate to install very common plugins from Yanfly like the core engine etc, in your demo-project, this way you’ll see most problems people could likely have with your plugin.)
Well, I hope my "feedback" will help. Good luck! -
Alright, v1.1.0 is up. I fixed a lot of issues you guys were having and I added some features. What I didn't add yet:
- different color fading (since it needs to be change-able on the fly and I need to decide the best way to do this)
- sprite color fading (it's actually simple, but I left it out for now)
- loopable maps (because it's a big chunk of work)
- reduced RAM usage (I actually need to do this first before I can do loopable maps in a better manner)
Yes, good way of thinking. Right now what I can say is when I tried on my project I immediately found a glitch on my maps using the "smooth camera" plugin from Galv, for some reason the camera would just stay at some corner of the screen and never move.
Can you link the script? It depends on how the script was written. This smooth camera script works, though: http://www.mediafire.com/file/k47fpx7wyakltbv/Camera+Scroll+EX.js
I also can't see any of my events if I'm not on a "classic map" with tileset and use a parallaxe plugin (can't find a way to make them re appear even by switching OFF some plugins.)
Fixed in v1.1.0.
Of course I'm not expecting the plugin to work with parallax-maps (yet ?^u^?) so I didn't put the tag in those maps and only tried on tileset based map (cool render by the way, very promising), the thing is... The glitch happens even on a parallax map that doesn't have any “mode7 tag” on it.
This would require rewriting how the parallax is rendered entirely. While it's technically possible, it's a bit of a hassle. I'll see, but no promises. xD -
Mode7 is based on the SNES's ability to display and/or rotate a flat set of tiles at an angle, it was never designed however to create actual 3D plains or in the context of what you want, hills and mountain ranges with elevated/lowered surfaces. You would require either an actual 3D based plugin that can manipulate terrain data to give raised/lowered terrain sections (similar to FPLE) or something that could apply a form of tessellation/bump-mapping/height map effect to the terrain (H-Mode7 does this but it never got transitioned over to MV).
Well, technically height maps could be implemented relatively easily since even though the original SNES Mode 7 isn't 3D, this script is. It would just need to load the file, upload it to the shader and change the shader code to offset pixels depending on the height map. But I would like to keep this script "simple" and not overdo it with features. More features mean more potential issues with other scripts. Now that a base Mode 7 script exists, I'm sure somebody will create mods and plugins for it. xD
hmm, I should take up learning Javascript. I'm more used to ruby than I am that, mainly because I am used to the older engines. I do hope that someone would like the idea too, although I have to agree to make terrine height does sound like it would cause incompatibilities with a few scripts. I'm definitely not proficient enough in coding to do that myself. -
@bblizzard I have not found the link to the new 1.1.0 version of the plugin. The demo and script links are from the first 1.0.0 version.
-
@Oscar92player I think I didn't upload it right. Try now.
-
@Oscar92player I think I didn't upload it right. Try now.
Thanks, now the the links redirect to the 1.1.0 version. -
Tested the new version.
* Floating events with maps angles exceeding 65-70 degrees are fixed
* Vehicles do not appear in the top-left corner of map when not set on the map
* FPS drops on large maps are still a major issue (and why I can't currently use the plugin while it's in this state). Memory usage has dropped at least by an average of 25-100 megs (generally when standing still) but still fluctuates as high as 450 when moving around and the CPU usage is still spiking abnormally high (at least more than 20% on my CPU) until the camera/characters stop moving.
I did three "Collect JavaScript CPU Profile" tests through MV's console to collect results on why the CPU usage is increasing when the camera/characters moves around. The first is with Mode7 disabled (but the plugin is turned on) on the map, both when idling and moving around. CPU usage stayed low and FPS remained stable (common with MV). The second test was with Mode7 enabled on the map while standing still, the results were similar to the first (though a little more activity). The third test however showed that when the camera and characters are moving around, "RectTileLayer.addRect" was excessively using the CPU.
I've screencapped the results of the third test and tagged the error messages on the side for reference. While it's doubtful that "Sprite.update" would be the cause of this issue, it's still being noted here due to the actions of "RectTileLayer.addRect". Hopefully this might somewhat help narrow down the issue.
-
* FPS drops on large maps are still a major issue (and why I can't currently use the plugin while it's in this state). Memory usage has dropped at least by an average of 25-100 megs (generally when standing still) but still fluctuates as high as 450 when moving around and the CPU usage is still spiking abnormally high (at least more than 20% on my CPU) until the camera/characters stop moving.
I didn't touch any code that could reduce the RAM usage. xD
I did three "Collect JavaScript CPU Profile" tests through MV's console to collect results on why the CPU usage is increasing when the camera/characters moves around. The first is with Mode7 disabled (but the plugin is turned on) on the map, both when idling and moving around. CPU usage stayed low and FPS remained stable (common with MV). The second test was with Mode7 enabled on the map while standing still, the results were similar to the first (though a little more activity). The third test however showed that when the camera and characters are moving around, "RectTileLayer.addRect" was excessively using the CPU.
I've screencapped the results of the third test and tagged the error messages on the side for reference. While it's doubtful that "Sprite.update" would be the cause of this issue, it's still being noted here due to the actions of "RectTileLayer.addRect". Hopefully this might somewhat help narrow down the issue.
This is a huge help, thank you! I think I now know where the issue lies. The original tilemap code refreshes the tilemap setup after moving a bit since it renders only the visible tiles to reduce performance and RAM requirements. I think this same code might be interfering with my setup that doesn't actually need refreshing. I need to look into that part of the code, get a better overview and resolve it. -
Ah, my mistake. I misread what you stated but even then, the subtle fixes you did (most likely the "floating events" bug) did reduce the RAM usage, even if the result is only minuscule (a meg saved is a meg that can be put to other uses). :)