Is graphics.library efficient enough for games?

[Nightfox]

Hey hey

I know that Amiga games are pretty much hitting the metal manually doing things like setting up the blitter etc. Since there are already some helpful functions in places like graphics.library to do basic drawing, I was wondering if these really should be avoided due to them being inefficient or other reasons.

Do games even create a RastPort struct at all?

I'm enjoying learning Amiga dev and it would be nice to know when it is a good idea to use these functions and which ones definitely should be avoided if making a game that you want to run well.

Thanks!!

[Thomas Richter]

Unlike what many people think, the blitter primitives in graphics are quite efficient, in particular if no clipping has to be made (i.e. rp->Layer == NULL). They just load the blitter registers with the data from the parameters, not much different from what manual blitting would also do. In case anyone wonders, the primitives are in assembler (e.g. BltBitMap() and BltTemplate()), not that it would make much of a difference.

Actually, that is the major drawback of graphics: Lack of abstraction. The primitives are so much bolded on the actual hardware that RTG is harder than it needed to be.

[Olaf Barthel]

Originally Posted by Nightfox

Hey hey

I know that Amiga games are pretty much hitting the metal manually doing things like setting up the blitter etc. Since there are already some helpful functions in places like graphics.library to do basic drawing, I was wondering if these really should be avoided due to them being inefficient or other reasons.

Do games even create a RastPort struct at all?

Speaking as somebody who, perhaps unwisely, wrote a commercial game in 1988/1989 which was published, yes, you can do this without running out of CPU or memory power and multitask at the same time. The baseline platform then was the humble Amiga 500 back in the day and unless you spend most of your CPU resources on computationally expensive work (think "SubLogic Flight Simulator II"), you don't have much to lose by playing nice with the operating system.

Back then it was still an option to just go to the bare metal, which worked well enough into the early 1990'ies, but from my limited insight into how this computer game industry worked, I'd say that the amount of knowledge the developers had to be comfortable with likely had a negative impact on productivity and debugging the dang thing. Back then it was common to reuse Kickstart code from disassembled trackdisk.device to read data off the floppy disk. You had to do this if you killed the operating system after booting and became responsible for interrupt handling and talking to the low level hardware.

Because some people never got around to read the specs for the hardware (or maybe those relevant pages were missing from the photocopied "Amiga Hardware Reference Manual") floppy disk access was something of a mystic craft exercised by heavily or not so heavily modified assembly language code that didn't always work robustly.

Directly talking to the hardware had its drawbacks, so some guys just didn't even bother and treated the Amiga like an Atari ST with nicely organized bitmap planes (although there were stories that some games, when ported from the Atari ST to the Amiga, just converted the Atari ST graphics layout to Amiga format very quickly).

The downside to not using the operating system is that you'll have a much harder time to create and debug what you are building. Back in the day that didn't matter much, because you were likely already conditioned to doing stuff the hard way by default. Coffee & cigarettes until you shipped.

I'm enjoying learning Amiga dev and it would be nice to know when it is a good idea to use these functions and which ones definitely should be avoided if making a game that you want to run well.

Thanks!!

My advice would be to build the stuff you need and measure the performance of what you built, then, perhaps, optimize as needed. Unless you target the humble Amiga 500 in its vintage configuration, you do not need to hang onto "proven" workarounds for fiddling with the bitmap contents just to speed things up. The graphics.library as we know it was very likely designed for the kind of games which were common in 1984/1985 (think "The Gauntlet" from Atari Games, ca. 1985) using bitmap sprites, double-buffering and playfield scrolling. When the Amiga became a desktop home computer, the use of these game-building APIs fell by the wayside.

You can still build games using a small part of the graphics.library API, but you likely won't be able to benefit from trying to use the rest because they assume a certain hardware to be around. Today's Amigas have largely given up trying to pretend that the custom chipset of old is relevant and you have the hardware-accelerated SVGA, etc. style framebuffer to work with.

How you use that is up to you. But, please, try to be nice first when you build it. You can always measure and tune your code later. Having the operating system around is helpful, not a sacrifice.

[bifat]

Games often do not use Rastport and Bitmap structures, but they can use equivalent or their own, better fitting structures, depending on the kind of game.
For some hard-hitting fullscreen action, you will likely need different strategies (for everything below 68030) and turn off the operating system, as it's in the way most of the time and does not really solve your problems. It's not specifically blitter operations which makes graphics.library slow and bulky, it's the huge overhead from (in the case of games) too much abstraction. Not too little, like the previous poster assumed.
I have programmed several games for the Amiga under the operating system for 68000. It can be done, but you may get a bloody nose from everything beyond strategy, point and click, board games etc.

[Nightfox]

Is there a way to tell whether or not a system function is going to work if you have turned off interrupts?

[Thomas Richter]

Originally Posted by Nightfox

Is there a way to tell whether or not a system function is going to work if you have turned off interrupts?

No, and you cannot "turn off parts of the Os" and expect other parts to continue working. The RKRM make a clear statement that you can only turn off interrupts for a short period of time - something in the 10-ms range - and that is all that you can depend upon. Thus, interrupts shall continue enabled. What makes you think that you need to disable interrupts? There is likely a better solution.

[Olaf Barthel]

Originally Posted by Nightfox

Is there a way to tell whether or not a system function is going to work if you have turned off interrupts?

Not as such, but you might not be wrong to assume that things will get harder, not easier, to accomplish if you turn off the motor of the car (interrupt servicing and handling), so to speak, as compared to just bringing the car to a complete stop (turning off multitasking).

For example, let's say you need to read data from a storage medium. If that is a floppy disk drive, you could actually do that with the interrupt servicing and handling turned off. You just have to do all the heavy lifting yourself. For example, you have to spin up the motor and wait sufficiently long until it is (according to the specs) operational (you did check that there is a disk in the drive, didn't you?). You have to set up the DMA operations to read the data you need and, of course, you also have to decode the MFM-encoded track contents. There's actually some example code (not too much, though: you still have to do the MFM decoding) in the old Amiga Mail articles which demonstrates how the sausage could be made.

If you were to read data from a hard disk, SSD or the network, you won't get far without interrupt servicing & handling enabled.

I'm not the expert, but I venture that the CPU time your system doesn't get to "waste" by leaving the multitasking and interrupt handling & servicing ticking along, will be negligible on anything but the humble 7 MHz 68000 CPU. Put another way, if there was a speedup, it would be the teensiest kind.

[kamelito]

IIRC the Denver Devcon contains some improvements planned for the graphics library to make better games using the OS and this famous specialfx.library. Dunno if anything better is planned in 3.3 or later versions of the OS in that respect.