Ultra Mode 7 [RMMV & RMMZ]

Hey Blizzard? How's life? Hey If you see this and have the time would it be possible to add a "SHIFT" parameter to the Camera? Basically to be able to move the camera on the X or Y axis while holding facing direction true and off of the actor as the target? Maybe even an unlock/lock camera to Actor function? It'd just be handy to be able to put Harold someplace on the screen other than the center in certain situations,.

Less important but so cool: Would it be difficult to add a "ROLL" function to the camera?

P.S. I've been super curious what special features your personal Ultra (Mega?) Mode 7 has. (I only know about the curved plane!) Any chance you'd add any to the plugin someday??

THANKS for the amazing plugin! It's the backbone to my project and without substitute.

Adding both a roll and repositioning of the camera is easy actually. I just didn't add them since they aren't that useful. MV's default camera scrolling should still work just fine with UM7 so you don't really need offsetting other than the implemented custom camera height. As for roll, the only real use case I can see is for some fancy effects. But I can add it if you really want it.

My own UM7 implementation has more side-features than actual Mode 7 related features (aside from curvature). e.g. I have a custom weather system that makes rain and snow (taking into account wind direction) fall across the map rather than just being a screen overlay (I still have to implement cloud overlays in the sky). I also use 8-directional sprites so the game needs to be able to handle that and 4-directional sprites simultaneously. And I have full mouse-based controls for the map and I use a completely custom map/tileset format. So I'm likely never going to add any of these to the public version. xD

Gyazo Screen Video
Gyazo Screen Video
A bit too much screen frost filter going on in that second one. xD Gotta tone that down.

I would definitely use camera roll to necessary effect. If it really isn't trouble I humbly request. No rush either, game won't be finished anytime soon. I'm going to use it for an interior airplane scene to simulate a plane going down. Also would be useful for Dutch angle shots.

Oh... Question? Would Doodads rotate with the plane or stay fixed to camera?

Also, camera shifting works fine using UM7's functions like you said it should. I was using Galv's Camera Control and Camera smoothing plugins and one of them was just screwing with UM7's camera.

Not really a request, but would it within possibility to have a second Mode 7 plane going at the same time but at a different angle? You could do some really cool stuff with it. Cloud layers, fogs, parallax rivers and effects, etc.


PS Your project looks dope. War tactics kind of gameplay? your weather system is pretty.

I have a peculiar compatibility issue... :kaomad2:
When I use a character-sprite with more frames. Through Galv's Frames plugin & Animations plugin. I get this jittery effect on character sprites:




This exclusively happens during Ultramode7, when the characters are set to pixelated in plugin parameter. (This jitter does not occur when this parameter is false.)

Note: the characters in the left, are default 3 frame sprites. (So no jitter there.) The ones in the middle have added frames. 20 frames for the 3D sprite, 10 frames for the tall-pixel sprites.

I would deeply appreciate a fix, or any guidance towards it. As it looks horrible when not pixelated. :kaocry:

---

---

Edit: I've added a breathing effect on the sprite using MOG_CharacterMotions.js
Which seems to be doing a good enough job of hiding the jitter.

@ephesus Sure, I'll add it later then.

Doodads should rotate because of how billboard sprites work. They only keep facing the camera. It doesn't mean they can't rotate with roll. In any case it will work however I implement it and I'll make sure they rotate. xD

What do you mean with the second plane thingy? I'm not sure what you're trying to do there.

I haven't played War Tactics, but I was inspired by the two Ogre Battle games for SNES and N64. So I'm definitely not the first one to come up with that kind of gameplay. xD

@SigmaSuccour This is exactly what pixelization on characters does. This is especially noticeable when there are very subtle movements in pixels like the breathing plugin you mentioned. That's why it doesn't happen when you set it to false. So just turn it off.

EDIT: I took another look at the video. From what I can tell, there is something else messing with the whole thing. I think the camera doesn't appear to ever really stop, but only keeps infinitely getting closer to its target coordinates. I think this kind of behavior could happen without UM7 at all as well, but it might be less noticeable if since sprites aren't scaled. If you can't figure it out, you can make a demo and I can take a look at it.

You're awesome.

The desired effect would be that the billboards rotate relative/anchored to/with the plane and not to/with the camera. I get that it might have to be manually implemented as the doodads will naturally want to rotate with the camera. I think...? Both could be used for different effects really. (a rolled camera with doodads still going straight up and down would make it look like there is an uphill or downhill grade)


I realized there are a few more issues than I thought with a second plane option but if this makes any sense:

Second plane option:
Like having an option to turn on a second visual effect only mode 7 plane. it could be set at a distance and angle relative to the main plane. Tiles would probably need to be set from a different portion of map from editor or different map.

Cloud layer: set parallel to and above main plane. (With cloud tiles using alpha transparency.)
Fog layer: set slightly above main plane. (would need custom images for billboards with bottoms faded away. same for character sprites.)
Water Layer: main map has water areas cut out completely by alpha. second plane is set parallel and below main plane with water tiles.
Under water layer: Water on map is transparent. second plane is set parallel and below main plane with underwater surface dirt/stone tiles.

steampunk walkways: same as above with metal walkways over steampunk stuff second plane

Yeah, this second plane thing looks more like a custom map system than just a Mode 7 feature. So I'll have to turn down that request.

Here because of (another?) compatibility issue. :kaocry:
When using SAN_AnalogMove.js (for pixel movement) the input controls don't change with non-zero Yaw Angle.

Can this be patched in any way? :LZSooo: So that the controls match the Yaw angle with SAN_AnalogMove.js?


EDIT: Just read your edit @bblizzard. I changed the sprite scaling from legacy to the latest/better one. And I noticed the jitter occurs depending on the camera distance. (In some distances, it doesn't occur.)
I'll prepare a demo and send it your way so you can take a better look. Thank you!

EDIT 2: Demo zipped & sent. :LZSsmile:

I hope it's not too urgent. xD I'll take a look at it when I have some time.

Please, take your time. :LZSexcite:

I've started work on a part of my game that mainly uses UltraMode7. So I've been playing around with it, and running some experiments.

Here's something I made using UltraMode7's 3D camera, with doodads images: :LZScheeze:


I have to say... it's one of the most fun I've had playing with a plugin. :LZSooo:

Hey Blizzard, OCRam is updating his plugins through MZ only, but for both MV AND MZ users through a plugin called RETRO which allows MZ plugins and scriptcalls to work in MV. It's hit and miss BUT by designing his plugins to work with RETRO specifically he's been able to basically make his MZ plugins cross compatible. Anyway, when running UM7 with his MZ lighting plugin the same issues that UM7 had with his MV lighting plugin have returned. Is it possible to patch for this?

@ephesus Press F8 and take a look at the console. Do any errors pop up? UM7 reports errors if a plugin compatibility code couldn't be loaded properly.

Wanted to try getting a first person perspective. But then I remembered I can't handle the perspective for too long, as I get sick. :kaocry:

Is that a less buggy Bethesda game I see there? xD

That's the best one I ever read guys. Thanks for the smile. At least Indie are concerned by how folks feels about bugs.

Well, I'm trying. xD This is just one of our games at Daygames.


https://gyazo.com/8af64c52ea09e35da2687bc50ecffe6f

That game has about 5-6k installs monthly. I'm content with these stats. I would like to push the ANR rate below 0.1%, but the majority of them is something like "the OS wasn't able to send the touch input data to the app in time" and I honestly have no idea what I can do to fix that since I already use ASAP on-demand processing of input and queueing it further internally. Oh well.

Crash rates on iOS are a bit higher. In 30k sessions we have like 50 crashes or so (depends on the game again).

I wait for this plugin's release on MZ so much, I'm not sure anyone can imagine

@SigmaSuccour Alright, I took a look at it. In total you have 3 problems. I'll go from bottom to top.

1. Using 12000 pixel textures is really not something I'd recommend. While most modern graphics cards probably can handle it, as soon as you go down one tier (e.g. laptops), the game will likely break. And you can almost straight forget a lot of mobile devices. You should keep them at 4096 or lower to ensure maximum compatibility and minimum problems.

2. I suspect that the shaders can't handle a texture this size with nearest interpolation well due to lower precision floating point variables. I tried manually forcing "highp" everywhere in PIXI on float and sampler2D, but I couldn't get the flickering to stop. I also tried changing "roundPixels" to false, but this only changed slightly how everything flickered, it didn't actually fix the issue.

I'm 90% sure that fixing this part would fix the actual problem. I've had a similar issue with DirectX 12 some 4 or 5 years ago where it would simply default to "mediump" precision and I would get weird flickering in some rare cases. I was able to fix it with "highp", but that was much easier since I created the render system myself. With PIXI it's difficult to find all places where this would be needed. I did find all the places where sampler2D is used and added "highp" precision to the code, but it didn't fix it. So I assume there are more places where I need to add it. Or there is something just wrong with WebGL and this issue can't be fixed this easily.

3. You are using <charAnims> on your characters that overrides the standard "Walking" and "Stepping" options in the event menu. If you don't have idle animations, you probably shouldn't use this option. The main problem here happens because of the previous two issues connected to Galv's plugin running through all 20 of the same idle frames. I'm still quite positive the core problem is with the renderer and 12k pixel texture, but this plugin exposes the issue.

The worst thing that even if you turn off idle animations, you could still see this issue during walking animations. But at least it would be much harder to notice due to the sprites moving and changing substantially between frames (or at least if they change fast enough like they are right now).

You can still consider turning off pixelization completely as I previously suggested.

Conclusion:

Try not using <charAnims> and use the other options instead to avoid having idle animations. This should mitigate most of the problems you currently have, but it won't entirely fix it. You can probably avoid the rest being noticed by being careful with the graphics.

One alternative solution would be to use a different plugin for spritesheets and possibly splits spritesheets into multiple files. You might need something custom if you want to stay at max size 4096 or below.

EDIT:

Just a small tip: I noticed that character sprites don't rotate properly when CHARACTERS_ADJUST_SPRITE_DIRECTION is turned on and a non-zero yaw angle is used. This is due to some compatibility issues with the other plugins. Everything works fine if you turn that option off. Some other plugin seems to be handling that code already.

@ephesus I added the roll feature. There are always some limitations depending on the order of applying the angles so I picked the one that is the least problematic.

@bblizzard This is awesome! Thank you for isolating the issue so much and for the suggestions. I can see more ways to work around this issue now.
And thank you so much for making it compatible with San_AnalogMove.js :LZSooo: (Just tried it. Works great.)

And also, love the roll feature! :LZSevil: (I think I can do some evil things with it.)