(Moving this thread back to the list - it only left the list because I was careless addressing my email.) Jonathan wrote:
Patch 5 works fine on one of the computers at my parents house and mostly fine on the other. The one that has problems is running XP and displays a line down the right hand side of the image. There is also a problem with fuzzy lines at the color boundaries. I suspect it is a problem with the 32-bit pixels versus 24-bit pixels.
Looks like patch 5 will be delayed a while longer.
If the problem is a shortage of free near memory, that can be highly dependent on the local environment because we have no control over the memory usage in VESA bioses. It has been many years since I attempted this, but if the diagnosis is right, the cure is to free up a little near memory, maybe by being a tad more aggressive with overlays. Of course the problem could also be being TOO aggressive with overlays. Tim
Tim Wegner wrote:
If the problem is a shortage of free near memory, that can be highly dependent on the local environment because we have no control over the memory usage in VESA bioses.
It has been many years since I attempted this, but if the diagnosis is right, the cure is to free up a little near memory, maybe by being a tad more aggressive with overlays.
Of course the problem could also be being TOO aggressive with overlays.
Since we mucked with the VESA assembly code, I suspect we just missed something. I've narrowed the problem to patch 5, as expected. There are massive changes in video.asm and patch/diff may be having trouble with them without telling us. I'll have a look at visdeo.asm over this next week. Also, I'll see if I can reproduce the problem on my laptop, since it will be two weeks before I'll be back in Iowa. Jonathan
Tim, Please try the executable, fract2002p5.zip, I've uploaded to the fractint directory. It should take care of the problem with stacking the screen. There is still more I want to look at. Jonathan
Jonathan asked:
Please try the executable, fract2002p5.zip, I've uploaded to the fractint directory. It should take care of the problem with stacking the screen.
Bad news, same problem. It exists not only with the new virtual screen, but with any svga mode. textsafe=save does not help. However the F3 mode (320x200) is OK. The symptoms are: generate default mandelbrot, then press <Esc>. The screen is garbled. Screen looks like this: pe <t> print image <p> toggle to/from ju lia <space> shell to dos <d> return to prior i mage <h> give command string <g> reverse thru hist ory <ctl-h> quit FRACTINT <esc> OPTIONS restart FRACTINT <ins> basic options... <x> COLORS extended options. .. <y> color cycling mode <c> type- specific par ms... <z> rotate palette <+>, <-> view window optio ns... <v> palette editing mode <e> browse parms... <ctl-b> make starfield <a> evolver parms... <ctl-e> ant automaton <ctl-a> sound parms... <ctl-f> stereogram <ctl-s> Use the cur sor keys to highlight your selection Press ENTER for highlighted choice, or F1 for help Followed by garbage. Looks like some address wrong. You can see the correct data, but each line rolls around so the left side of the screen shows on the right. Also, the top of the screen does not show, and there is garbage at the bottom. However pressing a video key (e.g. F3) allows one to draw another fractal, then pressing ESC gives the correct screen. While the free near space is down a little, I don't think that is the problem. The fee stack space is not down. I have placed this file at: http://twegner.dyndns.org/test.zip This file contains fractint.exe and fractrint.cfg. Could some of you try this and see if you can duplicate my problems? (When done, be sure not to confuse this with the real 2002p05 which has not yet been released.) Tim
Tim Wegner wrote:
Bad news, same problem. It exists not only with the new virtual screen, but with any svga mode. textsafe=save does not help. However the F3 mode (320x200) is OK.
The symptoms are: generate default mandelbrot, then press <Esc>. The screen is garbled. Followed by garbage. Looks like some address wrong. You can see the correct data, but each line rolls around so the left side of the screen shows on the right. Also, the top of the screen does not show, and there is garbage at the bottom.
However pressing a video key (e.g. F3) allows one to draw another fractal, then pressing ESC gives the correct screen.
Try it again, please. There was a small modification made to make the screen prompts wider, which I've removed. Don't knkow why it works okay on my laptop and not at all on some other machines. I suspect the video modes above F3 might still be broke. Jonathan
ad garbled text-screen: while working on the virtual screen, i've encountered that garbling when i scrolled the graphic screen and then switched to the text screen -- it was scrolled because of nondestructive mode change ("OR mode,80h" or something like that) so i added scroll(0,0) to stack_screen, then it was not garbled any more.. but the screen should not scroll for those actions posted.. so this maybe won't help you at all.. charlie ______________________________________________________________________ Reklama: FIMFARUM - Cesky celovecerni loutkovy film na motivy pohadek Jana Wericha. www.fimfarum.cz V kinech od 28. listopadu. http://www.fimfarum.cz
Charlie, never mind, I looked at Jonathan's diff and saw what yoiur were talking about in stackscreen(). I'll look through the diff and see if I can spot what is happening. Tim
Tim Wegner wrote:
Charlie, never mind, I looked at Jonathan's diff and saw what yoiur were talking about in stackscreen().
I'll look through the diff and see if I can spot what is happening.
I suspect the problem is the call to VESAvirtscan in video.asm. It should only be executed when dotmode=28. Jonathan
Jonathan Osuch wrote:
I suspect the problem is the call to VESAvirtscan in video.asm. It should only be executed when dotmode=28.
Yes, that is where the problem is. However, dotmode appears to always be set to 28 at that point in the code. Jonathan
Tim & Charlie, The problem we are seeing with VESAvirtscan are due to differences between the VESA 1.1 and 2.0 capabilities. Calling subfunctions defined in 2.0 while running a 1.1 VESA bios doesn't work very well. I should have time to straighten this out this afternoon. Jonathan
Tim, Please take a look at the patch 5 executable in the fractint directory. It should fix the problems you were seeing. It still needs some work, however. It is cutting down the size of the virtual screen for no reason. Also, if your video card does not support virtual screen sizes, there is no message to that effect. Back to Illinois. Jonathan
Jonathan asked:
Please take a look at the patch 5 executable in the fractint directory.
Works fine now!! The scrambled text screen symptoms are gone. However I don't understand how the virtual screen works. I saw the explanation in the view window docks, but don't quite get the idea. A simple tutorial is needed. I could help write if it I knew how it works! Tim
Tim,
Works fine now!! The scrambled text screen symptoms are gone.
However I don't understand how the virtual screen works. I saw the explanation in the view window docks, but don't quite get the idea.
The problem may be that scrolling is not supported by your video card. If you go to the viewwindow screen while in a VESA mode (say 888 at 800x600) and change the values at the bottom of the menu to larger numbers (say 1200x1000), when you press enter, the image should regenerate in a size larger than the screen size. If you end up with the same size image (800x600), then virtual screens and scrolling are not supported. I tried to put in a message to that effect, but need to reorder the logic (meaning it's not there, yet). My latest executable is in the fractint directory. The diff is included in the zipped file. This latest cleans up the problem with not being able to set a larger width. I don't know if it breaks the earlier fix for the problem I saw on my desktop. It shouldn't, but I won't know for 2 1/2 weeks. There are still problems when you press the space bar (with and without viewwindows turned on). The cursor and image go off screen. Looked in jiim.c, where this code is. Tried something, but it failed miserably. Jonathan
Jonathan wrote:
If you end up with the same size image (800x600), then virtual screens and scrolling are not supported. I tried to put in a message to that effect, but need to reorder the logic (meaning it's not there, yet).
if the setup fails, the sx/ydots should differ from the videoentry sx/y*, as it does for the not-enough-vram-cut-down (that i've put a message for in) (somewhere after setvideomode() in framain2.c) but, with vesa 1.x, what is wrong there? if any vesa call fails, it should disable the scrolling.. all those checks for vesa returned values, not enough? ..sigh.. ad dotmode==28, once again, this is sometimes set up even if the mode selected is NOT dotmode==28.. i failed to trace down where that "mis-set-up" is done.. and, maybe the old problem with overwritten videoentry when <esc>aping the <del> screen.. could also cause some strange behavior.. i've posted the following a few times already, but just for the case that there's somebody unaware of it yet: there was a way to change sx/ydots interactively long before i threw into the pot the (bitter) virtual screen spice.. by escaping the <del> screen, you can make fractint to think he's (she's? :o) in dotmode=11 (diskvideo), then come up with the <v> screen, where diskvideo allows changing sx/ydots.. these changes result in redrawing the onscreen image accordingly.. of course, this is not much useful, as for greater-than-screen values the bottom-right corner overflows from the top-left and for smaller values it behaves somewhat like the viewwindow.. .. charlie ______________________________________________________________________ Reklama: FIMFARUM - Cesky celovecerni loutkovy film na motivy pohadek Jana Wericha. www.fimfarum.cz V kinech od 28. listopadu. http://www.fimfarum.cz
Charlie,
if the setup fails, the sx/ydots should differ from the videoentry sx/y*, as it does for the not-enough-vram-cut-down (that i've put a message for in) (somewhere after setvideomode() in framain2.c)
but, with vesa 1.x, what is wrong there? if any vesa call fails, it should disable the scrolling.. all those checks for vesa returned values, not enough? ..sigh..
The problem occurred with a VESA 3.0 bios which doesn't support scrolling. It didn't like having subfunction 3 called at all and that was the first test you had. I changed it to subfunction 1, and then had to add the subfunction 3 call back in later to make things work on a 2.0 bios which does support scrolling. Yes, the scrolling is disabled, but the user can't tell this (yet). I will modify the view window menu so that the user can tell that virtual screen's are not supported by his/her graphics card. Jonathan
Tim, Take a look at the latest executable in the fractint directory. It doesn't quite handle viewwindows and virtual screens like I would like, but it's real close. Jonathan
Jonathan wrote:
Take a look at the latest executable in the fractint directory. It doesn't quite handle viewwindows and virtual screens like I would like, but it's real close.
1. This time I got virtual screens to work. I could move the physical windows's view in the virtual screen with the cursor keys or mouse. 2. When the video mode wasn't virtual, the <v> command showed the old menu. Good. 3. I could save a virtual screen. When I loaded it back, the virtual mode was loaded. I saw a few problems, though. 1. Dumb question. The controls usually used to make a zoom box now move the virtual screen. How does one make a zoom box? A new command mode is entered, this is going to be tricky to keep from being confusing. Maybe hold down the alt key and move around the zoom box, else be in the normal mode. 2. Usually the text screen was OK, but when I moved around the virtual screen, and went back and forth to text, eventually I could get a garbled text screen. I need to work on figuring out the exact sequence that reproduces this. meanwhile, we need to check if the fix you made is needed in other contexts. 3. Save a virtual screen and load it back. Press <del>. The video mode screen doesn't point to the right video mode. It appears that the right mode is loaded, it's just that the position in the video mode screen is wrong. Tim
Tim Wegner wrote:
I saw a few problems, though.
Set up a virtual screen, then select a different fractal type using the <t> screen. I get a scrambled image, which gets worse with changes to text mode and back.
1. Dumb question. The controls usually used to make a zoom box now move the virtual screen. How does one make a zoom box? A new command mode is entered, this is going to be tricky to keep from being confusing.
Actually, the zoom box works the same as before. The major problem is that it is off screen when <PGUP> is first pressed.
2. Usually the text screen was OK, but when I moved around the virtual screen, and went back and forth to text, eventually I could get a garbled text screen. I need to work on figuring out the exact sequence that reproduces this. meanwhile, we need to check if the fix you made is needed in other contexts.
Haven't seen this.
3. Save a virtual screen and load it back. Press <del>. The video mode screen doesn't point to the right video mode. It appears that the right mode is loaded, it's just that the position in the video mode screen is wrong.
I think that we may need to save the video modes back to fractint.cfg. Whenever the select video mode screen appears, fractint.cfg is reloaded. So, the saved video mode disappears and can't be found. Jonathan
Tim Wegner wrote:
3. Save a virtual screen and load it back. Press <del>. The video mode screen doesn't point to the right video mode. It appears that the right mode is loaded, it's just that the position in the video mode screen is wrong.
Still not fixed, but try the latest executable in fract2002p05.zip. The diff file for Fractint is included. The Xfractint and float-only specific diff's are in 2002p05xf.zip. I don't know what to do about updating the video mode. Perhaps think about it. 8-)) Saving the new/virtual modes to fractint.cfg is the only way to maintain the information in the video table. This can be done by calling update_fractint_cfg(). But, how many new modes can we save before running out of space? Jonathan
Tim Wegner wrote:
This file contains fractint.exe and fractrint.cfg. Could some of you try this and see if you can duplicate my problems?
Same thing as you, and F3 always gets the text screens back to normal. Though it does generate other video mode images correctly, and goes back to garbled text after ESC. P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html
participants (4)
-
Charlie Chernohorsky -
Jonathan Osuch -
Paul N. Lee -
Tim Wegner