KAZESUI'S PROFILE
Search
Filter
DynModeSeven
Hmm... so that's not just the case when you erase the event, but also like this.
Thanks for the heads up.
Thanks for the heads up.
Making your Custom Menu System
This was also mentioned on the last page (of comments), but here's a tutorial which takes you through how to make an Item Sub Menu
[DynRPG Plugin] DynModeSeven
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").
DynModeSeven
Yeah, the boundary thing is known. Rather than adding it in the readme, I plan on having it default to the upper left tile on the map when loading the map.
As for the rendering artifacts in your map, I honestly don't know why they appear.
I thought I had ironed out all bugs related to drawing the map, but I could have been mistaken. Would the tile in question happen to be an autotile?
And yes, battle animations will become unreliable during mode 7 rendering. The thing which happens there, is that the original map still exists beneath the mode 7 rendering, meaning your hero is still walking normally on that map. As such, any battle animation targetted to an event/hero, would appear at where these events would be on the normal map beneath the mode 7 rendering, rather than taking the mode 7 rendering into account. I'm not sure I could manipulate the show battle animation command to execute at any designated coordinate of my choice, so you'll simply have to treat that as something you can't use along with mode 7 rendering for now.
As for the rendering artifacts in your map, I honestly don't know why they appear.
I thought I had ironed out all bugs related to drawing the map, but I could have been mistaken. Would the tile in question happen to be an autotile?
And yes, battle animations will become unreliable during mode 7 rendering. The thing which happens there, is that the original map still exists beneath the mode 7 rendering, meaning your hero is still walking normally on that map. As such, any battle animation targetted to an event/hero, would appear at where these events would be on the normal map beneath the mode 7 rendering, rather than taking the mode 7 rendering into account. I'm not sure I could manipulate the show battle animation command to execute at any designated coordinate of my choice, so you'll simply have to treat that as something you can't use along with mode 7 rendering for now.
[DynRPG] DynPEC
[DynRPG] DynPEC
@effect_strength sets the strength of whatever effect you've chosen for the picture, either rotation or waver. Since you can only have one (and this is how it's stored internally anyway) there's no need to make another separate command for the two scenarios.
And yes, rotating anything big is rarily a good idea in rm2k3 if you want to avoid lag. This has been true since before DynRPG, and this plugin does not change that, since it just gives some extra control over the pictures, not change how they are executed.
And yes, rotating anything big is rarily a good idea in rm2k3 if you want to avoid lag. This has been true since before DynRPG, and this plugin does not change that, since it just gives some extra control over the pictures, not change how they are executed.
DynModeSeven
Yeah, same deal. I need to make a better template
@readme titles, I guess that's worth considering. I didn't really think about people wanting to actually take the readme files out of their respective demonstration projects, but I suppose that makes some kind of sense, even though it sounds like it could get a bit messy in its own sense to clutter a project with readme files, unique titles or not.
@readme titles, I guess that's worth considering. I didn't really think about people wanting to actually take the readme files out of their respective demonstration projects, but I suppose that makes some kind of sense, even though it sounds like it could get a bit messy in its own sense to clutter a project with readme files, unique titles or not.
DynModeSeven
An example of why one (in this case me) should be careful when copy pasting readme files to use a previous one as a template. You can totally disregard any mention of the dynrpg.ini file in relation to this plugin, as it doesn't use it. Thanks for pointing it out.
3D rendering in rm2k3? Perfectly possible
There would be a number of ways to do that, but that won't change how things are dealt internally in the rm2k3. This means you would still have to use charsets, tilesets, etc. with the same colour depth as always, since that's the only thing the maker knows how to draw, and trying to disable that is pretty much out the question.
So the most viable option would be to do some kind of replacing strategy, and then add some code in a plugin to render to the screen in full 24 bit color depth ( or even 32, if you fancy the transparency ). Dunno what the best way to make this user friendly would be though, and to a large part, it would mean redrawing the entire screen, which "could" affect the performance. Emphasis on "could", as the mode 7 plugin seems to be remarkably performant, even with only rudimentary performance tweaks.
Another thing I've been feeling like looking into, is the options of increasing the resolution of the window. I already have a good way of getting all the map data I need to show tiles and sprites beyond the 20x15 tile limit currently given, but there could be tons of other problems arising from trying to do that, which I'm just not aware of at the moment as well, since I'm stretching what the rm2k3 was supposed to do. I've seen something similar done for rm2k without DynRPG though, so I have a feeling it might not be as farfetched as it could seem.
I don't need more color depth to mess around in OpenGL though, and this seems like it could be a good time to refresh and extend some of my experience with OpenGL.
... Of course, lot of fun stuff which I probably won't have time to do anything serious about until march or something, because things are getting hectic again.
So the most viable option would be to do some kind of replacing strategy, and then add some code in a plugin to render to the screen in full 24 bit color depth ( or even 32, if you fancy the transparency ). Dunno what the best way to make this user friendly would be though, and to a large part, it would mean redrawing the entire screen, which "could" affect the performance. Emphasis on "could", as the mode 7 plugin seems to be remarkably performant, even with only rudimentary performance tweaks.
Another thing I've been feeling like looking into, is the options of increasing the resolution of the window. I already have a good way of getting all the map data I need to show tiles and sprites beyond the 20x15 tile limit currently given, but there could be tons of other problems arising from trying to do that, which I'm just not aware of at the moment as well, since I'm stretching what the rm2k3 was supposed to do. I've seen something similar done for rm2k without DynRPG though, so I have a feeling it might not be as farfetched as it could seem.
I don't need more color depth to mess around in OpenGL though, and this seems like it could be a good time to refresh and extend some of my experience with OpenGL.
... Of course, lot of fun stuff which I probably won't have time to do anything serious about until march or something, because things are getting hectic again.
[DynRPG Plugin] DynModeSeven
Mode 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.














