Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!aramis.rutgers.edu!paul.rutgers.edu!njin!limonce From: limonce@pilot.njin.net (Tom Limoncelli +1 201 408 5389) Newsgroups: comp.sys.amiga.hardware Subject: Re: Hardware Idiots ? Message-ID: Date: 23 May 91 15:32:49 GMT References: <1991May22.193016.12202@lynx.CS.ORST.EDU> Organization: Drew University - Madison NJ Lines: 49 In article <1991May22.193016.12202@lynx.CS.ORST.EDU> rudolpe@jacobs.CS.ORST.EDU (Eric Hans Rudolph) writes: > I am programming the game BattleZone for the Amiga. I have the whole thing > written in Lattice C and it is slow, even optimized. With 5 or so tanks on > the screen and n missiles, and full 20 object rotations, it gets bogged > down. Now if I go in and mess around with hardware registers and blitter stuff, > I will be pretty much machine dependant on some things. I hear tell that the There is nothing wrong with going right to the HW, just do it the correct way. I think there is more to this issue than just going directly to the hardware. You have a lot of objects on the screen. You seem to be doing a lot of work for each one. I would imaging that the rotating, etc. is taking much more time than the drawing. Maybe you should re-write the rotation algorithm in assembler. But then again, a slow rotation algorithm rewritten in assembler is still a slow algorithm. Have you considered pre-calculating the rotations? Have you considered looking at the algorithm to see what doesn't need to be re-rotated or re-calculated across screen updates? > conversion, I am using system calls like AllocMem and AllocRaster, but as Ah, that may be another problem. Those routines aren't very fast. Why not call AllocMem once in the beginning of the program (one big chunk) and then use it? Same with AllocRaster. Allocate all your rasters in the beginning of the program, then re-use them. If you are using either of those calls in a loop, there are things you can do to improve the speed. I'm sure someone will post a message that says, "look at StarGlider, and this and that; they're all in assembler and really fast. Re-write your code in assembler and go directly to the hardware and it will solve all of your problems". If you really look at StarGlider you will see pre-rotated shapes and other tricks. In other words, they aren't comparing two similar problems. Portability seems to be a concern of yours. Going directly to the hardware may solve your problems now, but if you move to any other computer you won't be able to do those tricks and you'll be back where you started. Get the algorithms right the first time you write the program and porting will be even easier. Tom -- Tom Limoncelli tlimonce@drew.edu tlimonce@drew.bitnet 201-408-5389 Three witches making a potion. One asks, "A Liza Minnelli record, light beer, poppers, Frye boots; what's this spell for anyway?"