I was originally writing this to Paul, but it became a general audience message :-). In article <002201c74408$28210bf0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Let me know how I can help.
How's your x86 assembly? :-P Seriously, we could really use some help on getting C versions of the existing x86 assembly fractal code. I've already taken care of the code in the non-fractal computing assembly files, with C code created for the X11 port and my driver abstraction (which takes care of the keyboard and video stuff). This could be done by tweaking the assembly and putting it in an __asm {} block, or it could be done by translating the assembly code into C, whichever is easiest for whoever does it :-).
One other thing I would like to do is real time 3d transforms rather than all the tedious mucking about with files.
For the 3D stuff, trust me I soooo understand what you're talking about! However, going back to the roadmap I posted earlier, there is more work to do on the 'basics' of the application before I think we should add more features. I mean, its great the way fractint evolved organically but that evolution has run up a cul-de-sac with the 16-bit assembly and DOSisms. Right now, we're still saddled with them -- I'm mostly dodging bullets and faking things out! I like the things you want to add -- but we still have to gut this house and reconstruct it a little bit more. Its like Katrina hit the fractint code and I've made it so the roof doesn't leak anymore, but don't try to use the bathroom! :) I haven't even gotten the X11 driver up and working yet. We need to do that in this "limp along" world so that we can merge back onto the HEAD. It makes sense for me to do this as i) I know X11, ii) I know the driver code having done 2 drivers for it so far (Win32 disk and Win32 GDI), iii) I know the code as it stands on the branch. Also, the sound code is not there yet. It should probably use DirectSound or some such. How's your knowledge of the sound stuff? The code on the branch is completely gutted of all the weird overlay and 16-bit isms that are still on the HEAD. All near/medium/far pointer stuff is GONE. All overlay stuff is GONE. All the assembly code is GONE. (Well, there's a tiny bit that I inlined as __asm {} blocks as a stopgap for the moment; I don't know if it works right.) The priorities right now are: - get C/__asm versions of all the assembly fractal computing code - get the X11 driver working - get the sound support back - get the Win32 code working in indexed color desktops *That* will be the end of the beta, and that's still quite a bit of work. Once we are that stage, then I want to: - separate engine from UI code - change the UI from polling to event driven - create a real Win32 UI (what we have now is Win32 pretending to look like CGA text screens) Then I will feel like its time to add new features. I know that probably dampens your enthusiasm as none of the things I outlined above are "fun". They're plodding, boring and require fairly extensive reworks to the existing code base. The application architecture of fractint is as old as fractint itself -- 15+ years -- and it shows. I wasn't there at the time, but when the Windows 3.1 port was done, IMO it should have gutted the DOS architecture and gone whole hog Windows. I can only guess that it didn't happen that way because screen updates in 3.1 were slow compared to DOS, which is why DOOM was written as a DOS app and not as a Windows app. However, clinging to the DOS world -- while initially a reasonable compromise -- has left us in the situation we have today. People just aren't interested in working on it that much until it becomes like a "normal" Win32 application. Even though I've made it *work* under Win32, its still far from "normal". Places where others could help out today: - get C versions of the assembly code that computes fractal types - work on the X11 driver (anyone could do it if they know X11; I just don't think anyone else is interested!) - add more fractal types (can you ever have enough?!?) this sort of feature is not impacted by the UI much - implement Win32 sound support As I say above, I know these aren't "fun" but they are necessary if we want fractint to continue... All my opinion, of course; who else's opinion would it be? -- "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/>
Hi Richard, I would happily convert the asm code into c code if only I knew what it was supposed to do. That has been my problem all along. When I have looked at the code, I couldn't see what it was trying to do. But I am happy to help if I can. G'donya matie, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com] On Behalf Of Richard Sent: Tuesday, 30 January 2007 12:21 PM To: fractdev@mailman.xmission.com Subject: How you can help (was: [Fractdev] beta 3) How's your x86 assembly? :-P Seriously, we could really use some help on getting C versions of the existing x86 assembly fractal code. I've already taken care of the code in the non-fractal computing assembly files, with C code created for the X11 port and my driver abstraction (which takes care of the keyboard and video stuff). This could be done by tweaking the assembly and putting it in an __asm {} block, or it could be done by translating the assembly code into C, whichever is easiest for whoever does it :-).
In article <003501c7440f$23cb1b20$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
I would happily convert the asm code into c code if only I knew what it was supposed to do. [...]
I hear ya... Some kind sould was gracious enough to comment some of these routines with their C equivalents in a block comment at the top of the function. Translating those was easy :-). In order of preference, I would go with: - someone who knew the x86 assembly routines and would either: i) migrate it to __asm blocks, handling the 16/32 bit change ii) migrate it to C code for use on all platforms - someone who understands x86 assembly code, but not necessarily the routines and would do i) or ii) above - me migrating the code by method i) - me migrating the code by method ii) If noone else does it, I will do it, but it will take longer and probably be more buggy. :-) But hey, you've all waited for me to finish this "driver abstraction" since I first took a stab at it in 1999, so.... -- "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 would happily convert the asm code into c code if only I knew what it was supposed to do. [...]
I hear ya... Some kind sould was gracious enough to comment some of these routines with their C equivalents in a block comment at the top of the function. Translating those was easy :-).
In order of preference, I would go with:
- someone who knew the x86 assembly routines and would either: i) migrate it to __asm blocks, handling the 16/32 bit change ii) migrate it to C code for use on all platforms
- someone who understands x86 assembly code, but not necessarily the routines and would do i) or ii) above
I can do this. But, don't expect much output until after February due to work constraints. I'll be working six days a week. Jonathan
In article <1170206004.3914.1.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
In order of preference, I would go with:
- someone who knew the x86 assembly routines and would either: i) migrate it to __asm blocks, handling the 16/32 bit change ii) migrate it to C code for use on all platforms
- someone who understands x86 assembly code, but not necessarily the routines and would do i) or ii) above
I can do this. But, don't expect much output until after February due to work constraints. I'll be working six days a week.
Yay! That will be of tremendous help, Jonathan, thanks! -- "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 (3)
-
Jonathan Osuch -
Paul -
Richard