Zoom box movement in autokey files
Hi... Not that it matters much, since fractint's autokey feature doesn't seem to be used by many: When playing an autokey file that was created for version 19.x and earlier, panning the zoom box now moves it too far, resulting in a much different image than was intended. This can be checked using demo.bat, demo.par and basic.key from the autokey files created for version 19.x and still part of the fractint distribution, choosing "Basic commands demo". (Not to forget: One has to change line 25 in basic.key from "DOWN * 2" to "DOWN * 4" to adapt it to the additional two prompts on the <x> screen introduced in, I think, fractint 20.1.) Regards, Gerald
On Sunday 09 November 2003 02:24 am, Gerald K. Dobiasovsky wrote:
Not that it matters much, since fractint's autokey feature doesn't seem to be used by many:
When playing an autokey file that was created for version 19.x and earlier, panning the zoom box now moves it too far, resulting in a much different image than was intended.
That got changed in the last patch because of the virtual screen addition. Thanks for letting us know about it. Jonathan
Jonathan Osuch wrote:
That got changed in the last patch because of the virtual screen addition.
Moving the zoom box around in both Fractint 19.6 and 20.2p5, it looks like the stepsize for fast panning (CTRL + Arrowkeys) has been increased somewhat... Since this is not a bug, how about modifying the .key files in the official Fractint distro instead? Since this doesn't require a programmer, I could try to do that... Regards, Gerald
Gerald wrote:
Not that it matters much, since fractint's autokey feature doesn't seem to be used by many:
Actually, it's an invaluable feature that can be used for many purposes like demos and debugging.
When playing an autokey file that was created for version 19.x and earlier, panning the zoom box now moves it too far, resulting in a much different image than was intended.
Understand that the autokey feature works by directly trapping user interface keystrokes. If the user interface changes, old autokey filews won't necessarily work. There are things the developers can do to minimize this, by adding new menu items to the bottom of menus, etc. It is desireably to not make changes that would break compatability with old autokey files. But fundamentally autokey files are designed to work with the version that created them. If autokey files were procedural instead of just trapping keystrokes, the situatrion would be different. That would be better, but would require a big redesign. We do need to check to make sure that the new virtual screen logic uses the standard fractint keyboard input routine. Tim
This can be checked using demo.bat, demo.par and basic.key from the autokey files created for version 19.x and still part of the fractint distribution, choosing "Basic commands demo". (Not to forget: One has to change line 25 in basic.key from "DOWN * 2" to "DOWN * 4" to adapt it to the additional two prompts on the <x> screen introduced in, I think, fractint 20.1.)
Regards, Gerald
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
On Sunday 09 November 2003 04:14 pm, Tim Wegner wrote:
We do need to check to make sure that the new virtual screen logic uses the standard fractint keyboard input routine.
The problem is that the panning/zooming distance was changed from 5 to 8 to maintain the starting position of the screen image on a byte boundary. Jonathan
gerald wrote:
I wouldn't have bothered you if it hadn't been for the demo files supplied with Fractint - new users would expect these to work.
thanx, er.. i should be blamed for that.. jonathan wrote:
The problem is that the panning/zooming distance was changed from 5 to 8 to maintain the starting position of the screen image on a byte boundary.
the distance could be set to 5 or 8, depending on an autokey flag, if there's any.. but, new autokey files recorded would require it to be 8 anyway.. so i can see no other way than updating those demo files.. charlie ____________________________________________________________ PC DEXX za 16.990 s DPH! Athlon XP 2200+, CDRW, 80G, 17" monitor. Poslední levný nákup před Vánoci! http://ad2.seznam.cz/redir.cgi?instance=65270%26url=http://www.dexx.cz/frame...
Charlie Chernohorsky wrote: gerald wrote:
I wouldn't have bothered you if it hadn't been for the demo files supplied with Fractint - new users would expect these to work.
thanx, er.. i should be blamed for that..
Come on, the virtual screen feature you brought to Fractint is really worth the small hassle of going through the demo files and correcting for the new zoom box fast-panning stepsize! BTW, doing exactly that, I found a few instances were the demo was broken because of user menu changes - so bringing the files up to date had to be done anyway. To Tim Wegner and/or Jonathan Osuch: I've updated the .bat and .key files of the demo where necessary. Now where to send the diff and by what method? Would an e-mail plus attachment to one of you be ok in that particular case? (Zipped the diff is about 1300 bytes.) Regards, Gerald
would anybody care about HPGL output for L-systems? (not that strange rasterized thing it does nowadays) i would use a smallest possible subset of HPGL to keep compatibility, targeting HP LaserJet printers - they can run a plotter simulation mode.. that piece of code is simple, but integration will be somewhat tricky.. so i need to know, whether anybody will take a use of it? thanx, charlie ____________________________________________________________ NOKIA 3100 již od 2977 Kč. Dost dobrý důvod dát svému starému telefonu kopačky! www.oskar.cz http://ad2.seznam.cz/redir.cgi?instance=64997%26url=http://www.oskarmobil.cz...
Charlie Chernohorsky wrote:
would anybody care about HPGL output for L-systems? (not that strange rasterized thing it does nowadays)
<delurk> Hi Charlie I've got a version here that outputs DXF files from the lsystem engine, adding HPGL should be fairly easy too with this patch as a start. Hmmm.. the attached patch is hopefully just the relevant parts of what appears to be the last dif I took.. sorry but I need to reinstate my fractint dev environment before I can test it but you should be able to spot where to hook in (I just used a debug value for simplicity here) Hope this helps, Robin.
hi robin, i took a look at your dxf patch - that use of a debug flag bypasses what i called to be tricky integration.. that's just what is left undone: you have an l-system already drawn, and THEN the user asks for action: [s] save as dxf / [p] print as hpgl what would you do then? you need to recalc the whole l-system! as it is too large to keep it in memory and once drawn, you have no coords info any ideas? charlie ____________________________________________________________ PC DEXX za 16.990 s DPH! Athlon XP 2200+, CDRW, 80G, 17" monitor. Poslední levný nákup před Vánoci! http://ad2.seznam.cz/redir.cgi?instance=65270%26url=http://www.dexx.cz/frame...
hi robin again,
sorry but I need to reinstate my fractint dev environment before I can test it but you should be able to spot where to hook in (I just used a debug value for simplicity here)
Robin.
i take back what i've said about on-demand-dxf-output.. -- command-line and prompt-screen switch is good enough since the same technique was used elsewhere in fractint so if you have finished your testing and you are not using a debug value anymore, then you should post it to jonathan.. i've run into some aspect-ratio problems with HPGL, first i need to add a paper-aspect-ratio setting.. so i'm not ready to merge with your changes now.. and there is one more problem with l-systems: using a virtual screen, the image is stretched to fit the whole screen (another aspect-ratio problem) this might affect the dxf output as well.. take a look at it, please charlie ____________________________________________________________ Licitovat nejvyhodnejsi nabídku je postavene na hlavu! Skoda Octavia nyni se zvyhodnenim az 90.000 Kc! http://ad2.seznam.cz/redir.cgi?instance=69100%26url=http://www.skoda-auto.cz...
On Monday 10 November 2003 11:38 pm, Gerald K. Dobiasovsky wrote:
I've updated the .bat and .key files of the demo where necessary. Now where to send the diff and by what method? Would an e-mail plus attachment to one of you be ok in that particular case? (Zipped the diff is about 1300 bytes.)
Yes, an email attachment would be fine. If you send it to both of us it is less likely to get forgotten in the next official release. Thanks. Jonathan
Tim Wegner wrote:
Actually, it's an invaluable feature that can be used for many purposes like demos and debugging.
I didn't mean to belittle this feature in any way, in fact it's quite nifty.
Understand that the autokey feature works by directly trapping user interface keystrokes. If the user interface changes, old autokey filews won't necessarily work. There are things the developers can do to minimize this, by adding new menu items to the bottom of menus, etc. It is desireably to not make changes that would break compatability with old autokey files. But fundamentally autokey files are designed to work with the version that created them. If autokey files were procedural instead of just trapping keystrokes, the situatrion would be different. That would be better, but would require a big redesign.
Yes, the Fractint docs are quite clear about the possible "limited lifetime" of an autokey file, so one using them has to expect to have to do some modifying of scripts from time to time. Menu changes are not hard to compensate for, if possibly a bit tedious finding the right places in the files. But things like the zoom box behaving differently require much more fiddling to get the same result as before the change. I wouldn't have bothered you if it hadn't been for the demo files supplied with Fractint - new users would expect these to work. Regards, Gerald
We do need to check to make sure that the new virtual screen logic uses the standard fractint keyboard input routine.
Gerald wrote:
I didn't mean to belittle this feature in any way, in fact it's quite nifty.
No, I didn't take it as belittling, your comments were quite welcome, thanks!
Yes, the Fractint docs are quite clear about the possible "limited lifetime" of an autokey file, so one using them has to expect to have to do some modifying of scripts from time to time.
But of course we try not to mess up the autokey feature if we can avoid it.
I wouldn't have bothered you if it hadn't been for the demo files supplied with Fractint - new users would expect these to work.
Yes indeed. Tim
participants (5)
-
Charlie Chernohorsky -
comdotatdotcom＠csi.com -
Gerald K. Dobiasovsky -
Jonathan Osuch -
Tim Wegner