Jonathan asked:
Any results?
HP-Pavilion with NVIDIA Vanta This works OK with virtual=no, but with virtual=yes, even non-virtual SVGA modes have problems going back to text. Something as simple as SF4 ESC gives a scrambled screen. BTW, it is possible that the virtual feature works, but since it messes up the text screens, I have no way to set it up to try it. I'm inclined to think that the virtual windows parameters should be settable even if the current mode is not a virtual mode. There could be words on the screen to the effect that these parameters only take effect in virtual mode. Dell Optiplex with ATI 3D Rage Pro - virtual screen modes works fine. Sony VAIO laptop with Rage Mobility 1 M AGP - works fine. Old no-name 120 Mhz Pentium with Diamond VIPER V550. Same behavior as HP - OK with virtual=no, scrambled screen otherwise. Summary. ATI video boards are OK, but Nvidia boards have problems. I believe the Diamond viper uses an Nvidia chipset. Since virtual=no works OK, I suggest you release this patch and let our loyal public help tabulate what works and what doesn't. We'll get more feedback that way. Or at least, move the proposed patched version to a public area. Tim
On Monday 24 February 2003 04:54 pm, Tim Wegner wrote:
I'm inclined to think that the virtual windows parameters should be settable even if the current mode is not a virtual mode. There could be words on the screen to the effect that these parameters only take effect in virtual mode.
And, I'm inclined not to do that. The only way a user would know if they could get into a virtual mode is to try it and see what happens. This would lead to many complaints when users try it in the standard svga modes and it doesn't work.
Summary. ATI video boards are OK, but Nvidia boards have problems. I believe the Diamond viper uses an Nvidia chipset.
I know the exact section of code causing the problem (VESAvirtscan). But, I don't know why (probably sxdots and sydots getting changed), and I don't know how to keep the video switch to text mode from getting into that section of code. If you have the time or energy you could put in jumps around sections of code in VESAvirtscan and see if it ever works on the Nvidia boards.
Since virtual=no works OK, I suggest you release this patch and let our loyal public help tabulate what works and what doesn't. We'll get
more feedback that way. Or at least, move the proposed patched version to a public area.
I'd like to release it the way it is just so I can move on. But, since it doesn't quite work, I know that won't happen. I'll take another look at the code. Maybe we can release it this weekend. Jonathan
And, I'm inclined not to do that.
OK. The point was only that I have no way to set the virtual mode parameters since I can't get to the text screen. Maybe viewwindows command line parameters?
I know the exact section of code causing the problem (VESAvirtscan). But, I don't know why (probably sxdots and sydots getting changed), and I don't know how to keep the video switch to text mode from getting into that section of code.
If you have the time or energy you could put in jumps around sections of code in VESAvirtscan and see if it ever works on the Nvidia boards.
Please give me more details on what to try.
I'd like to release it the way it is just so I can move on. But, since it doesn't quite work, I know that won't happen.
Consider at least making your version public so more people can try it. That's not the same as releasing. Tim
I'd like to release it the way it is just so I can move on. But, since it doesn't quite work, I know that won't happen.
Jonathan
Consider at least making your version public so more people can try it. That's not the same as releasing.
Tim
it would be nice..! i feel responsible (..guilty..) for all that mess but i need the version as altered by you to check what i've done wrong.. ad VESAvirtscan: it has a code reuse not quite clean to keep it small maybe an unfolding should be considered.. gratefully yours charlie ______________________________________________________________________ Reklama: Soutez o 10.000,- Kc a jedno z deseti baleni noveho Aquafresh Whitening systemu - pro zarive bile zuby, intenzivne svezi dech a cela Tva usta. http://ad2.seznam.cz/redir.cgi?instance=43403%26url=http://www.icewhitening....
On Monday 24 February 2003 10:14 pm, Tim Wegner wrote:
Consider at least making your version public so more people can try it. That's not the same as releasing.
Okay, I put the file f2002p4a.zip in the experimental directory on the developer's ftp site. This is a DOS executable identified as 20.02.4a and includes the diff file. Jonathan
On Monday 24 February 2003 10:14 pm, Tim Wegner wrote:
If you have the time or energy you could put in jumps around sections of code in VESAvirtscan and see if it ever works on the Nvidia boards.
Please give me more details on what to try.
Try jumping over the following sections (1, 2, 3) of code. This is where I have had the most trouble with my other video card. One of the problems is that just because you can read the value of the scanline length doesn't mean that you can actually set the scanline length. VESAvirtscan proc near xor ax,ax once_again: mov cx,sxdots ; this should be passed twice mov dx,sydots cmp cx,vesa_xres ; asked wider than screen x? jae setvirtscan cmp dx,vesa_yres ; asked higher than screen y? jae setvirtscan jmp wedone ; otherwise do nothing setvirtscan: cmp ax,004fh ; is this second pass? je secondpass (1) jump over next mov ax,4f06h ; VESA fn 6 scanline length mov bx,1 ; subfn 1 get line width int 10h cmp ax,004fh ; did that work? jne bad_vesa ; bad vesa.. try it anyway (2) jump over next mov ax,4f06h ; VESA fn 6 scanline length mov bx,3 ; subfn 3 get max line width int 10h cmp ax,004fh ; did that work? jne bad_vesa ; bad vesa.. try it anyway (3) jump over next mov ax,4f06h mov cx,bx ; get the max width in bytes mov bx,2 ; subfn 2 set width in bytes and cx,0fff8h ; 8 bytes width align int 10h cmp ax,004fh ; did that work? jne bad_vesa ; bad vesa.. try it anyway (4) here cmp sxdots,cx ; max width in pixels in cx jae alreadyset ; can't set more bad_vesa: Jonathan
Re: Virtual video test results (subject is here 'cos i can't get rid of that =?iso-8859-2? thing..) Jonathan (& Tim), that jumps you've suggested to Tim at VESAvirtscan, the destination "(4) here" should be at "bad_vesa", otherwise it would do.. nothing at all, beacuse if (4) here + cmp sxdots,cx ; max width in pixels in cx + jae alreadyset ; can't set more + bad_vesa: then sxdots always equals to cx when skipping the parts above, this cmp is related to the last VESA call, so it should be skipped also like: + cmp sxdots,cx ; max width in pixels in cx + jae alreadyset ; can't set more (4) here + bad_vesa: while looking at the experimental patch 5 diff file: at loadfdos.c, at restoring images, the function which resizes dotmode==28 entries (well, to be honest, i've forgotten its name) - it should also be disabled when virtual=no, like: + /* try to change any VESA entries to fit the loaded image size */ + if (virtual && video_vram && initmode == -1) { then, i've found a mistake at prompts2.c / getviewparams(): instead of: + if truebytes==4 (32 bit) it does &= ..FFFE (&= -2) if (truebytes < 2) + */ + ++truebytes; it should be: + if truebytes==4 (32 bit) it does &= ..FFFE (&= -2) + */ + if (truebytes < 2) + ++truebytes; (i guess it was caused by inserting that truebytes explanation) nothing serious, it just miss-estimates.. finally, using view-window for smaller-than-screen request is ok, but why do you turn off view-window for greater-than-screen? do you think it would have no use then? ( ! if (sxdots < vesa_xres && sydots < vesa_yres) { ! viewwindow = 1; ! viewxdots = sxdots; ! viewydots = sydots; ! sxdots = vesa_xres; ! sydots = vesa_yres; ! } else { ! viewwindow = 0; /* make sure it is off */ ! viewxdots = 0; ! viewydots = 0; ! } ) VESAvirtscan once more: that "mov ax,2" is strange! (so is "mov ax,1" fifteen lines above..) the scroll test should scroll the screen to the [cd; dx] not to the ax.. ax just indicates top-left corner here.. + noretrace: + ;; xor ax,ax + mov ax,2 ; try to move a tad + mov wait_retrace,0 ; don't wait for v. retrace + mov video_startx,ax ; video didn't scroll yet + mov video_starty,ax + call VESAscroll ; try the instant scrolling + cmp ax,004fh ; did this scroll? + je wedone it is also non-serious, but i see no use of it..? charlie ______________________________________________________________________ Reklama: Aktualni zpravy z domova i ze zahranici, krimi, kultura, sport, zpravy ze spolecnosti, vztahy a sex, horoskop a televizni program http://www.novinky.cz
On Monday 03 March 2003 05:31 am, Charlie Chernohorsky wrote:
that jumps you've suggested to Tim at VESAvirtscan, the destination "(4) here" should be at "bad_vesa", otherwise it would do.. nothing at all, beacuse if
(4) here + cmp sxdots,cx ; max width in pixels in cx + jae alreadyset ; can't set more + bad_vesa:
then sxdots always equals to cx when skipping the parts above, this cmp is related to the last VESA call, so it should be skipped also like:
+ cmp sxdots,cx ; max width in pixels in cx + jae alreadyset ; can't set more (4) here + bad_vesa:
Since it is just for testing purposes, it makes no difference. We just need to see if one of these bios calls is causing the problems.
while looking at the experimental patch 5 diff file:
at loadfdos.c, at restoring images, the function which resizes dotmode==28 entries (well, to be honest, i've forgotten its name) - it should also be disabled when virtual=no, like:
+ /* try to change any VESA entries to fit the loaded image size */ + if (virtual && video_vram && initmode == -1) {
I'll fix it. Thanks.
then, i've found a mistake at prompts2.c / getviewparams(): instead of:
+ if truebytes==4 (32 bit) it does &= ..FFFE (&= -2) if (truebytes < 2) + */ + ++truebytes;
it should be:
+ if truebytes==4 (32 bit) it does &= ..FFFE (&= -2) + */ + if (truebytes < 2) + ++truebytes;
(i guess it was caused by inserting that truebytes explanation) nothing serious, it just miss-estimates..
I can increase the number of lines that diff catches on either side of changes. This will increase the diff file size, but the problem should go away.
finally, using view-window for smaller-than-screen request is ok, but why do you turn off view-window for greater-than-screen? do you think it would have no use then?
( ! if (sxdots < vesa_xres && sydots < vesa_yres) { ! viewwindow = 1; ! viewxdots = sxdots; ! viewydots = sydots; ! sxdots = vesa_xres; ! sydots = vesa_yres; ! } else { ! viewwindow = 0; /* make sure it is off */ ! viewxdots = 0; ! viewydots = 0; ! } )
There are problems which occur when the two are used at the same time. For example, using orbits doesn't work quite right (in terms of where they appear). There may be other problems, as well. It is true that if all you are doing is drawing an image, it works fine. At this point, I'd rather it was turned off so that we don't get complaints about it not working right.
VESAvirtscan once more: that "mov ax,2" is strange! (so is "mov ax,1" fifteen lines above..)
the scroll test should scroll the screen to the [cd; dx] not to the ax.. ax just indicates top-left corner here..
+ noretrace: + ;; xor ax,ax + mov ax,2 ; try to move a tad + mov wait_retrace,0 ; don't wait for v. retrace + mov video_startx,ax ; video didn't scroll yet + mov video_starty,ax + call VESAscroll ; try the instant scrolling + cmp ax,004fh ; did this scroll? + je wedone
it is also non-serious, but i see no use of it..?
Yes, indeed! That is strange. But, it is there because of how VESAscroll is coded. If you pass (Xc/2-1,Yc/2-1) (screen center offset divided by 2 then subtract 1) in cx and dx, then subtracting the screen center offset from them returns a negative number. The code then sets cx and dx to (0,0). Then we compare them to video_startx and video_starty, which we set in VESAvirtscan to (0,0). But, since we have zeroes all around, we bail out without calling the bios move screen routine. Not too big a deal, except we are using the return from the bios call to determine success. Since we haven't made the bios call, ax still contains 0, and we fail the test. Therefore, I added a small nudge (which doesn't happen anyway because it is too small) to force the bios call to occur. Let me know if you need more detail. Jonathan
Re: Virtual video test results
then, i've found a mistake at prompts2.c / getviewparams(): instead of... (i guess it was caused by inserting that truebytes explanation) nothing serious, it just miss-estimates..
I can increase the number of lines that diff catches on either side of changes. This will increase the diff file size, but the problem should go away.
really? well, i've thought that if the end-of-comment mark is placed wrong, so it is not caused by diff.. i can think about some cases where increasing line-catch could help, but i don't think that it's this one..
VESAvirtscan once more: that "mov ax,2" is strange! (so is "mov ax,1" fifteen lines above..)
Yes, indeed! That is strange. But, it is there because of how VESAscroll is coded.. ..let me know if you need more detail.
Jonathan
oh what a shame.. no more details, thanks! i didn't think about passing thru this with s*dots equal to vesa_*res but, anyway, it should not ever get there then (as Tim said)..! so, now i can see that small move is reasonable, but something must be wrong if we get there with so small s*dots.. messed up charlie ______________________________________________________________________ Reklama: Novy slovensko-cesky film ve vasich kinech od 13.unora. http://www.falcon.cz
On Tuesday 04 March 2003 04:11 am, Charlie Chernohorsky wrote:
then, i've found a mistake at prompts2.c / getviewparams(): instead of... (i guess it was caused by inserting that truebytes explanation) nothing serious, it just miss-estimates..
I can increase the number of lines that diff catches on either side of changes. This will increase the diff file size, but the problem should go away.
really? well, i've thought that if the end-of-comment mark is placed wrong, so it is not caused by diff.. i can think about some cases where increasing line-catch could help, but i don't think that it's this one..
I'm sorry. You are correct, I mangled the code when I added the comments.
i didn't think about passing thru this with s*dots equal to vesa_*res but, anyway, it should not ever get there then (as Tim said)..!
so, now i can see that small move is reasonable, but something must be wrong if we get there with so small s*dots..
No, there is nothing wrong because normally we don't care about the result that VESAscroll returns in the ax register. Jonathan
Re: [Fractdev] Virtual video test results Jonathan wrote:
i didn't think about passing thru this with s*dots equal to vesa_*res but, anyway, it should not ever get there then (as Tim said)..!
so, now i can see that small move is reasonable, but something must be wrong if we get there with so small s*dots..
No, there is nothing wrong because normally we don't care about the result that VESAscroll returns in the ax register.
Jonathan
not the result.. i meant, why or how do we get to the point where the scrolling is tested when there is no request for a large screen?? (then it would never have got negative coords..! and no "move a tad" would be needed..) what is strange is why it does NOT skip everything up to the "wedone"? it should! (well, maybe i'm the one supposed to answer this..)
ad comments:
;o) charlie ______________________________________________________________________ Reklama: Zahrajte si potrhlé hry a kvízy nebo rozešlete pohlednice plné lásky na Oskarově Festivalu Drahoušků! http://ad2.seznam.cz/redir.cgi?instance=44096%26url=http://www.oskarinteract...
On Thursday 06 March 2003 06:15 am, Charlie Chernohorsky wrote:
not the result.. i meant, why or how do we get to the point where the scrolling is tested when there is no request for a large screen??
(then it would never have got negative coords..! and no "move a tad" would be needed..)
what is strange is why it does NOT skip everything up to the "wedone"? it should! (well, maybe i'm the one supposed to answer this..)
Ah, another good question. Because I didn't want the virtual screen prompts showing up on the viewwindows screen when it was not possible to use a virtual screen, I have the prompt code checking for video_scroll=1. But, the result is that the only way to initially get into the virtual screen checking code occurs when s?dots=vesa_?res. I changed the beginning of VESAvirtscan so that this could happen. A problem also arises because when you switch to a text mode, the bios changes vesa_?res to a value smaller than s?dots. At least some do. Jonathan
Jonathan wrote:
Try jumping over the following sections (1, 2, 3) of code. This is where I have had the most trouble with my other video card. One of the problems is that just because you can read the value of the scanline length doesn't mean that you can actually set the scanline length.
I tried skipping all the blocks, as well as changing bad_vesa to wedone as you suggested in a private email. Nothing helped. I assume that in each case I should put a jmp where one of your numbered "jump obver next" were placed, and place the jmp target before the next numbered spot (just after the jne bad_vesa). Any other requests? Keep in mind that even though I am using virtual=yes, I am not actually trying to use a virtual mode. I'm basically starting fractint thusly: fractint virtual=yes video=sf4 and then pressing ESC. If I understand the virtscan routine (unlikely! :-), I may never be entering the code you wanted me to skip. Aren't sxdots and sydots equal to vesa xres and yres in my case? Apparently not, because if I skip all the way to wedone, everything is OK. Tim
On Monday 03 March 2003 08:00 pm, Tim Wegner wrote:
I tried skipping all the blocks, as well as changing bad_vesa to wedone as you suggested in a private email. Nothing helped.
I assume that in each case I should put a jmp where one of your numbered "jump obver next" were placed, and place the jmp target before the next numbered spot (just after the jne bad_vesa).
Any other requests?
Hmm, the first jump makes no sense, except if you jump from it to wedone, there should be no problems (as confirmed below). If you jump from the second jump to wedone (change 'jne badvesa' to 'jne wedone'), then the first bios call will be tested. I think part of the problem is that even if we fail all the tests, we try to set it anyway. We should bail out if the first test fails. Try these changes at the third and fourth jumps, also.
Keep in mind that even though I am using virtual=yes, I am not actually trying to use a virtual mode. I'm basically starting fractint thusly:
fractint virtual=yes video=sf4
and then pressing ESC. If I understand the virtscan routine (unlikely! :-), I may never be entering the code you wanted me to skip. Aren't sxdots and sydots equal to vesa xres and yres in my case? Apparently not, because if I skip all the way to wedone, everything is OK.
They could be equal (and are when you first start up). But, in a text mode, vesa_xres and vesa_yres could be set to much smaller values. This would cause the code to execute. That is why I've been trying to prevent the call to VESAvirtscan when we switch to text mode. As you can see, I haven't been successful. Jonathan
On Monday 03 March 2003 09:04 pm, Tim Wegner wrote:
(change 'jne badvesa' to 'jne wedone')
I changed three of these, no luck.
More ideas ?? :-)
If we skip the whole routine via jmp wedone, everything is OK, as I said before. So SOMETHING in the routine is messing us up ...
That would indicate that the first 'int 10' is causing the problem, right? Have you run vesainfo or svgainfo on these machines? I put svgainfo.zip in the fractint directory a while back. That could tell us if your video cards support scrolling. Maybe. Jonathan
Jonathan asked:
Have you run vesainfo or svgainfo on these machines? I put svgainfo.zip in the fractint directory a while back. That could > tell us if your video cards support scrolling.
I found Vesainfo.exe in \gcc\allegro\tests See: http://twegner.dyndns.org/timvid.txt
On Tuesday 04 March 2003 05:19 pm, Tim Wegner wrote:
I found Vesainfo.exe in \gcc\allegro\tests
See:
Hmm, I'll have to study that. Take a look at the new executable and diff in the experimental directory. I've cleaned up the problems that Charlie pointed out and made a minor adjustment at the end of VESAvirtscan. When we bailed out with a bad bios call, we were adjusting sxdots and sydots even if we hadn't modified them. Perhaps this will clear up our problems. Fingers crossed. 8-)) Jonathan
Jonathan wrote:
Take a look at the new executable and diff in the experimental directory. I've cleaned up the problems that Charlie pointed out and made a minor adjustment at the end of VESAvirtscan.
No luck. I have recompiled everything, so if you have more things you want me to try, let me know. BTW, I am using a program called Winscp2 to move files to and from Julia and my Windows machine. Even easier than FTP, and more secure, uses OpenSSH. http://winscp.vse.cz/eng/ Tim
On Tuesday 04 March 2003 09:37 pm, Tim Wegner wrote:
No luck. I have recompiled everything, so if you have more things you want me to try, let me know.
I'll try the fix I had before that fixes your problem but causes my machine to mess up when you switch fractals using the <t> screen. Maybe it will work now. Jonathan
I just tried patch 4a with a Compaq Evo, Win XP and a VESA 2.0 S3 board. Worked fine. I never tried Fractint under Win XP before, but it worked fine at 1024x768x256
I wrote:
I just tried patch 4a with a Compaq Evo, Win XP and a VESA 2.0 S3 board. Worked fine.
I neglected to mention that I did observe an addressing problem when using a virtual mode. A little incorrect several-pixel-wide vertical sliver of a fractal appeared on the right-hand side of the phsical screen. The result wasn't too bad, but something is not right. I'll try again and give you more exact details.
On Wednesday 05 March 2003 04:53 pm, Tim Wegner wrote:
I neglected to mention that I did observe an addressing problem when using a virtual mode. A little incorrect several-pixel-wide vertical sliver of a fractal appeared on the right-hand side of the phsical screen. The result wasn't too bad, but something is not right. I'll try again and give you more exact details.
I have seen that on my mother's machine, also. It's running XP. Didn't have the time to look into it. Jonathan
On Tuesday 04 March 2003 05:19 pm, Tim Wegner wrote:
That doesn't quite tell everything I need. Try running svgainifo. At the end of its output (with a valid video mode) it provide a synopsis of the video functions that are available. For example, it tells me that my 3dfx card does not support setting the scan line length, but does support setting the display start. The ATI card supports both. Jonathan
That doesn't quite tell everything I need. Try running svgainifo.
The stuff returned for mode 256 is: SVGAINFO Version 1.1 by Ron Thomas Copyright 1994 Video mode in decimal:256 Vesa Signature: VESA Vesa Version: 3.0 BIOS Identification: NVidia Capabilities: 01000000 Number of killobytes of Video memory:4096 Supported VESA modes:- 256 257 258 259 260 261 262 263 264 265 266 267 268 270 271 273 274 276 277 279 280 282 304 305 306 307 308 309 310 317 318 325 326 Press Enter for more info Information for mode:256 Mode_Attributes: 039F Window A attributes: 07 Window B attributes: 00 Window granularity in kb: 64 Window size in kb: 64 Window A start segment: A000 Window B start segment: 0000 WinFunc Pointer: C000:5B6F Bytes per scan line: 640 Horizontal resolution: 640 Vertical resolution: 400 Character cell width: 8 Character cell height: 16 Number of memory planes: 1 Bits per pixel: 8 Maximum number of colours: 256 Number of banks: 1 Memory model type: 4:- Packed pixel graphics Bank size in kb: 0 Number of image pages: 15 Press Enter for more info 4F06h, Set/Get Logical Scan Line Length function, is Not supported 4F07h, Set/Get Logical Display Start function, Is supported 4F08h, Set/Get DAC Palette Control function, Is supported 4F09h, Set/Get Palette Data function, is Not supported 4F0Ah, Return VBE Protected Mode Interface function, Is supported 4F0Bh, Set/Get Pixel Clock function, Is supported 4F4Dh, Video Cursor Interface Request function, is Not supported 4F12h, Display Management Power Signaling function, Is supported
On Tuesday 11 March 2003 07:16 pm, Tim Wegner wrote:
4F06h, Set/Get Logical Scan Line Length function, is Not supported 4F07h, Set/Get Logical Display Start function, Is supported
We are checking these two in VESAvirtscan and failing the first *should* bail us out. However, on my 3dfx card, which also does not support 4F06h, if I bypass these tests I can scroll anyway. At any rate, I'm working on taking the check for video_scroll out of the prompts code (to an extent). But, it's currently mangled, so I must have missed something. Jonathan
Tim, Try the experimental code now. It has some quirks, but should work. Jonathan
On Thursday 13 March 2003 09:42 pm, Tim Wegner wrote:
My Nvidia board on the HP is a tough nut to crack. Sorry for the monotonous report, but same behavior as before after ESC. Works OK without virtual-yes (as before).
I expected as much. I'll track down where the <t> screen resets sxdots and sydots. Then I can use the setfortext and setforgraphics to set a flag that will jump around the VESAvirtscan code when a text mode is used. I had implemented this earlier and it fixed your problem, but caused others. Jonathan
Tim, The latest version of patch 4a is in the experimental directory. It should allow your problem video cards to work. It does, however, have the problem with a virtual screen getting messed up when choosing another fractal type through the <t> screen. This appears to not be a problem with sxdots and sydots as I had first suspected. OTOH, I'm clueless (again). Jonathan
The latest version of patch 4a is in the experimental directory. It should allow your problem video cards to work.
Yes it does, all is well now.
It does, however, have the problem with a virtual screen getting messed up when choosing another fractal type through the <t> screen.
Yes, I can duplicate this. It shows when using guessing, but not passes=1. Maybe that's a clue. Guessing reads the screen, but passes=1 does not. I'd look and see if the pixel reading routines need something for virtual mode support.
This appears to not be a problem with sxdots and sydots as I had first suspected. OTOH, I'm clueless (again).
Not too cluesless, because you fixed the problems with my video card. Maybe this comment is for Charlie. This is purely a personal preference, but in virtual mode often the screen scrolls when I don't think it should when I am moving a zoom box. If the zoom box can move, that's what it should do. The fractal should only pan if the zoom box hits the edge of the screen. Tim
On Saturday 15 March 2003 07:54 pm, Tim Wegner wrote:
Yes, I can duplicate this. It shows when using guessing, but not passes=1. Maybe that's a clue. Guessing reads the screen, but passes=1 does not. I'd look and see if the pixel reading routines need something for virtual mode support.
Hmm, I hadn't tried it with passes=1. Jonathan
On Saturday 15 March 2003 07:54 pm, Tim Wegner wrote:
Yes, I can duplicate this. It shows when using guessing, but not passes=1. Maybe that's a clue. Guessing reads the screen, but passes=1 does not. I'd look and see if the pixel reading routines need something for virtual mode support.
I see problems with passes=1. Setting symmetry=none helps, but doesn't fix it. Thought it could be problems with setting up the grid, but setting debug=3800 (forcing the use of the function instead of the static grid) didn't change anything. Jonathan
On Saturday 15 March 2003 07:54 pm, Tim Wegner wrote:
Yes, I can duplicate this. It shows when using guessing, but not passes=1. Maybe that's a clue. Guessing reads the screen, but passes=1 does not. I'd look and see if the pixel reading routines need something for virtual mode support.
Fixed it. The latest executable in the experimental directory should work. Jonathan
Yes, works for me (at least one one computer, the HP Pavilion with Nvidia), good job! Tim
Jonathan asked:
Can you think of any reason to leave in the virtual=yes command line option?
No, I can't think of any reason to leave it in. You might consider leaving virtual=yes in as an undocumented debugflag switch until we have more experience, but if that's any trouble, I have no problem with eliminating the switch entirely. Simplifies the docs. BTW, you've been sending messages both to the list and to me personally. I don't know if that is intentional or a side effect of ther new list software. It's sufficient to send a message to ther list, since my email program sorts the mail to the same place either way. If there's a list setting I need to change, I'll look into it. Tim
On Monday 17 March 2003 06:33 pm, Tim Wegner wrote:
BTW, you've been sending messages both to the list and to me personally. I don't know if that is intentional or a side effect of ther new list software. It's sufficient to send a message to ther list, since my email program sorts the mail to the same place either way.
If there's a list setting I need to change, I'll look into it.
Your "reply to" contains both email addresses. As does Charlie's. Mine doesn't. Jonathan
Jonathan wrote:
Your "reply to" contains both email addresses. As does Charlie's. Mine doesn't.
Good catch. I found a setting that causes reply-to to be overwritten, so now everybody's reply-to should be the list. The mailman software has always "strongly recommended" that the reply- to be set to the sender. I can understand why, but since our lists are relatively low volume, it has always seemed to me that for us it is better to have reply-to's go to the list in order to keep threads going. I know that this is a issue that has been discussed thoroughly in various places. If I'm wrong, I will cheerfully change the settings. If we follow the recommendation, replies would tend to go to the person directly unless you self-consciously edit the email address. On another issue, the archives expose our emails to spam harvesters. I could change the settings so only list members can see archives. Should I? I believe there is also an option to hide our emails. Should I turn that on? Another issue. I have always hated having to scroll through a list of bounces of attempted posts from non-members. The earlier software caused me to have to disposition each bounce individually. About 99.9% of these were spam, but occasionally there's a legitimate problem. The problem was we get 50 spam messages every few days. I have changed the settings to just silently discard attempted posts from non-members. This may be an unfriendly setting, but it reduces my list management responsibilities quite a bit. If anyone thinks this is wrong, say so, and say why. Normally list management is off topic, but I would welcome a little discussion to help me improve the list. The new software has many new options that I can set. Tim
Re: [Fractdev] List settings Tim wrote:
If we follow the recommendation, replies would tend to go to the person directly unless you self-consciously edit the email address.
it's easier to self-consciously change the list's email to a direct personnal address..
I could change the settings so only list members can see archives. Should I? I believe there is also an option to hide our emails. Should I turn that on?
no! it's much better when you can peek in without subscribing to assure oneself that you are at the right place.. it helps a lot but, hidding emails is ok.. Re: [Fractdev] Virtual panning
more, there could be a switch like: scroll zoombox: [always] / [at the edge only]
I'd only make a switch if it was clear that some people preferred the current behavior.
well, at least i DO.. :o) not it's only much easier to implement, but the scrolling is smoother.. sometimes, i just sit and scroll around.. i love it blur.. charlie ______________________________________________________________________ Reklama: Zahraj si online hry a vyhraj Nokia 3650 a dalších 99 cen. http://ad2.seznam.cz/redir.cgi?instance=43806%26url=http://www.razdva.cz/~se...
Re: [Fractdev] Panning Tim wrote:
Maybe this comment is for Charlie. This is purely a personal preference, but in virtual mode often the screen scrolls when I don't think it should when I am moving a zoom box. If the zoom box can move, that's what it should do. The fractal should only pan if the zoom box hits the edge of the screen.
Tim
it's also a possibility, but what should it do when the zoombox is stretched or skewed, zoomed out or even rotated..? then at least two edges would be offscreen while two other not.. so, hitting the edge of the screen doesn't imply scrolling.. well, it could figure out zoombox's bounding box and then, if it were too large in a direction, it would switch to center-scrolling in that direction.. more, there could be a switch like: scroll zoombox: [always] / [at the edge only] if this is an acceptable behaviour, i'll do that, or at least i'll try.. charlie ______________________________________________________________________ Reklama: Jeden svet 2003 - 5. rocnik Mezinarodniho festivalu dokumentarnich filmu o lidskych pravech. http://www.oneworld.cz
Charlie wrote:
well, it could figure out zoombox's bounding box and then, if it were too large in a direction, it would switch to center-scrolling in that direction..
This would be fine. The current logic seems to start pabbing the fractal when the zoom box reaches the center. If the logic waiting until a bounding box containing the zoom box touches the edge, that would be fine.
more, there could be a switch like: scroll zoombox: [always] / [at the edge only]
I'd only make a switch if it was clear that some people preferred the current behavior. Tim
In the past few days, I've run into a bug over a dozen times while exploring with the multifractal formula. I've also recently upgraded to patch level 5 of Fractint version 2002. It appears most often at 1600x1200 resolution, occasionally other resolutions. At 1600x1200, the following par illustrates the bug. It only does 2 or 3 lines at passes=1, and barely gets started at passes=t before it stops generating the picture. A showdot continues to move, but nothing else is generated. This is similar to a save and restore gif bug discovered several years ago, but no save and restore is necessary this time. It may have something to do with a buffer size since it occurs much more frequently with higher resolutions. Bug_Test { ; ; t= 0:01:28.42 on a P4 2Gh at ; 1600x1200 Image Copyright 2003 ; by Lee H. Skinner ver=2002 ; Version 2002 Patchlevel 5 reset=2002 type=formula formulafile=0from_ml.frm formulaname=multifractal ismand=n function=exp/exp/exp passes=t center-mag=-6.52603785028786300/-0.01400828975779934/\ 404.3077/1/77.5000000000016342/-4.47783476964502825e-\ 012 params=-0.1740997192297128/-0.2996141087069308/384.00\ 004/256.1106/2048.00016/768.00009/768.01536/256.01025\ /28974.5/12 float=y maxiter=2048 inside=maxiter outside=tdis logmap=yes symmetry=none periodicity=0 rseed=-2436 cyclerange=2/255 colors=000000zz1zzC<2>zzz<3>jqdfo_blU<3>Mb8<3>LQ8KM8K\ J8<2>I88H44G00<3>TA5WD6ZF7aI8eLAhMBiODjQF<3>qeBriAtm9\ vq8xu7zz5zz4zz3<4>zj4zg4zc4<3>zS5zP5zL6zI6zE6wE6tD6<6\
vAIv9Kv9M<3>x7Sy7Uy6Wz6Yz5_<3>f5Ma5IW4E<2>_4H<3>P3DN\ 2CK2A<3>805G0BO0G<3>g0Ul0Xq0`v0d<2>y0fz0gy0h<3>u1mt1n\ s1or2q<2>v2u<3>c5eZ6`U6X<2>F9LAAG7FO4KW0Qc<3>5Xc6Zc7`\ c7aa7c_7eY<3>FcgHciJbl<3>S_v<3>civflvinvlqvotvsww<2>z\ zz<3>rwzovzhsw<3>Gch8_d8Xa<3>8JP8FL8CI<3>SCCXCAaB9<3>\ uA2zA0xA0<12>SA1QA1NA1<3>D92<6>UXAW`BYcC<3>hrI<3>UnXR\ m_NlcJkgFfpAaz<3>PJoSFlWAi_5fc0ce7_jFRoNIzb0zj0zr0 }
-------------------------------start-frm----------------------------------- FRM:Multifractal { ;Albrecht Niekamp May, 03 ;only integers as first input, second input 5 digits to the right ;real(p2) factor1,border1 ;imag(p2) (-)maxiter1,input bas.frm1_2digits input bas.frm2_2digits ;real(p3) bailout,hyb.mandel: number of sides (Many_mods L.Allison) ;imag(p3) factor2,border2 ;real(p4) maxiter2,factor3 ;imag(p4) border3,maxiter3 ;real(p5) 1digit_shape only 5digits: shape,out1,out2,in1,in2 ; 1_mand 2_jul 3_hyb.mand 4_hyb.jul +5_reset (not shape) <0_no in/out1 ; optional basic frm2: out-nbr 1digit in-nbr 1digit 3_both +5_shape ;imag(p5) 1digit : 1_iter1reset 2_iter2reset 3_both +5_shape effect ; 2digits : many_mods multipl. shutoff +10_in/out1 +20_inout2 +30_both ; optional input2: frequency_2digits level_2digits amplitude_2digits ; d=real(p2) fac1=trunc(d) b1=(d-fac1)*100000 ; d=imag(p2) da=(d<0) if (da) d=-d endif mi1=trunc(d) d=round((d-mi1)*10000) p6=trunc(d/100)/10 d=d-1000*p6 if (da) p6=-p6 endif p7=d/10 ; d=real(p3) ba=trunc(d) mm=round((d-ba)*100000) ; d=imag(p3) fac2=trunc(d) b2=(d-fac2)*100000 ; d=real(p4) mi2=trunc(d) fac3=round((d-mi2)*100000) ; d=imag(p4) b3=trunc(d) mi3=round((d-b3)*100000) ; da=real(p5) t=(da<0) if (t) da=-da endif start=2-t dd=trunc(da) if (dd<5) start=0 endif vb=(dd==3)+(dd==4) da=round((da-dd)*100) d=trunc(dd/10000) vb=(d==3)+(d==4)+vb dd=dd-d*10000 d=trunc(dd/1000) or1=(d>5) d=d-5*or1 vv1=(d==3) vv2=(d==4) dd1=(d==2)+(d==4) dd=dd-d*1000 d=trunc(dd/100) or2=(d>5) d=d-5*or2 vv3=(d==3) vv4=(d==4) dd2=(d==2)+(d==4) dd=dd-d*100 d=trunc(dd/10) inr1=(d>5) d=d-5*inr1 v1=(d==3) v2=(d==4) d1=(d==2)+(d==4) dd=dd-d*10 d=trunc(dd) inr2=(d>5) d=d-5*inr2 v3=(d==3) v4=(d==4) d2=(d==2)+(d==4) d=trunc(da/10) ab=(d>=5) d=d-5*ab da=da-10*d bb1=(d==1) bb2=(d==2) d=da ab=(d>=5) d=d-5*ab ab1=(d==1) ab2=(d==2) ; d=imag(p5) dd=trunc(d) d=round((d-dd)*1000000) le=(d>10000) da=trunc(dd/10) so1=((da==1)+(da==3)==0) so2=((da==2)+(da==3)==0) dd=dd-10*da wo=(dd>=5) dd=dd-5*wo ir1=(dd==1)+(dd==3) ir2=(dd==2)+(dd==3) if (le) freq=round((trunc(d/10000))*10) ;frequency_lake effect by S.Gallet d=d-freq*1000 level=(trunc(d/100))/100 ;water level d=d-level*10000 ampl=d/100 ;amplitude of the wave angle=real(rotskew*pi/180) t=exp(-flip(angle)) h=1/real(magxmag) q=h/0.75*imag(magxmag) tanskew=tan(imag(rotskew*pi/180)) w=2*q*t v=2*h*(tanskew+flip(1))*t z3rd=center+(-q-h*tanskew-flip(h))*t z=pixel-z3rd s=imag(conj(w)*z)/imag(conj(w)*v) if (s<=level) da=level-s z=z+2*da*(1+ampl*sin(freq*da^0.2))*v endif z=z+z3rd endif if (ismand) if (vb) c=0.4*log(sqr(pixel^mm)) z=z*le else c=z*le+pixel*(le==0) z=0 endif else c=p1 z=z*le+pixel*(le==0) endif t=0 d3=(ismand==0) u=d3 : if (vb) if (d3) z=(z*z-real(c))^(z*u+imag(c)) ;frm: Albrecht Niekamp else z2=fn1(z)+c ;frm: Many_mods Linda Allison sqz2=cos(z2) z=c*(1-sqz2)/(1+sqz2) endif else if (ab) z=z*z+c+c*c-p7 ;frm: Puskás István else z2=z*z ;frm: Puskás István modified z=z2*z2+(p6+u)*z2+c-p1*(d3==0) endif bo=|z| If (wo) t=t+1 if ((t<mi1)+(bo>b1)) u=2*(fn1(t/fac1)) if (ismand) z=z*u if (vb) c=0.4*log(sqr(pixel^mm)) else c=z*le+pixel*(le==0) endif else z=z*le+pixel*(le==0) c=p1*u endif wo=0 if (ir1) t=0 endif endif elseif (start) t=t+1 if (start==2) if (bo>b2) u=2*(fn2(t/fac2)) rs=or1 ab=bb1 if (dd1) if (rs) z=pixel endif c=p1*u vb=vv2 d3=vb else d3=0 z=z*u c=z if (rs) z=0 endif vb=vv1 if (vb) if (so1) mm=mm+mm endif c=0.4*log(sqr(pixel^mm)) endif start=1 endif elseif (t>mi2) u=2*(fn2(t/fac2)) rs=inr1 ab=ab1 if (d1) if (rs) z=pixel endif c=p1*u vb=v2 d3=vb else d3=0 z=z*u c=z if (rs) z=0 endif vb=v1 if (vb) if (so1) mm=mm+mm endif c=0.4*log(sqr(pixel^mm)) endif endif start=1 if (ir2) t=0 endif endif elseif (bo>b3) u=2*(fn3(t/fac3)) ab=bb2 rs=or2 if (dd2) if (rs) z=pixel endif c=p1*u vb=vv4 d3=vb else d3=0 z=z*u c=z if (rs) z=0 endif vb=vv3 if (vb) if (so2) mm=mm+mm endif c=0.4*log(sqr(pixel^mm)) endif start=0 endif elseif (t>mi3) u=2*(fn3(t/fac3)) ab=ab2 rs=inr2 if (d2) if (rs) z=pixel endif c=p1*u vb=v4 d3=vb else d3=0 z=z*u c=z if (rs) z=0 endif vb=v3 if (vb) if (so2) mm=mm+mm endif c=0.4*log(sqr(pixel^mm)) endif endif start=0 endif endif bo<=ba } -------------------------------------------end-----------------------------
Tim,
In the past few days, I've run into a bug over a dozen times while exploring with the multifractal formula. I've also recently upgraded to patch level 5 of Fractint version 2002. It appears most often at 1600x1200 resolution, occasionally other resolutions.
Can you take a look at this? I see the problem at 1024x768 when the calculations get to the lower left corner. Fractint keeps on calculating, but no new pixels appear on the screen. Jonathan
Jonathan asked:
Can you take a look at this? I see the problem at 1024x768 when the calculations get to the lower left corner. Fractint keeps on calculating, but no new pixels appear on the screen.
I'll have a look. The formula is horendously complex, perhaps some array is over-run. Tim
participants (4)
-
Charlie Chernohorsky -
Jonathan Osuch -
Lee H. Skinner -
Tim Wegner