I've found a snapshot of my old code on my laptop and merged it into the existing fractint code (in the 'fractint' module). I've created a branch called 'rt-refactor-device' and I'm making commits on that branch. When I've got the branch compiling on Win32, I'd like someone to try compiling the branch for DOS and tell me how much stuff I broke :-). Originally I was targetting making the X11 version functional again before working on a Win32 version, but I think its going to be easier to go straight for a Win32 version working and then get the DOS code working again. I was actually nicely surprised how well most of the changes I'd made so long ago just 'merged' into the existing source base without any 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/>
Rich,
I've found a snapshot of my old code on my laptop and merged it into the existing fractint code (in the 'fractint' module). I've created a branch called 'rt-refactor-device' and I'm making commits on that branch.
I could be wrong, but it looks like your commits are going against HEAD instead of your branch. Jonathan
In article <1164460488.3512.7.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
I could be wrong, but it looks like your commits are going against HEAD instead of your branch.
Crap. You're right. I thought I had sticky tags on the folders... I will fix this right now by backing out the changes from HEAD and making sure everything is committing on the branch. Ah... wait, I think I know why this is happening. It was my mistake. :-) -- "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/>
OK, I think I got everything backed out now, thanks for the heads up Jonathan! What I did was make the mistake of copying a directory structure around and the CVS folders were all overwritten, so I ended up with the memory of the HEAD in the subfolders, but not in the top-level folder. -- "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/>
What's the current compilation environment for the DOS version? Maybe I can install it and check the DOS side myself. Is it VC5? -- "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,
What's the current compilation environment for the DOS version? Maybe I can install it and check the DOS side myself.
Is it VC5?
No, nothing near that recent. We're using MS C/C++ 7.0. I believe the problem is that after this version support for the 16-bit environment was removed. Jonathan
In article <1164484765.3512.14.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
Rich,
What's the current compilation environment for the DOS version? Maybe I can install it and check the DOS side myself.
Is it VC5?
No, nothing near that recent. We're using MS C/C++ 7.0. I believe the problem is that after this version support for the 16-bit environment was removed.
According to Wikipedia, Visual C++ 1.5 was the last version of Visual C++ to support 16-bit compilation. I can get Visual C++ 1.52 from MSDN Subscriber downloads, so let me see if that can compile the DOS code from the HEAD. -- "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/>
Richard wrote:
What's the current compilation environment for the DOS version? Maybe I can install it and check the DOS side myself. Is it VC5?
I thought it was prior to VC3, something closer to VC1. P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/
In article <4568A0D6.17A0@Worldnet.att.net>, "Paul N. Lee" <Paul.N.Lee@Worldnet.att.net> writes:
Richard wrote:
What's the current compilation environment for the DOS version? Maybe I can install it and check the DOS side myself. Is it VC5?
I thought it was prior to VC3, something closer to VC1.
Wikipedia states that VC2 was the first 32-bit only environment under the Visual C++ name. They don't have any information on the versions of the Microsoft C/C++ product, but do acknowledge that before it was Visual C++ it was Microsoft C/C++. -- "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/>
Richard wrote:
"Paul N. Lee" writes:
I thought it was prior to VC3, something closer to VC1.
Wikipedia states that VC2 was the first 32-bit only environment under the Visual C++ name.
Which is why one has to go back to VC1 (Visual C++ 1.5). I still have the old install of that lying around somewhere in a storage box (got to be at least 13 years old or so). Later, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html http://www.Nahee.com/Fractals/
In article <4568BB36.54B2@Worldnet.att.net>, "Paul N. Lee" <Paul.N.Lee@Worldnet.att.net> writes:
Richard wrote:
"Paul N. Lee" writes:
I thought it was prior to VC3, something closer to VC1.
Wikipedia states that VC2 was the first 32-bit only environment under the Visual C++ name.
Which is why one has to go back to VC1 (Visual C++ 1.5). I still have the old install of that lying around somewhere in a storage box (got to be at least 13 years old or so).
I got 1.52 off the MSDN subscriber downloads. It turns out you actually need an OS older than Windows 2000 in order to install the development environment :-). I had a VMWare image of a Win98 machine for testing and I've added a snapshot of the development tools on there. It looks like I could get everything to compile 16-bit if I created a new makefile or edited the existing makefiles. Do I need to setup some environment variables for NMAKE to just "do the right thing"? If I manually go into the common folder and do nmake /f common.mak then everything builds except parser.c and parserfp.c, which get lots of errors when comparing/assigning a far function pointer to a non-far function pointer. The struct member is declared far: void (far *f)(void); while the data variables are declared non-far: void (*StkNeg)(void) = dStkNeg; This does seem to be a legitimate problem when you compare or assign .f with StkNeg such as on line 1965: if(o[posp-1].f == StkNeg) { I didn't slug it through any farther than that. Has anyone else compiled the DOS application with Visual C++ 1.52? -- "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 <E1Go5qz-000374-00@xmission.xmission.com>, Richard <legalize@xmission.com> writes:
Do I need to setup some environment variables for NMAKE to just "do the right thing"?
If I manually go into the common folder and do
nmake /f common.mak
then everything builds except parser.c and parserfp.c [...]
Also, if I just attempt nmake /f fractint.mak from the top-level, then it says it can't find port.h when it compiles the stuff in common. I don't understand the problem there.... -- "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,
Do I need to setup some environment variables for NMAKE to just "do the right thing"?
The HELP, INCLUDE, INIT, and LIB environment variables should be set. The fractint specific variables are set up in the macro files macros_d and macros_w.
If I manually go into the common folder and do
nmake /f common.mak
then everything builds except parser.c and parserfp.c [...]
Also, if I just attempt
nmake /f fractint.mak
from the top-level, then it says it can't find port.h when it compiles the stuff in common. I don't understand the problem there....
I have a vague recollection of this. It has to do with the environment you are running in and how the recursion used by nmake is handled. Hmm, that doesn't sound so vague, does it? 8-)) How do you get to the command prompt? Do you run command.com or cmd.exe? Under XP, I use a shortcut to cmd.exe where I have edited the start directory to point to my top level fractint directory. If you are using Win98, that could be a problem (no cmd.exe). Jonathan
In article <1164545836.3523.17.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
Do I need to setup some environment variables for NMAKE to just "do the right thing"?
The HELP, INCLUDE, INIT, and LIB environment variables should be set. The fractint specific variables are set up in the macro files macros_d and macros_w.
OK, I'll look at that.
How do you get to the command prompt? Do you run command.com or cmd.exe? Under XP, I use a shortcut to cmd.exe where I have edited the start directory to point to my top level fractint directory. If you are using Win98, that could be a problem (no cmd.exe).
The compiler would only install on Win98 :-). So I'm using Win98 inside a VMWare and accessing the source tree on the host machine. I run command.com/exe on win98. -- "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,
The compiler would only install on Win98 :-). So I'm using Win98 inside a VMWare and accessing the source tree on the host machine. I run command.com/exe on win98.
I've been copying the MSC installed directories from computer to computer for about the last ten years. It requires some additional tweaks in the windows.ini file so some dll's can be found. Runs fine under XP. Jonathan
In article <1164568512.3558.5.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
The compiler would only install on Win98 :-). So I'm using Win98 inside a VMWare and accessing the source tree on the host machine. I run command.com/exe on win98.
I've been copying the MSC installed directories from computer to computer for about the last ten years. It requires some additional tweaks in the windows.ini file so some dll's can be found. Runs fine under XP.
I don't anticipate doing active development on the 16-bit version, so firing up the VM to do the occasional compile there is OK for me. -- Richard -- "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/>
OK, so I've got the code compiling. Now I just have a long list of undefined symbols :-). There are a variety of different concepts that are mashed into the "XFRACT" define, so I haven't been using that. I've been using _WIN32 to detect for my compilation environment. I'm not sharing anything with XFRACT or WINFRACT code bases, I'm just sharing with the core fractint code base. Some observations: - we should have a C layer for all the assembly language stuff I thought xfractint already had this and I steal code from the unix folder as needed, but it should probably be refactored more explicitly after I get this working. The WinFract code also has some assembly language stuff. - we should have a defined symbol for the fractint DOS code path Currently there is #ifndef XFRACT but I've had to modify all those to deal with stuff I *do* want and stuff I *don't* want for Win32. - string and memory handling is nuts! bcopy, memcpy, strcpy, make up your mind! :-) There are probably a gazillion bugs lurking around the code because of all the crazy string and memory handling and it looks like its only gotten worse since the last time I looked at the code base. I imagine its the tortured memory model of DOS apps that is causing most of this. - platform stuff should be factored out Timers, directory searching, math errors -- these are all things specific to a "computing platform" and should probably be refactored out cleanly. Right now all the video stuff and platform stuff is all glommed together into the win and unix folders, and the running assumption in the current code is that "new platform" equals "new video driver", but this isn't always the case. For instance, Win32 is a single platform that can support drivers for: disk, GDI, DirectX, OpenGL and X11. I'm probably breaking compilation of the DOS codepath by fiddling with the #defines, but just don't know it yet. I know for a fact that it won't compile as it is -- the driver abstraction has been introduced, but the existing fractint code has not been reworked into the driver framework. After I get the existing DOS code reworked into the driver framework, it would be very helpful if someone else could check out the branch and try compiling it. -- "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:
OK, so I've got the code compiling. Now I just have a long list of undefined symbols :-).
Looks like you have gotten a tremendous amount done in a short time. We need to think carefully about where to go from here. For starters we need to decide whether to attempt to get it to compile with the medium model 16 bit compiler. Since you have made changes with that possibility in mind, then it might be worth completing that program. On the other hand, if you get it working under WIndows in some fashion, maybe there's no need to keep the 16 bit compiler compatability. But I would think it is essential to get either the 16 bit or Linux versions working along with your windows version. Before doing any of the cleanups you mentioned it is essential to do a thorough audit of features and get as much working as possible. THis would probably take a while. I don't think there has been any global refactoring for a long time (maybe even ten years) so some of things you commented on have been there quite a while. Some of the cleanups (especially memory management) can't be done at all until we abandon the 16 bit environment. My suggestion is get all features working first, then systematically attack the cleanups you mentioned, though bring order to the defines may be necessary just to get thinbgs working. Tim
In article <4569E644.12856.1F0410@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Rich wrote:
OK, so I've got the code compiling. Now I just have a long list of undefined symbols :-).
Looks like you have gotten a tremendous amount done in a short time.
I was able to cheat by reusing what I had before. The source code hasn't changed much in the core functionality that I had refactored into the device interface.
We need to think carefully about where to go from here.
Agreed.
My suggestion is get all features working first, then systematically attack the cleanups you mentioned, though bring order to the defines may be necessary just to get thinbgs working.
I think we're in agreement on where to go from here. I know this has been discussed before, but refresh my memory on what's keeping the 16-bit code alive these days? :-) Are we interested in keeping a 'DOS only' version alive, even if its through a DPMI style flat memory model? Or are we truly ready to abandon DOS and embrace an event-driven window system model? The latter would really clean up the code substantially. Currently the I/O model is polling. The event stuff is jammed into the low-level keyboard I/O routines on the X11 and Windows ports so that when you check if a key has been pressed, the events get pumped. Having it truly be event driven would be a good refactor to do after the steps I've done this weekend. -- "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 asked:
I know this has been discussed before, but refresh my memory on what's keeping the 16-bit code alive these days? :-)
It's full featured, essentially bug free, and high performance. Plus it's 100% compatible with itself. :-) Other ports to the Windows platform have a lot of features missing.
Or are we truly ready to abandon DOS and embrace an event-driven window system model?
We are for sure ready when we have a full featured, backwards- compatible (in terms of PAR files) high performance version that the loyal user base is ready to migrate to from the DOS version. Is the basic functionality of your current version working? What works and what doesn't? Your work is certainly the most promising breakthrough in a long time for fractint if we can sustain it through a working version. Tim
Tim, What I have right now doesn't link yet :-). However, I notice where things are disabled for XFRACT that don't seem to be tied to assembly language, so I don't disable them with the #if. I'm trying to drag over anything that isn't assembly language and refactoring out the I/O. As we've discussed before, the engine is agnostic about its environment as long as it can do things like "put a pixel of a certain color here". One thing I just bumped into is in the multiple precision math code. There is a dependency on an assembly language routine, d2MP086, for which there is no corresponding C equivalent. That routine is coupled to code in mpmath_c.c, namely all the code that's commented out by the XFRACT declaration. The XFRACT path seems to comment out all the lStkXXX (L_MATH) and mStkXXX (M_MATH) math routines. For now, I'm going to follow suit, but it sounds like this is one of those things you would like brought over from the fractint side into a Windows application. Is there still some benefit to running L_MATH and M_MATH routines on a modern processor? If so, we need a C version of that assembly routine, at least for porting. We can work out a way to get the 32-bit assembly equivalent later if we need it in assembly for speed. (Although to be honest, if we were really going to write modern assembly for speed we should consider MMX/SSE style assembly for higher performance integer and floating-point.) -- "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 asked:
Is there still some benefit to running L_MATH and M_MATH routines on a modern processor?
I don't think so. In fact there's a float-only version in CVS that we maintained until recently. I think it's fallen a little behind, but could be brought up to the latest patch with a bit of work. This is probably moot since you started with the integer version. In my opinion (other's may disagree) we could ditch all integer math in your version. It's far more important to have have as much functionality as possible working the supported math types than to have all the math types working. I would rather spend finite developer resources that way then writing C equivalent's to integer math. But as with any open source project, he who is willing to do the work gets to decide. Tim
In article <456A0B9E.14964.762184@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Rich asked:
Is there still some benefit to running L_MATH and M_MATH routines on a modern processor?
I don't think so. [...]
That's what I thought too.
In my opinion (other's may disagree) we could ditch all integer math in your version. It's far more important to have have as much functionality as possible working the supported math types than to have all the math types working.
So how would we handle fractal types that are implemented only in L_MATH or M_MATH? I think that's the main reason why xfractint is missing so much stuf. If you look at all the stuff that's #ifdef'ed out, its all stuff using L_MATH or M_MATH (which seems to depend on L_MATH!). I'll have a look at the xfractint-float only code and see how it deals with this.
But as with any open source project, he who is willing to do the work gets to decide.
Mwuahahahahaha *rubs hands devilishly* -- "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'll have a look at the xfractint-float only code and see how it deals with this.
The float-only version is DOS, not sure if there's a Unix version. There's a whole tree for it in CVS. The regular Xfractint just ifdefs out the integer math; the float-only version removed it. Jontathan could tell you if there's an Xfractint version. I'm afraid I've misled you, though. Since you have already merged with the DOS version, best leave it. The float-only version does not have the latest patches. In any case I'd like to get Jonathan's take on this. Just ifdef out integer math - the XFRACT ifdefs are already there. In fact the smart thing for you to do is leave in the XFRACT defines and define them in your version, then make a new ifdef that excludes the X code. I really don't think there is ANY integer-only type, but I could be proven wrong. If we decide to take out the integer math we can. I did it once and I can do it again. There are a few gotchs, mainly leaving the fractalspecific array indices undisturbed. Tim
In article <456A13B2.26769.95B12A@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Just ifdef out integer math - the XFRACT ifdefs are already there.
This is what I've done so far. I've changed things like: #ifdef XFRACT ... #endif #ifndef XFRACT ... #endif to #if defined(XFRACT) || defined(_WIN32) and #if !defined(XFRACT) && !defined(_WIN32) on a case-by-case basis. This means that I am getting some stuff that xfractint leaves out, but not everything. For instance, I take the code path that deals with sound since my driver refactor dealt with that. (You'd want to use DirectX on Win32 for sound.) The XFRACT code path largely ignores anything with sound and implements stub routines to satisfy the linker. Back to the float-only version ... since it is a fork of the DOS code, wouldn't it be instructive to see diffs between the modules fractint and fractint-float? That would tell me the differences between the float-only version of fractint and the main version where I've made my changes. -- "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 <E1GoYie-0000Xk-00@xmission.xmission.com>, Richard <legalize@xmission.com> writes:
Back to the float-only version ... since it is a fork of the DOS code, wouldn't it be instructive to see diffs between the modules fractint and fractint-float? [...]
I did a folder diff using Beyond Compare 2 (I recommend this as your CVS diff/merge tool if you're not already using it!) and it was fairly easy to see what changed from the existing head to the float-only version. Lots of l* stuff deleted :-). So at some point I could merge all that stuff into my branch as well. Most of my changes affect I/O and most of the float-only changes affect computation so there should be few if any conflicts. -- "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/>
OK, it now compiles and links without error. This is quite a way from a working system however. First, I'll concentrate on getting the disk driver up and running. This has the simplest output, but still requires me to setup a window and whatnot. I can add GDI and DirectX support after I get the disk video mode working. -- "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/>
Hey, cool. After checking out the code on xmission's shell, I can compile xfractint on the HEAD with no errors. I can compile xfractint on the branch with no compile errors, but I get link errors. This is not surprising as I haven't updated the Makefile on the branch to account for the additional driver code. Still, that means I could probably get the xfractint version up to the point of testing sooner than I thought. -- "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/>
Down to 25 errors, 18 unresolved externals. Looks like we might be linking before the end of the evening. :-) -- "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/>
Woo hoo, down to < 100 link errors :-) -- "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 <4569F218.17587.126E91@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
It's full featured, essentially bug free, and high performance. Plus it's 100% compatible with itself. :-) Other ports to the Windows platform have a lot of features missing.
I see that now that I had to comment out L_MATH and M_MATH. There are a lot of fractals that are implemented using only those math types. If we had a fully C version of the L_MATH and M_MATH code, from inspection it looks like it will bring all that stuff back to life. -- "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 -
Paul N. Lee -
Richard -
Tim Wegner