OK, here is an initial stab at a beta. Known issues: - Sometimes the window size is confused when switching video modes. Workaround: switch to another mode, then switch back to the desired mode - After zooming around for a while with PAGEUP, the image freezes and the zoom box is not properly removed even when not zooming. Workaround: maybe changing a parameter slightly will help resync. - If the screen doesn't appear correctly, give it a second to flush any pending updates. You can also try minimizing/restoring the window to force a fulls creen repaint. - Close button most likely doesn't cause the app to exit all the way <http://www.xmission.com/~legalize/fractals/fractdev/FractIntSetup-21.00.beta1.msi> -- "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/>
1. Zoom Box: Left and right arrows work OK, but functionality of the up and down arrows (and with <ctrl> as well) are reversed. 2. Save doesn't show sidebar status. 3. Restore of image in a different (or maybe just larger?) resolution than the current video made causes Frac4Win to crash. Lee
2. Save sidebars do work, but from the bottom up. I didn't notice this before. 3. More on trying to restore - an error message states: The following files will be included in this error report: C:\DOCUME~1\Lee\LOCALS~1\Temp\6a3a_appcompat.txt But this file does not exist! 4. <L> command (browser) doesn't work. 5. <E> palette editor doesn't work Lee
In article <45AC1E21.1040204@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
4. <L> command (browser) doesn't work.
I think I have this 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 <45AC12F7.7000202@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
1. Zoom Box: Left and right arrows work OK, but functionality of the up and down arrows (and with <ctrl> as well) are reversed.
Do you still see this in beta 2?
3. Restore of image in a different (or maybe just larger?) resolution than the current video made causes Frac4Win to crash.
I just fixed this. I think we're nearing beta 3. -- "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/>
1. Zoom Box: Left and right arrows work OK, but functionality of the up and down arrows (and with <ctrl> as well) are reversed.
Do you still see this in beta 2?
No, it's fixed.
I think we're nearing beta 3.
Great! Lee
Rich wrote:
OK, here is an initial stab at a beta.
Wow!! This is really an accomplishment! Seeing high resolution images developing on the screen is really exciting. Even though we're not done, I give you all kinds of credit for having gotten this far, it was a daunting technical challenge for which you are more than a match. You may have reached a point where we can begin to help you, but that can be your call. I hardly did systematic testing, but after a few minutes: 1. the first formula type I tried had a syntax error. But darn, I didn't notice which one. I tried several others and they worked (at least, generated an image). I'll systematically check and rediscover which one it was. 2. I generated a mandelbrot before trying the formula type. The mandelbrot was still on the screen as the formula type generated. This didn't seem to cause as problem, but we should probably clear the screen. Now we need the services of a few fanatic fractint users to help fanatic user Lee Skinner :-). We need to systematically test different functionality and compare with the DOS version. Tim
Tim wrote:
Now we need the services of a few fanatic fractint users to help fanatic user Lee Skinner :-). We need to systematically test different functionality and compare with the DOS version.
Rich, i'm so glad to be amongst the first ones to shake your hand for such a good job! also, i volunteer to the comparative testing, having a DOS/W98 setup available at home.. Lee wrote:
1. up and down arrows are reversed 2. Save sidebars do work, but from the bottom up.
actually, everything renders bottom-up, ..have just verified it at the TAB screen.. also, Ctrl^Pad+ and Ctrl^Pad- zoombox rotation doesn't work.. mouse is not supposed to work yet, right? and those double-height video modes, as far as i can recall, there's some pixel aspect ratio variable burried somewhere.. ..wouldn't it be nice if one could specify the canvas size directly, say, at the view window prompt screen? (..well, later..) ..anyway, it's so encouraging! ;oE /charlie, the long-quiet-beholder/ P.S.: ..that original Fractint's keyboard operated UI is such a click-clack relief..
Hi Richard, Count me in for testing in a WIN XP environment :) Well dome matie, you have achieved what many of us have wanted to do for years. This is a major step forward. Thanks, 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=telstra.com@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=telstra.com@mailman.xmission.com] On Behalf Of charlie chernohorsky Sent: Tuesday, 16 January 2007 4:22 PM To: Fractint developer's list Subject: Re: [Fractdev] beta 1 Tim wrote:
Now we need the services of a few fanatic fractint users to help fanatic user Lee Skinner :-). We need to systematically test different functionality and compare with the DOS version.
Rich, i'm so glad to be amongst the first ones to shake your hand for such a good job! also, i volunteer to the comparative testing, having a DOS/W98 setup available at home.. Lee wrote:
1. up and down arrows are reversed 2. Save sidebars do work, but from the bottom up.
actually, everything renders bottom-up, ..have just verified it at the TAB screen.. also, Ctrl^Pad+ and Ctrl^Pad- zoombox rotation doesn't work.. mouse is not supposed to work yet, right? and those double-height video modes, as far as i can recall, there's some pixel aspect ratio variable burried somewhere.. ..wouldn't it be nice if one could specify the canvas size directly, say, at the view window prompt screen? (..well, later..) ..anyway, it's so encouraging! ;oE /charlie, the long-quiet-beholder/ P.S.: ..that original Fractint's keyboard operated UI is such a click-clack relief.. _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <1414.1995-1565-1053667122-1168924906@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
also, Ctrl^Pad+ and Ctrl^Pad- zoombox rotation doesn't work..
Can someone tell me if this works in beta 3? My laptop doesn't have a separate number pad, but I think I fixed 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/>
In article <45BEC0B2.3010405@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
also, Ctrl^Pad+ and Ctrl^Pad- zoombox rotation doesn't work..
No, it still doesn't work in beta 3.
Grrr. OK, I'll look into this more. What's your general impression of beta 3, Lee? -- "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 <45BECE89.9060602@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
What's your general impression of beta 3, Lee?
It looks pretty good now, I just wish it would execute a lot faster. It seems to be a couple of magnitudes slower than DOS. :-)
The speed issue is likely to be there for some time, probably until the application architecture is overhauled. Maybe Paul would like to try optimizing some of the display code? Its coded for "simplest thing that could possibly work" right now, not for speed. If you were coding a Win32 fractal plotter for speed from scratch, you would never do it this way! You would do it the way XaoS does things. However, we are getting to keep all the fractal type code this way, so its a trade-off. -- "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 Lee, Once I get CVS up and running and a copy of the source, I can look at some ideas that I have for updating the screen every second rather than every pixel. There would be a massive improvement in speed alone. There are a number of optimisations that can be performed if just working in RAM rather than to screen. 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----- The speed issue is likely to be there for some time, probably until the application architecture is overhauled. Maybe Paul would like to try optimizing some of the display code? Its coded for "simplest thing that could possibly work" right now, not for speed.
In article <005b01c7443a$57e42570$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Once I get CVS up and running and a copy of the source, I can look at some ideas that I have for updating the screen every second rather than every pixel.
It doesn't *quite* update to the screen every pixel. It accumulates a dirty region and redraws at most every time a key press is checked, but that's still a lot of drawing.
[...] There are a number of optimisations that can be performed if just working in RAM rather than to screen.
It works entirely in RAM right now. You *have* to do this in Windows because your window could get obscured and then exposed and you have to restore what was previously there. In other words, you can't depend on the "frame buffer" to remember what you drew to it -- so you have to have some sort of backing store. Right now this is an array of BYTEs and I redraw the screen from that with a StretchDIBits call. I could never get the rectangle blit working properly, so every time I draw its the whole screen, not the exposed portion. That would be a good change. There's lots more opportunities for speedy updates a la XaoS as well. XaoS is smart enough to reuse bits of your last computed image to compute the next image when you zoom in. However, it is still missing some major optimizations if you can believe that :-). This is part of why I want to separate the engine from the UI -- we need to get the engine computing on its own thread and once its separated we can also do some of the other display optimizations I want to try. -- "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, Yes I understand that it works in RAM, but does it calculate the memory address every pixel? How often is the screen refreshed? It looks like it is very often, if not every pixel. Just thinking out loud. 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----- It works entirely in RAM right now. You *have* to do this in Windows because your window could get obscured and then exposed and you have to restore what was previously there. In other words, you can't depend on the "frame buffer" to remember what you drew to it -- so you have to have some sort of backing store. Right now this is an array of BYTEs and I redraw the screen from that with a StretchDIBits call. I could never get the rectangle blit working properly, so every time I draw its the whole screen, not the exposed portion. That would be a good change. There's lots more opportunities for speedy updates a la XaoS as well. XaoS is smart enough to reuse bits of your last computed image to compute the next image when you zoom in. However, it is still missing some major optimizations if you can believe that :-). This is part of why I want to separate the engine from the UI -- we need to get the engine computing on its own thread and once its separated we can also do some of the other display optimizations I want to try. -- "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/> _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <00a701c744a4$1816a110$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Yes I understand that it works in RAM, but does it calculate the memory address every pixel?
Err... I'm not sure what you're getting at here. The fractint code computes scads of things every pixel; worrying about one memory address is hardly going to matter.
How often is the screen refreshed?
At most, every time it checks the keyboard for input.
It looks like it is very often, if not every pixel.
Yes, it is very often. The keyboard is checked a lot. -- "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 believe that this is where we can gain the greatest speed improvement. If the screen is refreshed often, there is a lot of work for windows to do here and that would cause a delay. Refreshing the screen after a delay will really help. Here is a sample of how it could be done: time_t last_time = 0; time_t update_time = 1; long pixelsout = 0L; extern RECT r; extern HWND PixelHwnd; // pointer to window handle for pixel updating /************************************************************************** Plot pixel **************************************************************************/ void outpoint(WORD x, WORD y, DWORD colour) { long i; time_t this_time; long local_width; Bla bla bla // check the time every nnn pixels if (++pixelsout > (BigNumFlag) ? 3 : 100) { pixelsout = 0; time(&this_time); if (this_time > (last_time + update_time)) { InvalidateRect(PixelHwnd, &r, FALSE); last_time = this_time; } } // put the pixel data to RAM here Bla bla bla } 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----- Yes, it is very often. The keyboard is checked a lot. -- "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/> _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <00b801c744ab$0633c160$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
I believe that this is where we can gain the greatest speed improvement.
Yeah, the winfract and x11 code had stuff in it to say "only draw stuff every N times you come in here to check if stuff should be drawn".
If the screen is refreshed often, there is a lot of work for windows to do here and that would cause a delay.
To be honest, I don't really notice it on my machine, but that doesn't mean much :) -- "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 and Paul
I believe that this is where we can gain the greatest speed improvement. If the screen is refreshed often, there is a lot of work for windows to do here and that would cause a delay. <<
On my machine, DOS Fractint completes the default Mandelbrot at 1600x1200 with symmetry=none and passes=1 in 3.16 seconds. In Windows, it's 110.75 sec. That's about 35 times slower! I hope you can get at least some improvement before releasing a general test version. It will make further testing go much faster! Then we can test arbitrary precision and some slower types, such as the MandelbrotMix4 and MandelbrotBC2 formula types that Jim Muth uses a lot. Lee
In article <45BFB90F.2000004@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
On my machine, DOS Fractint completes the default Mandelbrot at 1600x1200 with symmetry=none and passes=1 in 3.16 seconds. In Windows, it's 110.75 sec. That's about 35 times slower!
Its also the worst case. At this point, there's little to no difference between testing in 320x200 and 1600x1200.
make further testing go much faster! Then we can test arbitrary precision and some slower types, such as the MandelbrotMix4 and MandelbrotBC2 formula types that Jim Muth uses a lot.
There's nothing blocking testing of that right now... -- "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/>
There's nothing blocking testing of that right now...
True, except that these two formula types are generally much slower due to the exponentials and logs in the formulas - but if the Windows slowdown is based upon the number of pixels and not based on math calculation time, then they should have a much less noticeable speed ratio. I'll experiment with them. Lee
In article <45BFBC5E.4030608@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
There's nothing blocking testing of that right now...
True, except that these two formula types are generally much slower due to the exponentials and logs in the formulas - but if the Windows slowdown is based upon the number of pixels and not based on math calculation time, then they should have a much less noticeable speed ratio. I'll experiment with them.
Yes, the calculation time should be identical -- unless some things get faster because the optimizer in the current compiler is better than the previous compiler. And this is certainly the case. And yes, its the display that is not optimized and the work is proportional to the size of the image, so testing with 1600x1200 is going to be the slowest way to test... -- "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 <1414.1995-1565-1053667122-1168924906@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
also, Ctrl^Pad+ and Ctrl^Pad- zoombox rotation doesn't work..
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 <45D1385C.8030305@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
Just to be nitpicky: shouldn't the thread be beta 3 instead of beta 1?? :-)
The bug was reported in beta 1 and I keep the mail around until I've fixed everything mentioned in it. The BUGS.txt lists problems in the order they are reported as well. -- "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 <45D13BFB.6060001@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
The bug was reported in beta 1 and I keep the mail around until I've fixed everything mentioned in it.
I see! I was under the impression that all bugs reported in beta 1 and beta 2 had already been fixed.
Some bugs are easier to fix than others... when you install the beta there is a "known problems" shortcut that opens BUGS.txt which describes all the outstanding bugs I know about.
Will beta 4 be available soon?
Yes, there's one more bug I want to fix before releasing beta 4. -- "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 <45ABF2FD.15109.634091@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Wow!! This is really an accomplishment! [...]
Thanks
match. You may have reached a point where we can begin to help you, but that can be your call.
Feel free to dive in at any time :-). I think the driver code has everything it needs in terms of hooks, but that there are some things like side-effects through global variables where my driver code is off. Things like calling such-and-such a routine is supposed to set global variables but I don't set them, or such-and-such a routine is supposed to be influenced by global variables, but my routine doesn't use them. In those situations, familiarity with the existing fractint DOS code, particularly the assembly code, will be helpful in spotting and correcting those errors. There is a certain "clunkiness" to the whole UI. Unless I see an easy way to fix those issues, I say let it stay clunky, as long as its correct, until the whole polling DOS mode is refactored out of the code.
1. the first formula type I tried had a syntax error. But darn, I didn't notice which one. I tried several others and they worked (at least, generated an image). I'll systematically check and rediscover which one it was.
Most of the fractal specific stuff should work since it doesn't do any IO with the user, just output to the screen through a few specific low-level hooks. That part pretty much works; its weirdness caused by specific UI elements that are wiggy still. I need to try more of the UI stuff that's more exotic like the orbits window, colormap manipulation and palette editing. I know I'm not supplying a reasonable bitmap font for the palette editor.
2. I generated a mandelbrot before trying the formula type. The mandelbrot was still on the screen as the formula type generated. This didn't seem to cause as problem, but we should probably clear the screen.
I saw this shortly after I put the beta out there and I have it fixed now.
Now we need the services of a few fanatic fractint users to help fanatic user Lee Skinner :-). We need to systematically test different functionality and compare with the DOS version.
I'd love testing from a small group of users for now and when things are more solid, we can open it up to a larger group of users. Until things are more solid I think it would just end up with lots of people reporting the same bug. Right now the bugs are easy to find :-). -- "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/>
Tim wrote:
2. I generated a mandelbrot before trying the formula type. The mandelbrot was still on the screen as the formula type generated. This didn't seem to cause as problem, but we should probably clear the screen.
Rich, this is somewhat worse with l-systems, which are all drawn translucently over previous renderings.... /charlie/
In article <1416.1997-3216-1155389313-1168926460@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
Tim wrote:
2. I generated a mandelbrot before trying the formula type. The mandelbrot was still on the screen as the formula type generated. This didn't seem to cause as problem, but we should probably clear the screen.
this is somewhat worse with l-systems, which are all drawn translucently over previous renderings....
Yes, same bug; it will be fixed in the next beta. -- "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, here's some more testing info: I) started fractint, selected a non-disk video, rendered mandel, so far OK.. – then restarted using <Ins>, selected a disk-video mode -> blank screen (although it seems to respond to keyboard input, it doesn't display anything) ..while selecting a non-disk video after an <Ins> restart is OK.. II) started fractint, selected a disk-video mode, "rendered" mandel, OK so far.. – on completion, went to the "View Window Options" screen (<v>), lessened dimensions, submitted -> fractint crashed (most of the time) III) started fractint, selected a mode like 8-8-8, or 1280x1024 (formerly VESA), – went to the "View Window Options" screen (<v>), changed nothing, submit -> "insufficient free memory/disk space" ... reason: VESA virtual screen setup is here in effect, trying to figure out the size of the video memory – of course it fails, in win32 environment.. so untill someone implements a win32 fullscreen mode AND a win32 virtual screen setup, there is no use for virtual screens in a windowed context and i suggest turning it off (e.g. make "virtual=n" a default setting) /charlie/
In article <1428.2013-25137-1729383460-1169004320@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
I) started fractint, selected a non-disk video, rendered mandel, so far OK.. <E2><80><93> then restarted using <Ins>, selected a disk-video mode -> blank scr een (although it seems to respond to keyboard input, it doesn't display anything) ..while selecting a non-disk video after an <Ins> restart is OK..
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 <1428.2013-25137-1729383460-1169004320@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
II) started fractint, selected a disk-video mode, "rendered" mandel, OK= so far.. =E2=80=93 on completion, went to the "View Window Options" screen (<v>)= , lessened dimensions, submitted -> fractint crashed (most of the time)
I could not reproduce this. -- "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 <1428.2013-25137-1729383460-1169004320@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
II) started fractint, selected a disk-video mode, "rendered" mandel, OK= so far.. =E2=80=93 on completion, went to the "View Window Options" screen (<v>)= , lessened dimensions, submitted -> fractint crashed (most of the time)
Oops, sent too fast... can you still repro this on 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/>
participants (5)
-
charlie chernohorsky -
Lee H. Skinner -
Paul -
Richard -
Tim Wegner