Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
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
+++ DynRPG - The RM2k3 Plugin SDK +++
Even if you're using indexed colours, you may only use colours from a 16 bit colour palette for it to be valid in rm2k3.
If you're doubting the loadFromFile method itself, just try to make it load some of the RTP images from the RTP folder. If this works, then you're probably just messing up your own image somehow
If you're doubting the loadFromFile method itself, just try to make it load some of the RTP images from the RTP folder. If this works, then you're probably just messing up your own image somehow
Introduction to pixel movement in rm2k3
Ah, mixed up a bit with something else I once made.
Just checked the project and yes, you're right, there's no End ID.
There's just Event Start ID, which determines which events you'll be able to interact with by walking on them, and the Obstacle Start ID which gives the events which should not be passable.
So you'll need to set the obstacle id one instead, and all events with same or higher id will then become unpassable
Just checked the project and yes, you're right, there's no End ID.
There's just Event Start ID, which determines which events you'll be able to interact with by walking on them, and the Obstacle Start ID which gives the events which should not be passable.
So you'll need to set the obstacle id one instead, and all events with same or higher id will then become unpassable
Introduction to pixel movement in rm2k3
in some autostart event. They only need to be set once per map, and they will depend on the events you're using for that particular map.
As for the lower layer tile, you'd just have to copy the passable tile so that you have two of the same tile, one which you make passable, and one which you make not.
Alternatively just use some other tile below those the upper tiles which should be unpassable
As for the lower layer tile, you'd just have to copy the passable tile so that you have two of the same tile, one which you make passable, and one which you make not.
Alternatively just use some other tile below those the upper tiles which should be unpassable
Introduction to pixel movement in rm2k3
For upper layer... nope :x
You'd just have to make some lower layer tile below it be unpassable or so.
As for events, you might have forgotten to set the variables "Event Start ID" and Event End ID".
You have to ensure that all the events which are supposed to be unpassable make a consecutive sequence of event ID's, and then set the lowest ID of the sequence to the start ID and the highest to the End ID.
This is because you might not want all events to be unpassable, and they need to make a consecutive sequence for it to reasonable easy and not be too big a load in terms of executing the event (bad event code will quickly lead to lag).
You'd just have to make some lower layer tile below it be unpassable or so.
As for events, you might have forgotten to set the variables "Event Start ID" and Event End ID".
You have to ensure that all the events which are supposed to be unpassable make a consecutive sequence of event ID's, and then set the lowest ID of the sequence to the start ID and the highest to the End ID.
This is because you might not want all events to be unpassable, and they need to make a consecutive sequence for it to reasonable easy and not be too big a load in terms of executing the event (bad event code will quickly lead to lag).
Introduction to pixel movement in rm2k3
unpassable tiles should be given terrain ID 4 if the code from the collision event is pretty much the same.
The branch checking the variable where the terrain ID is stored after the get terrain id command, is the one which decides what value the tiles should have.
A value which can be switched to your liking, and also good for expanding if you want different behaviour for other kinds of tiles (ice floor, floor which slows you down, etc.), by simply adding more branches. That can of course come later though, as this could also quickly complicate things a bit further
The branch checking the variable where the terrain ID is stored after the get terrain id command, is the one which decides what value the tiles should have.
A value which can be switched to your liking, and also good for expanding if you want different behaviour for other kinds of tiles (ice floor, floor which slows you down, etc.), by simply adding more branches. That can of course come later though, as this could also quickly complicate things a bit further
Introduction to pixel movement in rm2k3
Have you remembered to set the terrain ID's in the chipset you're using?
This must be done, otherwise the code won't be able to tell passable tiles from unpassable tiles
This must be done, otherwise the code won't be able to tell passable tiles from unpassable tiles
Introduction to pixel movement in rm2k3
The picture itself might be 24x32, but the sprite surely isn't. Also, like the typical chars, you want the head to walk into the obstacles somewhat, to give the impression that the hero is standing. If you went to the actual corners, you'd have lots of space between the sprite and the wall.
As long as you don't change the division by 16, you can play around a bit with the subtraction and addition and alter the values to get an idea of how it works.
As long as you don't change the division by 16, you can play around a bit with the subtraction and addition and alter the values to get an idea of how it works.
Introduction to pixel movement in rm2k3
The addision and subtracting comes before the division by 16.
As said, the pixel coordinates of your hero sprite is somewhere inside the picture, but you need to use coordinates to move the picture as well as check if there are obstacles, and you can only check for obstacles at the coordinates you specify.
If you leave the coordinates as normal, you'd walk halfway into an obstacle because the coordinates are inside the picture. This is why you subtract and add from these coordinates.
Since the coordinates of your sprite is always the same relative to the sprite picture, the corners will also always be the same relative to those coordinates.
Meaning the lower left corner will always be 7 pixels to the left and 15 pixels down of the coordinates of the sprite (-7 in x direction and +15 in y direction).
However, we want to use get event ID and get terrain ID for collision checking, and to do that, we need tile coordinates, not pixel coordinates / screen relative coordinates. This is why we divide by 16. Since every tile is 16x16 pixels big, we can get the tile coordinates this way.
the screen relative coordinates 160,120 (middle of the screen), would then be 10,7 in tile coordinates on a 20x15 map (This gets slightly different for bigger maps). With this, we're then able to use get terrain and event ID, which makes checking for obstacles lot easier
As said, the pixel coordinates of your hero sprite is somewhere inside the picture, but you need to use coordinates to move the picture as well as check if there are obstacles, and you can only check for obstacles at the coordinates you specify.
If you leave the coordinates as normal, you'd walk halfway into an obstacle because the coordinates are inside the picture. This is why you subtract and add from these coordinates.
Since the coordinates of your sprite is always the same relative to the sprite picture, the corners will also always be the same relative to those coordinates.
Meaning the lower left corner will always be 7 pixels to the left and 15 pixels down of the coordinates of the sprite (-7 in x direction and +15 in y direction).
However, we want to use get event ID and get terrain ID for collision checking, and to do that, we need tile coordinates, not pixel coordinates / screen relative coordinates. This is why we divide by 16. Since every tile is 16x16 pixels big, we can get the tile coordinates this way.
the screen relative coordinates 160,120 (middle of the screen), would then be 10,7 in tile coordinates on a 20x15 map (This gets slightly different for bigger maps). With this, we're then able to use get terrain and event ID, which makes checking for obstacles lot easier
Introduction to pixel movement in rm2k3
Not sure where the problem is, so I'll do a potentially unnecessary detailed explanation.
From Basic Mathematics, you might remember that graphs typically have x and y coordinates, with x growing in the right direction, and decreasing to the left, while y increases upwards and decreases downwards.
It's similar for most computer related scenarios, except that y increases downwards and decreases upwards.
Now, Imagine that the sprite we're using have a collision field looking like a filled square. If this square touches any obstacle, it should not be able to move further in the direction of the obstacle. However, the coordinates we typically operate with to move the sprite, is only a single pixel inside that this square, so what we do, is that we take the coordinate of this pixel, the subtract or add from the x and y coordinates, so that the position of the pixel now is at one of the corners of the square. We then convert this set of pixel coordinates to tile coordinates, so that we can get the terrain and potential event ID from this tile to check if there's an obstacle there.
However, if we only check at one corner, for example the top left, then if we'd stay slightly to left of an obstacle above, but still so that we'd hit the obstacle while trying to move up, we'd walk straight into the obstacle, and that's why we need to check at both corners. The next corner can be found simply by adding at to the previous corner once it has been checked, since the check has already been done. For very large sprites, you would even have to check somewhere inbetween the corners, since the tiles only span 16 pixels, and we have to check all tiles in the direction we're heading (meaning, corners can at max be 16 pixels apart)
From Basic Mathematics, you might remember that graphs typically have x and y coordinates, with x growing in the right direction, and decreasing to the left, while y increases upwards and decreases downwards.
It's similar for most computer related scenarios, except that y increases downwards and decreases upwards.
Now, Imagine that the sprite we're using have a collision field looking like a filled square. If this square touches any obstacle, it should not be able to move further in the direction of the obstacle. However, the coordinates we typically operate with to move the sprite, is only a single pixel inside that this square, so what we do, is that we take the coordinate of this pixel, the subtract or add from the x and y coordinates, so that the position of the pixel now is at one of the corners of the square. We then convert this set of pixel coordinates to tile coordinates, so that we can get the terrain and potential event ID from this tile to check if there's an obstacle there.
However, if we only check at one corner, for example the top left, then if we'd stay slightly to left of an obstacle above, but still so that we'd hit the obstacle while trying to move up, we'd walk straight into the obstacle, and that's why we need to check at both corners. The next corner can be found simply by adding at to the previous corner once it has been checked, since the check has already been done. For very large sprites, you would even have to check somewhere inbetween the corners, since the tiles only span 16 pixels, and we have to check all tiles in the direction we're heading (meaning, corners can at max be 16 pixels apart)
Introduction to pixel movement in rm2k3
Thank you for these points. Ought to tell me the stuff which needs to be fixed up, so that it will be easier to understand.
The other pages in the collision event correspond to the other directions.
Basically, this system only checks if there is a collision in the direction you're walking. So while you need to subtract from y to check if there's and obstacle above, you'll have to add to y to see if there's an obstacle below.
Same apply for left and right, just with the x coordinates.
Notice that there should be two sets of coordinates as well. when facing up, you'll subtract and add to the x coordinate to get the upper left and upper right coordinates for detecting an obstacle.
If you look at the event, you'll get an idea of which coordinates to use. These could of course vary, depending on the size of your sprite.
The other pages in the collision event correspond to the other directions.
Basically, this system only checks if there is a collision in the direction you're walking. So while you need to subtract from y to check if there's and obstacle above, you'll have to add to y to see if there's an obstacle below.
Same apply for left and right, just with the x coordinates.
Notice that there should be two sets of coordinates as well. when facing up, you'll subtract and add to the x coordinate to get the upper left and upper right coordinates for detecting an obstacle.
If you look at the event, you'll get an idea of which coordinates to use. These could of course vary, depending on the size of your sprite.
Games - Tester
Games - Other
