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
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
[RM2K3] DynRPG Compiling Error
author=McBick
I tried this too, but it gives the same error. I think the issue is the destructor in the class, but I am not familiar with how destructors work, so I could be wrong. I may just be better off creating my own window function as nothing I have tried works, not to mention I would have more customization options if I make my own.
I experimented with the RPG::battleData::navLevel and I have discovered some things. If I set it to 0 first, I will then be allowed to change it to whatever value I want, but this ends up doing nothing if I set it to RPG::BNAV_IN_COMMAND_WINDOW, so useless. Also this is the exact error I receive, "Access violation in module "RPG_RT.exe" in with address 004BFF9E and offset 00000034 of type Read occured". If I understand correctly the address is to RPG::battleData and the offset is RPG::battleData->navLevel, but I'm not sure why it is a Read type violation.
Is there a way to force input? I could do that instead, but I don't see a way to force input in DynRPG.
As mentioned, it could be because it the only way RPG Maker expects to be able to transition from one state to another involves processing key inputs. It's quite possible that they allocate a pointer of some sort internally in case the player acts upon a nav position, which is not always valid. Again, I believe it's safe to assume this particular member variable does not expect to be messed with. And no, the address of BattleData should be 0x4CDD38 not 0x4BFF9E (note, prefixing numbers with 0x implies that the number following it is given in hexadecimals), at least based on the headerfile. Either way, it boils down to it trying to access something it shouldn't, for reasons which will be hard to determine without the source code.
There are ways to simulate key presses with C++ code, but it's very hacky and I would not really recommend this as a solution. Apart from that I'm also not sure how to force the change.
[RM2K3] DynRPG Compiling Error
First of all, thank you for using the code tags. It makes it so much easier to read the code.
std::map is not an operator, but rather a "data structure", which is an umbrella term for objects focused on storing data. In particular, map is a binary tree, to quickly find the value associated with a given key. In your case, the integers are the key and the pointers are the value.
std::map dynamically allocate the necessary memory as needed, so your RAM is pretty much what defines the limit. In other words, nothing you need worry about. As long as you keep it global it should be fine as is.
If you don't need direct access to the various pointers, there are also other alternatives you could use, like std::list or std::vector.
std::vector resembles a normal array which you can call with the square bracket operator, but dynamically increases it's size as needed (assuming you use the right methods).
If you're looking at learning a little bit of C++, having a quick look at all three of these could be a good start as they are very common, and generally useful. If you simply want to draw all pictures you've made, it could be easier to just put them all in a std::vector and then iterate over all the elements in the array.
For all of these, you do not need to worry about the memory of the data structures themselves... but if they contain pointers to dynamically allocated memory, (like the RPG::Images), you still need to care for those yourself.
This was specifically related to the code you put before you added the if test for your image. With this if statement, this should work a lot better
That said, I want to highlight something about that if statement of yours as well, i.e. the
What it does, is not not to check if there is an image in std::map myImage, but rather if there is a key with the same value as "img" in myImage. The reason this is relevant is because it doesn't say anything about whether the RPG::Image* has been allocated or not. This should not be a problem right now, but something to keep in mind when you start removing images because you're transitioning from battle to non battle and back. The best thing to do is probably to make sure to completely empty myImage inbetween these, while remembering to destroying each instance of RPG::Image first.
I'm assuming you're referring to RPG::Image and RPG:Window, because as mentioned, in general you should not make new RPG::class objects outside a few exceptions. As for terminating themselves, effectively, they should. Once a program terminates, it will generally free up the heap and stack memory it was using, but that's more of an implicit cleanup rather than a real one, but you should be fine even if you don't use onExit to clean stuff.
You might want to consider doing some cleanup still for whenever there are scene changes still though.
This was added with the updated DynRPG version, which I never got around to use. Also, I never really dealt much with stuff related to the battle scene, as I personally wasn't very interested in it.
What I can say though is that to try and assign values to most of the RPG classes will usually lead to bad things in my experience. Exactly why, is hard to say as I would like to see the source code of RPG Maker for that, but for the navLevel thing, it could be because it expects the state to be RPG::BNAV_IN_PARTY_WINDOW, and from the perspective of RPG Maker, the only way to transition from this window to another, is to do a certain action (involving selecting a certain option), and the rest of the code operates on the assumption that this holds true. When the state is suddenly changed without going through the normal process of changing the state, the variables of this new state might not have been initialized properly and thus leads to what is referred to as a segfault in c++ lingo, i.e. trying to access something you should not have access to because you either messed up the indexing or you didn't assign / allocate / create it yet.
I guess there are some parameters which you can change the value of (like the ATB gauge from the sound of it), but this should be not be the expectation when it comes to the various members of the various classes.
You made a mistake in there. When you write
it assumes you've already instantiated an object of the Window class with 0 as a key
I can't guarantee that the code above will work, as I don't have a good way of testing it, and as mentioned, I've never worked with the RPG::Window class, but this would probably be how you should be doing it. It assumes you're allowed to instantiate it like this rather than like a pointer, which generally wasn't allowed with any classes I used in DynRPG (Not saying it isn't correct, just pointing out a potential cause in case it doesn't work).
author=McBick
So if I am to understand correctly using the map operator is in fact allocating the proper memory for me? I just want to make sure. I have changed my code to this for images.
std::map is not an operator, but rather a "data structure", which is an umbrella term for objects focused on storing data. In particular, map is a binary tree, to quickly find the value associated with a given key. In your case, the integers are the key and the pointers are the value.
std::map dynamically allocate the necessary memory as needed, so your RAM is pretty much what defines the limit. In other words, nothing you need worry about. As long as you keep it global it should be fine as is.
If you don't need direct access to the various pointers, there are also other alternatives you could use, like std::list or std::vector.
std::vector resembles a normal array which you can call with the square bracket operator, but dynamically increases it's size as needed (assuming you use the right methods).
If you're looking at learning a little bit of C++, having a quick look at all three of these could be a good start as they are very common, and generally useful. If you simply want to draw all pictures you've made, it could be easier to just put them all in a std::vector and then iterate over all the elements in the array.
For all of these, you do not need to worry about the memory of the data structures themselves... but if they contain pointers to dynamically allocated memory, (like the RPG::Images), you still need to care for those yourself.
author=McBick
How can that be? I thought variables are an address in memory, so if I use the same variable it is using the same memory? Otherwise how would you manipulate memory? How can I ensure I am using the same memory then?
This was specifically related to the code you put before you added the if test for your image. With this if statement, this should work a lot better
That said, I want to highlight something about that if statement of yours as well, i.e. the
if(!myImage[img])
What it does, is not not to check if there is an image in std::map myImage, but rather if there is a key with the same value as "img" in myImage. The reason this is relevant is because it doesn't say anything about whether the RPG::Image* has been allocated or not. This should not be a problem right now, but something to keep in mind when you start removing images because you're transitioning from battle to non battle and back. The best thing to do is probably to make sure to completely empty myImage inbetween these, while remembering to destroying each instance of RPG::Image first.
author=McBick
If I create new RPG::class objects will I have to destroy them with the onExit function or will they terminate themselves?
I'm assuming you're referring to RPG::Image and RPG:Window, because as mentioned, in general you should not make new RPG::class objects outside a few exceptions. As for terminating themselves, effectively, they should. Once a program terminates, it will generally free up the heap and stack memory it was using, but that's more of an implicit cleanup rather than a real one, but you should be fine even if you don't use onExit to clean stuff.
You might want to consider doing some cleanup still for whenever there are scene changes still though.
author=McBick
By any chance do you know how the Window class/functions operate?
This was added with the updated DynRPG version, which I never got around to use. Also, I never really dealt much with stuff related to the battle scene, as I personally wasn't very interested in it.
What I can say though is that to try and assign values to most of the RPG classes will usually lead to bad things in my experience. Exactly why, is hard to say as I would like to see the source code of RPG Maker for that, but for the navLevel thing, it could be because it expects the state to be RPG::BNAV_IN_PARTY_WINDOW, and from the perspective of RPG Maker, the only way to transition from this window to another, is to do a certain action (involving selecting a certain option), and the rest of the code operates on the assumption that this holds true. When the state is suddenly changed without going through the normal process of changing the state, the variables of this new state might not have been initialized properly and thus leads to what is referred to as a segfault in c++ lingo, i.e. trying to access something you should not have access to because you either messed up the indexing or you didn't assign / allocate / create it yet.
I guess there are some parameters which you can change the value of (like the ATB gauge from the sound of it), but this should be not be the expectation when it comes to the various members of the various classes.
author=McBickstd::map<int, RPG::Window> myWindow; void createWindow() { myWindow[0].create(64, 64, 120, 96, false); }
This function results in a memory read error, "A violation in C08BC35D occured at C08BC35D with Read".
You made a mistake in there. When you write
myWindow[0].create(64, 64, 120, 96, false);
std::map<int, RPG::Window> myWindow; void createWindow() { myWindow[0] = RPG::Window() myWindow[0].create(64, 64, 120, 96, false) }
I can't guarantee that the code above will work, as I don't have a good way of testing it, and as mentioned, I've never worked with the RPG::Window class, but this would probably be how you should be doing it. It assumes you're allowed to instantiate it like this rather than like a pointer, which generally wasn't allowed with any classes I used in DynRPG (Not saying it isn't correct, just pointing out a potential cause in case it doesn't work).
[RM2K3] DynRPG Compiling Error
The "new" operator is an essential part of the language and is not really something frowned upon. If you've read the DynRPG manual, you might have gotten this idea since it explicitly tells you not to use new with any of it's classes, which is very correct but for different reasons. Don't try to use "new" on any of the DynRPG classes, you'll probably break things.
That said, I imagine you can get away without using this operator, since it's often implicitly called for you. RPG::Image::create() somewhere along the lines of function calls does put this memory on the heap, while returning a pointer to this memory. std::map also allocated part of it's memory dynamically, most likely with the new operator. It's just that it does it all for you so you do not have to think about it. The compiler is not the one which do these. This is in fact a weakness of stuff put on the stack, as it needs to know exactly how much memory needs to be allocated for these objects beforehand and does not allow for dynamic scaling (i.e . it expects all sizes to be known at the time the code is compiled).
In the way your current code is setup, you wouldn't lose the address in the pointer when you go out of scope thanks to the global std:map, but you would lose it the second you call RPG::Image::create() again, since it now allocated new space and gives you a new pointer to the address of the newly allocated memory.
It's also important to know that just because an image is not visible on the screen when you call draw does not necessarily mean it has been destroyed. For every single frame displayed by the game everything is redrawn. Normally, what happens is that everything is drawn onto the canvas by a predetermined order. Anything drawn later will be drawn on top of what was already drawn (i.e. graphics from events set as "above hero" will be drawn after anything related to the tileset, and any picture will be drawn on top of everything else (except a picture with a higher ID). First when everything has been drawn on to the canvas, the canvas will be displayed to the player.
I'm not sure exactly when the event script commands are triggered (which is what would trigger onComment), but it's quite possible that this happens before the rest of the stuff is drawn to the canvas, meaning that when you draw an image to canvas in the onComment callback, you are indeed drawing it to the canvas, but everything is drawn on top of that afterwards, and you end up not seeing it. Nothing has been destroyed, you're just not seeing the results for other reasons.
So, even if you put the comment in a parallel process (which you would need to since otherwise you'd only be drawing the image for the single frame you executed the comment), there's still no guarantee that you will see it.
onFrame does a better job here, since I believe this is called after RPG Maker is done drawing everything it wants to draw, which is done for every frame. onFrame or onDrawScreen are proabably your best bets here. You could also use onBattlerDrawn, but you'd probably want to include an if statement there to make sure you're only executing the code after the last Battler has been drawn.
The answers to this is kind of contained in the wall of text up there, but just to directly address the various questions
Only stuff which is put on the stack. RPG::Image::create allocated memory on the heap and returns a pointer to it which is not destroyed after the function is terminated.
Still looks like it. Try callinginstead after having called RPG::Image::create one time instead, as this will clear the image without creating a new one. Only works after you have created an Image though.
You might use the same variable name, but the code don't consider that to be the same object. You might have saved the address of that memory block in some other variable somewhere else in the code and want to reuse that variable name for a new pointer, which is what's happening it the code you outlined.
Is it actually being destroyed or just not drawn? Not necessarily the same thing. You need to draw an image every frame, because if you don't the next frame is drawn on top of the old image and you won't see it anymore. This is why the text plugin also uses the onDrawPicture callback, since this something which is drawn for every frame (if the picture exists), but still allows for some graphics chosen by the developer to be put on top of the text (which is why I did not go for onFrame or onScreen myself).
What I would recommend, is to create all the images necessary in onComment callback at the start of a battle, and then to draw the images created in onFrame (without the use of RPG::Image::create in this callback). You use Destroy when the image is not used anymore or when the battle is over at which point you'll have to stop drawing as well (onFrame will keep drawing whatever it's told to draw whether you're in a battle or not, so you'll need a way to discern when you're in battle).
also, tiny tip. Use the code tags when posting code. This allows you to use square brackets, and the formatting is a bit easier to read.
That said, I imagine you can get away without using this operator, since it's often implicitly called for you. RPG::Image::create() somewhere along the lines of function calls does put this memory on the heap, while returning a pointer to this memory. std::map also allocated part of it's memory dynamically, most likely with the new operator. It's just that it does it all for you so you do not have to think about it. The compiler is not the one which do these. This is in fact a weakness of stuff put on the stack, as it needs to know exactly how much memory needs to be allocated for these objects beforehand and does not allow for dynamic scaling (i.e . it expects all sizes to be known at the time the code is compiled).
In the way your current code is setup, you wouldn't lose the address in the pointer when you go out of scope thanks to the global std:map, but you would lose it the second you call RPG::Image::create() again, since it now allocated new space and gives you a new pointer to the address of the newly allocated memory.
It's also important to know that just because an image is not visible on the screen when you call draw does not necessarily mean it has been destroyed. For every single frame displayed by the game everything is redrawn. Normally, what happens is that everything is drawn onto the canvas by a predetermined order. Anything drawn later will be drawn on top of what was already drawn (i.e. graphics from events set as "above hero" will be drawn after anything related to the tileset, and any picture will be drawn on top of everything else (except a picture with a higher ID). First when everything has been drawn on to the canvas, the canvas will be displayed to the player.
I'm not sure exactly when the event script commands are triggered (which is what would trigger onComment), but it's quite possible that this happens before the rest of the stuff is drawn to the canvas, meaning that when you draw an image to canvas in the onComment callback, you are indeed drawing it to the canvas, but everything is drawn on top of that afterwards, and you end up not seeing it. Nothing has been destroyed, you're just not seeing the results for other reasons.
So, even if you put the comment in a parallel process (which you would need to since otherwise you'd only be drawing the image for the single frame you executed the comment), there's still no guarantee that you will see it.
onFrame does a better job here, since I believe this is called after RPG Maker is done drawing everything it wants to draw, which is done for every frame. onFrame or onDrawScreen are proabably your best bets here. You could also use onBattlerDrawn, but you'd probably want to include an if statement there to make sure you're only executing the code after the last Battler has been drawn.
The answers to this is kind of contained in the wall of text up there, but just to directly address the various questions
author=McBick
I thought in c++ objects created are destroyed after the function is terminated, unless you return an object?
Only stuff which is put on the stack. RPG::Image::create allocated memory on the heap and returns a pointer to it which is not destroyed after the function is terminated.
author=McBick
From what I am to understand I am generating an infinite amount of Image objects?
Still looks like it. Try calling
myImages[0]->init(width, height)
author=McBick
How can that be though, if I am creating the same object?
You might use the same variable name, but the code don't consider that to be the same object. You might have saved the address of that memory block in some other variable somewhere else in the code and want to reuse that variable name for a new pointer, which is what's happening it the code you outlined.
author=McBick
And how is it that my image is constantly being destroyed over and over?
Is it actually being destroyed or just not drawn? Not necessarily the same thing. You need to draw an image every frame, because if you don't the next frame is drawn on top of the old image and you won't see it anymore. This is why the text plugin also uses the onDrawPicture callback, since this something which is drawn for every frame (if the picture exists), but still allows for some graphics chosen by the developer to be put on top of the text (which is why I did not go for onFrame or onScreen myself).
What I would recommend, is to create all the images necessary in onComment callback at the start of a battle, and then to draw the images created in onFrame (without the use of RPG::Image::create in this callback). You use Destroy when the image is not used anymore or when the battle is over at which point you'll have to stop drawing as well (onFrame will keep drawing whatever it's told to draw whether you're in a battle or not, so you'll need a way to discern when you're in battle).
also, tiny tip. Use the code tags when posting code. This allows you to use square brackets, and the formatting is a bit easier to read.
[RM2K3] DynRPG Compiling Error
author=McBick
So I figured out what was wrong, kinda. When I create an image in a function that only runs once, for example the onComment() function. My RPG::Image object is destroyed after the function finishes executing the code which results in nothing happening. I had to use the onFrame() function to ensure it would persists in every scene. Unfortunately, now I have run into another issue and that is my images are being immediately destroyed after being made and I am not sure why. I at least see my image for a frame before it is destroyed though, unlike before where nothing would happen. The only solution I found is to have it draw to the canvas every frame which makes me think the game automatically destroys all images every frame and redraws them, excluding the new images.
A quick lesson in C++ (slightly simplified)
There are two types of memory which are relevant during runtime of a program called "stack" and "heap". When you define a variable inside a function, like an integer, this is put on the "stack" memory, and is only valid within it's scope, usually defined by the curly brackets. You can define an integer within an if bracket, in which case that integer will not be usable once the code execution is outside the if block (as denoted by the curly brackets).
The nice thing about the stack is that it cleans itself and does not cause problems.
The heap memory is for variables which are generally supposed to persist outside of the scope of functions. You normally allocate the memory for these variables with the "new" operator in C++, or calling a function which uses this (or C equivalent like malloc()). Usually, the variable you use to associate with this memory block allocated, is by a pointer. And it is important to keep track of the address stored in this pointer, since stuff which is put on the heap does not go away unless you specifically remove it (usually with the "delete" operator in C++).
Now, to take it back to your issue, what you're doing might a whole lot worse than you're imagining.
Whenever you call
RPG::Image* myImagePtr = RPG::Image::create(320, 240);
You're allocating an image of 320x240 pixels on the heap, and you store the address to that data in the pointer "myImagePtr". Problem is, that this pointer is put on the stack, and when you leave the function, it goes out of scope and it loses the address of that data, which now can never be deleted (until the termination of the program). This is known as a memory leak, and if you're calling this functionality at every frame without freeing that image, you probably have a massive leak going on. (You might want to open the task manager and look at the memory consumption of your game application during runtime. If it keeps increasing, that's a pretty bad sign).
In other words the game does not destroy the images at every frame, you're just losing track of them (also, the game is re-drawing everything every frame, so trying to call canvas draw with the onComment callback will not do much as it will "maybe" draw it for the single frame where the comment is triggered and will be lost immediately afterwards)
What you need to do, is to make a global variable of some sort. You could create one instance of that 320x240 image, and just draw text on that directly, but it makes it tricky to remove text afterwards, so you'll probably have to "clean" the image every time you want to remove something. You need make the drawing of the image happens in a callback which is drawn at every frame you want it to be visible, and here the order can be important.
[RM2K3] Dyntext error
I do have my doubts that this could be the issue, but if you save the game while a text is being displayed, iirc this will be stored alongside the savefile and automatically displayed when you load the file again (even if there is no event script to generate that piece of text anymore).
That's the only thing from the top of my head which I could imagine being the reason, apart from the text being generated by some other event script long forgotten.
That's the only thing from the top of my head which I could imagine being the reason, apart from the text being generated by some other event script long forgotten.
[Poll] Better late than never! The DynRPG plugin contest
I did not remember having entered this at all, Possibly because I made quite a few plugins with no contest in mind (maybe I had already forgotten about it by my second public plugin).
It's a little bit sad that I didn't at the very least (re)submit the updated version of the particles effect plugin as it saw a substantial upgrade some time later than this particular iteration.
It's a little bit sad that I didn't at the very least (re)submit the updated version of the particles effect plugin as it saw a substantial upgrade some time later than this particular iteration.
HoloLens Games
author=slashauthor=SaileriusToo bad the HoloLens probably won't be quite portable though.
Why do you say that? They said that it's fully self-contained and doesn't need to be tethered to any other device. It has its own onboard CPU and GPU, unlike the Oculus Rift.
I think he was referring to, like, wearing the HoloLens down the street. It doesn't really look like it's suitable for that yet - it's big and clunky, and I'm not sure what the battery life is like - but I'm sure that'll be one of the first things they start working on after the initial release.
Sorry, should have been more explicit there. I meant exactly this.
HoloLens Games
I find the HoloLens to be rather intriguing myself, and wanted to take a look into an SDK involving it when they first presented (which didn't seem possible back then as it was limited to people from the U.S.).
I'm wondering how much knowledge you need to bring along in terms of computer vision to be able to make anything reasonable. Personally, I'm more excited about non game stuff you can make with this though, like scientific data visualization, but I'm also fascinated by what this can do for games.
Too bad the HoloLens probably won't be quite portable though. Still waiting for the day where Augmented Reality glasses will provide a reasonable opportunity to make real life into an mmorpg, where your gear is drawn on top of your actual clothes, and where you can somewhat duel each other in the real world.
I'm wondering how much knowledge you need to bring along in terms of computer vision to be able to make anything reasonable. Personally, I'm more excited about non game stuff you can make with this though, like scientific data visualization, but I'm also fascinated by what this can do for games.
Too bad the HoloLens probably won't be quite portable though. Still waiting for the day where Augmented Reality glasses will provide a reasonable opportunity to make real life into an mmorpg, where your gear is drawn on top of your actual clothes, and where you can somewhat duel each other in the real world.
The "new" RM2k3 engine
author=kory_toombs
Actually RMN shouldn't be supporting the pirated version of RPG Maker 2003 anymore. There's no excuse now. Allow old games to stay, but don't allow any new one's on here.
Banning new games made in tsuk3 because of it's illegality would be a bit like banning every game which use graphic rips or any music or sound effect which is neither your own nor public domain. These are also technically not legal, even if the game is non commercial.
For hobbyists, who aren't striving towards becoming actual game maker, and who might only bring along one unique trait (writing / coding / graphics...), I'd argue there's reason to be more lenient as long as they don't claim whatever they borrow is their own, while still getting to enjoy making games.
For the same reason, I see no problem in people still getting to upload games made in the old pirated version to the site. If rips of any kind can be tolerated, despite being technically illegal regardless of the nature of the game, one should be able to cut some slack to the tsuk3 as well.
There's enough key differences between the old and the new version still (patches, plugin support), to give reasons to stay with the old one if you're not planning to go commercial or anything anyway.
Also, if there's gonna be a competition with newer makers being allowed but with scripting restriction, I assume that will also mean a patch / plugin restriction on the tsuk3 side as well
Games - Tester
Games - Other
