Summary of changes on the rt-refactor-device branch
- driver abstraction code merged in from my old xfractint sources - VS.NET 2003 project and solution files added - Win32 compiles and links without errors - Symbols renamed to avoid system header conflicts: DELETE => FIK_DELETE (conflicts with Win32 DELETE #define) virtual => virtual_screens (C++ keyword) overwrite => fract_overwrite (conflicts with curses) - added casts to eliminate compiler warnings; mostly this is because strlen() returns size_t (which is unsigned) and its used in a signed expression. - 30 compiler warnings remain in the code, all cast issues - XFRACT compiles on linux, but fails with unresolved link externals to the new driver layer. TODO: - Stub implementations need to be provided for a bunch of basic routines relating to timers, directories, and key I/O. - Examine the WinFract code to see how much of it can be stolen for a basic Win32 implementation. - Get the X11 version linking with a refactored XFRACT implementation. - Get a Win32 disk video mode going -- "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,
TODO:
- Stub implementations need to be provided for a bunch of basic routines relating to timers, directories, and key I/O.
- Examine the WinFract code to see how much of it can be stolen for a basic Win32 implementation.
- Get the X11 version linking with a refactored XFRACT implementation.
- Get a Win32 disk video mode going
You should take a look at the code in the experimental module. It has changes to your original implementation that were needed to clean up some problems. It's no where close to being up to date. Jonathan
In article <1164675287.3498.12.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
You should take a look at the code in the experimental module. [...]
What's the name of that module? I deduced the names of the existing modules by snooping around directories on dreamhost.com :-). I saw: fractint fractint-float allegro Is the allegro module the one you're talking about? -- "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,
You should take a look at the code in the experimental module. [...]
What's the name of that module? I deduced the names of the existing modules by snooping around directories on dreamhost.com :-).
I saw:
fractint fractint-float allegro
Is the allegro module the one you're talking about?
Ah, sorry, you're correct. The allegro module is the one you want. Jonathan
In article <1164764163.3567.0.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
You should take a look at the code in the experimental module. [...]
Is the allegro module the one you're talking about?
Ah, sorry, you're correct. The allegro module is the one you want.
OK, I looked through the Allegro module and I have these observations: - It looks like a fork of the fractint-float code; the integer code all appears to have been removed from allegro - added a delay routine to the driver interface - fixed the same bug I did that one of the sound routines returns int, not void :-) - "keypressed()" => "fkeypressed()"; I'm not sure of the reason for this change yet, but it appears consistent throughout. Am I missing anything else Jonathan? I didn't do an eyeball review of *every* file, but I did a diff between the allegro module and my xfractint code that I used as the basis for the merge. -- "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,
OK, I looked through the Allegro module and I have these observations:
- It looks like a fork of the fractint-float code; the integer code all appears to have been removed from allegro
- added a delay routine to the driver interface
- fixed the same bug I did that one of the sound routines returns int, not void :-)
- "keypressed()" => "fkeypressed()"; I'm not sure of the reason for this change yet, but it appears consistent throughout.
Am I missing anything else Jonathan? I didn't do an eyeball review of *every* file, but I did a diff between the allegro module and my xfractint code that I used as the basis for the merge.
Yes, it is branched from the float-only source. I believe I had to move at least one of the driver interface calls in fractint.c to keep it from crashing. keypressed got changed because it is an Allegro key word. I would suggest compiling and running the Allegro port, but the Allegro interface was/is in a constant state of flux, and it probably will no longer work. Just one of the reasons I stopped working on it. Still, the d_allegro.c file might provide you with some insights. Jonathan
In article <1164930291.3491.26.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
I believe I had to move at least one of the driver interface calls in fractint.c to keep it from crashing. keypressed got changed because it is an Allegro key word.
OK, that's good info. I'll look at fractint.c in more detail when I get a chance. I'll see if I can get the allegro module to compile too. -- "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 <1164930291.3491.26.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
I believe I had to move at least one of the driver interface calls in fractint.c to keep it from crashing.
I couldn't find any differences except float-only differences in fractint.c
I would suggest compiling and running the Allegro port [...]
What environment were you using for this? Linux? -- "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 believe I had to move at least one of the driver interface calls in fractint.c to keep it from crashing.
I couldn't find any differences except float-only differences in fractint.c
Hmm. I know I had to move one of the driver calls. I'll look around to see if I can find it.
I would suggest compiling and running the Allegro port [...]
What environment were you using for this? Linux?
Yes, Linux. The last version of Allegro that I used was 4.1.14. I'll try it with version 4.2. Jonathan
In article <1165011990.4111.6.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
I believe I had to move at least one of the driver interface calls in fractint.c to keep it from crashing.
I couldn't find any differences except float-only differences in fractint.c
Hmm. I know I had to move one of the driver calls. I'll look around to see if I can find it.
I could have missed it because there are a lot of extraneous diffs with the float-only changes.
I would suggest compiling and running the Allegro port [...]
What environment were you using for this? Linux?
Yes, Linux. The last version of Allegro that I used was 4.1.14. I'll try it with version 4.2.
OK, I don't have a linux box of my own, but I can attempt compiling it on xmission's shell which is linux. -- "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,
Hmm. I know I had to move one of the driver calls. I'll look around to see if I can find it.
I could have missed it because there are a lot of extraneous diffs with the float-only changes.
I believe what I'm thinking of is in framain2.c. There is a call to resizeWindow() that should be driver_resize(). There are a bunch of FIXME lines in the Allegro module. Most were put there by you, but some are mine. They may be worth looking at as a reminder. I did make changes to d_fract.c, d_disk.c, d_x11.c, drivers.c, and drivers.h, which may be worth a look. For example, I added a delay routine. You may be handling this differently. There are things I did in d_allegro.c that did not get carried over to d_x11.c. So, again, it's worth a look. You've also hard coded the number of colors at 256. One of my changes was to use the colors variable instead. This may have been a carry over from the older Xfractint code. As it stands, your branch will not compile under DOS because of the change to the definition of main() (int vs void). This is probably not a big concern unless we create a d_dos.c driver and try to save all the legacy code and the 16-bit environment. Jonathan
In article <1165672806.3522.12.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
I believe what I'm thinking of is in framain2.c. [...]
That's great feedback Jonathan. I'll see if I can reconcile this with my branch this weekend. I'll be taking off the whole week of Christmas and I'll be doing a big spurt of work on fractint then. I hope to have Win32 disk video working by the end of it at least. -- "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 (2)
-
Jonathan Osuch -
Richard