Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
Profile
Locker
Play ListsKAZESUI'S PROFILE
Close
Search
Filter
All
Game Pages
User Statuses
[DynRPG Plugin] DynModeSeven
To an extent, this is already possible by simply using events with those graphics.
While it probably wouldn't be very difficult to add some command to make this more automatic without the usage of events, it would still suffer from the same problem as with the event sprites:
Your fence is probably look very disjoint.
While it probably wouldn't be very difficult to add some command to make this more automatic without the usage of events, it would still suffer from the same problem as with the event sprites:
Your fence is probably look very disjoint.
DynModeSeven
Might work well without the mode 7 Plugin, but probably not such a good idea to do with the mode 7 rendering. There's nothing stopping you from doing this right now, just load and unload the map for every frame. I have a good feeling you'll start to experience lag real soon doing it this way.
The mode 7 rendering is a fairly heavy weight process.
Drawing an entire map to an image (especially for a large map) is a very heavy weight process. You don't want to do this every frame.
Why does this not cause a problem for the regular map drawing in rm2k3? Because it uses a different approach. Normally, it is well defined how many tiles fit into the screen (20x15... + some border tiles) so it's not that expensive to render the tiles on the fly based on their id's.
With mode 7 however, given certain settings, every tile along on direction could be represented, making drawing all the visible tiles a lot more expensive and less feasible, and is ultimately the reason why this is not done in this plugin.
The mode 7 rendering is a fairly heavy weight process.
Drawing an entire map to an image (especially for a large map) is a very heavy weight process. You don't want to do this every frame.
Why does this not cause a problem for the regular map drawing in rm2k3? Because it uses a different approach. Normally, it is well defined how many tiles fit into the screen (20x15... + some border tiles) so it's not that expensive to render the tiles on the fly based on their id's.
With mode 7 however, given certain settings, every tile along on direction could be represented, making drawing all the visible tiles a lot more expensive and less feasible, and is ultimately the reason why this is not done in this plugin.
DynModeSeven
It sounds like it might be related to a known issue, which is a rm2k3 specific problem when it comes to drawing events on wrapped maps. It does however sound pretty obscure for a transparent picture to prevent an event from being drawn.
So just to make sure, could you run the mini map test on a map with no wrapping (and with wrapping command in the plugin being set to disabled)?
As for popping up or not. This is something I've been thinking about, but anything which moves along the flat map are a bit problematic, as it either becomes a lot more to code, or might require the map to be drawn twice.
One thing as well. I might be able to make a custom version of the Plugin which would rely on an event being drawn rather than a picture. Thing is that it would always have to be set to the largest event ID, so it could cause be a bit more work there (assuming no other unforseen issues with using the events for this purpose instead). Unless you're perfectly fine with how the plugin works right now, I'd probably wait a bit with trying this until I've ironed out some of the issues with this plugin though.
So just to make sure, could you run the mini map test on a map with no wrapping (and with wrapping command in the plugin being set to disabled)?
As for popping up or not. This is something I've been thinking about, but anything which moves along the flat map are a bit problematic, as it either becomes a lot more to code, or might require the map to be drawn twice.
One thing as well. I might be able to make a custom version of the Plugin which would rely on an event being drawn rather than a picture. Thing is that it would always have to be set to the largest event ID, so it could cause be a bit more work there (assuming no other unforseen issues with using the events for this purpose instead). Unless you're perfectly fine with how the plugin works right now, I'd probably wait a bit with trying this until I've ironed out some of the issues with this plugin though.
[DynRPG Plugin] DynModeSeven
@1. I suppose ladders would look pretty weird in mode 7 to begin with. If you put the ladder in the upper layer of the chipset, it shouldn't be a problem though and then draw it onto the map, apart from not having event properties that is.
I suppose that's somewhat missing @rotation command, given that you have made a spritesheet with more than 4 angles. Otherwise, you should be able to use the regular direction commands of the event to change the angle of the sprite.
offsets already exist upon creating the sprite, but could also be added to be manipulated anytime I guess
I suppose that's somewhat missing @rotation command, given that you have made a spritesheet with more than 4 angles. Otherwise, you should be able to use the regular direction commands of the event to change the angle of the sprite.
offsets already exist upon creating the sprite, but could also be added to be manipulated anytime I guess
+++ DynRPG - The RM2k3 Plugin SDK +++
It seems to be a problem with the new patch itself.
I've opened a new project in an attempt to test it out, and old plugins does not work with the new version, and neither do plugins compiled with the new version ( along with the correctly upgraded compiler ).
I don't think you'll find problems in your plugin source code
I've opened a new project in an attempt to test it out, and old plugins does not work with the new version, and neither do plugins compiled with the new version ( along with the correctly upgraded compiler ).
I don't think you'll find problems in your plugin source code
Rm2k3 Plugin Tiles
Having skimmed through it, I can't see anything in particular which would cause a huge slowdown, which in my mind would probably mean that there's something else which slows it down, like the fog event you're calling, or it could be that for some reason, that you're scanning too much.
It could also be that the you're not jumping far enough while scanning in a direction. You could try to increase how much is added to the sight radius variable in each step. If this decreases the time it takes for you to execute the event, then there's probably too much scanning going on. Beware though, as if it's increased by too much, the result becomes more inaccurate.
That said, while the plugin where any tile can change into to any tile would be pretty hard to realize at the moment, having a plugin change from one tile with no important property apart from visual ones to a fixed tile beneath is not equally impossible. Depends on the exact implementation in mind of course, but given the use of the trigonometry script, I assume that you're using it to detect which tiles should be revealed.
This should be possible... though I'm afraid I probably won't have time to do it myself anytime soon (just throwing it out there for anyone who'd have time and would be up for a challenge).
It could also be that the you're not jumping far enough while scanning in a direction. You could try to increase how much is added to the sight radius variable in each step. If this decreases the time it takes for you to execute the event, then there's probably too much scanning going on. Beware though, as if it's increased by too much, the result becomes more inaccurate.
That said, while the plugin where any tile can change into to any tile would be pretty hard to realize at the moment, having a plugin change from one tile with no important property apart from visual ones to a fixed tile beneath is not equally impossible. Depends on the exact implementation in mind of course, but given the use of the trigonometry script, I assume that you're using it to detect which tiles should be revealed.
This should be possible... though I'm afraid I probably won't have time to do it myself anytime soon (just throwing it out there for anyone who'd have time and would be up for a challenge).
[DynRPG Plugin] DynModeSeven
1. Would it even make sense to have a sprite in the current form to be set below hero in the current format? I have a feeling that would look pretty awkward and the only way to make it look more passable would be to have it flat like the map itself.
Having anything flat and moving along the map has it's own set of issues, meaning this one could be some time away.
If they're not moving however, that might be more fixable.
2. Thanks, should be fixable. Will fix it when I get the time.
3. If the jump command doesn't affect the screen relative coordinates of the hero/event then probably not, since this plugin is reliant on those coordinates to redraw the sprites on top of the mode 7 rendering.
4. Why wouldn't you have a boundary if the map wasn't set to wrapping anyway? Though I suppose I could default it to some tile to remove the crashing, but then you might risk having a bad boundary texture, rather than just seeing the game crash, and then right away figuring out that you need to set the boundary value to whatever's appropriate.
5. The disabling command "should" remove it, and I think it worked during testing. Will take a look at it though. Could you please post the exact comment command you were using to try and disable it though, just to be on the safe side?
6. I haven't set any limit in the plugin, and I don't see why it would crash at any amount of events, so probably not. Never tried to put that many events on a map just for the sake of testing though, so I'm not entirely certain. I think rm2k3 itself will cap you at 5000 or 9999 events though.
Having anything flat and moving along the map has it's own set of issues, meaning this one could be some time away.
If they're not moving however, that might be more fixable.
2. Thanks, should be fixable. Will fix it when I get the time.
3. If the jump command doesn't affect the screen relative coordinates of the hero/event then probably not, since this plugin is reliant on those coordinates to redraw the sprites on top of the mode 7 rendering.
4. Why wouldn't you have a boundary if the map wasn't set to wrapping anyway? Though I suppose I could default it to some tile to remove the crashing, but then you might risk having a bad boundary texture, rather than just seeing the game crash, and then right away figuring out that you need to set the boundary value to whatever's appropriate.
5. The disabling command "should" remove it, and I think it worked during testing. Will take a look at it though. Could you please post the exact comment command you were using to try and disable it though, just to be on the safe side?
6. I haven't set any limit in the plugin, and I don't see why it would crash at any amount of events, so probably not. Never tried to put that many events on a map just for the sake of testing though, so I'm not entirely certain. I think rm2k3 itself will cap you at 5000 or 9999 events though.
+++ DynRPG - The RM2k3 Plugin SDK +++
Ah right. I believe you would have been able to do that by going to the project folder, deleting the rpg rt executable and then removing the ".bak" extension of the other rpg_rt executable. I assume it's a backup of the original exe prior to patching it with dynrpg (or whatever cherry patch was used).
+++ DynRPG - The RM2k3 Plugin SDK +++
author=Cherry
Known bug, with transparency in general. The transparency changes depending on the Y position of the event on the screen.
Is already fixed (on my computer), will be released soon.
[Poll] Which game engine do you prefer? (I fixed it)
Games - Tester
Games - Other
