Ultra Mode 7 [RMMV & RMMZ]

@StarWarrior00 As I said numerous times already, this is not possible without basically rewriting the entire sprite rendering engine of MV.

I don't understand. I'm asking for a way to make an event image / sprite render flat not a non-event image to render in 3D so to speak.

Since non-event images render completely flat, I do not understand why any rewriting would need to be done.

The way RPG Maker MV displays the map is the problem, the code itself makes events stand up, as they are not part of the map. He's checked this before, and the current setup does not allow it, and to make it work would require an almost complete rewrite of how MV displays maps, which would in turn break most other plugins. Sadly, flat events won't happen. Best you could do is paint a crater under the building event, and place the building event in front to obscure it, then delete the building event when the player steps there, revealing the map-painted crater.

I'm afraid that's not possible. The best options would be what I said earlier.
If I'm right the only thing UM7 does is repositioning the X1Y1X2Y2 of the map so it gives the illusion of a 3D space, like folding an A4 paper into a tube as an example. BUT I don't think that can be done for each individual event. It's discussed a few times earlier already if it's possible to give "depth" to events (be it a flat event or not). But that requires a 3D buffer since your processor needs to calculate where to put X2 and Y2 of the event. And that idea is thrown away since it's a lot of work that wouldn't be worth it because using another (3D like Unity) engine instead of rewriting this one is would be a lot more logical and easy.

Ah well, I suppose that if it can not be helped, it simply can not be helped.

That said, my apologies if I came off as rude. Totally not my intention~ :LZSproud:


No problem. Thanks a lot~! :LZSproud:

Small note: A resolution of 1920x1080 works with little to none performance decrease! Mostly just 2 and rarely 5 fps coming from 912x480 (Although I do have 1 cursed map that thinks it's a Nintendo 64 and stays between 11 and 24fps). Everything looks much more clear and modern :)
If the 1920x1080 resolution is used, the Base Scale Z needs to be set on 1000.

Update: Mostly fixed by changing the DEFAULT_PARALLAX_DISTANCE to 0, but it's leaving a single pixel line along the top of my screen that appears to be the bottom line of the parallax image, and no value is fixing it. Positive numbers push the image down, and the upper tiled image becomes more visible, and negative numbers seem to not work.

It's incredibly hard to see, but the top pixel row of my screenshot is the bottom row of pixels from the background tiling.

Edit: I got it to work by pushing the image so far down, it tiled back over, but I'm sure this hack will make the game display improperly if running in anything but fullscreen 1920x1080. Hitting F4 + F3 to window and resize it does indeed break the background.

Sounds like a possible bug, I see no reason for it not to be one.

@Arend Galenkamp Yup. I developed it on my own game first after all and I'm running 1280x720. Since it's a really simple rendering method, it should scale easily even beyond 1080p. The only real limit should be how much the GPU can take.

What do you mean by that? Also please read omnivance's post.

@Omnivance It was indeed a bug with the OX/OY coordinates not being 0 with your settings. I fixed it in v1.4.4. You don't need to use DEFAULT_PARALLAX_DISTANCE.

@Arend Galenkamp Added Thomas Edison MV compatibility in v1.4.4. If you have a cursed map, you should take a look at the performance profiler in MV. :) You should be able to quickly pinpoint which piece of code is causing the huge spike and then take it from there. From experience I'll guess it's something with event updates and you have an event that's processing something in a bad way.

@StarWarrior00 What I said about 1080p was directed at Arend and performance, not to Omnivance's post.


So basically there's 3 major things to look out when rendering on a GPU.

The first and foremost is the resolution in pixels. e.g. 1920x1080 (which is 2073600 pixels) is 2.25 as many pixels as 1280x720 (which is 921600). That means that the GPU needs to have a 2.25 more powerful rasterizer in order to achieve the same FPS.

The second thing is the polygon count. In general you always assume the rendered polygon count stays the same when increase the resolution, but technically in case of UM7 it's not like that. Because the tiles are defined by pixel size 48x48 and not by size in space, usually when you increase the resolution in MV, it actually also renders more polygons since more polygons are visible now. However, this number doesn't double in UM7 exactly, because of the perspective view. It would double in normal MV and it would about double if you used orthogonal projection in UM7. Again, this is for a polygon count change that increases with resolution, something that usually only pixel-perfect 2D games do.

The third thing is everything else: Lighting, shadows, various effects such as bump mapping or ambient occlusion, anti-aliasing, etc. It's not so easy to determine the performance impacts of each (except maybe anti-aliasing which usually increases the internal resolution for rendering which is easily measurable), because most effects affect only certain objects in the scene and not others, some are computationally more demanding, some are less, etc.

So basically what I was trying to say is that increasing the resolution in MV to 1080p shouldn't behave much differently whether UM7 is turned on or off and the resolution with stable 60 FPS you can use mainly depends on the GPU, not on the plugin itself (since it's written in a manner that uses the same way of rendering polygons as the default tilemap, but it applies 3D perspective transformation to it).

I know all that as I have a gaming PC (10+ years me thinks). But what difference does ones GPU make for a 2D game engine like RPG Maker MV?

A lot more than you'd expect. There's actually one other thing related to the polygon count: The texture.

If you take a couple of high-resolution textures and render them on screen one over the other, you'll noticed a huge impact on the FPS when compared to other things. It's not just the polygons, it's also the textures that are rendered. When textures are rendered like that, for every pixel on the screen, the GPU needs to determine the color. So if you take e.g. a 4096x4096 texture and render it onto an area of just 100x100 pixels, this will really impact the FPS count. The thing is that in order to determine each of the 100x100 pixels, the GPU needs to interpolate the color from the 4096x4096 texture. In the simple case of bilinear interpolation the GPU would still need to check an area of 40x40 pixels on the texture for every single rendered pixel.

There's something called mipmapping that creates smaller texture versions in advance (of sizes that are halved over and over, eg. 2048x2048, 1024x1024, 512x512, 256x256, etc. in the case of a 4096x4096 texture) and then uses them instead of the full-size texture for rendering polygons in pixels that are smaller that the texture actually is. One of the simplest way to notice this is to play newer game on an older PC and set texture quality to "high" or "ultra" setting. While RM is relatively simple and each sprite uses just 2 polygons (or just a single quad) having a lot of stuff on screen can still cause GPU performance issues, especially when there are many objects with smaller textures. And barely anybody uses mipmapping in their 2D engines, because it requires additional VRAM, but most things are more or less rendered in a pixel perfect manner.

Another example would be parallax mapping. Many people don't understand that e.g. a 16384x16384 parallax image won't work on a lot of GPUs, because textures that large have been started to be supported on GPUs only relatively recently. Or the fact that mobile GPUs often can't handle images larger than 2048x2048. Since MV games can be exported for mobile, this is a problem.

One would think that 2D games are comparably very simple to process for a GPU, but that's not so much the case. The actual truth is that back in the 80s and 90s the developers were quite ingenious to save on VRAM, GPU processing power, etc. e.g. They had a limited amount of sprites they could render at once. Each sprite could use only a few colors at the time which were usually determined in advance via an indexed color palette so the sprite would only ever know its own index and the GPU then would make sure to use the proper palette while rendering the sprite on screen. Also, the resolution was very, very small in comparison. IIRC the SNES had a resolution of 320x240 on PAL or something very close. Seriously, the optimizations and limitations that were present back then were really necessary, because the hardware was nowhere near as powerful as today. Today nobody really gives these things a second thought, but in reality it's quite easy to choke a decent GPU with just a 2D game. I should know, because it happened to me a few times over my career. :X Especially on mobile.

Wow, that was quick! And it is working beautifully! Thanks so much for the quick bugfix!

Thank you for the multiple updates/fixes and the new license, amazing work as always.
4096x4096 seems to be OK "recently" let's hope things will get better for more and more GPU.

Cheap integrated GPU (like "intel HD" stuff) can handle that 4k² size from what I tested; newest Apple mobile devices are fine with that too but it's still important to monitor the memory usage.

Many people confuse the size of a PNG file and the size it takes once in memory, like "a 8mo PNG will take 8mo of memory". Better be careful.

Yeah, that's not correct. xD You take the resolution times the number of channels (or number of bits), not the compressed image size. A PNG can be 32, 24 (no alpha channel) or 8 bit (indexed / palette colors). So if the resolution is 4k*4k, that's actually 16M pixels. And if you use 32-bit pixels, that's 64MB of VRAM. Even a maximally compressed JPEG that's like 100kB will still take 48MB of VRAM at 4k*4k size. A lot of mobile phones will start crashing your app once you go above 100MB of VRAM, even newer budget phones. It's more a safety feature than an actual memory limitation though. Especially iOS devices are very, very aggressive about that. iPad 2 (which is still supported by Apple and can run iOS 10) consistently started crashing somewhere above the 100MB VRAM usage mark, mostly because the device itself only has 512MB of RAM. I think it could sometimes take 150MB spikes in VRAM usage, but a single crash in over 20 sessions is still far beyond unacceptable (IMO anything above 0.1% shouldn't be acceptable, but I heard some publishers are ok if you just keep it under 5% which I personally find disgusting). iPad 3 will start crashing somewhere above 200MB which has 1GB of RAM. So it's mostly iOS doing the limiting, not so much that there isn't enough RAM to go around.

We had a game that easily used several hundreds of MB of VRAM with all PNG textures. This obviously wouldn't work on mobile devices so we had to resort to compressed textures (PVR on iOS and ECT on Android). We managed to keep it between 100-120MB while keeping the GUI and item icons still as PNG (because the game really looked bad if those were compressed, too).

There's actually a bit more to max texture size. DX9 has a way to check the GPU just as all OpenGL and OpenGLES APIs do. But DX11 and DX12 (I think DX10 as well, but last time I worked with it was 5 years ago so I don't remember anymore) do support at least 4k*4k for max texture size, even when using the DX9 feature level. Another interesting fact is that while all DX versions (at least from DX9 onward AFAIK) have one way or another to get the VRAM size, OpenGL does not have this functionality.

Anyway, to be completely safe I still suggest staying under 2k*2k for mobile.. I noticed MV does it, too. xD

So for the past 8 hours I've been trying to figure out the problem. Long story short: It's Terrax Lighting that randomly bamboozles the game. Has nothing to do with UM7 I think. First I'm going to sleep, then I'll go to Terrax' thread for a solution.

EDIT: I figured out the problem. Turns out YEP X ExtDoodadPack1 doesn't like a high resolution and Terrax Lighting at (1920x1080) resolution. Back at a steady 60-64fps now :)
Edit edit (because appearantly things don't ever work the first time): It was Doodad Pack 1 AS WELL as the fact that Quasi Simple Shadows isn't completely compatible with Terrax Lighting. I think the low fps after a second mapchange has to do with caching.

Thank you very much for the update! :D

Hello, Quasi Simple Shadows has a bug where the shadows don't scale at all to how UM7 is configured.
I have a feeling this is a lot of work to fix so if you already think "Aw hell no" I'll drop QSS completely as it also needs to be fixed for Terrax Lighting.
Here is a demo I made with QSS, TL, and UM7: https://1drv.ms/f/s!AsqbW0RDykVgiooCRY0GQ7TePMShkw

I'll take a look at it. Maybe it's a relatively quick fix like with the others.

EDIT:

@Arend Galenkamp Done, v1.4.5 is up. It was simpler than all the others so far. xD BTW, make sure you put UM7 below Quasi's plugin. It was inverted in the demo you sent.

See, if I did real 3D coordinates for all the sprites, there's no way I could make compatibility work with other plugins without rewriting half of their code. So you would have flat sprites, but nothing else. xD

Ultra Mode 7 Is amazing!
I have a problem however, My project is going to use a Tactical battle system and i need to remove the "Depth" effect from using M7's pitch.
What i mean is i need the sides during pitch to retain their size and not get thinner / Squish together at the top screen.
I like the effect, but it causes problems with the battle system. Is it somehow possible?

I hope you understand what i mean, i don't know how else to explain it :kaoeh: