tim's request: relaxed zoombox scrolling
hi tim, this spring, you talked about not scrolling unless the zoombox touches the edge of the screen (ie. visible part of image) since that would be too ambiguous, i simply made it to scroll when the zoombox center touches the edge of the screen.. i've sent a diff to jonathan.. try it and tell me, please, whether it fulfils your request charlie ____________________________________________________________ Vychází Best of Chinaski-PREMIUM. 21 největších hitů včetně tří novinek- nahlédněte do historie i budoucnosti jedné z nejoblíbenějších kapel současnosti!http://ad2.seznam.cz/redir.cgi?instance=63636%26url=http://www.chinaski.cz
On Tuesday 04 November 2003 10:20 am, Charlie Chernohorsky wrote:
this spring, you talked about not scrolling unless the zoombox touches the edge of the screen (ie. visible part of image)
since that would be too ambiguous, i simply made it to scroll when the zoombox center touches the edge of the screen..
i've sent a diff to jonathan.. try it and tell me, please, whether it fulfils your request
Charlie, Your patch worked fine. One thing I would try to fix is that currently if you scroll the image prior to zooming, the zoom box comes in centered on the image, and not the screen. So, the zoom box could end up off the screen if the virtual image is big enough. I'd also like to see the zoom box starting size be the size of the screen and not the image. That way it would be visible immediately. Besides, how can you tell what the resulting zoom will look like if you can't see it? Both are minor points. Jonathan
jonathan wrote:
One thing I would try to fix is that currently if you scroll the image prior to zooming, the zoom box comes in centered on the image, and not the screen. So, the zoom box could end up off the screen if the virtual image is big enough.
if the virtual image is big enough, and you scroll it before zooming, then it should scroll when you start zooming so that the zoombox _center_ becomes visible, does it not? if that image is not big enough, it doesn't scroll when you start zooming, because the zoombox _center_ is already visible, even if you scroll it to any image corner before zooming.. (sxdots <= 2 * vesa_xres && sydots <= 2 * vesa_yres)
I'd also like to see the zoom box starting size be the size of the screen and not the image. That way it would be visible immediately. Besides, how can you tell what the resulting zoom will look like if you can't see it?
it's simple, just count PG_UPs / PG_DNs :o) well, changing the starting size looks easy, but what should it do when you enlarge zoombox so that it reaches the screen size? stop zooming or wait until it reaches the image size? what about adding a hair-cross to the zoombox center? and maybe that hair-cross should scale along with the zoombox? (though it looks not that easy..) charlie ____________________________________________________________ Nakup ojeteho vozu ... nonstop a v pohode na www.vyzkouseno.cz http://ad2.seznam.cz/redir.cgi?instance=46834%26url=http://www.vyzkouseno.cz
Hi Team, I have decided to delay the development of a WINFRACT application as it is too daunting at present. I am studying MFC (Microsnot Foundation Class) libraries and C++ as a possible way for the future. In the short term however, I am putting a lot of effort into upgrading ManpWIN, my WIN32 bit, true colour program based on the original WINFRACT and my early DOS mandelbrot program MANP. I see this as a parallel development to FRACTINT and I am happy to share sources and ideas wiith the team. The latest executable can always be found at http://www.deleeuw.com.au/download/manpwin.zip I am currently working on ManpWIN being able to interpret script files to develop a series of PNG files for animation. This should be available in a few days. Any comments greatly appreciated. Best regards, Paul de. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ----------------------------------------------------------
Hello, Paul - I had considered implementing a high-performance Windows adaptation of Fractint, but have been too occupied with schoolwork to start something of such a scale. Personally, I would recommend against the use of MFC. I would tend to use raw win32 calls along with the DirectX API to create this project (if we do it, we may as well do it correctly). If you have any source code, even in its most preliminary form, I would be more than glad to look at it, and perform some coding here and there. Tell me what you think! - Greg Toombs --- Paul <pdeleeuw@deleeuw.com.au> wrote:
Hi Team,
I have decided to delay the development of a WINFRACT application as it is too daunting at present. I am studying MFC (Microsnot Foundation Class) libraries and C++ as a possible way for the future. In the short term however, I am putting a lot of effort into upgrading ManpWIN, my WIN32 bit, true colour program based on the original WINFRACT and my early DOS mandelbrot program MANP.
I see this as a parallel development to FRACTINT and I am happy to share sources and ideas wiith the team.
The latest executable can always be found at http://www.deleeuw.com.au/download/manpwin.zip
I am currently working on ManpWIN being able to interpret script files to develop a series of PNG files for animation. This should be available in a few days.
Any comments greatly appreciated.
Best regards,
Paul de.
----------------------------------------------------------
Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562
----------------------------------------------------------
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com
http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
In article <20031106220604.2741.qmail@web41307.mail.yahoo.com>, Greg Toombs <gregtoombs@yahoo.com> writes:
Personally, I would recommend against the use of MFC.
Well, MFC is what it is. Its a fully featured application framework that does lots of the grunt work for you. That is the upside -- it saves you work. The downside is that it is a monolithic class library and if you're in for a penny, you're in for a pound. It feels "heavy" in that even a small MFC program brings in a big bunch of stuff. However, the incremental cost for adding more functionality after you take that first step is small.
I would tend to use raw win32 calls along with the DirectX API to create this project (if we do it, we may as well do it correctly).
DirectX has a place in Fractint. I would -not- recommend using raw Win32 API, however. Its just too much work and doing a major Windows revamp of Fracint is already enough work just by itself. (I know, I've studied the source code and made some efforts in that direction.) If you're going to do anything, you should start with the device abstraction that I introduced into the xfractint code base. It would be easy to start with that and go the DirectX route with a simple text-based UI like fractint already has. This would introduce a minimal amount of fussing with the Win32 API. If you want a "fancy" UI then I would recommend using some sort of UI framework that is native to Windows, such as MFC or WTL. I don't believe in "portable" UI frameworks; it has been my experience that they tend to be lowest common denominator and don't get everything exactly right on any of the platforms on which they work, thus making everything written with them feel just a little odd on every platform. The important point, though, is to start with the device abstraction that I've already introduced into the code. The code base for fractint should migrate into an "engine" portion and a "UI" portion. For the UI portion we should be able to do that in the best way for each platform (i.e. a native windowing toolkit like MFC for Windows, Toolbox for the Mac, etc.), or we could continue on with the stupid text-based UI that fractint has right now. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
I am keen to have a merger of XFractint with its rich parsing and fractal options and ManpWIN with its WIN32, true colour and ability to generate animation frames based on a script file (almost complete). I have found this an arduous task and would appreciate any assistance. ManpWIN is based on 'straight' C and windows API calls and so it 'should' be possible to merge the two. I am very happy to work in a team to get this done. I know nothing about ActiveX so I have avoided it. If anyone wants the source for ManpWIN (It's a bit rough and experimental), let me know your direct email address and I will send it to you. Thanks, Paul de. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ----------------------------------------------------------
participants (6)
-
Charlie Chernohorsky -
Greg Toombs -
Jonathan Osuch -
Paul -
Rich -
Tim Wegner