Ultra Mode 7 [RMMV & RMMZ]

@bblizzard Thanks, I've asked Xilefian where I need to put the code.
I've already asked her, but maybe you know too. Is it possible to change the degree the engine would describe as moving "up"? Because if that can be regulated with a Variable it can be controlled the same way the YAW degree is, with the same variable even.

Weird, it looks like it's doing Far Z in reverse when it's on "0". So from the distance from the camera instead of the player:
https://1drv.ms/v/s!AsqbW0RDykVgidBdJjnN0QN93jQVkA

Here are the black lines (UM7 is on, pitch is 10 degrees): https://1drv.ms/v/s!AsqbW0RDykVgidBe1m9PXGpgGzczSQ

@seaotter You're using multiple tiles on the same space so they end up interfering. Just make sure that you have only a single tile on the top layer. Or find out if some other script turned on depth-buffer, because UM7 doesn't enable depth-buffer and this should only ever happen if the depth-buffer is enabled.

@Arend Galenkamp Do you mean "up" as in vertical placement / height (considering the X and Y coordinates as ground coordinates) to simulate some kind of "lift-off"?

Well, this is how near Z and far Z work. http://www.songho.ca/opengl/files/gl_projectionmatrix01.png Near Z is the smaller plan closer to the camera origin point and far Z is the larger plane behind. Technically the default values I picked aren't so good for real 3D as the near Z is too close to the camera, but in order to preserve the size of the characters as close as possible to the original size in the middle of the screen (it was hand-picked, not mathematically calculated!), the default near Z value worked the best.
Your best bet to avoid these problems is to use a larger near Z value, but also make sure that you increase the far Z value. But there is no way to make this work mathematically. You'll have to do it experimentally. Just make sure that the far Z is larger than the near Z value (the coordinates are flipped logically in the image where the far Z is a smaller value than near Z, but I used an inverted logic, because of how X and Y coordinates are placed).

As for the black lines, can you post the image that you use for the event?

I managed to grab a screenshot from the video for you of the issue he's referring to where weird "artifacts" are appearing on events. I also recently saw this issue happening in my project and did a little digging in to the situation. When I checked the sprites/tile sheets, I noticed that the event is somehow displaying a single pixels length of sprite/tile to the very left and top of the event, the very same length of sprite/tile that's to the very left and top of the sprite/tile inside the sprite/tile sheet itself.

Just to note, I have recently updated to Windows 10 and even though I do have "Characters Pixelated" set to true in the plugins config, the events sprites are being blurred instead of pixelated (either because MV is "blending" the pixels when stretched/shrunk by default or because my NVidia GeForce settings were "defaulted" during the upgrade transition). It might be possible that the "blending" factor is somehow grabbing a single vertical and horizontal line from the left and top of the sprite/tile when displaying them on screen.

Yup, you got it right. I assumed as much which is why I asked for the graphic. It happens because of texture pixel interpolation. It doesn't really help to set it to pixelated / nearest neighbor interpolation, because it still has to do that interpolation that causes the issue (it doesn't really have anything to do with blending). The only way to really get rid of it is to make sure the boundary pixels are repeated at least once on the image definition. In case of how MV renders graphics and sprite-sheets (since it doesn't take that extra pixel into account), the best way to handle this is likely to delete the other event frames / neighboring graphics that cause these artifacts (in case of the tree on the tileset) or increase the size of the frames and reposition all frames (in case of the bear).

When you have transparent space around the graphic, it makes it a lot easier. The biggest problems happen when you have a tileset where various graphics are right next to each other and the interpolation can really cause a lot of issues.

EDIT: IDK if Yanfly's doodads use sprite-sheet graphics for objects or not, but if they use a single texture file for every object, this issue shouldn't happen with it once I add support for it.

I double checked with another map that's using UM7 and yeah, you seem to be right regarding how the "interpolation" causes the issue as I didn't even notice until now that it seems to be grabbing "all" sides of the sprite/tile in the sheet (not just the left/top side). When placing any doodad's with Yanfly's plugin, it allows you to tweak the doodad so you set them as "smooth" or "hard" so when a doodad is shrunk or expanded, it will either preserve the hard edges of the pixels or smooth them (you can see that the trees in my screenshot all use "hard" to preserve edges). I'm not sure if animated doodads are affected since I've yet to "test" if the same issue will happen with them.

Still, this doesn't explain why even though the "Characters Pixelated" setting is turned on in the plugin, MV is still causing the events sprite (or tile) to be "blurred" (the bear in my screenshot should be "pixelated" and not "blurred" even when stretched/shrunk as the setting is turned on in the plugin).

EDIT

A quick search around revealed this post which includes a small plugin script that can be used to "force" all event sprites to remain pixelated (sprites will stretch/shrink unevenly but this is to be expected). I'm not sure if it will work on events that use tiles. By default, MV generally "stretches" graphics using a bilinear filter like method but in our case, it also seems to be "grabbing" the horizontal/vertical edges from "outside" the frame of the sprite/tile instead of remaining transparent. Using this plugin script should technically resolve the horizontal/vertical pixel strip appearing from all sides of an event (this technically resolves the issue I mentioned about where "Characters Pixelated" isn't working as intended).

Yes, yes, exactly that! Shrinking the source rectangle for the texture would eliminate the problem entirely.

The pixelated option in UM7 is for the tilesets only. I didn't want to mess with sprites or other graphics since it wasn't necessary. Just look up rpg_managers.js at around line 800. You should see stuff like:


The default for both characters and tilesets is "false" which translates to pixelated (true is bilinear interpolation). So you might have this different or you might be using another plugin that's messing with this. The issue with the border pixels is more apparent when bilinear interpolation is on, but generally it can also appear on nearest neighbor interpolation if the scale is large enough. The best workaround is simply making sure there are extra border pixels to interpolate from. Oh, also "alpha bleeding" should be turned on when saving the graphics (IDK if default RTP has this). This makes sure that the invisible pixels around a graphic have the same color rather than hard white or black which can also cause artifacts. This is something that's done when saving the graphic, not while rendering.

EDIT: See? This is nearest neighbor interpolation, but the issue still happens.

https://gyazo.com/49c9278bdd363b2e138164d9395435ec

@Arend Galenkamp BTW, this image is with the compatibility fix for MOG's Character Motion added. Took, like, 15 minutes to fix it. ._.;

EDIT: There, now I don't have to feel guilty anymore for postponing this over and over. >_>

v1.4.1

• added compatibility with Yanfly's Gridfree Doodads
• added compatibility with MOG's Character Motion

Doodad scaling now works as well as placing doodads is so much easier! You absolute legend!

Yeah, I figured that it would be really useful if you could place them while Mode 7 was on so I implemented it. Took me like 2 hours since I had to try some of the combinations with the coordinates until I figured out the real one. The doodads themselves were easy, but getting the "cursor doodad" to scale right required some extra math, because it uses screen coordinates, etc. and I use map coordinates and map display X/Y for determining the position and scale in Mode 7. xD

A small note to anyone who's interested in this like me, If you want to use this script with MOG's Chrono engine it actually works fine for the on screen battles as long as you disable MOG's character motions, otherwise the scaling of sprites as they fade into the distance is reversed!

Basically, this isn't compatible with MOG's character Motions, so don't mix them XD

@bblizzard with a little jury rigging I managaed to use this for my ideal battle scenes, thanks a lot!

OOC, would it be possible to layer maps on top of one another, or use regions to create levels and slopes? Using events as parallax lets you create a similar feel to Octopath Traveler's battle scenes, was wandering if it'd be possible to extend that into the maps as well.

I do believe he's stated this plugin isn't exactly ideal for this kind of feature as Mode 7, by SNES standards, only ever uses an X/Y axis (aka the tilemap) but has no actual Z axis (or to put it another way, it doesn't support vertex based heights like DOS Wolfenstein/Doom). Mode 7 is more akin to stretching/shrinking the 4 points of a tile to "appear" like 3D but is still restricted to a 2D styled plane.

The next best thing I could point to for what you want is the Camera Translate Rotation Engine but I personally don't know if it supports height/level/floor plane movement (I don't use it but I saw it a while back as another possible alternative).

Did you try v1.4.1 yet? I did fix the scaling issue on Friday. :)

Yes I'm using 1.4,1 (i only just found this plugin yesterday, it's awesome though!), when I plugged it into the Chrono Engine the scaling issue still exists. It's possible it's due to how Character Motions interacts with Mog's other scripts.

Did you put UM7 below Mog's Character Motion (and Chrono Engine)? If you did and still have issues, it's possible that you're right about what you said, that the combination of plugins causes the issues.

...I went to a trade school for for computer programming for 3 years, and though that teacher was terrible I'm still mad at myself for not thinking of changing the god damned order.

It works when put below it, and I am a bloody idiot lmfao XD

@bblizzard, I know I asked about it months ago (which you answered back during September that it would be possible) but nothing ever came of it since. I've been wondering if you still plan to add the "color gradient" plugin command functionality used for fading tilemaps in to the distance? As a number of my maps do use day-to-night cycle, "white" isn't exactly ideal for night time situations. I know I could change the FADE_Z to technically hide it but being able to change the coloration/alpha/blend of the fade would prove to be far more useful.

As a matter of fact I do plan to do this very soon. Maybe even tomorrow.

EDIT: Done:

v1.4.2

• added new parameter FADE_Z_COLOR
• added option to setup custom fade colors for specific maps
• added option to change fade color at any time

I also looked into:

• flat events one more time
• sprite scaling
• what's up with star passability
• coloring sprites with the fade color

And the answers are:

• Flat events can't be done, because it requires rewriting the default sprite shader from scratch. There's no way around this.
• Sprite scaling currently uses the Z-coordinate for that. If you have issues with scale, you should experiment with the near Z, far Z (both increase) and camera distance values (make sure to adjust BASE_SCALE_Z, too, if you change the default camera distance).
• Star passability doesn't actually make sense in Mode 7, because the tileset is rendered flat
• Coloring sprites in the same way I color the fading tiles can only be done by rewriting the default sprite shader. Unfortunately the default blend modes don't support LERP (linear interpolation) with colors. I tried doing something with sprite tint and color tones, but these simply can't simulate LERP and it won't work, the math doesn't check out. :/

This is basically it, the definitive version of the plugin. Well, maybe I'll think about a height coordinate on the tilemap, but in general, this is it.

SO. MANY. MESSAGES. SO. MANY. WORDS.
With "up" I mean moving forward in the "8"(numpad) direction like in KMS' video with the three.js Mode7 from a few years back (NOT in the Z value as the animation of going into an airship already simulates that), it's not dependent on the map but on the YAW (which is regulated with left and right).

Somehow the last update magically fixed the trees jumping in front of the camera (with Near Clip Z on 0). I have a feeling it now reads the same as when the value of the FOV is 0. That it reads it as the action of not clipping at all instead of a value. Thanks for the explaination though, I really like learning how it all works :)
Xilefian didn't respond yet btw. So if someone else reads this, please help me. I'm desperate with this one. Really want it to work.

The Mystery of the Black Lines is solved now, it was indeed picking up the outer line of pixels from the neighbour sprites.

And bloody thanks for the MOG Character Motion and Doodads compatibility! :D
It looks SO good!

I'm glad you like it. :)

If you make me a demo with everything implemented except the controls, I can add that movement code so you can have that airship movement.

For anyone who gets the following error...


Please go in to your plugin list, open UltraMode7's config, click "Ok" and then click "Apply -> Ok" and then save your project. This will "fix" the issue due to your projects plugin config missing settings that were recently added in to v1.4.2 of the UltraMode7 plugin.

I still got blackline at 1.42