[comp.lang.pascal] Optimizing Arcade Games

bsasaki@uhunix2.uhcc.Hawaii.Edu (04/23/91)

Hello, 
 thank you all for the info about MCGA. I currently have BGVGA256.BGI
up and running on my MCGA system (199,319) and 256 colors. I am just
beginning to learn how to program a simple arcade game in pascal,
and currently using PutImage and GetImage extensively for animation,
ie.. writing the image, then XORing the old image position. I was
wondering if I should continue on this path for animation. Will
I run into memory problems if I use too many images. Or worse yet,
will the program become too slow to be recognised as an arcade game
after updating 4-5 images on the screen? Please give me some hints
on how to optimize my program and tricks or philosophies that anybody
can give me. I am using Turbo Pascal 5.0. Thank you very much.

								Aloha!
								newbie
'I wanna go back to my little grass shack..'

christer@cs.umu.se (Christer Ericson) (04/24/91)

In article <12610@uhccux.uhcc.Hawaii.Edu> bsasaki@uhunix2.uhcc.Hawaii.Edu writes:
>Hello, 
> thank you all for the info about MCGA. I currently have BGVGA256.BGI
>up and running on my MCGA system (199,319) and 256 colors. I am just
>beginning to learn how to program a simple arcade game in pascal,
>and currently using PutImage and GetImage extensively for animation,
>ie.. writing the image, then XORing the old image position. I was
>wondering if I should continue on this path for animation. Will
>I run into memory problems if I use too many images. Or worse yet,
>will the program become too slow to be recognised as an arcade game
>after updating 4-5 images on the screen? Please give me some hints
>on how to optimize my program and tricks or philosophies that anybody
>can give me. I am using Turbo Pascal 5.0. Thank you very much.

If you're not willing to write your own assembler routines for "blitting"
stuff on the screen, there's a simple trick you can use to speed up your
current routine by a power of two (sacrificing some memory in the process).

Instead of XORing the new image and then erasing (again XORing) the old image,
combine this into one XORing by having an image that is the combination (XOR)
of the old image and the new image. This means that you'll need one "regular"
image (used to draw the image the first time, and when erasing it completely)
and one "combination" image for _every_ possible dx/dy move your image can
make. In most cases you'll only need four extra images (for one pixel up/down/
left/right moves), or eight in case you can move diagonally too, and this
shouldn't eat up too much memory. If you have a lot of different images and/or
weird move patterns then you'd be better of with your own assembler routines.
I'm no PC programmer (God forbid! :-) but I'd guess that Turbo Pascal's
Get/PutImage aren't that hot so if possible go for some optimized routines of
your own.

/Christer


| Christer Ericson                            Internet: christer@cs.umu.se |
| Department of Computer Science, University of Umea, S-90187 UMEA, Sweden |