I was thinking he could start with 6.0 just to understand how to set up the project, then be comfortable later to switch over. Then again, the steps he gives is pretty obvious on the newest version of Visual Studio too. For example, I use VS 2005 Professional, and the steps he gives were immediately obvious for this version, so I guess it would be wise to ignore 6.0. But I'm sure you already have an IDE with Win32 support.
For those of you thinking of buying this book, this may deter you.
http://forums.microsoft.com/msdn/sho...15436&siteid=1
Table of contents:
http://www.amazon.ca/gp/product/toc/...5398&s=gateway
Last edited by VirtualAce; 09-17-2006 at 01:46 PM.
Once again, Bubba has proven not to have finished the book. The book mentions those libraries but it does not use them.
You wrote the post. I finished Tricks 3 days after I bought it. You will find posts by me on here about it from way back when. So don't go assuming I haven't finished it and stop calling people kids when you don't know who they are.
You are not the only one around here who does graphics and none of us knows it all. Directing people as you are is going to do nothing for them. We've done some research on you and it seems you post everywhere on the net including gamedev. And you've had problems there too.
So chill out.
Last edited by VirtualAce; 09-17-2006 at 01:52 PM.
So thats why it has 2 chapters completely dedicated to directdraw?? And for those who dont know, directdraw does not exist any longer, it has been replaced by Direct3D. It is ancient, DirectX 7 stuff.
STL Util a small headers-only library with various utility functions. Mainly for fun but feedback is welcome.
Oh my god, only an noob/idiot would care about what API he uses to learn general graphics. Truth is you'll learn it probably with D3D and 10 years later hear that it has become deprecated. Was it a waste of time? The book makes it very clear that you have to learn graphics, not an API. Today's generation thinks the opposite and you find them right here. Bubba, learn to be more accurate then because you should have known that Tricks does not use those libraries. Suggesting that it did will make me correct you.
But my question then is why spend money on a book you can only use to half its extent or even less??
If i had a choice betwean a book which teaches graphic and an api that works today, and a book that teaches graphic and an api which is old and unsupported, id pick the first choice any day.
>>Truth is you'll learn it probably with D3D and 10 years later hear that it has become deprecated. Was it a waste of time?
No because then you know the api when it was there. But if you, 10 years from now learn about Direct3D, but at that time its called DirectXPwnYo, its a huge waste of time.
And im going to pretend i didnt see that idiot remark.
Last edited by Shakti; 09-17-2006 at 02:04 PM.
STL Util a small headers-only library with various utility functions. Mainly for fun but feedback is welcome.
Because we are in the current generation. Man will you ever just admit that this stuff is highly outdated? Stay with the technology and you will do yourself the biggest favor. I've done 2D rasterization in DJGPP and in Turbo C++ and in BASIC for god's sake. It didn't do anything to help me with Direct3D because Direct3D is based on a totally different approach.
You set the texture and it rasterizes for you. I don't even see how knowing what's going on will help you at all since you cannot rasterize for it. Getting to a surface requires a lock() and an unlock() so D3D can use it. But the only way to get a pointer to a surface is to lock() and unlock() so immediately if you go tinkering with crap you get performance issues. And if you want to do environment mapping you simply set up a cube map, set the render target, and let D3D render to it. Still no rasterization. Why? B/C hardware rasterizing is 100 times faster than software. Yes they are using some of the old school algos, but it won't help you with FPS. The biggest factor in FPS today is polygon reduction, level of detail, texture detail, triangle strip computation (more the better), and batch rendering to name a few.
Have you not seen my threads about terrain and so forth? No I'm not a professional game developer and yes this is a hobby. But I'm not an idiot when it comes to graphics, nor is psychopath or Bob McGee. I'm sure there are more here that I've missed (sorry guys) but almost everyone is saying the same things.
So newcomers do yourself a favor and get a book that is current and you will get much farther.
If you would like me to list every book in my library then I reckon I will. But know that I eat books alive man. I buy them, read them, and use them constantly as well as a host of internet sites. I will not knowingly give bad advice here on the boards b/c it is not my intent to mislead or stick someone on a technology chase. Most of us here just tell it how it is and from what I've seen at/in gamedev, gamasutra, game mags, newer books, MSDN, blogs, and IRC chats - we are all saying the same things.
So don't go calling member here noobs and idiots that have been here many years and have about 3k more posts than you do. We've contributed to this board over the years and wouldn't you think if we were way off base people like Salem, Prelude, and others would have banned us and/or told everyone we were wrong....many years ago? Fact is most of us here code daily in Direct3D and/or OpenGL. psychopath and Bob have demonstrated excellent knowledge of OpenGL. psychopath and I have had our disagreements on lighting models and so forth, but the guy knows his stuff. Bob Mcgee and I have also had our disagreements but in the end we come out with a mutual respect. Shakti although he is quiet knows a lot about game programming and has been a key player in helping me with scripting, rendering, resource management, and other game code issues. Are you calling all of them noobs to since they agree with me? There are many on this board that know their stuff. Perspective has implemented a terrain engine based on a very good LOD algorithm. In fact I'd die to get it working half as well. So before you go thinking your Mr. Superior I think you ought to realize that many of us here are not stupid when it comes to graphics and it's because we daily research algos and we code this stuff daily. Probably the only reason we don't have any games to show is because we can't stay on task long enough to finish them and/or we don't have artists, sound designers, etc, etc. Many of us lack the resources to put together an industry standard game.
Get with the program bud and stop calling people noobs and idiots when you have no reason to. A little respect and common courtesy is in order.
Last edited by VirtualAce; 09-17-2006 at 02:17 PM.
Learning 2D/3D is learning 2D/3D. You can apply it to any API. It is not a waste of time regardless of what tool you use to get the job done. At the end, you would have known it was all about algorithm development and theory that does NOT go away. In knowing that, caring about what API you use to get the job done is pathetic and typical for the average 90% of students I see on message boards. The book uses DirectDraw to teach you programming because you learn to draw them yourself much easier than you can with Direct3D, and to think of how to even do so would require much more tutorial work. The point is use what's best for the job, and even to this day DirectDraw was a good choice to teach algorithms with. You should be able to apply what you learned to whatever the hottest API is in the market today or in the future. God, message boards make this sound like the most contraversial game programming book in the world. Maybe it's time to let go of message boards for a while. Teachers and authors are right, it is a waste of time talking on technical message boards simply because there's so much misinformation going around. 90% of the people aren't even qualified to give an answer but they do probably because the book was too overwhelming so they have to slander the author, or a book is now horrible without a doubt because Microsoft declared something deprecated, and therefore you can't learn anything from someone with 24+ years of experience. My last bit of advice is get away from these message boards. These people even waste my own time because I have to correct them every damn time because they can't back themselves up or don't have enough experience to come to this basic logic. Learn to get past the API.
Last edited by dxfoo; 09-17-2006 at 02:45 PM.
If i want to learn the theory behind graphics I would buy a book on the theories.
I do not think its a good idea to recommend a book that uses an api which is so old, the creators of the API cant even guarantee that it will run good on todays machines with DirectX 9. Microsoft have stated that there are some things that are not backwards compatible. You say the api is not important, tell that to the guy who is trying to learn this but has to go through a heapload of errors and problems to get the examples to work. Because you can not dispute the fact that in order to make practice of the theory you need to actually have a program running.
And what you are saying is basicly "Hey read this, it will teach you the 'behind the scene' of graphics and is great and bla bla bla", but when the person wants to implement something on his own, he must learn a new version of the api because the one the book taught does not work any longer...
Ok no problems you say, just go and buy this book....
What question do you think the guy will ask then?? He will ask "why in zeus b*tthole didnt you tell me that straight away".
As I said if I want to learn the theory and the math behind the scene, I will buy a book on that. If I want to learn how to write graphical applications using DirectX I wont go buy a book which teaches me directx which is like 6 (I havent checked that figure so it might be wrong) years old.
Edit: Saying that the api doesnt matter is also ignorant. Because in order to learn stuff well you have to do stuff yourself, you have to play around with what is being discussed in the chapter. And you can not play around with something you can not link...
Last edited by Shakti; 09-17-2006 at 02:50 PM.
STL Util a small headers-only library with various utility functions. Mainly for fun but feedback is welcome.
So while we are on the topic that APIs don't matter, let's venture back to the days of DOS and address a few items. This list covers sound, input, 2D/3D graphics, and more.
- How does 2D rasterization work and why and how can you implement it in a software engine?
- How does perspective correct texture mapping work?
- How does digital audio work?
- How does 3D actually work and why?
- What clipping algorithms do most video cards use?
- What culling algorithms are in use today and why?
- How do you get input from the computer under Win32?
- How would you do it under DOS and how does that apply today?
- How do you program the DMA for auto-init mode?
- How do you program the DSP on your audio card for auto-init mode?
- What other modes of DMA are there?
- How do you program the PIC in 32 bit protected mode?
- How would setup a rasterizing system in 32 bit protected mode?
- How do you transform vertices from local space to screen space?
- How do you blit an image to a surface without using any library?
- How do you perform animation under Win32 or under DOS?
- How do you gain access to the linear frame buffer to do SVGA graphics?
- How do you perform back buffering or triple buffering with no hardware support?
- How do you perform texture filtering without hardware support?
- How do you perform linear texture mapping?
- How do you perform anisotropic filtering without hardware support?
- How do you do anti-aliasing on lines without hardware support?
- How do you intercept hardware interrupts in protected mode to respond to hardware?
- How do you do back buffering for SVGA in real mode?
- How do you do page flipping?
- How do you program the timer to be of any use?
- How do you write an interrupt 09h keyboard handler to accept multiple keypresses?
- How do you prevent memory pages from being swapped to disk and/or allow for pages to be swapped without causing a page fault in PM?
- How do you get around the fact that the DMA chip will not read a portion of memory over 1MB and yet still use it in protected mode?
- How do you perform post processing on a buffer w/o hardware support?
- How do you perform enivronment mapping w/o hardware support?
- How do you perform bump mapping w/o hardware support?
- How do you write pixels to SVGA in real mode when the pixel address is beyond 64kb?
- What is an alternative to the interrupt based bank switching support?
- What is VESA and why does it matter?
- What is bank switching and why is it important for real mode?
- What is XMS and how do you use it?
- What is EMS and how do you use it?
- How do you stream videos from a CD-ROM under MSCDEX.EXE?
- What interrupt are most CD-ROM's on?
- What interrupt's are really being used when a sound card says it is usign interrupt 3,5 or 7?
- How do you find the base address of the DSP on your card?
- How do you find the interrupt your sound card is using w/o using Windows or drivers?
And the list goes on. I'd be interested to see the responses.
Since we think the API doesn't matter then let's go there all night long. I could do this for days.
Last edited by VirtualAce; 09-17-2006 at 07:34 PM.
Btw, I agree as far as the old API stuff goes... that is what put me off playing with DirectX for a while because I couldn't make it work without fiddling with everything, finding replacement headers that wrap so that you can use old style API... crap like that. Eventually I gave up and just went to the MSDN to play with DirectX. Same with old OpenGL guides (such as the nehe guides) while they are packed with good info, trying to play with the old API to do stuff sucks.
I apologize for my behavior. It is quite unprofessional to call people kids and so forth since I don't know these people in cyberland. I'll share my opinion but I don't think I will keep defending it anymore. I just have better things to do than chit-chat for an hour. How would you feel if someone kept attacking your own personal book recommendation? It's just based on my own experience of what worked for me - heck, this book series helped me stand out for my recent new job. But saying it's the only way is not true at all. However, I do think if anyone is interested in graphics and learning how it works underneath, this book is the god of them all. Depending how far you want to go with graphics, this may be a good option. I do wish to share a quote that LaMothe said. I feel pretty much the same way and experienced it myself in the last few years.
That's why I find his books interesting. He had the same idea with Tricks II:"I have this love for the game Asteroids. I guess it was that $100 I won in college on a bet. Some other computer science students bet me that I couldn't write an Asteroids game right in from of them in Pascal on an IBM XT. They had seen other games I'd written and said I copied them. Of course, thse were your typical comp-sci students who couldn't do anything unless there was an API call for it. I sat down and wrote Asteroids in about eight hours flat - an exact copy of the vector version by Atari (no sound, though). I won the 100 bucks, and then I slapped tham all with a backhand and took their pocket protectors."
I love it for that reason. It's a great educational series for computer science students. Your competitors are usually the ones who just relys on API calls, and more in thought, they aren't the ones who make the impossible "possible." It's about what the API can do for them. Maybe that works for them though since I know we all don't have the same goals or interests. But seriously, if you want to become an innovator in graphics, pick this book up. DirectDraw will help you get there as much as an Amiga or Mac will. This book simply chose to use DirectDraw to communicate the algorithms for side scrolling, isometric games, drawing lines, etc. all in pixels. It's used simply to teach game programming and algorithms without the hassle Direct3D/OpenGL would give. Obviously, what MS currently supports does not allow you to take full control anymore since you're working with triangle primitives. Last, don't be afraid to use a deprecated API. It is COM-based, meaning a DirectX 3.0 program will work on DirectX 9.0 without a doubt. Like Andre' mentioned, your whole life is not tied to it. When you move to the next hottest API in the market, you're already a graphics guru. It is simple to migrate. I did on the job and Big Steve is already asking how did I just do that. He's been there for ten years and is a big fan of APIs that do most of the work. I went the innovative route. Others have their own routes. They have to find out what works for them as much as the poster does."My goal for Tricks II was to teach how to develop a 3D software rasterizer and complete engine from the ground up. Thus, this book is both theoretical and practical. Everyone today is comfortable with using 3D APIs and accelerators, but the knowledge of how to develop a 3D engine from plotting a pixel to a fully lit, shadowed, perspective corrected, Z buffered display is slowly being lost.
This book is both for the computer graphics enthusiast that wants to understand the math and theory behind the algorithms, but also for the practical developer that wants to know how to make a Quake I/II level engine to possibly implement the technology in hand helds or pure silicon. I have yet to see anyone that has started from nothing and shown readers a real working engine that was not pre-developed."
Once again, I apologize for throwing names around. I'll work on sharing my opinion and just leave it at that. Otherwise, every book thread will turn to another war caused by somebody
I personally would much rather have a working program faster than trying to set up old APIs to work with newer stuff. I have a couple of LaMothe's books but really they were useless to me till I learned more about the newer API so I could make use of internet guides also.
Apology accepted.
This is not true though when MS themselves say that older versions of DirectDraw will simply not work in DirectX 9.0 DirectGraphics. They specifically recommend against using DirectDraw at all.Obviously, what MS currently supports does not allow you to take full control anymore since you're working with triangle primitives. Last, don't be afraid to use a deprecated API. It is COM-based, meaning a DirectX 3.0 program will work on DirectX 9.0 without a doubt.
