Math for slow image zoom

Question

I have an .bmp image with a comic book layout. Currently my code works like this. If I right click and hold down mouse button i can draw a marquee type box around one of the

Answer 1

I'm actually working with Glen on this project. I wrote some of the code in question so I would like to clarify what it does. I left comments out of it because I quickly threw it together. Most of the code here is used via an open license that we found. The code originally did not have the loops:

if (x - startx < y - starty) then
       begin
         while (x - startx < y - starty) do
         begin
            x := x + 100;
            startx := startx - 100;
         end;
       end
       else if (x - startx > y - starty) then
       begin
          while (x - startx > y - starty) do
          begin
              y := y + 100;
              starty := starty - 100;
          end;
       end;

This is what I added, and it was added because the original code was not working the way we thought it would work. Basically you select the area via drag and drop. The selected area gets zoomed in on, but instead of showing the full area selected, it fits the smaller of either x-startx or y-starty to the view area. So, to try and clarify that, if you have an area selected that is 50pix high and 100pix wide, it will zoom and fit the 50pix top to bottom filling the view area, but the 100 pix get clipped. The sides fall off the viewing area. So the code that was added here is to fix the problem by making what was the smaller of the two the larger of the two. By doing this it actually will fit the view to what was the original larger of the two which is now the smaller of the two. It's an incredibly sloppy fix, but it works. Your method would also fix this issue for us as well and might do so in a nicer manner. The big issue with it all is that if the area is a very larger area slected, then 200pix might not actually be enought to fix the difference. For our purposes it might work for 85%+, but not all of it, so this code still needs work.

The other code you question is actually what was driving us nuts before. There is an utter lack of comments throughout the entire document and we're still trying to piece together exactly what it all means. The coef is actually what is driving me mad. I'm not even entirely sure what it is meant to do in the first place. I did try a seperate coefx and coefy and that actually breaks it. The zoom box is far different than it was suppose to be. As far as I can tell the current method adds no odd stretching, as to why I am unsure.

Here's a link to the code we're using though if you would like to take a look at it on a full scale. http://www.torry.net/authorsmore.php?id=986 Zimage on that page.

As for the actual question at hand, we're not clear on exactly what coef does in the first place, so making changes to it is resulting in us just breaking things and not working in a trial and error manner. If you wouldn't mind taking a look at it for us to figure out exactly what it does that would get us on to being able to change it to the correct values, and get rid of my slop code in the process. Which would then allow us to move forward into the zoom animation.

To add another question about the animation. In doing so, would this also allow us to add an animation when moving from one zoom point on an image to another zoom point. For our application it will be from one comic panel to another, either below or to the side, and in most cases a different size as well. Would loading inbetween values for left, right, top and bottom be the best way to show that type of animation? If so I think that would also work in moving from full image to first zoomed panel as well.