Keep in mind that this tutorial is written assuming you have read and understood the first two. If not, you'll just be more confused. Ok..so what we're going to do is make a sprite editor to save yourself from the incredible tediousness (is that a word) of DATA statements, as well as making your rpg's far easier to develop. A good sprite editor is INVALUABLE in making an rpg. It should be easy to use, easy to maintain, and easy to upgrade. This tutorial is meant to go tobgue in cheek with the supplement APEDRAW.ZIP so if you don' have it yet, download it and check it out. While the program focuses specifically on how to write the editor, the tutorial will focus on the theory behind it. The code for the program is extremely well commented, and you should be able to figure out alot from that alone.

Now...the good stuff. The previous two tutorials dealt with DATA staments and GET and PUT statments. With this knowledge in mind, there are two types of editors we can make.
1)We can make an editor which stores all the pixels in an array, and then writes the contents of the array to a data file. You can then read the contents from the data file and translate it back into your tile. When I first got into sprite editing, I used this method, but sonn found it to be wasteful, and very tedious.
2)You can program your editor so it BSAVEs your files, which simplifies the program, and rids you of dealing with arrays. This method is far superior to the first in terms of implementation and ease of use.
By now, I hope you can see the usefulness of BSAVE/BLOAD. These two functions make our life much easier.

For an editor then, all you need to do is draw your picture, and then BSAVE it. This can be accomplished several ways, but the easiest is to have a big grid (I call them zoom grids) and have the user work within the grid, and have a preview of the actual tile (from now on refered to as the real tile) somewhere else on the screen. The tricky part is getting what you draw on the grid onto the tile. Basically what you need to do is have two different parts to your procedure that actually plots the graphics, (I hope this isn't getting to wordy, I'm trying to keep it as readable as possible) one which will plot onto your zoom grid, and one which will plot onto your real tile. Since the image you save is determined by your real tile, it is important to make sure it is accurate! An easy way to accomplish this is to have two different sets of variables, one which keeps track of the cursor on your zoom grid, and one invisble one which keeps track of your real tile. Now because your zoom grid and real tile are at different ratios (when you move in a given direction, you only move one pixel on your real tile, however you move 8 on your zoom grid) when you're keeping track of your variables, be sure to take this into account. for example...

'code to move cursor for both zoom grid and real tile
'in this case we'll say that you're moving the cursor one increment to the right

zoomgridx = zoomgridx + 8
realx = realx + 1

We do it this way because your zoom grid is just an enlarged picture of your real tile, and one pixel on your real tile is 8 pixels on your zoom grid (hope this makes sense...it is alot easier to see in practice.) Well...that said you'll need to save your file, and this is the cool part about using BSAVE, you rid yourself of arrays. If you correctly plotted your pixels on your real tile, all you have to do is GET that tile and BSAVE it! That's it! Then your tile is all saved and ready to be used in some other program. Now we'll look at a program which has gets a tile off the screen and BSAVEs it. In this program , we'll say that the user has configured his editor so that the zoom grid is on the left of the screen, and the real tile (which is the one you want to grab and BSAVE) is on the right somewhere. We'll say it's a 16x16 tile, with starting coordinates (250,100) and ending coordinates (266, 116). So to grab this tile and save it, we would just do this..

DIM Tile(129)

GET (250, 100)-(266, 166), tile

DEF SEG = VARSEG(tile(0))
BSAVE "anyname.bas", VARPTR(tile(0)), 404

When you look at it this way, the possibilites are endless. If you want to make a mask, all you have to do is load up your tile, alter the real tile so that it's configured for masking (see tutorial #2) and then resave it. Another useful application (and one that I implemented in a later version of ApeDraw) is the ability to lighten and darken a tile. Once you get into palette manipulation (I'll try to get a palette tutorial up sometime soon) you can configure your palette so it's in a logical order, and then if you want to lighten your tile, you can just use POINT and go through and add 2 to every color, making your whole tile lighter! This is very helpful for RPGs, where you want to have a tile next to a wall slightly darker then the rest of those same tiles.

In conlusion, I hope I've shed at least some light on the process of making a good tile editor. If all is not clear, hopefully once you see apedraw.bas in action you'll understand what I'm talking about. A good tile editor is a powerful tool, and one that is essential in the creation of any good rpg. Just ask Me, Interaci (author of relics) Tsugumo (author of the game) or anyone else who is developing a halfway decent rpg.