Heh... and that's when you know you wrote every part of it... imagine several people doing different parts and then trying to stick all of that together.Originally Posted by Bubba
Well who said anything about finishing projects?
I've finished a few but mostly what I have are like tech demos demonstrating this technique or that. Sticking it all together in a game is quite a challenge.
Game Programming takes more coordination that football.
Sent from my iPadŽ
Yeah the word 'nightmare' pops into my mind. Shakti and I are trying our hardest to actually complete at least one level of a game. We are doing all the design docs before we write one letter of code. Once we agree on the design we say it should take either an act of God or a signed letter from the our nation's leaders to alter it. Hopefully this will keep us on track and focused.Heh... and that's when you know you wrote every part of it... imagine several people doing different parts and then trying to stick all of that together.
Luckily that's what I do for foodHeh... and that's when you know you wrote every part of it... imagine several people doing different parts and then trying to stick all of that together.Having programming as career and hobby might sound silly, but afterall my work is software/applications for industry in fields from embedded systems to process mgmt and hobby is just writing tiny games for my personal pleasure. Still couldnt agree more about doing large projects with couple dozen of coders... Maybe that's why theres own field called "software project mgmt" which applies as well for any large project from automating SAM systems to corporate ERP's and MMO games
Back to the topic and more text for thread starter:
I still believe for beginner is best serving himself by starting from easy stuff. Draw a pixel, draw a texture... it doesnt matter if its 3D or 2D, just do it. Move it... and play around with the simplest game idea occuring in mind. Moving graphical thingies on screen with some user input... maybe add some collision detections for those thingies and move on. Dig deeper. Every step taken forward will steer into direction of real interest.
Game project is not about programming. It's more about other things, programming is just the task that dog's do for you once you have the specifications written perfectly. But learning programming BY writing games -> No need to involve that "other stuff". I believe it's best to focus on "game PROGRAMMING".
And btw, that "Beginning Game Programming" named book might be good one. Perhaps I would have bought that book 10 years ago, would I have stumbled on it by any occurence. But today I think books can also make things either alot more boring or more difficult. Using these nice libraries I mentioned earlier might be very good to try out programming user interactive applications which are focused on entertaining the user (like Games are). Books might dig too deep into tech, or just scrape the surface and cover subjects involving the example too much (would I learn anything from game programming book which focuses mainly how to write football manager game when I could be the person who cares the least about football on earth. Such book could be great covering all kinds of subjects required but I might die in boredom about "footballish" approach).
Just my few cents for this thread (again)
Well, I have the book Windows Game Programming In 24 Hours which I think to be he same as Beginning Game Programming but I dont like it as all it seems to say is here is some code but I don't expect you to understand it and it does that all the way through the book and then at the end expects you to go off and make your own game. Although Beginning Game Programming might be different.
They do look different after reading a bit of an online smaple but I don't know how different.
The only worthwhile question I read was...
Q: 2D rasterization was never figured out eh? Ok if it was never mastered then how the hell does our 3D card do it? Is it using some kind of magical math voodoo?
A: Each vendor made a standard way of drawing each call, whereas for software, there was no standard. Afterall, you and I can build a software engine and I bet you more than anything that each call will be entirely different.
Come on, Bubba! You helped me out plenty of times but this question was pretty basic. And, the API the graphics programmer use would only bother inexperienced developers. 3D Math is 3D Math as much as 2D math is 2D math, so who gives a rip on what tool you use to carry out your instructions. Building your own rasterizer has its benefits, especially if graphics also partains to building video cards, etc. (they do). But then again, today's seasonal graphics programmers seem more trapped to hardware. Who's to say there will always be hardware acceration available? It's good to learn from the ground up because you never know when you might need it. Isn't OpenGL software based on Windows without hardware acceleration or an ICD available? Someone had to write that code, and I'm sure that he or she was a well-aware graphics programmer.
I came across and like Lamothe's explanation of Tricks II of why he used software rasterization for 3d...
"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. This book really has it all from rasterization techniques, lighting models, Z, 1/Z buffering, MipMapping, affine, perspective corrected texturing with approximations, bilinear and trilinear filtering, alpha blending techniques for real-time, camera models, shadow generation, light mapping, BSPs, Octrees, occlusion culling, basic MD2 character animation, optimization theory, and a lot more. Included in the book are a number of working demos from 3D space games to jet skiing."
Some screenies from the book:
http://www.emediawire.com/prfiles/20...Ifig13_47a.jpg
http://www.emediawire.com/prfiles/20...fig14_34ss.jpg
http://www.emediawire.com/prfiles/20...iifig12_50.jpg
http://www.emediawire.com/prfiles/20...IIfig13_69.jpg
http://www.emediawire.com/prfiles/20...Ifig15_14a.jpg
http://www.emediawire.com/prfiles/20...iifig12_15.jpg
I'm not here to sell anything. Just browse it for free at the bookstore and find out for yourself. I personally find "most" people who can't finish the book are the ones complaining which is why you often find them on message boards rather than flooding the review sites which have usually well-educated thoughts on the book. Anyway, the OP has a lot of responses/opinions to choose from, so I don't see any reason to argue any further with what worked in our own backgrounds. We're all doing what we love to do, I hope
Last edited by dxfoo; 09-08-2006 at 12:15 PM.
I assure you this question was rhetorical as well as the other ones.Q: 2D rasterization was never figured out eh? Ok if it was never mastered then how the hell does our 3D card do it? Is it using some kind of magical math voodoo?
You can't be serious right? Why would we ever go back to software? Hardware is always faster than software.Who's to say there will always be hardware acceration available?
This discussion is over as far as I'm concerned. I may have helped you dxfoo in the past but I can tell you now you are steering the OP in the wrong direction. And you, my friend, sound a bit confused as well.
Last edited by VirtualAce; 09-08-2006 at 12:41 PM.
I guess this book is meant for a certain group of people who want to focus on building video cards and the such, not just games. But then again, you're a graphics programmer, not a "game" programmer who, yes, work with hardware all the time these days. and if you think of yourself as a "game" programmer, you should probably look for another career. Any specialization is an art. You usually learn to draw with your hand before you draw it on the computer. That's the way I see it for an artist, and as a graphics programmer you should learn to rasterize it yourself before you let the hardware draw it for you. Get it?
I own my own local game company here but there's nothing stopping me from using hardware accelerated code for it. We're using OpenGL and fully hardware accelerated, but the more I understand graphics, the more I want to learn how it works underneath on the side because of that passion thing again, so Tricks gives something rare that really helps my understanding. Since I enjoy it, I share because I believe that even beginners should start doing the rasterization by themselves again. I am speaking for educational value, not really that you'll use it in the workplace unless you write graphics drivers etc. You already trained yourself how to do it before you started letting hardware take care of it for you.
Of course, as a graphics developer you will be working with hardware 99.99% of the time. But if you don't have a passion for learning how the older games like DOOM was created, I don't see why you persue a future career in graphics. Remember, these companies you are applying for started with software rasterization most likely, so you will be taken more seriously as a graphics programmer. I don't know why they wouldn't
No comment. The hole just gets deeper and deeper.
What free online material is there for any of this stuff?
Well, if you know C++, you should go ahead and learn all you can on the Win32 API. This is the Windows programming that comes prior to drawing pretty pictures on the screen. Basically, a game requires nothing more than a window to draw onto, but there are a million functions that will help you along the way. A good website that has helped me back in the day was http://www.functionx.com/win32.
Ok well I got a £25 book token today for creating a website for someone so I could spend that on a nice programming book. I was wondering what Windows Game Programming For Dummies was like, this is also by Lamothe (I dont really need fast algorithms and what not just something that will teach me the basics and is easy to learn from).
Just get a book!
Eh, I wouldn't recommend buying just any book. The last book I bought with that mentality (that "I'm sure I'll at least learn something" mentality) was a complete waste of money (Physics for Game Developers - David M. Bourg). Money that I could've spent on a better book.
EDIT: Ok, not a complete waste of money, but i'm sure there are better books. Actually, I'm very sure there are better books, based on what I read about it after buying it.
M.Eng Computer Engineering CandidateB.Sc Computer Science
Robotics and graphics enthusiast.
Ok, anway thanks for that web-page, it is very easy to follow as it is breaking it down a lot more than forger's but I am sure that it is very out of date and that Buba will find everything that is wrong with it.
