I never said your program was bad, just that I thought I could find a better way. In normal mode it scrolls at the same exact speed, the grey while scrolling is just a bit crappier.

I'll post up the source later so you guys can check it out.

Buff(768)->GDB1, or something like that.

Hey guys,
After reading through his source, I thought that the way kindermoumoute accessed the data was roundabout and not that fast or efficient, so I tried making my own. Tell me if we should keep it or not ^^



It does, however, use the same item identification system as kinder's menu does.
(Also, I haven't put in the sprites for the weapons yet )

kindermoumoute, there are only 4 colors. Saintrunner's doing the best he can. >>

We can map two weapons to one color, the text should differentiate anyways.

Guys are we using 8x8 tiles or 16x16? I need to know soon.

Alrighty, so what you want to do is make a subroutine like this:

Lbl GT
{r2/8*12+(r1/8)+GDB1}
Return

Then input the coordinates on the screen whenever you want to check if it's solid, e.x.

If sub(GT,X,Y)
DelVar "System32"
End

and you should be good to go!

A breakdown of that code:

When you call the subroutine, X gets stored to r1 and Y gets stored to r2. What you're doing is dividing both by 8 (because your tiles are 8x8), then multiplying the Y value by 12 to get the right row, then adding the X value to get the right column (and thus the tile you want.)

Note: This works if tile 0 is empty and tiles 1 and onwards are solid. There are more complicated things you can do (check out BuilderBoy's tile-masking tutorial)

I personally don't see the point of tracking changes; you're going to have to unarchive and archive each map anyways. It might even be harder and take longer to track just the changes, when you could just overwrite the old map with the new one completely.

I'm more concerned about how it generates areas and pieces them together (so you don't have scattered desert in the middle of a forest, etc.)