Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!pacbell.com!tandem!zorch!amiga0!mykes From: mykes@amiga0.SF-Bay.ORG (Mike Schwartz) Newsgroups: comp.sys.amiga.programmer Subject: Re: Block Moves Blits Message-ID: Date: 28 Jun 91 11:47:28 GMT References: Organization: Amiga makes it possible Lines: 116 In article utoddl@next1.oit.unc.edu (Todd M. Lewis) writes: > >Mike Schwartz writes: >>In article utoddl@next1.oit.unc.edu (Todd M. Lewis) writes: >> >>[ paraphrased: He wants to drive the blitter to do >>BlitMaskBitMapRastPort() himself ] > >Sorry, Mike, that's not what I said. A side effect of what I want to do >would be the creation of the routine BltMaskBitMapBitMap(), which currently >doesn't exist. But that's not the point. The points are (1) to understand >all the nuances of using the blitter to do block moves, and (2) to provide >a working piece of example code which incorporates every detail that must >be dealt with when using the blitter directly, excluding perhaps dealing with >overlapping blits and layers. > 1) Get the SOURCE to blitlab. It not only has code to drive the blitter, but it also has 'C' code that emulates the blitter. If you want to reinvent the wheel, go ahead. Tom has already given us a great example of how to use the blitter. Also, AmigaMail contains a few examples as does the Hardware Manual. 2) get blitlab... >My reasons are simple and follow the two points above: (1) I'm doing lots >of blits over and over and I can make them go faster (I hope) if I precalculate >each blit and do the QBlit() tricks, which requires that I understand how >the blitter works, and (2) it would be a shame to make sense of all that >and not share it with other programmers. > 1) Precalculating is a good idea if you want speed, but QBlit makes no sense at all. If you know the size of what you want to blit, it is trivial to code up REAL fast blit routines to blit specific sized items. Also you might want to consider RAW blitting, which has been covered here a few times. Once you do an OwnBlitter(), you can load the values you want into the blitter registers and most of them stay there forever, or until you release the blitter (Qblit forces you to reload the blitter registers over and over). 2) Your desire to share your results is commendable, and I appreciate it. >Several people have pointed out to me that I left out some steps in my >thumbnail description of what I was doing. I didn't mean to be incomplete, >but I didn't want to get bogged down at the OwnBlitter/WaitBlit/DisownBlitter >level--I want to get bogged down at a much lower level:-) > You NEED to be complete, especially when dealing with the blitter the way you want to. Again, if you don't do things correctly, your code will cause havoc to the system. If the OS is using the blitter to scroll a window while you are storing to the blitter registers, you are going to make the blitter store to random memory locations - instant GURU. Also, again, you need to do OwnBlitter() if you want to keep the blitter registers loaded with the numbers you want. Once you set up the blit, you only need to store Source, Destination, and BltSize to start the next plane blit. Any other way, and you will have to load up to 14 registers again and again. You might also consider using blitter NASTY, which makes the blitter go 2x faster. You might also consider using the CPU instead of the blitter if the CPU is an 030 (it is faster that way). >>And, by the way, rewriting BMBMPRP() is a great idea. It is a useful >>general purpose function as is, but it is at least 100 times slower >>than most software needs it to be. > >Have to disagree with you there, at least until I see some data supporting >your assertion. BMBMPRP() has to deal with layers, and must set up the blitter >without making any assumptions about the blit. The overhead could easily take >longer than the blit itself, especially for small (say, the size of a lemming) >blits. My guess (I haven't looked at the code) is that BMBMPRP() is just about >as optimized as it can get and still work. > BMBMRP() is slow no matter how you use it. Try it for yourself and see. Create a bitmap and rastport with NO layers and it still is dog slow. When I first started programming the Amiga 6 years ago, a friend gave me a blit routine he wrote called BlitBitMapPlane(), which was written in 'C'. It took 16 input parameters on the stack (for each plane of a blit no less) and it in turn called an internal blit routine with another 14 parameters on the stack. All that pushing and popping of parameters gets multipled by 5 if you do 32 colors... Anyhow, this terribly inefficient 'C' code was 10 times faster than BMBMRP(). And if you really want to know how to use the system blit routines to do BMBMRP() style blitting, you can do 2 BltBitMap() calls faster than a single BMBMRP() call. >Incidentally, if I do get a working BltMaskBitMapBitMap(), I can promise you it >will be dog slow. Why? Because I intend to make it as clear as possible >for people to understand what is involved in blitter settup. In fact, it should >not be used. Just knock up a RastPort with a null Layer, set the BitMap ptr to >the right place and use BltMaskBitMapRastPort() and save yourself some time and >code size. > You should explore the 2 BltBitMap() calls before you determine how dog slow your code needs to be. You should try 2 BltBitMapRastPort() calls as well, which also runs real fast. I agree you will save yourself programming time and code size if you don't bother to try to make faster code. >>**************************************************** >>* I want games that look like Shadow of the Beast * >>* but play like Leisure Suit Larry. * >>**************************************************** > >I want games that play like Lemmings, but where people send me the money! > >Todd (utoddl@next1.oit.unc.edu) Lewis -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************