Tim, I've decided to back the assembly language formula parser changes out of the next patch. Still can't get it to work. Running the C code through -Wall has fixed a couple of bugs that we barely new existed. I do want to run the patch through the DOS code and see what breaks before I release it. That may take a while. As it stands, the next patch is going to be huge. There are only a couple of actual bug fixes in it (or will be in it). Jonathan
On Sunday 24 February 2002 08:57, Tim wrote:
Are you working with djgpp or Xfractint?
Xfractint. After I've applied the next patch, I may try compiling under djgpp again. I am also considering giving up on Allegro. Not that I've worked on it recently. I was never able to get the performance out of it I was expecting. Perhaps OpenGL would be a better approach. In which lifetime is this going to happen? 8-)) Jonathan
Jonathan, contemplating the dreadful awesomeness of the human condtion, wrote:
In which lifetime is this going to happen? 8-))
I hope to be programming in new environments in a future life also. Very hard to get a toehold. (Note: don't read anything too metaphysical into "future life". I mean before I die :-)
In article <3C78EBAD.24715.D7D13@localhost>, Tim Wegner <twegner@swbell.net> writes:
I hope to be programming in new environments in a future life also. Very hard to get a toehold.
This is the road I travelled: - "Win32 Programming" by Rector & Newcomer. This book teaches you basic Win32 API programming, all the while assuming you have a brain and already know how to write programs. It is full of advice from the battle-scarred: sometimes knowing what -not- to do is just as important as knowing what to do. Its comprehensive enough that you can use it as a Win32 reference and be confident that after you've read a chapter on a subject you -really- know that subject. I spent many hours looking at Win32 programming books in the bookstore before settling on this one. A bonus is that it doesn't fall apart with heavy use because its hardback. - "Programming Windows with MFC", 2nd ed, Jeff Prosise. MFC is at least as big a beast as Win32. It helps to start with a solid grounding in the Win32 API, but you can learn the Win32 API concurrently if you have a good online reference like MSDN library (which can be browsed for free on the web). Again, he starts with the assumption that you have a brain, have written programs before, and have even written some raw Win32 API programs. He starts by doing things the "hard way" by writing complete MFC apps by hand without the AppWizard. By the time he introduces you to the AppWizard, you are already familiar with everything the AppWizard generates so its not "magic". With those two books you will have a very solid grasp of Win32 and MFC.
From there you can go further into COM programming, or DirectX programming. For COM I suggest ATL, and "ATL Internals" by Rector & Sells is the encyclopedic reference for ATL, but it might be more detail than you need. "Professional ATL COM Programming" by Grimes is a straightforward introduction to COM programming with ATL. For some advanced tasks with COM, Grimes wasn't enough for me and I didn't "get it" until I read ATL Internals. (Specifically, exposing STL containers as COM collections with both the collection and the enumerators built with the ATL template classes.)
If you aren't yet familiar with the massive amounts of functionality in the C++ standard library, I definately suggest "C++ Standard Library" by Nicolai Josuttis. Again, a hardback book that will hold up to frequent use and comprehensive enough that you can use it as your sole reference and not find yourself wanting. Avoid any C++ books by Schildt, they suck horribly in my opinion. As for .NET and all that, my guess is that its still too new for good books, but I haven't investigated. Don't succumb to marketing induced fear and think that your C++ knowledge (or even knowledge of COM) is irrelevant now that .NET is here. It has its place, but core Win32 API apps will be with us for quite some time. Fortunately DOS is finally dead. ;-) -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> Don't Support Spammers! Boycott Fractal Painter 7! <http://www.xmission.com/~legalize/spammers.html>
Jonathan wrote:
I am also considering giving up on Allegro. Not that I've worked on it recently. I was never able to get the performance out of it I was expecting.
In what way was the performance bad?
Perhaps OpenGL would be a better approach.
I wonder how well OpenGL handles the sort of pixel graphics we need. The following looks interesting: http://www.scitechsoft.com/download.html See Scitech MGL. Apparently it supports djgpp. Even though Jan Hubica is having the same problem making much progress these days as we are, I thought his Windows version of Xaos was quite amazing. See http://prdownloads.sourceforge.net/xaos/winxaos31.pre3.zip I'm not sure where the source for this is. I *think* it was created using Cygwin. Tim
On Tuesday 26 February 2002 19:45, Tim wrote:
I am also considering giving up on Allegro. Not that I've worked on it recently. I was never able to get the performance out of it I was expecting.
In what way was the performance bad?
It was/is too slow. I tried using the inline assembly routines they have but that made things even slower.
Perhaps OpenGL would be a better approach.
I wonder how well OpenGL handles the sort of pixel graphics we need.
Don't know.
The following looks interesting:
http://www.scitechsoft.com/download.html
See Scitech MGL. Apparently it supports djgpp.
I'll have a look.
Even though Jan Hubica is having the same problem making much progress these days as we are, I thought his Windows version of Xaos was quite amazing. See
http://prdownloads.sourceforge.net/xaos/winxaos31.pre3.zip
I'm not sure where the source for this is. I *think* it was created using Cygwin.
I've downloaded Xaos a couple of times and I think I've looked at it once. Jonathan
In article <3C7BE5C6.22003.968563@localhost>, Tim Wegner <twegner@swbell.net> writes:
I wonder how well OpenGL handles the sort of pixel graphics we need.
The key to all modern graphics APIs is to avoid the "VESA memory-mapped model" of diddling pixels one at a time. You need to batch up pixels into blocks for updating. This is true of Direct3D and OpenGL, particularly if you're trying to manipulate pixels directly in video memory -- which is horribly slow. Its often faster to manipulate a block of pixels in the system memory and request the card do the transfer to video memory by DMA or something. -- Ask me about my upcoming book on Direct3D from Addison-Wesley! Direct3D Book <http://www.xmission.com/~legalize/book/> Don't Support Spammers! Boycott Fractal Painter 7! <http://www.xmission.com/~legalize/spammers.html>
participants (3)
-
Jonathan Osuch -
Rich -
Tim Wegner