What could have been a good career in game development
1) The program code was linear and used a shitty switch/case construct to take keyboard inputs and call functions that would move my character on the screen. However, since moving the character meant redrawing bitmaps on the screen, a lot of CPU cycle was spent on this (on a 486) and I wasn't able to get fluid motion from other objects in the game screen. For eg: I would have a moving paddle that I need to jump on top off. However to do this, the paddle should move independant of my character. But if I pressed and held an arrow key to move the character, all CPU cycles would go into moving the character and then the CPU would have to wait for no inputs from the keyboard to move the other objects in the game. I was never able to get things work independant ofone another.
I now know that the solution to my problem is threading but I am not really sure how to create threads that have functions in them and call them. It would be nice if someone can point me to a beginners tutorial on threads that addresses the kind of problem I am facing.
2) I was always amazed at how games like dave and such had more colors than the 16 colors Turbo C would allow. I have now come to know that int13 is used to gain access to a larger color pallete. However the usage seems very confusing. Any links that can give me a good insight into this?
3) Considerable amount of CPU cycle was spent drawing bricks and blocks on the screen. I figured the way games did it was use tiles and replicate them. How do I get any bitmap I create to come up on the parts of the screen where I want it to? Are we doing a direct frame buffer write, if yes, how do I gain access to the frame buffer and what are its controls?
I am not a CS major and nor do I obviously code for a living but I would like to get back into it seriously. Any help is appreciated. Thanks.
29 comments
[ 4.9 ms ] story [ 72.0 ms ] threadthings have, um, changed significantly -- nowadays libraries like directx abstract away the details of direct hardware access and handle graphics, sound, input, timers, etc.
if you're just looking to play around with games, pygame is perfect for you -- http://www.pygame.org .
if you're really looking to learn the details, you should probably grab a couple books on amazon (hard to recommend one in particular without knowing what you wanna do.)
Pyglet has no dependencies and I just found it a lot simpler than pygame to get started with.
Secondly, a real-time game is a turn-based game where the turns occur in real-time. Unlike a strategy game, the computer continues even if you don't make a move. Imagine AD&D melee combat at 30 rounds per second. This doesn't require threading.
And, if you're using the Canvas tag you're excluding IE users. If you're only going to reach a limited audience anyway, why not use Flash and reach a much bigger limited audience?
On the other hand, I guess Canvas teaches you about drawing to buffers, while Flash teaches you about more abstract things.
But as for the questions:
1. Threading is not the answer; it was a missing concept on DOS machines. Interrupt polling is what you want to look at. 2. I recall reading about this but never did it myself. These days you're lucky if both the monitor and graphics card support mode 13h. 3. The term you want is "fast rectangle blit". This is still relevant if you use software rendering.
The real question is whether you would want to use a modern, abstract, weakly typed language like Python instead of a strongly typed and machine-code compiled language like C++. The latter is, usually, considerably slower. The decision all depends on how serious you want to get. For small-scale experiments, Python is just fine because it takes half the time and half the effort to write and test a piece of code. Unless you are pushing the limits on how fast you want something to run, Moore's law works in your favor and you can very quickly create something which does what you want and is fast enough. If you need the speed, you will know, but at least then you will have a simple prototype which will keep you from falling in any stupid traps on the way.
So to answer your question, development speed is the factor that makes people want to use these languages. You don't have to jump through hoops unless you need run-time execution speed.
And yes, Python has excellent library support for doing just about anything that doesn't have to be blazingly fast. This, along with better language constructs (more dynamic classes and methods, weak typing, versatile and easy-to-use lists and mappings, list mapping functions etc), is what makes development much faster. Oh, and it doesn't hurt that you can dynamically test the things you've written, if you want to.
- Code is shorter and potentially easier to read.
- While static typing can identify some bugs at compile time, these are usually the easiest bugs to find regardless of the language you use. The hard bugs -- the ones not caught by the compiler -- only become obvious through testing. So if you have a good suite of tests, you will find both classes of bugs, whether or not you use a statically typed language.
- In a dynamically typed language, you spend less time wrestling with the typing system -- instead of casting in C or Java, doing long template-related declarations in C++, or convincing ML or Haskell that your program should be allowed to run.
- And, more theoretically, a statically typed language limits the space of programs that you can write. While most of the programs disallowed by static typing are buggy, some are useful, and a statically typed program with the identical useful functionality is longer.
Of course, static typing has its benefits as well. It's the reason our fastest languages are as fast as they are, and it's a comforting safety net, especially in large projects.
Also, many people don't realize just how much faster computers are now than they were 10 years ago. As part of the prototyping for my startup, I wrote a couple games in JavaScript, which is roughly 1000 times slower than C. They were generally quite playable, except on Firefox/X-windows where an odd Canvas bug seems to be adding a lot of latency without pegging the CPU. I'd still use Flash if I were doing a production game (JavaScript's timing is inconsistent, with occasional long pauses presumably for garbage collection), but as long as you stick to 2D it's quite feasible to do games entirely in interpreted languages.
Parallel to the input (okay you will need a separate thread of keyboard listening and for game logic) you will loop over your entities and update their state, processing things such as movement.
http://en.wikipedia.org/wiki/Mode_X
If you really want to pick up where you left off, I'd suggest downloading djgpp (gcc for dos - http://www.delorie.com/djgpp/zip-picker.html) along with the Allegro library, which wraps up a lot of the nastiness of direct hardware access.
I wonder if I should start a new degree in CS, but I am 30, I have a child, and I am not sure if it's better to learn by myself or if it's worth doing a degree. Can online studies be a good idea? Or do you guys think it's just a waste of time?
Unless you really want to deal with all this blitting stuff, I recommend that you look at making flash games. You get to deal with the more interesting problem (to me) of making a fun, playable game vs. dealing with the nuts and bolts of graphics programming.
Also ask those guys at popcap how their financials look. I bet they aren't doing too poorly :)
For about 3 years, I've said that the minigame will rule the world and it it beginning to turn that way. Look at 90% of the Wii games and they are all minigames. Games like Peggle and the downloadable content for XB360 are all minigames that make bank.