31 January 2024, 12:58 | #1 |
Registered User
Join Date: Apr 2016
Location: Perth, Australia
Posts: 431
|
Is graphics.library efficient enough for games?
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!! |
31 January 2024, 13:12 | #2 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,403
|
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. |
31 January 2024, 14:00 | #3 | ||
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 538
|
Quote:
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. Quote:
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. |
||
31 January 2024, 14:00 | #4 |
Registered User
Join Date: Mar 2021
Location: Berlin
Posts: 26
|
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. |
31 January 2024, 16:14 | #5 |
Registered User
Join Date: Apr 2016
Location: Perth, Australia
Posts: 431
|
Is there a way to tell whether or not a system function is going to work if you have turned off interrupts?
|
31 January 2024, 17:09 | #6 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,403
|
Quote:
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. |
|
31 January 2024, 17:39 | #7 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 538
|
Quote:
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. |
|
31 January 2024, 18:32 | #8 |
Zone Friend
Join Date: May 2006
Location: France
Posts: 1,889
|
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.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Issue with graphics.h library? | Amiga1992 | Coders. C/C++ | 50 | 23 April 2024 15:13 |
Library for loading graphics | sparhawk | Coders. General | 2 | 07 March 2020 20:38 |
Flickering graphics using BltBitMap function of graphics.library | balrogsoft | Coders. C/C++ | 16 | 04 February 2020 14:54 |
Making games in C. graphics.library? | elanstra | Coders. C/C++ | 16 | 02 December 2019 21:28 |
Sas/C vs. GCC regarding graphics.library | Steffest | Coders. C/C++ | 7 | 27 October 2017 03:52 |
|
|