Ultra Mode 7 [RMMV & RMMZ]

Short answer: It's better if you convert to the new way since it's mathematically correct now. And yes, I did include the LEGACY_SCALING option so if somebody is very far with the project and doesn't want to convert, they can still use the old way.

Long answer: So while working on the rain implementation, I noticed that some rain drops are too close to the camera. That means that I would have to increase the near-Z clipping plane to fix it. I knew that I would have issues with it since I never could get the scaling to work in a mathematically precise manner. So I put a day aside to investigate this very thoroughly. I found out that when I convert a map coordinate to a screen coordinate, the X and Y values work fine, but the actual Z value doesn't. Since I use the Z for scaling, this broke scaling when larger values were used for the near-z clipping plane. It would be perfect if one used 0 and would still look reasonably well with a value of 10. But the higher you go, the more the scaling is offset. So after 6h or so of digging and experimenting, I finally figured out the formula that I need to apply to the Z coordinate to get the proper value.
If you want the formula, just find the piece of code that is changed with LEGACY_SCALING. It's just one if-block. The code reads:


The value for projection.data[10] is:


So the transformation formula is:


But again, it's better if you just remove your custom setups and disable LEGACY_SCALING. You can now use any NEAR_CLIP_Z and FAR_CLIP_Z and the plugin will properly handle scaling and visibility.

There's just something about the map now that makes it look significantly better. It's such a subtle thing, but now the sprites actually feel like part of the 3D map rather than slapped-on 2D sprites.[/b]

Thank you! Ok I’ll keep your new scalling method activated and adjust my numbers, the only thing I change on the fly in my maps is usually “pitch” so it’s no problem to change those values in the plugin’s parameters as I don’t have anything to change anywhere else.


Yes :) it’s the thing I was telling you when asking if it was possible to have a higher “internal resolution” (or something similar to get rid of the jitters, but I didn't know how to explain that correctly because it's more about "feeling") since I noticed at the time that when using the plugin on a 1080p project the problem was less visible, maybe because the higher your resolution = more room for imprecision.

But now it’s better than that, no matter your resolution, it feels like a perfect anchoring.

The only thing that is still here and can make sprites seem “not 100% on the same plane” is a slight offset at the origin of sprites (using doodads at least) that appear more and more as they get on the edges of the screen when scrolling, it’s more visible if you have a wide aspect-ratio/resolution, but still something you can notice vertically too.

It’s probably easier to spot if your camera’s pitch isn’t too big (since you better see the ground directly under sprites) let’s say you try to put a stick sprite (event/doodads) right in the middle/center of a square on the floor (tileset) we can even put a red cross in the middle of that square.
If your MC is right in front of that stick, it will appear exactly planted in the middle (right on the red cross, covering it), but as you move away from it you’ll begin to see its base/origin slightly shifting away from that square-tile’s center, and you'll normally see the red cross because now the stick isn't exactly aligned anymore.

Of course, if we’re talking about a tree on grass (or anything “non geometrical” and more “organic”) it’s less obvious to notice, and like with many other things it’s always possible to hide some problems with a good design.
Just telling you in case you can think of any reason why it happens, it's not that big of a problem but it's pretty much the only remaining minor issue I can think about since everything else is now perfect.

You might be able to do something about that actually. MV has something called object-characters. If you look at the implementation of Game_CharacterBase.prototype.shiftY, you will notice this:


Object-characters are spritesets with an exclamation at the front of the filename. You can see plenty of examples in the RTP. In any case the object-characters are planted precisely as the appear in the frames in the file, but non-object characters (e.g. humans, animals, monsters, etc.) are offset by 6 pixels upward so they don't appear at the bottom of the tile, but slightly above it. You might be able to solve your issue by slightly editing this method. e.g. You could do something like this in a custom plugin:


This would remove that offset from characters while UM7 is active. I actually did the same thing in my game.

The offset I’m talking about is a bit less obvious than a “fixed shift” because it looks more like the sprite is slowly “sliding away” (as you go on the edges of the screen), but that Y shift you talk about might actually be the culprit when trying to use “Altimit Pixel Movement” with your plugin. The 2 work together but we need to adjust the collision on the Y axis whenever we’re on a Mode7 map.

(Or the other way around, but one thing is certain, the Y collision box coordinate isn’t the same between M7maps and 2Dmaps. Good thing we can adjust that on the fly.)

If you want me to show you the “sliding” problem with a video I can do it, maybe it’s easier to see with my type of resources, it’s something that has been here since the beginning.

It’s affecting both X and Y, maybe the easiest way to see it would be to use a camera pitch at ZERO (imitating the regular default RM camera then) and put some events on the floor, if you look closely at their feet you’ll probably see the thing I’m talking about, they slightly “slide away” when you move your MC vertically and horizontally. Use a blue square 48² event on top of a red square 48² tile, with a 0° pitch the blue event should cover 100% of your red square, this will be the case if you move your MC close to it, but as soon as you move away from it (doesn’t matter if it’s vertically or horizontally) you’ll gradually see some pixels of the red tile under the blue event, the further away you’ll be from it, the more you’ll see.

If it’s impossible to fix, here’s a solution using graphic design: in that particular situation you can make your “blue square event” a little bit bigger than 48x48, something like 52, to compensate and make sure it’ll always cover the red square on the ground. It’s something to keep in mind for other stuff since this particular example is just an unlikely situation to better spot the problem, and I think the bigger your “pitch angle” is, the less distractive this problem will be.

Yeah, a video would definitely help determine what the issue is. Does it happen as well when you disable the movement plugin?

Hey! I have a little issue with this plugin. Whenever I stand on the same row as the boat or above it, it is visible. However, when I'm below it, it disappears. I have all settings for the plugin as default, so I don't think it's something I've done wrong.

Visible: https://gyazo.com/dcf5ac3d313e06af9aa4c6b1aaa26905

Gone: https://gyazo.com/1dbd695e1b9168781a1aafd3d776179a

Hey hey! Im loving it!

Perhaps I missed it..... But is there a way to enable and disable mode 7 on the fly with a script call?

Nope. Due to the way Mode 7 is calculated, setup and displayed, there is no good way to transition between Mode 7 and the normal map display. Your best bet would be to set it up in such a way that the camera points downward and then just change the camera angle.

Hey @bblizzard, long time no speak!

I'm trying to fix a problem, and I thought someone here might be able to help me.

For part of my next game, I've got this scene where I need the player to be able to drive endlessly, left-to-right, down a road in a city location. To achieve this, I've made a short stretch of road, and all my buildings (and eventually street furniture too) are events. The player only drives along a short stretch of road over and over again (which repeats infinitely).

Obviously, normally this would get old really fast, as the player would realise it's a short "rolling road". To help mitigate this, I've put together a system where I randomise all of the buildings, and in the final game, I'll randomise the ones that are offscreen, so it won't be quite so apparent that it's a short stretch of road.

However, I'm having a problem:



As you can see, when you cross the threshold where the map repeats, several of the buildings vanish/appear. I'm not quite sure why this is happening; I just know it isn't my stuff because if I disable all of the randomisation and just have single buildings as events (with no scripting), it still happens.

I'm still using v1.3.0 of your script, in case that helps to know - it's always worked perfectly for my needs, so I've never gone on to newer versions.

Any idea what's going on here, and whether it can be fixed?

EDIT: Incidentally, I just tried updating to the latest version, and it didn't fix the issue (though it's different - like, I see half the buildings render, then I cross threshold and see the other half). Is there a simple solution to this problem? I assume it stems from how the game renders events on looping maps.

Edit 2: tried using the looping maps tile value; doesn't seem to make any difference.

EDIT 3: Just to illustrate what I'm seeing:

When the player spawns, this is what you see if you zoom right out; the blob is the player's location and the lines are the edges of the map (which repeats)



Then, if you walk slightly to the right, this happens:



Is this just how it works? As it potentially means that some x-axis repeating maps simply may not work with the plugin; unless I've missed something really obvious. I've got it to work with other maps, but I've realised that's because the events are smaller in those maps, so while they do flicker, the effect is much less visible.

EDIT: Also, thought this might have to do with the zoom/Fov/Distance giving a lot of visibility, where in a closer view, this wouldn't happen. But even if you set the FoV to zero, it still happens, so it can't be that.

EDIT: Furthermore - I'm trying all sorts of values with the LOOP_MAPS_EXTEND_TILES value, and it doesn't seem to matter if you set it to zero or 1,000; the effect in-game seems identical. Is this value still hooked up to anything?

@EthanFox

I just checked the looped map in the demo and I'm getting the same issue of popping up / vanishing event sprites. I was sure I fixed that. o_O I'll definitely need to check and fix that.

For your particular problem, I think you could mitigate it by having the stretch of road extend further. As far as I can tell right now you have 3 blocks and the player is looped on the middle block only. If you make it e.g. 5 block, it might stop the popping up / vanishing. If you're still in no hurry, you can wait until I fix the issue on my end. (It's possible that you're actually experiencing a different issue or that there are two separate issues here.) I'll probably have time somewhere next week to take a look at that.

Hey, thanks for the suggestion! I did a quick version and unfortunately, extending the road didn't fix it; like obviously you see the problem less (as there's more distance between the edges!) but it's no less obvious.

You will have to have more blocks in either case. The way MV works with looping maps is that it displays sprites in a looped manner in regards to map coordinates. But if you have a small enough looped UM7 map, technically a sprite should appear twice as it's visible on its real map position and it's looped map position. This obviously doesn't work as MV wasn't intended to work like that and display one sprite on two positions.

Ah okay :) in that case, I'm going to hold off on this until you have time to look at a fix for the bigger issue; once you've done that, I can load up the level and work out how much bigger I have to make it, while keeping it as small as possible for optimisation/ease of use. Right now it's very hard to tell.

Hey bblizzard,
do you plan to port this Plugin to MZ?

Depends on what MZ uses as tile renderer. If it doesn't use PIXI.js and pixi-tilemap, I won't port it since I'd have to rewrite it from scratch.

Hey bblizzard, so I tried something.

Firstly, I reverted to 1.3.0, as this was the version I was using up until now with less ambitious maps. I also tried extending the map horizontally (doubled it, so it's now 122 units wide).



As you can see, I get 2 problems. The issue with the ground might be fixed in your newer versions, but you can still see that the buildings on the left disappear. This is no better in the latest version; in fact it's much worse (similar to what I originally posted above).

So yeah, you were totally right - extending the map horizontally does make the problem less noticeable (I've also made the distant buildings closer to reduce how far left and right the player sees) but there's something else at work.

EDIT: Fixed the hole in the floor by reducing the map's y-length; i.e. made the map shorter, vertically - but that doesn't have an effect on those vanishing buildings.

FURTHER EDIT: As another test, I made the map 200 units wide, so massively increased the width over the original 60; the problem is exactly the same as in the video after you cross the threshold.

@EthanFox Alright, v1.6.1 is up. I overhauled the entire code handling positioning in looped maps and added special handling that will check for sprite visibility in order to determine which of the 3 (if one looping is turned on) or 9 (if both loopings are turned on) should actually be used. This should cover 95% of all edge cases where problems could occur. You still need some buffer zones obviously as small maps and the FOV could cause a sprite to still be visible in 2 places at once theoretically (which obviously can't work in MV). Let me know if you have any performance issues. This code is much "smarter", but it also requires more CPU time. I don't expect lag to happen since most of it are just adding and multiplication operations, but if you have a bunch of events/sprites, it adds up.

Thanks @bblizzard!

I was hoping this solution would have resolved the same issue that Yanfly's Grid-Free Doodads has with doodads disappearing off the "left" side of the screen with looped maps... alas it does not (I did report about the issue a long while back ago to you).

@Espilonarge How big are your maps? Is it possible that they disappear because they have to become visible on the other side of the looped map? I didn't test the new code with Yanfly's Grid-Free Doodads, but the code governing positioning now uses the same new code as the other objects and sprites.