There are several ways. You can use masking within a pixel to indicate collision or interactable areas, like megadan says.

For the collision issue, you can also solve it using math, in order to figure figure out all kinds of things apart from just "is this tile full-on collision?".

You might have a tile which is flagged as "collision starting from bottom left, going upwards in a 45 degree angle to the right". The actual collision for the tile's pixels can then be determined by a simple linear formula: mx + b, with m being the slope and b being the start offset.

You might also then have collision which is only checked if the player is below (or above, or from the left/right), which would allow you to pass through the collision in some directions. Collision does not need to be "nothing can ever penetrate this square tile" -- although it can be. It depends on what you need/want.

In both cases, you need to do more checking that just on a tile level. You'll want to store and check a more finely detailed position.

Out of curiosity, how are you implementing collision now? I think the easiest answer will depend on that. It could be as simple as just increasing a value on your collision detection, or require you to re-think how you're currently implementing it. If you're simply just saying, "if tile = X type of tile, don't move," then probably the easiest solution would be to make your diagonally textured tiles the same "type" as your road tiles and only return a collision on tiles that are 100% forest. But, again, this really all depends on how you're currently doing things.

I haven't used rpgmaker though, so perhaps the collision detection doesn't allow for much programming wiggle-room. Are you able to define what constitutes a road tile?

From what I've seen, a lot of developers these days just use the overkill method of a full-on 3D physics engine, simply because the tools are available, cheap or free, and high quality, and gaming devices are powerful enough to run basic avatar collision with ease. For a while there weren't many non-custom options that were specifically for 2D, so 3D physics engines were used with various constraints to make them behave more or less in 2D space. Fortunately there are now more options for natively 2D engines, such as Box2D or Chipmunk.

So if using the above strategy, in your case you'd just end up defining a basic collision shape that was close enough to the visual representation to work for each terrain tile image you use, another collision shape for your avatar (a circle might even be sufficient), and then just let the physics engine do the rest of the work for you. It might seem heavy-handed, but it can save a ton of development time, makes certain feature easy that you might not have even considered beforehand, and the CPU itself is barely even gonna notice in most cases.

There's lots of ways to handle finer-grained collision --

One simple way is is to not have just one Boolean 'collidable' flag for the tile, but multiple flags. For example, you could have 4 flags that correspond to "can I move through this tile moving from left to right?", "...from right to left?", "... from top to bottom?", "...from bottom to top?". Or, 8 flags corresponding to "can I enter this tile from the top, bottom, left, and right? Can I leave this tile heading up, down, left, and right?" Or, have 16 flags that correspond to positions in a 4x4 grid that sub-divide the tile into collidable units. Sometimes people treat those 16 flags as a kind of 'code-word' that identifies a somewhat smoother collision segment (basically, connect the points of diagonally-adjacent collidable units, because no one wants to get eaten by a grue because they got caught on some non-obvious protrusion of the collision segments. FYI, in case its non-obvious, you probably want to encode these multiple-flags into one larger value, as having many separate Boolean's is wasteful and will blow out your cache for no good reason.

Another approach is to have a "collision mask" which is just an image equal in size to the tile where certain color values mean that the corresponding pixel in the tile is either passible or non-passible, using a single bit per pixel, or using 4/8 bits per pixel to implement the 4/8 flag schemes described above.

You can also mix and match them all -- only using the more details and more-expensive kinds of collision where you actually need it. The majority of tiles, I'd wager 80% or so, are fully passable or fully blocked and so don't need anything more than a simple boolean.