steveb@cbmvax.UUCP (Steve Beats) (04/06/88)
In article <10907@shemp.CS.UCLA.EDU> cc1@CS.UCLA.EDU (Michael Gersten) writes: >I have a question on speed. >Just how fast are the drawing routines? > I can't give a definitive answer on this one, but I have heard a lot of comments from people on and off UseNet that they fared better with thier own routines. It does kinda make sense. The ROM animation routines are trying to be everything to everybody and will probably spend a lot of time doing things you don't require; unnescessary overhead. I would suggest using the animation routines first, identify the problem/slow areas, and then recode those sections yourself. > >Another question: Is there anyway to get two video displays on the screen >HORIZONTALLY; I.e., is the current limitation on only vertically seperated >viewports hardware or software? I'd like to get > > 200 by 200 4 plane 20 by 200 blank 100 by 200 one plane > I see a couple of approches to this one. Do you REALLY need 4 planes for the first horizontal bitmap? If you can get away with 3 then dual play- field mode will do what you want with minimal messing around. You just set up your two playfields so they don't overlap and voila, you've got the setup you describe. From your ScrollVPort reference, I'm assuming you want to smooth scroll the first (3 plane) bitmap. This would be really easy in dual playfield mode since the playfields can scroll independently. If you must have 4 bitplanes, then I'm afraid we're getting into some real theoretical territory here. First a few no-can-do's. You can't reload the video DDFSTART and DDFSTOP registers during display time (I think) this can only be done during horizontal retrace. You also can't have bitplanes with different modulos in the same ViewPort. So, what can we do? Weeeelll; First off, you're going to need a set of copper instructions for each line of the display. They will look something like this; CWAIT line,196 wait 4 pixels before vertical break CMOVE 1plane,BPLCON0 enable only 1 bitplane CWAIT line,316 wait 4 pixels before end of line CMOVE 4planes,BPLCON0 enable 4 bitplanes again This would be an ideal place to use the CSKIP instruction to loop around and do the same thing on each line. However, the graphics.library doesn't provide any support for this instruction (how would you sort it in?) so it would be easier (read more system friendly) to use separate instructions for each line. Remember, in lo-res, 4 bitplanes, you get to use one copper move instruction every 4 pixels, so your 20 pixel blank area effectively gives us a 5 instruction window. Now we have a 4 bitplane display that turns off 3 of the planes in the right place. Scrolling is our next problem. Since you need to scroll the whole bitmap, we're going to have to bring the blitter into play too. Use the smooth scrolling registers to position the whole display where you want it and then use the blitter to re-position the small text area back to where it was. I suspect this would be real slow but it's the only thing I can think of. Oh yeah! I just had another thought. Why not use BOBs for your animation and just use a 200 bit wide by 4 plane bitmap. The area to the right of this (100x200x1) could be done by positioning 7 sprites next to each other and rendering into them. This would work really well because sprites can be any height. You would have to write your own rendering routines though to get text and or graphics into the sprite data (it's word pairs). I like that idea! This would give you exactly what you want with just a little extra work involved in the sprite rendering code and no special copper lists required. Steve