Using the Copper

[guy lateur]

Originally Posted by roondar

You can indeed disable all interrupts and that does prevent the OS from doing anything at all. Do note however that WaitTOF(), WaitBlitter(), disk IO and pretty much all other Wait() or signal response type functions the OS provides only work when the correct interrupts are available and if used while interrupts are disabled they may either hang or re-enable interrupts, neither of which is what you want.

My personal view these days is that you either use the OS (to do timing, IO, input, etc) or you don't use the OS at all. Manually disabling interrupts can have detrimental effects on system stability, especially so the system has a 3rd party harddisk controller or any form of network card.

That said, it is possible to selectively switch the OS on and off. However, if you wish the OS to stay on... You can change the priority instead and only use OS supported functions to dabble with interrupts (meaning no Forbid()/Permit() and no manual interrupt vectors except through Exec)

Ok, thanks for the explanation, roondar, I appreciate it!

I'd like to be friends with the OS for as long as possible, so I'll just use the priority for now -- it seems to work, after all. Also, most users probably won't appreciate my demo leaving their system in an unstable state..

[guy lateur]

Originally Posted by hooverphonique

A screen cannot capture input, but a window can, however. Otherwise, I think you can use input.device to capture input (mouse/keyboard) for yourself - I've never bothered with that in my demos/intros, though...

Thanks for the pointers, I may look into that sometime. It's a really minor annoyance, though, so I probably won't bother either. There's still a lot of way more fun stuff on my todo list..

[guy lateur]

Update: the copper bar now spans the whole vertical range of the screen.

As mentioned earlier, I was annoyed that I had some hard coded numbers in my source regarding the first (0x2b, anyone?) and last visible/copper-renderable lines on the screen. I got rid of them using some values in the View/Port structure in GfxBase. These are the relevant properties:

DWidth = GfxBase->ActiView->ViewPort->DWidth;
DHeight = GfxBase->ActiView->ViewPort->DHeight;

DxOffsetV = GfxBase->ActiView->DxOffset;
DyOffsetV = GfxBase->ActiView->DyOffset;

I translate these into more user friendly values as follows:

lineTop = DyOffsetV + 1;			// use +1 for caution
lineBottom = DHeight + DyOffsetV - 1;	// use -1 for caution
nrLines = lineBottom - lineTop + 1;

I can understand that DyOffsetV contains the magical 0x2b line starting value (lineTop), but the calculation of lineBottom is a little weird. Apparently, what you lose at the top (DyOffsetV), you get back at the bottom (DHeight + DyOffsetV). Is this the correct way to calculate this? It seems to work, but it feels kind of strange, especially when you try to apply the same logic to the horizontal values -- but let's not get into that just yet..

As mentioned earlier, I'm testing this on an Amiga Forever emulated A1200, and also on a real A1200. Both have their screen modes set to high-res PAL, but I do get different numbers (*) from the View/Port structures. Like I said, it seems to work, but I can't say I really understand it. It would be nice if somebody could elaborate a bit more on these numbers. The docs (http://amigadev.elowar.com/read/ADCD...ED.html#line63) aren't very helpful, unfortunately.

(*)
AF emulation:
DWidth, DHeight: 640, 256
DxOffsetV, DyOffsetV: 129, 44
Real A1200:
DWidth, DHeight: 724, 282
DxOffsetV, DyOffsetV: 93, 30