From: owner-fractdev-digest@lists.xmission.com (fractdev-digest) To: fractdev-digest@lists.xmission.com Subject: fractdev-digest V1 #21 Reply-To: fractdev-digest Sender: owner-fractdev-digest@lists.xmission.com Errors-To: owner-fractdev-digest@lists.xmission.com Precedence: bulk fractdev-digest Thursday, April 29 1999 Volume 01 : Number 021 ---------------------------------------------------------------------- Date: Thu, 29 Apr 1999 21:16:20 -0300 (EST) From: Humberto Rossetti Baptista Subject: Porting Fractint (was Re: (fractdev) DOS support via allegro?) Hi All, Good to the the list moving :-) "Phil" I've browsed in to the XaoS code (alnd I wrote the author for more info but haven't got an answer yet). It uses a nice approach to isolate OS-specifica prats from the main program, what makes porting easy if the C style isn't plataform specific or makes assumptions on sizeof things etc. I have managed to compile hc (and it works) and fractint (it does not work yet) qith DJGPP and I was writing a small quick intro to those that want to experiment with DJGPP. I'll post it to the list as it is fairly small. If we can use a similar approach: an API to handel OS-specific stuff I guess the rest of the problem would be clean the code from plataform assumtions and we could have Fractint running in several platforms (like XaoS for instance). []'s Humberto R. Baptista humberto@insite.com.br - --------------------------------------------------------------------------- Insite - Solucoes Internet http://www.insite.com.br - -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@ L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@ t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++ y+++* - ------END GEEK CODE BLOCK------ - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 21:18:52 -0300 (EST) From: Humberto Rossetti Baptista Subject: (fractdev) Preliminar DJGPP howto :-)) HOWTO work with GCC in DOS - for the Fractint Devel Team 1. Getting the Tools Go to DJGPP (Delorie's GCC port to DOS) http://www.delorie.com/djgpp/ And select the /Zip Picker/ there choose your preferred SimTel mirror and pick (at least) the options: -Build and run programs with DJGPP - - -C -RHide or Emacs - -Allegro Toolkit -GRX And download the files. 2. Install From the result of /Zip Picker/: " You need to update your C:\AUTOEXEC.BAT to include the following lines: set PATH=C:\DJGPP\BIN;%PATH% set DJGPP=C:\DJGPP\DJGPP.ENV Note that the PATH statement should follow any other PATH statements, or you may edit an existing PATH statement. You'll need to restart your computer for these changes to take effect. " 3. Build and test Allegro & GRX Go to the allegro directory: c: cd \DJGPP\ALLEGRO and make all files: make This should produce all binaries using your newlyn installed DJGPP and all the examples too, do a CD EXAMPLES and experiment with all the examples: ex*.exe Some of them will give good implementations ideas besides showing what allegro can do. []'s HB - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 18:19:38 -0600 From: Phil McRevis Subject: Re: Porting Fractint (was Re: (fractdev) DOS support via allegro?) Humberto, if you're also working on DJGPP issues, that would be great to coordinate. My primary development platform is Borland C++ tools on the PC. I have downloaded djgpp but haven't installed it from the zips yet. In article , Humberto Rossetti Baptista writes: > If we can use a similar approach: an API to handel OS-specific stuff I > guess the rest of the problem would be clean the code from plataform > assumtions > and we could have Fractint running in several platforms (like XaoS for > instance). That's the idea exactly. I've outlined what I see (so far) as the OS specific issues in another message. - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 21:29:55 -0300 (EST) From: Humberto Rossetti Baptista Subject: Re: (fractdev) portability thoughts On Thu, 29 Apr 1999, Phil McRevis wrote: > memory allocation > memory "models" > virtual memory: mmap vs. home-brew file I/O cache > > Memory models disappear completely when dealing with a DPMI extender > port. Yep. > Fractint has elaborate strategies for coping with limited amounts of > memory for various situations. Would a flat-model port eliminate the > need for this parsimony? Do the DPMI's provide virtual memory? If > so, then I'd suggest ditching the parsimonious behavior in favor of > the VM from the DPMI. If the flat-model only eliminates near/far/huge > business but still leaves the need for being parsimonious, then the > disk caching logic and so-on should remain. The "extender" used to put a app in flat mode (32 bit) in DOS and the DPMI server should handle ALL memory stuff. Other platforms do this nicely (linux for instance) so we shoud invest as little as possible in this. As the DPMI + extender do this for uss let's not mess more with overlays, memory models and disk caching strats. > signals > > There are differences between unices. Some signal handlers return > void, some return int. Autoconf can handle this. As of now fractint does not need to handle them except in specific platforms (unix) so we could leave them to be dealt with later. > compilation issues / portability / assembler I was converned w/ the assembly part of fractint, but is easy to avoid it completly as the Xfractint code already does. As tim pointed out this is the way we should go: Make Xfractint more portable, maybe running in DOS and Linux and then clean things up. > autoconf I've never dealt w/ autoconf in the developpers role, but I am seing a lot of stuff here that isn't essential to put things up and running in a portable manner. > The arbitrary precision arithmetic routines used by fractint aren't > portable to non-x86 platforms. However, the gmp (GNU multiple Why not? I havent checked this myself but if I recall right it has a nice C version of everything that is MP related. Tim? > Given the other items on the portability menu, I'd rank this as a > rather low-priority item. (On the other hand, if you deseperately > want xfractint calculating arbitrary precision M-sets on a cray, you > might prioritize it higher. :-) Yesssss. And also I think gmp is C++ isnt' it? Humberto R. Baptista humberto@insite.com.br - --------------------------------------------------------------------------- Insite - Solucoes Internet http://www.insite.com.br - -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@ L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@ t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++ y+++* - ------END GEEK CODE BLOCK------ - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 21:37:20 -0300 (EST) From: Humberto Rossetti Baptista Subject: (fractdev) Porting fractint strategies (32bit flat mem. model etc.) List, I wish to help a little with some simple suggestions to all that are thinking/working with the portability issue: a) let's release a "last" 16 bit versino ASAP (Tim?) and feature freeze it (just correct bugs). b) Let's concentrate in put up a version running in DJGPP/DOS (or gcc/Linux, wichever has the larger number of developpers willing to help) with the LEAST modiffications needed. I think this should be done in the api manner XaoS does as "Phil" pointed, but without adding to much fuzz to the process and then c) Hunt down all others platform-centric issues and remove historic code (that wont'be used any more) together with: d) work on the low level drivers to several platforms (using the API) to spread the Fractint development further more. The b) item seems like a bottleneck point to me, that's why i'm insisting in the simplicity approach :-) After it is done we can work in paralell, cleaning code, porting, and (of COURSE) coding new stuff for Fractint :->>> []'s Humberto R. Baptista humberto@insite.com.br - --------------------------------------------------------------------------- Insite - Solucoes Internet http://www.insite.com.br - -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@ L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@ t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++ y+++* - ------END GEEK CODE BLOCK------ - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 21:46:19 -0300 (EST) From: Humberto Rossetti Baptista Subject: Re: Porting Fractint (was Re: (fractdev) DOS support via allegro?) On Thu, 29 Apr 1999, Phil McRevis wrote: > Humberto, if you're also working on DJGPP issues, that would be great > to coordinate. My primary development platform is Borland C++ tools > on the PC. I have downloaded djgpp but haven't installed it from the > zips yet. Frankly I've been using Borland tools anlo and just recently downloaded the djgpp (and Allegro and rhide a nice IDE for DJGPP, very similar to borland's) and it is GREAT. Works very well. See if my draft of DJGPP howto helps! :-))))) (it's already posted). > That's the idea exactly. I've outlined what I see (so far) as the OS > specific issues in another message. Speaking of "echo" :-) Right I've read it and I think I've being doing it wrong in not sharing the experiences with the list, so all of you jus cope w/ me while I compensate for that :-) XaoS approach to the platform-api is to put all variables and function adresess specifict to that platform in a big struct and go for it. I am thinking if we should do the same or if there would be any gain to slpit the api in several areas (for instance graphics, sound, mice/keyboard, disk related etc.) What do you think?? []'s Humberto R. Baptista humberto@insite.com.br - --------------------------------------------------------------------------- Insite - Solucoes Internet http://www.insite.com.br - -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@ L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@ t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++ y+++* - ------END GEEK CODE BLOCK------ - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 18:50:31 -0600 From: Phil McRevis Subject: Re: (fractdev) portability thoughts In article , Humberto Rossetti Baptista writes: > I've never dealt w/ autoconf in the developpers role, but I am seing a > lot of stuff here that isn't essential to put things up and running in a > portable manner. What things are you seeing that aren't essential? All the things I listed are portability issues. > > The arbitrary precision arithmetic routines used by fractint aren't > > portable to non-x86 platforms. However, the gmp (GNU multiple > > Why not? I havent checked this myself but if I recall right it has a > nice C version of everything that is MP related. Tim? Some low-level stuff is written in assembly, see bigflta.asm and bignuma.asm. Poking around a little more, it looks like bigfltc.c implements C versions of the assembly routines. As I say, I consider switching to gmp to be a very low-priority item, i.e. one of optimization not one of correctness. You want to do it eventually to get fast MP support on more than just x86 DOS platforms. (Even x86 linux can't take advantage of the x86 assembly for fractint's MP math since the assembly is 16-bit!) > Yesssss. And also I think gmp is C++ isnt' it? gmp is ANSI C. - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 18:53:51 -0600 From: Phil McRevis Subject: Re: (fractdev) Porting fractint strategies (32bit flat mem. model etc.) Humberto, what you propose is exactly inline with my thinking. I'm already signed up for the "driver harness" a la XaoS and adjusting the existing xfract code to use the harness. Then I'll remove all memory model stuff. That should serve as the starting point for whoever adds display driver support back in for the DOS DJGPP side of things. There are places where parallel developers can work without bumping into each other (different display driver implementations), but its probably best to have just one person overhaul the central control logic and associated glue to the driver. We've kinda talked about this forever so I just got sick of talking about it and I'm doing it. :-) - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 19:03:41 -0600 From: Phil McRevis Subject: Re: Porting Fractint (was Re: (fractdev) DOS support via allegro?) In article , Humberto Rossetti Baptista writes: > XaoS approach to the platform-api is to put all variables and function > adresess specifict to that platform in a big struct and go for it. I am think ing > if we should do the same or if there would be any gain to slpit the api in > several areas (for instance graphics, sound, mice/keyboard, disk related etc. ) > What do you think?? I'm thinking that the driver keeps private any data that it needs only to get its job done. Under X11, that means things like pixel lookup tables, dynamically allocated X resources (windows, pixmaps, colormaps, GCs, etc.) and so-on. These are visible only to the driver. Then there is a collection of stuff that is supplied to fractint for handling the video driver support. This is basically an array of structures that define video mode characteristics. Currently this collection of settings is couched in very PC-centric terms, right down to the interrupt call arguments! That basic idea would remain the same with display drivers, however. What changes is the control logic that initializes the table at program startup-time (and possibly updating it during runtime). Right now the table is created from fractint.cfg as a fixed list. Some of the data currently stored in the table (like PC interrupt arguments) becomes private data of the driver. The rest remains relevant as a result from a driver when its queried from fractint. - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 22:06:12 -0300 (EST) From: Humberto Rossetti Baptista Subject: Re: (fractdev) Porting fractint strategies (32bit flat mem. model etc.) On Thu, 29 Apr 1999, Phil McRevis wrote: > Humberto, what you propose is exactly inline with my thinking. I'm excelent. > probably best to have just one person overhaul the central control > logic and associated glue to the driver. We've kinda talked about This is exatcly why i called this a bottleneck. > this forever so I just got sick of talking about it and I'm doing it. > :-) Cool. I do not have a lot of time spare right now, but if you need any help just say so. PS: got the DJGPP howto? []'s Humberto R. Baptista humberto@insite.com.br - --------------------------------------------------------------------------- Insite - Solucoes Internet http://www.insite.com.br - -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@ L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@ t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++ y+++* - ------END GEEK CODE BLOCK------ - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 22:18:19 -0300 (EST) From: Humberto Rossetti Baptista Subject: Re: (fractdev) portability thoughts On Thu, 29 Apr 1999, Phil McRevis wrote: > What things are you seeing that aren't essential? All the things I > listed are portability issues. Yes, but you have already pointed that some are less priority than others :-) Also some things are not done properly but are done like the handling of \ and / (i guess it is in port.h as several other stuff like data types are also defined). []'s Humberto R. Baptista humberto@insite.com.br - --------------------------------------------------------------------------- Insite - Solucoes Internet http://www.insite.com.br - -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@ L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@ t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++ y+++* - ------END GEEK CODE BLOCK------ - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 20:27:53 -0500 From: "Damien M. Jones" Subject: Re: (fractdev) C++ templates and generic programming and fractint! :) Rich, - Ah, but here you're using the inheritence/OOness of C++ to exploit - reuse. The generic programming/template model, as embodied by the STL - for example, is really quite a different kind of reuse than that - provided by class hierarchies. My mistake, I thought you were referring to inheritance with different terminology, and not the STL. You're right, that IS different. And yes, I was using inheritance to exploit reuse. Damien M. Jones \\ dmj@fractalus.com \\ Fractalus Galleries & Info: \\ http://www.fractalus.com/ Please do not post my e-mail address on a web site or in a newsgroup. Thank you. - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 19:55:01 -0600 From: Phil McRevis Subject: (fractdev) driver characteristics Since Humberto brought up some specifics of drivers, I'll say a little about how I'm implementing the driver harness. Naturally we'll be able to change the harness later. The point is not to design some end-all be-all graphics API. The idea is just to get things going incrementally. Feel free to kibitz, if its a big issue, something can be done now, but please consider this more of a 'status report' for your information on what I'm doing, more than a design review where I'm proposing the idea. :-) Existing video mode glue logic in fractint is currently implemented in select_video_mode(). It walks through the table stored in memory and creates the scrollable display of available video modes. When you select a mode from the list (or by some other means like video=), then the proper parameters are snatched out of the table and sent to the assembly routine setvideomode (video.asm), which issues the appropriate commands to the video card. With the harness, select_video_mode() instead walks a list of drivers and queries each driver about the modes supported by the driver. It then displays a scrolling list created from the driver responses. When the user selects an item on the list, select_video_mode() calls through the driver harness to set the video mode. This means that when we get to the point of having all (or several) or the drivers I list below, under win98 you could have the choice of the same video modes supported by multiple drivers. The video display list might look like this: key...driver...name.................xdot.ydot.color.comment............. SF1 win32 GDI Surface 1024x768 5:6:5 SF2 directx Windowed 1024x768 5:6:5 SF3 directx Full Screen 1024x768 8 256 colors SF4 directx Full Screen 1024x768 5:6:5 16-bit RGB SF5 directx Full Screen 1024x768 5:5:5 15-bit RGB SF6 opengl Full Screen 1024x768 8 256 color indexed SF7 opengl Full Screen 1024x768 8:8:8 24-bit RGB (This is an ASCII graphic mockup; not a screen dump.) Xdot and ydot take on a subtle meaning in a windowed environment, but window systemless drivers still need to be able to report device dimensions. The video parameter ('video=') currently only specifies a function key which is bound to a video mode. It doesn't force a particular video mode, just selects one from the key list. If you want to write a script or parameter file that uses a particular video mode, you have to ensure the proper key assignment is setup first. To set the function key assignment you have to get into the fractint.cfg file. Icky! With the harness, the video parameter is updated to specify both the driver and the desires video mode provided by the driver. So you'd say something like "video=directx/1024x768/8". A new method for binding the keys to video modes will have to be provided, as the old method depended on fractint.cfg which is now specific to the fractint driver. But what about the stuff the fractint.cfg file did? That's used by the "fractint" driver (see blow) as input to decide what video modes it lists when queried. Some really random ideas: should image and model formats (3D raytracing files, etc) be supported as compile-time modules like drivers? should drivers be allowed to invoke the engine distinct from fractint's gui? Is the engine a client of the driver, or is the driver a client of the engine? Fractint is currently architected towards the latter. Reversing the assumption would be difficult. should 3D drivers subsume 2D functionality? Is there any reason you'd want to use ogl for 3D, but x11 for 2D? If not, then "x11" and "opengl" drivers will provide everything you need. Select an "x11' driver video mode for 2D stuff and an "opengl" driver video mode for 3D stuff. Fractint doesn't (yet) mix 2D and 3D rendering together. Drivers - ------- display drivers I think should be done, in no particular order: "curses" possibly uses curses, but only has character I/O. Displays "pixels" using characters as similar to XaoS. Enumerate text vide modes (DOS) or screen sizes (curses?) to form "video modes" table. Works in DOS (pd curses) and unix (native curses). "fractint" port existing fractint assembly code to 32-bit flat model. Included is the native video and mouse support coded in assembly. "allegro" Uses Allegro library under DJGPP to enumerate video formats and provide video/mouse/sound support. "disk" Video modes contain list of standard image sizes and "custom", letting you set the size. "win32" text menus are displayed graphically somehow. graphics display native to GDI presented as video mode. Emulate other modes? Only if someone desperate for it -- directx would be the preferred solution! "directx" text menus are displayed using a regular win32 window on GDI surface, or as graphic text on graphics screen (driver option). graphics display is done through full-screen with DirectDraw. DirectDrawDevices enumerated by DDraw are the video modes. "direct3d" Same as directx, but uses D3D for 3D effects. "x11" Text menus are displayed graphically using X11. Available visuals on the screen are the video modes. "opengl" Same as X11, only OGL-capable visuals are video modes. Uses OGL for all pixel I/O and 3D. like XaoS, more that one driver can be available, but only one driver can be active at once in any given graphic window. - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 23:44:47 -0300 (EST) From: Humberto Rossetti Baptista Subject: Re: (fractdev) driver characteristics On Thu, 29 Apr 1999, Phil McRevis wrote: [... description of select_video_mode] Just to clear things for me: are you taking for a staring point the fractint or the xfractint code (the 2 are the same, but w/ different #defines ) [... harnessing the video mode] > With the harness, the video parameter is updated to specify both the > driver and the desires video mode provided by the driver. So you'd > say something like "video=directx/1024x768/8". A new method for > binding the keys to video modes will have to be provided, as the old > method depended on fractint.cfg which is now specific to the fractint > driver. That is very nice. Seems ok, but in one given platform there will be all the drivers to all the platforms or just the ones concerning that one platform? > should image and model formats (3D raytracing files, etc) be > supported as compile-time modules like drivers? That is also a nice idea. [...] > Drivers > ------- > display drivers I think should be done, in no particular order: > "curses" > possibly uses curses, but only has character I/O. > Displays "pixels" using characters as similar to XaoS. I guess this is aalib ?? It is not curses but i guess if could be seen as though it is. Wouldn't it be interesting to abandon the text mode completly and user the graphic mode for messages also? This could lead with work and time to an uniform fractint gui look all across different platforms. []'s Humberto R. Baptista humberto@insite.com.br - --------------------------------------------------------------------------- Insite - Solucoes Internet http://www.insite.com.br - -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GB/C/CA/CM/CS/CC/ED/FA/H/IT/L/M/MU/P/S d?>dpu s:- a->!@ C++++$ USL+++$ P+++@ L+++@ !E W++@ N++(+)@ o+>++++$ K? w>---$ O-@$ M--@ V-- PS@ PE@ Y+>+++$ PGP+@ t+++ 5+@ X+ R>+++$ tv@ b+>++++$ DI++$ D++>++++$ G e+++>++++ h(---)>*$ r+++ y+++* - ------END GEEK CODE BLOCK------ - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 21:15:56 -0600 From: Phil McRevis Subject: Re: (fractdev) driver characteristics In article , Humberto Rossetti Baptista writes: > Just to clear things for me: are you taking for a staring point the > fractint or the xfractint code (the 2 are the same, but w/ different #defines ) The answer to your question is yes and no. :-) I'm using xfractint 19.61 pl66 code. The differences between xfractint 19.61 pl66 and fractint 19.61 pl66 are the inclusion of assembly files on the fractint side, with corresponding .c files on the xfractint side. For instance, here's the source in my xfractint directory (datafiles removed for clarity): 3d.c end1.c hc* lsys.h rotate.c evolve.c hc.c lsysf.c slideshw.c externs.h hcmplx.c makefile soi.c ant.c f16.c help.c memory.c soi1.c big.h file_id.diz help.src miscfrac.c stereo.c bigflt.c fpu087.c help2.src miscovl.c targa.c biginit.c frachelp.mak help3.src miscres.c targa.h biginit.h fracsuba.c help4.src mpmath.h targa_lc.h bignum.c fracsubr.c help5.src mpmath_c.c testpt.c bignumc.c fractalb.c helpcom.h parser.c tgaview.c bigport.h fractalp.c helpdefs.h parserfp.c tplus.c calcfrac.c fractals.c intro.c plot3d.c tplus.h calcmand.c fractint.c jb.c port.h tplus_a.c calmanfp.c fractint.h jiim.c port.new tru.c cmdfiles.c fractint.ifs line3d.c printer.c unix.c cmplx.h fractype.h loadfdos.c prompts1.c unix.h decoder.c framain2.c loadfile.c prompts2.c unixscr.c diskvid.c frasetup.c loadmap.c prototyp.h video.c diskvidu.c lorenz.c read.me yourvid.c editpal.c general.c lsys.c realdos.c zoom.c encoder.c gifview.c And here's fractint 19.61 source: 3d.c calmanfp.asm fractint.h loadfile.c port.h cmdfiles.c fractint.mak loadmap.c printer.c ant.c cmplx.h fractype.h lorenz.c prompts1.c bcauto.bat decoder.c framain2.c lsys.c prompts2.c bcfract.bat diskvid.c frasetup.c lsys.h prototyp.h bcfract.cfg editpal.c general.asm lsysa.asm realdos.c bcfract.mak encoder.c gifview.c lsysaf.asm rotate.c bcfract2.cfg externs.h hc.c lsysf.c slideshw.c bclinkf.bat f16.c hcmplx.c lyapunov.asm stereo.c bcmakall.bat fmath.h help.c makefrac.bat targa.c bigflt.c fpu087.asm help.src miscfrac.c targa.h bigflt.h fpu387.asm help2.src miscovl.c targa_lc.h bigflta.asm fr8514a.asm help3.src miscres.c testpt.c bigfltc.c frachelp.mak help4.src mpmath.h tgaview.c biginit.c fracsuba.asm help5.src mpmath_a.asm tplus.c biginit.h fracsubr.c helpcom.h mpmath_c.c tplus.dat bignum.c fractalb.c hgcfra.asm newton.asm tplus.h bignum.h fractalp.c intro.c parser.c tplus_a.asm bignuma.asm fractals.c jb.c parsera.asm video.asm bignumc.c fractint.c jiim.c parserfp.c yourvid.c calcfrac.c fractint.cfg line3d.c plot3d.c zoom.c calcmand.asm fractint.def loadfdos.c I think the makefiles are also different; otherwise they share all the same .h and .c source with #ifdef XFRACT in the few places where it matters. The driver harness goes in some of the places where XFRACT is currently used. Then fractint and xfractint will be using the same source with even fewer #ifdef XFRACT's sprinkled around the code. >That is very nice. Seems ok, but in one given platform there will be all > the drivers to all the platforms or just the ones concerning that one >platform? Its identical to what XaoS does. (XaoS uses autoconf) The configure script probes the compilation system to determine what features are available. configure determines what drivers will be available at runtime. Alternatively, you can set #defines in your build process to attempt to compile support for a particular driver. Of course, someone will have to implement the driver before it can be compiled :-). > > Drivers > > ------- > > display drivers I think should be done, in no particular order: > > "curses" > > possibly uses curses, but only has character I/O. > > Displays "pixels" using characters as similar to XaoS. > > I guess this is aalib ?? It is not curses but i guess if could be seen > as though it is. Umm... oh yeah, I think I looked at aalib, which is a full-blown 2D graphics package that renders to text. Kinda cool, but no its not necessarily to use something that fancy for a curses driver. Fractint really doesn't need anything more fancy than getpixel and putpixel for graphics it turns out. Amazingly modular... I'm surprised more people didn't just assume they could bcopy() indices straight onto the display. > Wouldn't it be interesting to abandon the text mode completly and user > the graphic mode for messages also? This could lead with work and time to an > uniform fractint gui look all across different platforms. What I suggested for the window system drivers is that they do exactly that. Curses may or may not be available on the system (system dependency). But a window system driver has the capacity to draw text into its window directly. It doesn't need curses to draw text. In fake, it gets more complicated (to me anyway) to have curses doing text and X11 doing graphics. - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT legalize@xmission.com - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 21:21:21 -0600 From: Phil McRevis Subject: (fractdev) the credits screen Tim, the credits screen just smacked me in the face like a conceptual ton of bricks. The stone soup tradition of fractint is more than just a concept of open source software, its the cumulative non-violent cooperative effort of all those *people* in the credits screen. I know on some of the other fractal lists there's been heated debate about fractint's open source tradition vs. the new kids on the block. :-). But I couldn't think of another program that starts up with a credits screen, the way a good action movie blasts the credits up quick in the beginning so that you can be on the edge of your seat for the entire ride. Sure, lots of programs have about boxes and thanks lists and so on. But of all the open source software I use, I couldn't think of one that embodies the stone soup tradition of mutual cooperation more than fractint. - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ Date: Thu, 29 Apr 1999 23:32:15 -0600 From: Phil McRevis Subject: (fractdev) 'xfractint makedoc' segfaults around page 220 Has anyone else seen this? It chunks away seemingly normally for about 222 pages in Appendix H when it crashes with a seg fault. Program received signal SIGSEGV, Segmentation fault. 0x98294 in printerc (info=0xeffff0d8, c=12, n=0) at help.c:1113 (gdb) where #0 0x98294 in printerc (info=0xeffff0d8, c=12, n=0) at help.c:1113 #1 0x98acc in print_doc_output (cmd=1, pd=0xeffff008, info=0xeffff0d8) at help.c:1254 #2 0x944c4 in process_document (get_info=0x9848c , output=0x98808 , info=0xeffff0d8) at helpcom.h:459 #3 0x99100 in print_document ( outfname=0x756d6d61
, msg_func=0x7279206f <_end+42538935>, save_extraseg=1713391218) at help.c:1403 #4 0x52498 in cmdarg (curarg=Cannot access memory at address 0x230044. ) at cmdfiles.c:1158 Cannot access memory at address 0x230038. (gdb) l help.c 1110 Junk at end of line specification. (gdb) l "help.c":1110 No source file named "help.c". (gdb) l help.c:1110 1105 { 1106 if (c==' ') 1107 ++info->spaces; 1108 1109 else if (c=='\n' || c=='\f') 1110 { 1111 info->start_of_line = 1; 1112 info->spaces = 0; /* strip spaces before a new-line */ 1113 putc(c, info->file); 1114 } #1 0x98acc in print_doc_output (cmd=1, pd=0xeffff008, info=0xeffff0d8) at help.c:1254 (gdb) l 1249 return ( keep_going ); 1250 } 1251 1252 case PD_FOOTING: 1253 info->margin = 0; 1254 printerc(info, '\f', 1); 1255 info->margin = PAGE_INDENT; 1256 return (1); 1257 1258 case PD_PRINT: #2 0x944c4 in process_document (get_info=0x9848c , output=0x98808 , info=0xeffff0d8) at helpcom.h:459 (gdb) l 454 if ( !output(PD_START_SECTION, &pd, info) ) 455 return (0); 456 457 if ( pd.new_page && pd.lnum != 0 ) 458 { 459 if ( !output(PD_FOOTING, &pd, info) ) 460 return (0); 461 ++pd.pnum; 462 pd.lnum = 0; 463 if ( !output(PD_HEADING, &pd, info) ) #3 0x99100 in print_document ( outfname=0x756d6d61
, msg_func=0x7279206f <_end+42538935>, save_extraseg=1713391218) at help.c:1403 (gdb) l 1398 1399 info.margin = PAGE_INDENT; 1400 info.start_of_line = 1; 1401 info.spaces = 0; 1402 1403 success = process_document((PD_FUNC)print_doc_get_info, 1404 (PD_FUNC)print_doc_output, &info); 1405 fclose(info.file); 1406 1407 if ( save_extraseg ) #4 0x52498 in cmdarg (curarg=Cannot access memory at address 0x230044. ) at cmdfiles.c:1158 (gdb) l 1153 escape_exit = yesnoval[0]; 1154 return 3; 1155 } 1156 1157 if (far_strcmp(variable,s_makedoc) == 0) { 1158 print_document(*value ? value : "fractint.doc", makedoc_msg_func, 0); 1159 #ifndef WINFRACT 1160 goodbye(); 1161 #endif 1162 } (gdb) q The program is running. Quit anyway (and kill it)? (y or n) y Debugger finished - -- Legalize Adulthood! ``Ain't it funny that they all fire the pistol, at the wrong end of the race?''--PDBT - -------------------------------------------------------------- Thanks for using Fractdev, The Fractint Developer's Discussion List Post Message: fractdev@lists.xmission.com Get Commands: majordomo@lists.xmission.com "help" Administrator: twegner@phoenix.net Unsubscribe: majordomo@lists.xmission.com "unsubscribe fractdev" ------------------------------ End of fractdev-digest V1 #21 *****************************