Right, okay I'll do that. See I had to reset it several times yesterday. I really hope it's not still running from then O_O edit: thanks, Edgar. You hit the nail on the head, I had like 4-5 of them still running. I'm surprised my computer did not die a horrible death. Some of them looked like the processes weren't using much to run though... Anyhow it's working as I intended it to now :) hey you know whats pretty cool when you put two bangs !! its like they're not there

-----------------------------------------------------------------------------------

Okay I need help again.
I got the above to work although I edited commented out some of it's code so I can work on getting a working scrollbar. I am trying to take advantage of a ratio:
full bitmap size / view size
should equal
scroll area / scrollbar

I thought I had the math part right but it's drawing slightly off. It looks fine at first, but when scrolled all the way down the scollbar overlaps the button

I have the function at the very bottom; draw_scrollbar.
Any help would be appreciated.
And sorry if you think the code is messy. I usually do tests like these before cleaning up the code.

I think it's calculating the X wrong, but I think the stretched width is correct.

Heh. I can tell you didn't look at the code
Thanks for helping though. See I haven't tried to get the scrollbar to function yet...I was just getting it to show the view position accurately. The only way to scroll right now is the buttons. Also the view is vertical scrolling, but the scrollbar is horizontal scrolling. Weird I know, but I like the idea. If you do look at the code, the function is on the very bottom.

But why would I need to scale the offset? I'm using stretched blitting so it just has the first x,y and the width and height, which are relative to the first x and y. So if I got the x wrong...the whole thing's wrong.

Do you mean I should permanently separate it or just for the sake of easy aid? What sort of things to people usually separate? I was thinking about getting the bitmap loading into a new file but I didn't really know how I'd do that. I can try to make a new program with the scrollbar code if that's what you want. Thanks. Oh and which variable names aren't descriptive? Some of the vague ones should have comments next to their declarations if that helps. I don't remember having any ridiculous ones though...the worst is that some of them are similar, such as Scrollbar->w and Scrollbar_Width. The first is the length of the bitmap file, the second is the width of the stretched scrollbar.

I separate things that are easily recognized as discrete objects or ideas. In effect, things like widgets, sets of data, data manipulation, generic i/o handlers, etc...

When you asked me about why the scrollbar offset should be scaled, I was talking about the offset of the drawing position of the scrollbar handle in relation to the scrollbar area.

Yes. All you need to do is find the ratios for :
a) The total length of the object being viewed (including the non-visible portion) to the total length of the scrollbar area (not including buttons).

b) The length of the visible portion of the object being viewed to the total length of the viewable object.

The ratio of (a) is your stretch factor in that dimension. The ratio of (b) times the length of the scrollbar area gives you the length of the scrollbar handle.

The scrollbar handle's offset divided by the ratio of (b) gives you the actual size of the viewing object's drawing offset.

It's best to just draw out the design on paper first, and then when you know what you're doing, put it into code. That method helps me finish things anyway.

Well, it would probably help you to make a separate module for your map data and methods, a map class that knows which tiles can be in it and holds an index to a tile list for each position in the map. Another module could be used for your editor. A third module could be for a tileset class, that's used by your map class and your editor class, etc...

Don't use integer division. Convert to doubles and get a double type ratio.

It will get rid of the inaccuracy caused by clipping of the fractional part. Is that the only thing wrong? I don't know, but I can try looking over things more tomorrow.

Store the ratios as a double, use temporary doubles or casts to prevent the integer division.

//
int a = 12 , b = 5;
double atob = double(a)/double(b);// using double constructors
double atob2 = (double)a/(double)b;// using casts to double type

int also_a = int(atob*double(b));// may not actually get exactly 'a' back
                                 // due to floating point inaccuracy
//

Please try to be consistent in your formatting schemes, it makes it a lot easier to read code if you do. (Don't mix tab indentation with space indentation, always indent when there is a new block {})

DevCpp may have a setting to control the number of spaces that a tab press will indent. CodeBlocks certainly does, but if there are tabs in the source code then you have to look at arrows every place there's a tab so I just replace them all with 2 or 3 spaces depending on what I'm coding for.

Things like this (from your last code posting) :

            if (Scrollbar_X_Pos < Scrollbar_X_Offset)
            {
            Scrollbar_X_Pos = Scrollbar_X_Offset; //don't expand past the left button               
            }

If you get in the habit of always doing your formatting consistently, you'll never have to 'clean it up'.

The ratio of a to b and a second method to find the same ratio. Just an example.

Okay, so let's see what your code is now.

It goes too far left because you scale the offset, this should remain the same.

Scrollbar_X_Pos = (double(TestClipT)/ViewRatio)+(double(Scrollbar_X_Offset)/ScrollRatio);
//should be 
Scrollbar_X_Pos = (double(TestClipT)/ViewRatio)+double(Scrollbar_X_Offset);

The ViewRatio should be calulated using ScrollArea.

ViewRatio = (double(TestBuffer->h) / double(TestClipHeight));
//should be
ViewRatio = (double(TestBuffer->h) / double(ScrollArea));

This works correctly for me. It should stay where it is supposed to now.

Ya, sorry about that. I was rapidly changing my post as I figured things out, at the end removing all the unnecessary pieces hoping you hadn't seen yet.:-X
EDIT: Hmm, I changed a lot, let me see what the original was and then I tell you what I was sopposed to change.

It appears as though you only need to change ViewRatio to Scroll Ratio in the width area and change the X position as stated above.

ScrollRatio = (double(TestBuffer->h) / double(ScrollArea)); //original
ViewRatio = (double(TestBuffer->h) / double(TestClipHeight)); //original
Scrollbar_X_Pos = (double(TestClipT)/ViewRatio)+double(Scrollbar_X_Offset); //changed this
Scrollbar_Width = (double(TestClipHeight)/ScrollRatio); //and this

EDIT2: sorry again, I'm changing this too.

Okay this one should work this time:

Scrollbar_X_Pos = (double(TestClipT)/ScrollRatio)+double(Scrollbar_X_Offset);
Scrollbar_Width = (double(TestClipHeight)/ScrollRatio);

The Ratio's are the same as in the original file you posted. The pixel gap is there because ScrollArea is 184 and should be 185 I think.

EDIT: This way seems to continue to work properly when the scroll area is increased.

I guess I don't understand the problem now. Perhaps all my edits got something changed that wasn't supposed to be. Check my binary that's attached and see if it works as desired. If it does I can give you the right source.

Ok, sorry it took so long to reply, I've been watching COPS. The only function I changed is the draw_scrollbar, here is the one I am using:

void draw_scrollbar()
{
    ScrollRatio = (double(TestBuffer->h) / double(ScrollArea));
    ViewRatio = (double(TestBuffer->h) / double(TestClipHeight));
    Scrollbar_X_Pos = (double(TestClipT)/ScrollRatio)+double(Scrollbar_X_Offset);
    Scrollbar_Width = (double(TestClipHeight)/ScrollRatio);

    stretch_sprite(Buffer, Scrollbar, Scrollbar_X_Pos, Scrollbar_Y_Offset, Scrollbar_Width, Scrollbar->h);
};

I have also attached the entire source file if changing that doesn't work.