Saturday, March 6, 2010

8086 Instruction set

80x86 instructions can be (roughly) divided into eight different classes:
1) Data movement instructions
• mov, lea, les , push, pop, pushf, popf
2) Conversions
• cbw, cwd, xlat
3) Arithmetic instructions
• add, inc sub, dec, cmp, neg, mul, imul, div, idiv
4) Logical, shift, rotate, and bit instructions
• and, or, xor, not, shl, shr, rcl, rcr
5) I/O instructions
• in, out
6) String instructions
• movs, stos, lods
7) Program flow control instructions
• jmp, call, ret, conditional jumps
8) Miscellaneous instructions.
• clc, stc, cmc
The following sections describe all the instructions in these groups and how they operate.
At one time a text such as this one would recommend against using the extended
80386 instruction set. After all, programs that use such instructions will not run properly
on 80286 and earlier processors. Using these additional instructions could limit the number
of machines your code would run on. However, the 80386 processor is on the verge of
disappearing as this text is being written. You can safely assume that most systems will
contain an 80386sx or later processor. This text often uses the 80386 instruction set in various
example programs. Keep in mind, though, that this is only for convenience. There is
no program that appears in this text that could not be recoded using only 8088 assembly
language instructions.
A word of advice, particularly to those who learn only the instructions noted above:
as you read about the 80x86 instruction set you will discover that the individual 80x86
instructions are not very complex and have simple semantics. However, as you approach



One quick note: this chapter lists many instructions as “available only on the 80286
and later processors.” In fact, many of these instructions were available on the 80186
microprocessor as well. Since few PC systems employ the 80186 microprocessor, this text
ignores that CPU. However, to keep the record straight...

Friday, March 5, 2010

The Milestones In A Games Life

A game runs sequentially, this happens this time, this happens after that. A game is structured in such a way that it is easy to understand, here is the “usual” order of a game:

Section 1: Initialization

* Allocation Of Required Memory

* Set Variables

* Open And Load Files

* Load Images, Sounds, Movies, Music

* Set Up Player Variables (score, power, speed)

Basically, this section’s purpose is to get the game ready to play. Sometimes it is important to keep the initialization separated into many functions, so when you want to reset certain variables, you can call on the appropriate init function.

Section 2: Game Entrance

* Loop Back Point For Every Game Cycle

* Actions Of The game Begins

Section 3: Game Logic

* AI For Enemies

* Collision Detection

* Setting Of Variables

Do Not Mix Graphics And Logic, Keep Them Seperated

This is the section where you would give the enemy some brains, and do

some processing.

Section 4: Movement

* Move Objects

* Scale Objects

* Rotated

* No Drawing Yet, Just Changing the Location Variables

Again, no drawing is done yet, this section comes after the logic, when you would determine how much the enemies would move, this section would be when you add that value to the enemies location variables.

Section 5: Player Input

* Where The Keyboard hits Are Read And Processed

* Mouse Movement Processed

* Joystick Movement Processed

One minor note, that doesn’t mean that all input devices have to be supported, that just means that this is where you evaluate their use during the game.

Section 6: Player Movement

* After The Evaluation Of Input, Players Variables Are Processed

* Also, Players Logic Should Also Be Put Here

Again, same as section 4 above, no drawing is done in this section.

Section 7: Rendering

* Screen Image Built Up

* Background First, Work Your Way Into Objects Closer To The Foreground

* This Is Where Everything Is Drawn, This Is Also What Takes The Mose Time Of The Game Cycle.

This is where you can finally draw everything.

Section 8: Music, Sound, Chores

* Odds And Ends Are Taken Care Of Here

* Updates Sounds

* Start Or Stop Or Pause The Music

* Updating Global Variables (frames processed, score, time elapsed)

* At Termination Of This Section, Program Jumps Back to Section 2

The Components That Comprise A Complete Game:

A game consists of many pieces, a good analogy would be a puzzle. When the puzzle is complete, it looks great. A game has many pieces, and when weaved together with the use of great programming, it creates a finished puzzle. Here are the pieces that you will need to create in order to “weave” a game together.

Recording Sounds:

* There are many public sound archives where you can get sounds.

* Or, you can make them yourself, with a sound editor

* A great tool, you may not realize, is the human voice, you can make almost any sound just by using your voice, and a little sound editing.

Drawing Graphics:

* I suggest you get a good drawing/graphics program. I have Photoshop, and I use it for all image drawing, for editing and everything else I use Paint Shop Pro, you can get it as shareware.

* Draw animations in frames, create bounding boxes so you can visibly see the individual frames in a given picture file.

Orchestrating Music:

* Music is difficult, especially when your not a musician, and few programmers are.

* Get a good midi recording or editing software, using a simple tool like this, you will be surprised at what you can create.

* Sometimes, putting a bunch of notes into a song will yield a good tune, then seriously edit it from there, that’s how I make almost all my music.

The Coding:

* Programming your game should in my mind, be the last thing done. There are a couple reasons for this, 1)Most of the code will require the graphics to test, 2)You can concentrate on the programming 100%

* Keep related functions in separate files, and use tried-and-true programming techniques.