Changes: - fractint.cfg supported with new driver field - driver for each mode displayed on video mode screen - intro screen spacebar issue fixed - better text screen updates - better banner image on setup dialogs - install *.doc files as *.txt, cause that's what they are... - add shortcuts to .txt files and to install folder Known issues: - saved image is wrong - makedoc= doesn't work right - keyboard input is still a little funky in places/at times <http://www.xmission.com/~legalize/fractals/fractdev/FractIntSetup-21.00.alpha1.msi> If you install this version on a machine with alpha 0, it will be upgraded to alpha 1. There is an on-again off-again issue with the keyboard input. I think it stems from me trying to steal too much code from xfractint and not writing it from scratch :-). At any rate, its better now, but I can still manage to get it confused occasionally. Feedback appreciated. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich, I downloaded the alpha and briefly tried running it. The text screens look great! What functionality should I be checking to help you? Tim
In article <4598F4B1.28487.A8123E@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
I downloaded the alpha and briefly tried running it. The text screens look great!
Sweet :)
What functionality should I be checking to help you?
Anything text related, since the main image doesn't save right. Slideshows don't work right and don't play friendly with event-driven I/O. I think to get them back on, I'll need to make a separate slideshow thread that periodically feeds keyboard input to the app or something. The existing code has a busy-wait loop while its looking for keyboard input and checking slideshow code at the same time. While you could literally do the same thing in Win32 land, it would be silly for a machine to be using 100% CPU when its sitting there waiting for a keystroke or a timer to expire. Basically the slideshow stuff has to be reworked to be timer based instead of polling. The keyboard input code is acting like a bowl of jello: push here, it pops out there. I tried going back to the original assembly code and translating that into C and it sort of helped, but not quite. I think the bottom line is that the wintext.c code is *almost* what you need to implement fractint's keyboard input model, but because its not *exactly* what you need it keeps messing things up. Keys either end up being discarded too early (in which case the UI appears dead) or they need to be hit multiple times in order to work (in which case the UI appears sluggish). There's times where I have it working in most places and then there's some weird keyboard interaction in another part of fractint that's different from all the rest and it messes up again. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich wrote:
Slideshows don't work right and don't play friendly with event-. driven I/O. I think to get them back on, I'll need to make a separate slideshow thread that periodically feeds keyboard input to > the app or something.
My suggestion is not worry now about the slideshow mode. First get the text input exactly the way you want it. Then (maybe) get the slideshow to work. Problem is the slideshow mode is a secondary feature that depends on the keystroke trapping architecture. Maybe later we can make a whole new procedure-based scripting language that wouldn't depend on the user interface. Tim
In article <45993818.13380.F9234@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
My suggestion is not worry now about the slideshow mode. [...]
I looked at it because it came up when I transliterated the assembly code and also because I thought "hey, if it works, then I can use it as a sort of unit test for going through the screens.". -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Lee asked:
What is the slideshow mode?? I can't find anything about that in the docs.
Rich just renamed the feature that old timers know and love as Autokey by the name "slideshow". The history is that when finishing up Fractal Creations 2nd Edition, Mitch Waite asked for a way to do demos. Because the keystroke capturing was nicely organized through a single function, it was an easy matter to feed keystrokes in from a file. Bert Tyler (I think, or maybe Jonathan) made a few changes to the assembler implementation of the gvetkey routine, and I did the rest in a few days work. Rich wrote:
I looked at it because it came up when I transliterated the assembly code and also because I thought "hey, if it works, then I can use it as a sort of unit test for going through the screens.".
Good point. My advice is only to point out that if you haven't finalized the keystroke input, then the autokey is a moving target. Finalize the ketstroke input, then you probably won't find it hard to finish autokey. (He says, realizing that the event-driven nature of windows might make it hard.) You are right that as long as we keep the keystroke input, autokey is a great mechanism for regression testing. Tim
In article <459946F9.21549.49AFC5@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Lee asked:
What is the slideshow mode?? I can't find anything about that in the docs.
Rich just renamed the feature that old timers know and love as Autokey by the name "slideshow".
I mistakenly called it slideshow because of the names of the routines and associated variables :-). Its really the "autokey" stuff as Tim says.
Good point. My advice is only to point out that if you haven't finalized the keystroke input, then the autokey is a moving target.
Well, I *thought* I had it and then it wriggled out of my hands again :-). Now I think I've *really* got it. It was a case of "too many chefs" throughout the code, all trying to manage the buffering. So I took the buffering out of the wintext.c code and put it into the win32_disk driver and now things are finally behaving as expected. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Bug report! I don't know what is supposed to work so far, but I've noticed the following: 1. Closing the window upon exit: <esc> <y> always seems to work (DOS compatible) The upper right corner button works sometimes - but usually not after completing a fractal Sometimes the screen clears to white but the window frame remains. 2. Orbits window crashes - probably because you don't do this in disk video mode. :-) 3. Tab Screen: You can return from it with <esc> but not by pressing another <tab> also: <ctrl><tab> to get to the 2nd tab page doesn't work. 4. Viewwindows screen doesn't bring up any parameters. 5. X-Screen: Can't highlight any line other than passes. Can't modify passes=g to anything else. I notice that you have true-color modes in the Select Video Mode page, but FractInt doesn't have the ability to handle these yet, does it? Lee
In article <459971A5.5080201@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
Bug report! I don't know what is supposed to work so far, but I've noticed the following: [...]
All good stuff, thanks.
I notice that you have true-color modes in the Select Video Mode page, but FractInt doesn't have the ability to handle these yet, does it?
I think its just using a truecolor output, not doing truecolor rendering. I think Jonathan added that code fairly recently. It might be in the docs, I'm not sure. Those modes were in the existing fractint.cfg, I just tossed 'em in there to see what would happen :-). -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich wrote:
I think its just using a truecolor output, not doing truecolor rendering. I think Jonathan added that code fairly recently. It might be in the docs, I'm not sure. Those modes were in the existing fractint.cfg, I just tossed 'em in there to see what would happen :-).
We dragged Bert Tyler out of fractint retirement to add the VESA true color modes quite a while ago. They work, but the program architecture assumes 256 colors in most places, so true color is not well integrated. After the basic refactor is done, Paul DeLeeuw's handling of truecolor would be good to look at. That said, I think the project is best served by the literal port approach you are taking, except for legacy code that we're quite sure we don't want (e.g. built-in printer drivers). -- and hold off and add new features later. Tim
In article <459971A5.5080201@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
3. Tab Screen: You can return from it with <esc> but not by pressing another <tab>
Fixed.
also: <ctrl><tab> to get to the 2nd tab page doesn't work.
Fixed.
5. X-Screen: Can't highlight any line other than passes. Can't modify passes=g to anything else.
Fixed. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
In article <459971A5.5080201@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
4. Viewwindows screen doesn't bring up any parameters.
Fixed. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
In article <E1H1vo3-0008Rs-00@xmission.xmission.com>, Richard <legalize@xmission.com> writes:
In article <459971A5.5080201@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
4. Viewwindows screen doesn't bring up any parameters.
Fixed.
Woops, maybe I spoke too soon. Its showing the parameters now, but the image doesn't recompute right when I change the resolution. Tim, Jonathan: What's the purpose of the diskisactive variable in the code? The only place its used to decide anything is in startdisk(), which shortcut returns immediately if this is zero. All the other uses in the code are the rest of the modules turning this on and off at various places. What is this variable trying to guard against? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
In article <459971A5.5080201@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
2. Orbits window crashes - probably because you don't do this in disk video mode. :-)
I could not reproduce this currently, even in disk video mode. It Just Works. Of course its rather lame since you can't interactively see what you're doing :-), but it does update! Can you reproduce this in beta 2? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
It works fine in beta 2. So do the arrows. Although <ctrl-arrow> doesn't offer any speed-up. In the <m> screen, if you press the down arrow until it stops, the menu items orbits window <o> (left side near top) and the stereogram <ctrl-s> (right side at bottom) duplicate themselves. (in Win32 Disk Video 800x600) Lee ---------------------------------------------------------------------------
2. Orbits window crashes - probably because you don't do this in disk video mode. :-)
I could not reproduce this currently, even in disk video mode. It Just Works. Of course its rather lame since you can't interactively see what you're doing :-) , but it does update! Can you reproduce this in beta 2?
In article <45B583DD.3030102@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
It works fine in beta 2. So do the arrows.
Great!
Although <ctrl-arrow> doesn't offer any speed-up.
Yes, it is fixed in the next beta.
In the <m> screen, if you press the down arrow until it stops, the menu items orbits window <o> (left side near top) and the stereogram <ctrl-s> (right side at bottom) duplicate themselves. (in Win32 Disk Video 800x600)
I noticed this too, I haven't tried it on the DOS one to see if it has the same bug. Do you know off-hand? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
In article <45B583DD.3030102@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
In the <m> screen, if you press the down arrow until it stops, the menu items orbits window <o> (left side near top) and the stereogram <ctrl-s> (right side at bottom) duplicate themselves. (in Win32 Disk Video 800x600)
Ha ha ha ha ha!!! I successfully reproduced the DOS bug in the Win32 version!! -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
In article <45B583DD.3030102@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
In the <m> screen, if you press the down arrow until it stops, the menu items orbits window <o> (left side near top) and the stereogram <ctrl-s> (right side at bottom) duplicate themselves. (in Win32 Disk Video 800x600)
Tim & Jonathan: If you look in realdos.c, line 787, fullscreen_choice does this: for(;;) { /* main loop */ if (redisplay) { /* display the current choices */ if ((options & CHOICEMENU) == 0) { memset(buf,' ',80); buf[boxwidth*colwidth] = 0; for (i = (hdg2) ? 0 : -1; i <= boxdepth; ++i) /* blank the box */ putstring(topleftrow+i,topleftcol,C_PROMPT_LO,buf); } /*...*/ If I change the if clause to 'if (1)' instead of 'if ((options & CHOICEMENU) == 0)', then it fixes this bug. The question is... does this change introduce other problems? Does it look right to you two? I'm not sure what CHOICEMENU is supposed to mean... -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich wrote:
If you look in realdos.c, line 787, fullscreen_choice does this:
for(;;) { /* main loop */ if (redisplay) { /* display the current choices */ if ((options & CHOICEMENU) == 0) { memset(buf,' ',80); buf[boxwidth*colwidth] = 0; for (i = (hdg2) ? 0 : -1; i <= boxdepth; ++i) /* blank the box */ putstring(topleftrow+i,topleftcol,C_PROMPT_LO,buf); } /*...*/
If I change the if clause to 'if (1)' instead of 'if ((options & CHOICEMENU) == 0)', then it fixes this bug.
The question is... does this change introduce other problems?
Hate to say it, but I'll bet it does, since this routine is used for a lot of menus. I'd like to spend time on this, but it will likely be a few weeks - way too complex here, mainly due to living amidst piles of stuff in about 1/3 of our house, probably for another month. After that I will catch up. Tim
In article <45B699AD.20995.157C5D@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Rich wrote:
If you look in realdos.c, line 787, fullscreen_choice does this:
for(;;) { /* main loop */ if (redisplay) { /* display the current choices */ if ((options & CHOICEMENU) == 0) { memset(buf,' ',80); buf[boxwidth*colwidth] = 0; for (i = (hdg2) ? 0 : -1; i <= boxdepth; ++i) /* blank the box */ putstring(topleftrow+i,topleftcol,C_PROMPT_LO,buf); } /*...*/
If I change the if clause to 'if (1)' instead of 'if ((options & CHOICEMENU) == 0)', then it fixes this bug.
The question is... does this change introduce other problems?
Hate to say it, but I'll bet it does, since this routine is used for a lot of menus.
This flag is used in the following places in the code: - the above code fragment that draws the background box - in footer_msg() to adjust the text of the message - in main_menu() when it calls fullscreen_choice None of the other screens are using this flag. With this change, TAB screens and F1 help screens still look fine as do all the other screens like 'x', 'y', 'z' that I've tried. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
Rich & Tim,
if ((options & CHOICEMENU) == 0) {
If I change the if clause to 'if (1)' instead of 'if ((options & CHOICEMENU) == 0)', then it fixes this bug.
The question is... does this change introduce other problems?
Hate to say it, but I'll bet it does, since this routine is used for a lot of menus.
This flag is used in the following places in the code: - the above code fragment that draws the background box - in footer_msg() to adjust the text of the message - in main_menu() when it calls fullscreen_choice
None of the other screens are using this flag.
With this change, TAB screens and F1 help screens still look fine as do all the other screens like 'x', 'y', 'z' that I've tried.
The only time this section of code is *not* executed is when the second bit of options is set (for example, when options == 2, since CHOICEMENU == 2) when the fullscreen_choice() routine is called. I only saw the one instance in main_menu() where this happens. So, it would appear that using if(1) should work. Let's try it for now. Please document the change so that it will be easy to find if we run into problems later. Thanks. Jonathan
In article <1169690859.13526.14.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
The only time this section of code is *not* executed is when the second bit of options is set (for example, when options == 2, since CHOICEMENU == 2) when the fullscreen_choice() routine is called. I only saw the one instance in main_menu() where this happens. So, it would appear that using if(1) should work. Let's try it for now. Please document the change so that it will be easy to find if we run into problems later. Thanks.
That's what I've got in the branch; I haven't committed this to the HEAD. So far no problems. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>
participants (4)
-
Jonathan Osuch -
Lee H. Skinner -
Richard -
Tim Wegner