does it have anything to do with my scrollbar event handler? or is it on your end?

Based on what your handler does, I tend to think it's an issue on my end.

I was guessing that, but wasn't sure

I'll try to spend a few minutes on it tonight, but I can't promise anything.

k, its not really critical yet, but once I start the mapper, I will definitely need working scrollbars

By the way, are you aware that your current method of updating the Level text will not update it onscreen? You have to use GUIFindFirst and GUIFindNext calls to update the actual data in the GUIStack.

yeah, Im aware of that, I just wasn't when I initially wrote the code, then immediately though of it a second l8r. I also need a slightly more prettiful way of displaying the level.

kk. If you just use the gui search tools to update during the scrollbar event handler, it will update the level text when the scrollbar scrolls.

I know, but I meant the text is currently going to be an ascii character 1-15.....

I want to make it actually display 01-15

Here's a routine that displays the number in a:

Code:
Is that what you were looking for?

thanks for doing that, but it isn't cause Im not using _vputs, Im using a GUIRText item in the GUI stack

Is there some way to copy a null-terminated string from op3 to the GUIRText item? If so, then leave off the _vputs and do that.

oh snap, thats way easier

anyway back on the topic of Strategic Conquest, the only thing Im worried about atm is the amount of data the map takes up, if I fix the map size it would total 2304 bytes, if I allow variable map sizes it could take up to 4068 bytes.

so should I fix map size at 96*64 tiles, or allow switching between 64*48, 96*64 and 128*64 tiles? keep in mind this is just for the map itself and doesn't include any of the pieces, which take up 8 bytes each

You should use bitcompression if you limit it to, say, 16 types of tiles per map instead of 256. And I think a pair of bytes at the beginning of the mapdata indicating width and height would be a good idea.

dude, its 2 types of tiles, land or water for the master map and explorerd/unexplored for the 2 player maps

That would be 768 bytes for a 96*64 tile map, then, wouldn't it? (96*64)/8...

times 3 since theres 3sets of data: the master map and one for each player

Ah, fair enough. I didn't realize you had already taken that into account. I was initially under the impression that you would allow any of several different types of tiles for variety.

perhaps I should explain there a 2 tiletypes and a bunch of different pieces (thats what all the ripped sprites are for) representing different types of military vehicles

The data for the pieces is compressed into the smallest possible number of bytes, and it