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