Tim, I will probably put out two patches simultaneously, instead of including Charlie's virtual screen changes in a combined patch. This will make it easier to find problems if any should occur. The other changes are getting lost with all the changes Charlie is making for virtual screens. Jonathan
Jonathan wrote:
I will probably put out two patches simultaneously, instead of including Charlie's virtual screen changes in a combined patch. This will make it easier to find problems if any should occur. The other changes are getting lost with all the changes Charlie is making for virtual screens.
Exactly the right thing to do. Put related changes in the same patch. Tim
Tim, The patches are pretty close to complete. The only things left are to actually split them, add the documentation, and fix the places we broke Xfractint. One question: When using the supervga graphics modes, is a flag set when we are actually using VESA modes? We've added three 256 color modes to fractint.cfg so they could have a dotmode=28. We could possibly avoid this if dotmode=27 plus a vesa flag would give us the same result. I've put a temporary file with the current version of these patches in the fractint directory. Just in case you feel inclined to have a look prior to release. The virtual screens are pretty cool. They only work in dotmode=28 graphics modes. Jonathan
Jonathan asked:
One question: When using the supervga graphics modes, is a flag set > when we are actually using VESA modes? We've added three 256 color modes to fractint.cfg so they could have a dotmode=28.
Sorry, I don't know the answer.
I've put a temporary file with the current version of these patches in the fractint directory. Just in case you feel inclined to have a look prior to release.
I'll have a look, thanks. Tim
Tim Wegner wrote:
I've put a temporary file with the current version of these patches in the fractint directory. Just in case you feel inclined to have a look prior to release.
I'll have a look, thanks.
It it pretty ugly with regards to documentation (there is none). Go to the <v> screen while using a VESA mode (dotmode=28). There are some things to clean up for Xfractint, as I had suspected. Unfortunately, I have to figure out what I was working on in unixscr.c before I can do much more. I don't want to trash the changes, but it won't compile as it stands. Jonathan
Tim, I've decided it's too much work to split the patch into two pieces. So, an almost ready patch is in the fractint directory. I've added the docs (or at least the important stuff). Haven't tried it on Xfractint, yet. That will probably happen Saturday morning. Jonathan
Jonathan,
I've decided it's too much work to split the patch into two pieces. > So, an almost ready patch is in the fractint directory. I've added the docs (or at least the important stuff). Haven't tried it on Xfractint, yet. That will probably happen Saturday morning.
I have two problems. One is that when I try any of the new virtual modes, the screen is trashed when I press <ESC>. (Perhaps I need a frasrc.zip file to make sure I have applied all the diffs right, but I *think* I reconstructed the sources OK. The second is that I am not exactly sure how the virtual mode is supposed to work. Could you give me a little tutorial? If it's in the docs, just tell me where to look. If the virtual mode is what I think it is, it's a really good idea. It would be wonderful to decouple fractint's capability from the video mode and allow the fractal to be bigger than the version shown on the screen. POVray works this way. On the other hand, it woul;d sure be much easier to imp-lement this once we're out from under DOS. Gee it's hard to work in a DOS window when it's been a while!! Tim
Tim Wegner wrote:
I have two problems. One is that when I try any of the new virtual modes, the screen is trashed when I press <ESC>. (Perhaps I need a frasrc.zip file to make sure I have applied all the diffs right, but I *think* I reconstructed the sources OK.
Hmm.
The second is that I am not exactly sure how the virtual mode is supposed to work. Could you give me a little tutorial? If it's in the docs, just tell me where to look.
It is sort of in the docs. If you ever used the <v> screen to change the resolution of the disk video modes, it works the same way. The view window help docs have been updated, but I'm sure there is still not enough information there. The additional information is at the bottom of the first page, so it doesn't amount to much.
If the virtual mode is what I think it is, it's a really good idea. It would be wonderful to decouple fractint's capability from the video mode and allow the fractal to be bigger than the version shown on the screen. POVray works this way.
On the other hand, it would sure be much easier to imp-lement this once we're out from under DOS.
Perhaps. But, for now tweaking the VESA graphics modes is what is being done.
Gee it's hard to work in a DOS window when it's been a while!!
I hope you aren't actually working in a window, as that is certain not to work. I found some things in Xfractint that I must have broken in patch 4. The zoombox using page-up and page-down is invisible. And, at least one text box message doesn't display text. Once I get these sorted out and I check that I haven't broken anything in the DOS version, the patch should be ready. After we getting it working on your machine, of course. Jonathan
Tim Wegner wrote:
I have two problems. One is that when I try any of the new virtual modes, the screen is trashed when I press <ESC>. (Perhaps I need a frasrc.zip file to make sure I have applied all the diffs right, but I *think* I reconstructed the sources OK.
Have you managed to get past this? I've uploaded the latest patch with the fixes for Xfractint in it. If you are still having problems, it won't help. I'll try it on the desktop machine at home Friday evening. Jonathan
Jonathan Osuch wrote:
One question: When using the supervga graphics modes, is a flag set when we are actually using VESA modes? We've added three 256 color modes to fractint.cfg so they could have a dotmode=28. We could possibly avoid this if dotmode=27 plus a vesa flag would give us the same result.
also, when a videomode with dotmode==27 is selected, setvideo somehow (i failed to trace it) changes it to dotmode=28 then, videoentry.dotmode==27, but dotmode==28, pretending it allows VESA calls, but it doesn't strange.. so an update like dotmode=videoentry.dotmode%100 is needed at <v> screen.. (that's why i put it there, but i don't think it's the best way to solve it) ..just to mess up discussion :o) charlie ______________________________________________________________________ Reklama: Poctenicko pro kazdy den: http://www.novinky.cz
participants (3)
-
Charlie Chernohorsky -
Jonathan Osuch -
Tim Wegner