Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site amiga.amiga.UUCP Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!hplabs!pyramid!amiga!dale From: dale@amiga.UUCP (Dale Luck) Newsgroups: net.micro.amiga Subject: Re: Blitter Message-ID: <1007@amiga.amiga.UUCP> Date: Mon, 21-Apr-86 13:14:22 EST Article-I.D.: amiga.1007 Posted: Mon Apr 21 13:14:22 1986 Date-Received: Wed, 23-Apr-86 13:15:42 EST References: <8604192201.AA10369@cory> Reply-To: dale@tooter.UUCP (Dale Luck) Organization: Commodore-Amiga Inc., 983 University Ave #D, Los Gatos CA 95030 Lines: 53 > >From: Tomas G. Rokicki > >I have an application which requires extremely fast blitter operations. >The 420 microsecond overhead for each call of BltTemplate() is too high >by a factor of ten. Two questions: > a) Is there a way around this with a C function? I have searched >through all the manuals, and have come up with nothing . . . > b) I currently plan to write a short assembly language function >to write to the blitter registers directly. How can I prevent this from >mucking with the operating system? How do I tell when the blitter is free, >and how do I lock it for my use? Do I have to disable interrupts, or what? > If we had provided a way of doing this operation but with only 10% of the overhead, why would we have provided the slow function? :) So there is no magic 'faster' command as there appeared to be in the linker. There are different ways of making your graphics operations faster by reducing the amount of work and increasing the number of assumptions the graphics routines can make. Are you BltTemplateing into a window? If you open a custom screen and use the RastPort that exists in the Screen struct you can elliminate all the layer stuff it needs to do and speed up your graphics operation. This is true for all graphics operations. They are much faster in naked rastports than they are in layered rastports. Note that naked rastports also do not provide and clipping, so you have to know what you are doing before telling it to draw those 1000 pixel lines. Make sure it wont draw outside of the bitmap borders. If this is still not fast enough, and you feel that you can achieve better performance by talking to the blitter yourself then we also make that available in a 'system ok' fashion. There are two ways of doing this. You can use the blit queue which is interrupt driven and asynchronous. You set up a routine to be called by the blitq'er. It gets called when the blitter is free, you then stuff the registers and start the blit yourself, you need to obey proper protocal and return values so that you don't crash the machine here, consult your rkm. You can use OwnBlitter/DisownBlitter. These are synchronous routines. OwnBlitter returns when you logically own the blitter. The blitter however maybe be busy with a blit from the previous owner. After OwnBlitter you should call WaitBlit(). At this time you can stuff those blitter registers and start off a blit. When you are done with your last blit you MUST DisownBlitter or dire circumstances will result. The entire graphics/text/layers/windows/.... (even trackdisk) requires quick and efficient access to this one resource so please play ball with the rest of us. The game will go longer that way. :) Have fun with your new found speed toy. Dale Luck