Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
[DYNRPG PLUGIN] DYNMODESEVEN
Posts
Kazesui
5797
Kazesui
View playlists
CloseMode 7 in the Super Nintendo is a hardware graphics mode, which allows scanline scaling and rotation of a single background, that's all. In other words, the nintendo game developers already had to use a bit of clever programming to turn this into the pseudo 3d rendering which it is usually associated with. Depending on what you consider clever, almost any programming on the snes could be considered clever, considering the hardware limitations. Alone because rm2k3 is on a computer, DynModeSeven is not going to be exactly like the mode 7 on the snes, and it would not be very user friendly to try an emulate it either (or plugin-developer friendly for that matter).
That aside, being able to mess around with a single background is not enough to do doom. The Doom cartridge had an extra co-processor which allowed it to do some more 3d stuff. You can think of it, as if the came with an embedded graphics card in it, which they could make use of to do slightly more sophisticated algorithms, like the ray caster algorithm I spoke of.
So in short, no, DynModeSeven does not work exactly like mode 7 of snes, and no, that mode 7 would not be enough to recreate doom.
That aside, being able to mess around with a single background is not enough to do doom. The Doom cartridge had an extra co-processor which allowed it to do some more 3d stuff. You can think of it, as if the came with an embedded graphics card in it, which they could make use of to do slightly more sophisticated algorithms, like the ray caster algorithm I spoke of.
So in short, no, DynModeSeven does not work exactly like mode 7 of snes, and no, that mode 7 would not be enough to recreate doom.
McBick
1339
Oh cool, didn't know that. Guess I'll just be sticking to world maps with Dynmode 7 for now. Was going to try to create a First Person dungeon using it, but from what your telling me it isn't possible because I would need a roof too. I thought maybe with working with pictures I could do some clever tricks, but doesn't seem possible.
gadesx
307
there is a way to make a dungeon generator in real-time with a plugin?
2k3 have the function to generate but no in realtime,
can be interesting for make dungeon crawlers,
maybe using a map like base always, that change the rooms.
2k3 have the function to generate but no in realtime,
can be interesting for make dungeon crawlers,
maybe using a map like base always, that change the rooms.
Milennin
2060
I wonder if it would be possible to make something like Sonic 3 & Knuckles Emerald stages with this plugin?
Kazesui
5797
Something like that stage should probably be possible, just don't count on being able to do those curved lines on the top properly.
@gadesx
Realtime could get difficult, since I don't have access to the cached map information. The information I use for the DynModeSeven Plugin is the information stored in the map files themselves as well as the information in terms of tile properties given in the database. I might be able to alter the properties of tiles, but altering the tiles themselves remains problematic for now (unless you're able to reload the map for your "realtime").
@gadesx
Realtime could get difficult, since I don't have access to the cached map information. The information I use for the DynModeSeven Plugin is the information stored in the map files themselves as well as the information in terms of tile properties given in the database. I might be able to alter the properties of tiles, but altering the tiles themselves remains problematic for now (unless you're able to reload the map for your "realtime").
I wanna have mode 7 for airship only, for worldmap only. Is there a way to do this? I don't understand the code right now.
TheNecromancer
3160
Well you choose when to activate it, so part of the event that puts you in the airship would have the commands for starting mode 7. When you leave airship, you would turn it off.
I love this plugin - I have a number of experiments I'm working on with it.
Some thoughts:
-Fixed directions and fixed graphics for events doesn't seem to work.
- The chipset transparency doesn't work. All you end up with is the background colour of the chipset. It would be useful to have sections of the floor not rendered (or rendered as transparent or whatever) so you could display a background or a picture behind it.
- Would there be a way to implement a changing picture offset in realtime feature? So you could move the hero or other picture added using the @add_sprite command up or down the screen in relation to the map? Then you could conceivably make things like cliffsides by displaying pictures below the events their tied to on the y-axis, or moving the hero up stairs and jumping and such.
- Would there be anyway to make the background behave more like the paralax backgrounds in the normal map display? Things like autoscroll or scrolling with the hero? Or using animations as backgrounds?
Love your stuff man. Keep it up!
Some thoughts:
-Fixed directions and fixed graphics for events doesn't seem to work.
- The chipset transparency doesn't work. All you end up with is the background colour of the chipset. It would be useful to have sections of the floor not rendered (or rendered as transparent or whatever) so you could display a background or a picture behind it.
- Would there be a way to implement a changing picture offset in realtime feature? So you could move the hero or other picture added using the @add_sprite command up or down the screen in relation to the map? Then you could conceivably make things like cliffsides by displaying pictures below the events their tied to on the y-axis, or moving the hero up stairs and jumping and such.
- Would there be anyway to make the background behave more like the paralax backgrounds in the normal map display? Things like autoscroll or scrolling with the hero? Or using animations as backgrounds?
Love your stuff man. Keep it up!
I like the mode 7 rotation, but when you rotate, it screws with the cursor interface. That is, no matter if you're facing vertical or sideways, right should go right in regard to the screen. I dunno, I was facing sideways and i think I had to press down to go down. If facing sideways, I could see someone to my right, that shouldve been the direction I need to press.
Mkay I figured out what was off. Regardless of the perspective, you're actually traveling the same path, standing between the cactus and the mountain always goes back and forth between the two (at forty-five degrees, I should have been walking to the tree diagonally over), meaning you're really just moving up and down. If the perspective is 45 you should be moving diagonal, if it's 90, up should be moving at a right angle, if it's 180 down is up, etc. This is exactly how secret of mana handled flammie's rotation during flight, and it was smooth. I'd say now that the graphics rotation works, this is the next step.
Mkay I figured out what was off. Regardless of the perspective, you're actually traveling the same path, standing between the cactus and the mountain always goes back and forth between the two (at forty-five degrees, I should have been walking to the tree diagonally over), meaning you're really just moving up and down. If the perspective is 45 you should be moving diagonal, if it's 90, up should be moving at a right angle, if it's 180 down is up, etc. This is exactly how secret of mana handled flammie's rotation during flight, and it was smooth. I'd say now that the graphics rotation works, this is the next step.
Kazesui
5797
Indeed, fixed graphics and fixed direction does not work. The SDK does not give access to these event properties, so I'm unable to handle them accordingly (outside of adding more comment commands).
Transparency might not work at the moment, true. If you just want to use a picture as a custom background, you can do that by disabling the background however.
Adding more control over sprite offsets, so that the developer can manually control it is on my todo list for when I get time.
You will need to make your own custom background for that, using pictures and disabling the background.
As for rotation and direction, yeah it's a bit wonky at the moment. You can still fix this to a certain degree, by just eventing in your own movement scheme, which adjust in accordance to the rotation (with key inputs and move commands). I'm pretty sure that's what pepsiOtaku did for his airship.
Eventually, I would like to add a more free movement scheme, where up is forward, and the sides are simply rotate, more similar to how it actually worked in several snes games. But again, there's the issue of getting time to implement that, so don't expect it too soon.
Transparency might not work at the moment, true. If you just want to use a picture as a custom background, you can do that by disabling the background however.
Adding more control over sprite offsets, so that the developer can manually control it is on my todo list for when I get time.
You will need to make your own custom background for that, using pictures and disabling the background.
As for rotation and direction, yeah it's a bit wonky at the moment. You can still fix this to a certain degree, by just eventing in your own movement scheme, which adjust in accordance to the rotation (with key inputs and move commands). I'm pretty sure that's what pepsiOtaku did for his airship.
Eventually, I would like to add a more free movement scheme, where up is forward, and the sides are simply rotate, more similar to how it actually worked in several snes games. But again, there's the issue of getting time to implement that, so don't expect it too soon.
author=Kazesui
Indeed, fixed graphics and fixed direction does not work. The SDK does not give access to these event properties, so I'm unable to handle them accordingly (outside of adding more comment commands).
It does. http://rpg-maker.cherrytree.at/dynrpg/class_r_p_g_1_1_character.html#af32eb82be5b7d3b83149036911c5d3e0
Kazesui
5797
Whoops, never used it, so forgot it existed.
Then fixed direction thing might be fixable as well
Then fixed direction thing might be fixable as well
I knew it existed.
Being that I'm a sucky programmer and don't really understand the syntax, I must've read these pages a zillion times, trying to understand the few codes I wrote. So yea, I knew you could tweak movement like that. I just didn't know how to go about it.
Being that I'm a sucky programmer and don't really understand the syntax, I must've read these pages a zillion times, trying to understand the few codes I wrote. So yea, I knew you could tweak movement like that. I just didn't know how to go about it.
One bug I should report is that the @using_background parameter doesn't seem to work. According to your readme, Kazesui, if I want to disable the background I need to have a comment that says "@using_background false" or "@using_background no" but nothing seems make it work - I either get the default background or just black if I don't have the @set_background parameter in my initial event.
gadesx
307
With some values the zoom is good but the character are above the window,
maybe there is a way using the option of move window of rpg maker?
maybe there is a way using the option of move window of rpg maker?
McBick
1339
I noticed that moving up/down at 270* moves the hero at double the speed of moving left/right, this is is true for other angles as well. I think the texture scale might be affecting this.
as my last post in this topic got deleted i am asking again. how can i get it working when i get the final airshop.(my project have 3 airships and only the last will use mode7.)
Kazesui
5797
There's no "airship" support at the moment, so you'd probably have to emulate it in a similar manner as pepsiOtaku did, i.e. event in a kind of custom directional movement scheme based on the rotation (I believe).
I'll have to write up some kind of document about that at some point. Edit: Oh dear, I kind of did below!
It's very complicated and convoluted, but in a nutshell, you can't use the default vehicle functionality as you know it. The end-result and responsiveness is hard to beat, and very customizable though. I'm kind of a mad scientist when it comes to systems like this, so you have been warned. :)
To start with, the vehicle graphic is the engine recognizes is just blank. It merely serves as a way for the hero to be recognized as being in or out of the vehicle. I have a basic event hidden somewhere on my map of the airship graphic, and a parallel process event that moves that event to the same position of the actual vehicle location. I do this so I can hide the airship graphic easily when I need to. Next, when the hero enters the airship, a switch is turned on that begins an autostart event that mimics the escape key, and enter key, so that I have control over animation when you enter/exit. When you enter, all the airship graphic frames are shown with a 100% opacity so they can be hidden/shown later on without causing lag.
Next, I have your typical key input processing style of parallel process event that recognizes what arrow key is being held down. The left and right keys control rotation as kazesui mentioned, and the up/down keys move you forward and backward. Using this event, I show/hide the airship graphics in 9 scenarios: When the ship is idle, idle+left, idle+right, forward, forward+left, forward+right, backward, backward+left & backward+right.
Here's where I complicate things, but for a very good reason. With key-input processing, I wasn't getting the responsiveness I was looking for (it got messy when you held down more than one key at a time), so I wrote a plugin that basically mimics key input processing, but it's more responsive. As with KIP, it sets a variable to 2 or 3 if left or right is being held down, and a separate variable to 1 or 4 if up or down is being held down. Next, the plugin actually moves the hero in the appropriate direction based on that logic. The variables are merely for the pictures & animation.
As for the actual rotation logic, since I'm stuck with 8-directional movement at the moment, I basically figured out the best angle ranges to use for moving in a particular direction. The parallel process event tells the plugin which angle you're facing, and the plugin decides which direction to move in (you still have to think of the map as a traditional map, so 0 degrees is right, 90 is down, 180 is left, and 270 is up. add/subtract 45 for each of the diagonals. Then, if you imagine that like a pie with 8 slices, imagine rotating the whole thing by 22.5 degrees, so that 68-112 would be the range for down, 158-202 would be the range for left, 112-158 would be down-left, etc.
Once you wrap your head around the above, the rest of it is tweaking and bug-fixing. Like with a lot of my other systems, it's hard to really make any sort of tutorial for them because there's a ton going on, and when I revisit the code I've written, it takes a few hours to remember what the hell I wrote. :)
All I have left to say is, I would LOVE to condense all that into a simple plugin, but it's just not that easy yet.
It's very complicated and convoluted, but in a nutshell, you can't use the default vehicle functionality as you know it. The end-result and responsiveness is hard to beat, and very customizable though. I'm kind of a mad scientist when it comes to systems like this, so you have been warned. :)
To start with, the vehicle graphic is the engine recognizes is just blank. It merely serves as a way for the hero to be recognized as being in or out of the vehicle. I have a basic event hidden somewhere on my map of the airship graphic, and a parallel process event that moves that event to the same position of the actual vehicle location. I do this so I can hide the airship graphic easily when I need to. Next, when the hero enters the airship, a switch is turned on that begins an autostart event that mimics the escape key, and enter key, so that I have control over animation when you enter/exit. When you enter, all the airship graphic frames are shown with a 100% opacity so they can be hidden/shown later on without causing lag.
Next, I have your typical key input processing style of parallel process event that recognizes what arrow key is being held down. The left and right keys control rotation as kazesui mentioned, and the up/down keys move you forward and backward. Using this event, I show/hide the airship graphics in 9 scenarios: When the ship is idle, idle+left, idle+right, forward, forward+left, forward+right, backward, backward+left & backward+right.
Here's where I complicate things, but for a very good reason. With key-input processing, I wasn't getting the responsiveness I was looking for (it got messy when you held down more than one key at a time), so I wrote a plugin that basically mimics key input processing, but it's more responsive. As with KIP, it sets a variable to 2 or 3 if left or right is being held down, and a separate variable to 1 or 4 if up or down is being held down. Next, the plugin actually moves the hero in the appropriate direction based on that logic. The variables are merely for the pictures & animation.
As for the actual rotation logic, since I'm stuck with 8-directional movement at the moment, I basically figured out the best angle ranges to use for moving in a particular direction. The parallel process event tells the plugin which angle you're facing, and the plugin decides which direction to move in (you still have to think of the map as a traditional map, so 0 degrees is right, 90 is down, 180 is left, and 270 is up. add/subtract 45 for each of the diagonals. Then, if you imagine that like a pie with 8 slices, imagine rotating the whole thing by 22.5 degrees, so that 68-112 would be the range for down, 158-202 would be the range for left, 112-158 would be down-left, etc.
Once you wrap your head around the above, the rest of it is tweaking and bug-fixing. Like with a lot of my other systems, it's hard to really make any sort of tutorial for them because there's a ton going on, and when I revisit the code I've written, it takes a few hours to remember what the hell I wrote. :)
All I have left to say is, I would LOVE to condense all that into a simple plugin, but it's just not that easy yet.
