Paint and a lot of experimentation, and a lot of zooming in/out.

you should look at Digitan's Robot War tileset, which is pretty simple and effective.

also, is it an action RPG or FF style?  because world maps aren't a big deal for FF style RPGs.  Personally, I'd like to see more cool battle animations, like Golden Sun epicness.

if you really want nice looking world maps, you should just draw the map first and see how you can break it down into tiles.  If it's too many, than start simplifying things a bit.

imho, DS dev > GB only because so many people are doing it now so you have a large community to help you out.

edit:

so you're not going to continue LL1?

the scanlines result from the masking pattern.  that is, which pixels are displaying the "light" plane and the "dark" plane.  Because of the way the planes and masks are alternating, you get scan lines.  correct me if I'm wrong.  as a result, there might be very little difference in terms of said scanlines.

vertical is good because the default setting for the LCD port is to do the first 8 pixels and then the 8 pixels below (auto increments via columns).  I'm pretty sure you could change it to match horizontally aligned (normal way of setting up a buffer), but iirc every routine (like text and MOST IMPORTANTLY sprite routines) is defaulted to this set up.  

good choice Iambian!  taking a page right out of crash.

Where are the pictures for this game btw?

Quote from: Iambian on June 08, 2009, 11:44:33 pm

(2) The text routine is being handled by a 4x4 aligned tilemapper. That has been verified to work so I'm filling it with the text needed to render all in-game text. It turns out that all objects are aligned in this manner, so I can have what I like to call a "textmap". The menu borders are being coded in this way, and has already been demonstrated to work.

ASCII map in grey ftw. xD
 Actually, from LL1 I discovered that making a custom font set with menu borders, special symbols (like a hand, sword, bow, etc..) makes things simple and nice.

That was intelligent design on the part of Zera, inspired by looking at the ROMs of games like original FF

it's for double buffering, which offers advantages like artifact reduction and being "smoother"  Keep in mind the active buffers MUST be together.  when the app was originally written, it was realized that 768x2 and some extra bytes were needed straight out of RAM.  RGP is good enough for almost anything you'd normally write.  heck, with a little ingenuity, you can make a game that's looks good and has a lot of action.  but for things like SSB, it's reasonable that tr1p1ea made his own (other than the fact he's a genius). 

I suggest you keep the double buffering unless you really want to allocate plotsscreen and appbackupscreen for other variables. 

blame the LCD controller on all calcs except 86s for not being able to do good gs.  memory mapping would eliminated the port communication that makes gs such a drag.