Graphics/game and RTG programming

[ProfPlum]

I grew up with an Amiga. Did some development during my college years - graphics & intuition lib stuff.

I want to revisit Amiga development when I eventually retire, one needs a hobby!

I have installed vbcc and built some simple apps.
(I happen to be a developer by day)



Questions...

Do games need to be developed by programming the hardware directly or programming via the OS is also an option.

For games, why assembler as opposed to C - I noticed there is an entire discussion/thread about this topic. I'll go through it eventually. A sentence or 2 will suffice for now.

RTG - quite common now. Vampire, PiStorm, ZZ9000, ...
Is RTG development done via the P96 framework, the Amiga OS itself, or both?

[Samurai_Crow]

Originally Posted by ProfPlum

Questions...



Do games need to be developed by programming the hardware directly or programming via the OS is also an option.



For games, why assembler as opposed to C - I noticed there is an entire discussion/thread about this topic. I'll go through it eventually. A sentence or 2 will suffice for now.



RTG - quite common now. Vampire, PiStorm, ZZ9000, ...

Is RTG development done via the P96 framework, the Amiga OS itself, or both?

1. OS friendly games can be used as a fallback option if a) you aren't using most of the features of the chipset anyway, or b) you are not using an Amiga chipset at all. I started writing a replacement for Graphics.library in C mostly, but nobody would use it in this day and age because the Amiga chipsets were never designed for future hardware nor was the operating system.

2. GCC 6.5 is ok because Bebbo created custom passes that use all the tricks. GCC 13.2 is ok for hardware banging outside of the critical loops because Bartman of Abyss made an emulation environment that lacks 6.5's runtimes for now. (Those 2 are working together on bringing GCC13 up to snuff.)

3. RTG requires a patched version of Graphics.library accompanied by P96 or CyberGraphics. I think Kickstart 3.2 is incorporating those patches. There's no advantage to bypassing the OS when doing RTG because Cybergraphics and P96 malfunction with it disabled anyway.

Vampire/Apollo SAGA core can be hardware banged because its core implements the features of RTG into an Amiga-style chipset and Gunnar insists that hardware banging is system-friendly under those circumstances.

[Bruce Abbott]

RTG = Retargetable graphics. By definition this means working through the OS and/or RTG library. No hardware banging because the hardware could be anything.

Hardware banging is typically done on low-end Amigas like the A500 and A1200, for a few a reasons:-

1. To get the best possible performance.

2. To do affects that can't realistically be done through the OS.

3. Because hardware banging is is 'easier'.

If you are a using a system with RTG then none of these things apply, because you can't bang the hardware.

The Vampire and PiStorm are powerful enough that you shouldn't have to program in asm. You might still want to use it for critical sections to get the best possible performance, but that is probably not something you should be considering at the design stage.

RTG is done through the RTG library and/or through the OS, depending on what you want to do. For games you will probably want to go through the RTG library for performance.

However, if you program only for powerful systems with RTG, you will severely limit your audience. You might want to ask yourself, am I really making an Amiga game, or a game for 3rd party addons? You may be happy with that. However you should realize that producing a good game takes a lot of effort. Few games are worth producing just to play by yourself, so having a wide audience is important for keeping the motivation up.

So for your own benefit as well as ours, I recommend you design your games to run on the minimum possible spec Amiga consistent with what you want to achieve. If possible, make it run either through RTG or the native chipset, with the user able to choose what screen mode to use. Also try to make it compatible with the OS version typically installed, eg. 3.0 for the A1200 and A4000.

Depending on what the game does, it may be possible to do it all using OS functions. I have done for it for commercial titles on the A500, CDTV and CD32. I programmed in asm, but that was just my choice. Similar results are possible in C.

[VladR]

Originally Posted by Samurai_Crow

3. RTG requires a patched version of Graphics.library accompanied by P96 or CyberGraphics. I think Kickstart 3.2 is incorporating those patches. There's no advantage to bypassing the OS when doing RTG because Cybergraphics and P96 malfunction with it disabled anyway.

So, my only RTG experience is with writing a flatshader for Vampire V4 and it was suggested that I use CGX (honestly, I don't recall why today). But now I can see that it's the P96 library that is used everywhere (especially for Emu68k).
I looked into P96 and it's having regular updates (even recently this year!).

So, is there any particular benefit of using CGX over P96 ? I don't mean from functionality standpoint - all I need from OS/RTG as a coder is a pointer to the chunky framebuffer and a function to flip the framebuffers. The rest is my engine.

Perhaps in past CGX was preferable for some reason ?

Originally Posted by Samurai_Crow

Vampire/Apollo SAGA core can be hardware banged because its core implements the features of RTG into an Amiga-style chipset and Gunnar insists that hardware banging is system-friendly under those circumstances.

What specifically do you mean? SAGA registers ? Or the AMMX extension ?

[Samurai_Crow]

Originally Posted by VladR

Perhaps in past CGX was preferable for some reason ?





What specifically do you mean? SAGA registers ? Or the AMMX extension ?

The AROS version of Cybergraphics is completely open source freeware while P96 is behind a "paywall" and is closed source.

Re:hardware banging on SAGA
I was referring to the custom core registers being accessed without drivers at all.

[Karlos]

You want to avoid hardware banging, but if you may well want to perform direct access to bitmap data in the graphics card's VRAM. For that, you'll need to care about locking, target pixel format and so on. I don't know about the current state of the art for RTG operations but back on CGX4.1 on 68K, conversion between formats was dog slow. I ended up writing my own.

[VladR]

Originally Posted by Bruce Abbott

However, if you program only for powerful systems with RTG, you will severely limit your audience. You might want to ask yourself, am I really making an Amiga game, or a game for 3rd party addons? You may be happy with that. However you should realize that producing a good game takes a lot of effort. Few games are worth producing just to play by yourself, so having a wide audience is important for keeping the motivation up.

So for your own benefit as well as ours, I recommend you design your games to run on the minimum possible spec Amiga consistent with what you want to achieve. If possible, make it run either through RTG or the native chipset, with the user able to choose what screen mode to use. Also try to make it compatible with the OS version typically installed, eg. 3.0 for the A1200 and A4000.

That is, basically, impossible.

I've been recently collecting data on MIPS and the RTG range (slowest vs fastest) is in the order of roughly ~3,000 : 1 (OC'ed CM4 vs A1200)

No SW rasterizer game ever on PC could handle that kind of performance differential and scale well (I don't count VSYNC or hard framecap as a solution).

These days, you can have modern 3D engines scale that much (huge performance differential between 3D cards) due to LOD in shaders and postprocessing, but core game assets are still done just in 1-3 LODs.

The resolution itself does only so much. 1600x1200 vs 320x200 is merely 30:1.
That's a far cry from 3,000 : 1

Here's a small MIPS/MFLOPS table that I collated recently:

;	MIPS / MFLOPS		HW
------------------------------------------------------------------
;	2,600			OC'ed CM4 @ 2.3 GHz
;	1,635	/ 1,681		2 GB PI4b / PiStorm32Lite / A1200
;	  883	/   828		PI3b
;	  627	/   595		PIZero2w
;	  163	/    81		Vampire V2 V1200
;	  78.5	/ 56		68060@100 MHz (Rev 6)
;	  39.2	/ 28		68060@50 MHz (Rev 4) : TF1260
;	  30.1	/  7.7		68040@40 Mhz : Cyberstorm
;	  19.3	/  4.8		68040@25 Mhz
;	   9.5	/  1.4		68030@50 Mhz : TF536
;	   7.9	/  1.0		68030@40 MHz

;	  38.6	/ 27.7		68060@50 MHz : A1200 + Blizzard 1260 + 64 MB Fast
;	   9.6	/  		68030@40 MHz : A1200 + ACA1232 + 128 MB Fast
;	   3.5	/		68020@17 MHz : A1200 + ACA1221 + 64 MB Fast
;	   1.3	/		68020@14 MHz : A1200

;	   9.53	/		68030@40 MHz : A500 + Indivision ACA1232
;	   3.59	/		68020@17 MHz : A500 + Indivision ACA1221
;	   1.51	/		68000@14 MHz : A500 + Indivision ACA500

;	   0.9	/		68020@25 MHz

That's a scary performance range !

[VladR]

Originally Posted by Samurai_Crow

The AROS version of Cybergraphics is completely open source freeware while P96 is behind a "paywall" and is closed source.

Oh, I see. Makes sense.
Wait, is there also a different non-AROS version of CGX ?
Meaning, if I wanted to run my CGX-based engine on a different RTG HW than Vampire, it wouldn't be the same library ? Perhaps also behind a paywall ?

Originally Posted by Samurai_Crow

Re:hardware banging on SAGA
I was referring to the custom core registers being accessed without drivers at all.

Right. Well, there couldn't possibly be any OS library written for the SAGA registers (unless someone wrote those extensions), as that's a brand new development, after all. So, it's not like there is another option other than HW banging...

Is there even open-source version of the libs like graphics.library / intuition / etc. ?

[derSammler]

Originally Posted by VladR

So, is there any particular benefit of using CGX over P96 ? I don't mean from functionality standpoint - all I need from OS/RTG as a coder is a pointer to the chunky framebuffer and a function to flip the framebuffers. The rest is my engine.

First, CGX was a commercial product that you had to buy. P96 on the other hand was basically free (when you had certain hardware) or shareware with no limitations for other supported graphics cards. Versions up to 2.1 are still, so that is one reason why it has broader use even today.

Moreover, P96 has CGX emulation. So when using P96, it does not matter if the software was written to use CGX or P96 - it will just work. And while people say the CGX emulation is not perfect and has bugs, I never found even a single issue with any RTG software using P96 2.1.

Conclusion: writing software for CGX makes more sense, as it will run on both P96 and CGX, leaving it up to the user which system to use.

[VladR]

Originally Posted by Karlos

You want to avoid hardware banging, but if you may well want to perform direct access to bitmap data in the graphics card's VRAM. For that, you'll need to care about locking, target pixel format and so on.

Well, the whole purpose of RTG is that one code runs on hundred different accelerators. Once you start fragmenting your framebuffer implementation based on internals for one specific HW combo, you could easily spend half your life trying to get it running on just major RTG cards...

For example, under CGX I just call CGX's _LVOWritePixelArray (a6) at the end of each frame (to convert my chunky framebuffer that I fill on 68000) which in theory should work under all RTG accelerators (starting with lowly A1200, through 060/Vampire, all the way to RPi), right ?

Originally Posted by Karlos

I don't know about the current state of the art for RTG operations but back on CGX4.1 on 68K, conversion between formats was dog slow. I ended up writing my own.

You mean Chunky to Planar conversion ? Aren't those part of RTG drivers responsibility ? I'd assume that this would be the single most optimized thing within RTG library, no ?

[Samurai_Crow]

Originally Posted by VladR

Is there even open-source version of the libs like graphics.library / intuition / etc. ?

AROS is an open-source replacement for AmigaOS written mostly in C. ApolloOS is a fork of it. The old version of ApolloOS on GitHub isn't the latest version with more AMMX stuff in it but it should use the same ABI and API.

[VladR]

Originally Posted by derSammler

First, CGX was a commercial product that you had to buy. P96 on the other hand was basically free (when you had certain hardware) or shareware with no limitations for other supported graphics cards. Versions up to 2.1 are still, so that is one reason why it has broader use even today.

Thanks ! That's very interesting. It explains why some people were drawing the line around 2.1! Amiga sure has some rich history!

Originally Posted by derSammler

Moreover, P96 has CGX emulation. So when using P96, it does not matter if the software was written to use CGX or P96 - it will just work. And while people say the CGX emulation is not perfect and has bugs, I never found even a single issue with any RTG software using P96 2.1.

Conclusion: writing software for CGX makes more sense, as it will run on both P96 and CGX, leaving it up to the user which system to use.

I didn't know that. But, how would that work and not crash (or throw error code) ?
This is how I open CGX in my code:

			move.l	4,a6
			move.l	#CyberGraphXLibName,a1		; Name
			move.l	#41,d0				; Version
			jsr	_LVOOpenLibrary(a6)		; Open library
			move.l	d0,CyberGraphXBase		; Store Ptr

Are you saying I can keep that code and it will just, somehow (automagically!), run on a system that has no actual CGX library (but just P96) ?
I never ran that code outside of AROS and Vampire V4 / V2.

Does P96 insert some library hooks or something ? How does that work on the OS-level without throwing error? Does Amiga OS implement library replacement on an OS level, actually ?

[Samurai_Crow]

ApolloOS 7 is on https://github.com/ApolloTeam-dev/ApolloOS.

[Karlos]

Originally Posted by VladR

You mean Chunky to Planar conversion ? Aren't those part of RTG drivers responsibility ? I'd assume that this would be the single most optimized thing within RTG library, no ?

No, I mean interconversion of various chunky / RGB formats. Please bear in mind this was circa 25 years ago.

[kamelito]

@ProfPlum
You can look at https://github.com/AmigaPorts/ACE
And https://github.com/Lexodev/SAGE/tree/release/R23Q3

[Thomas Richter]

Originally Posted by VladR

Thanks ! That's very interesting. It explains why some people were drawing the line around 2.1! Amiga sure has some rich history!

Note, however, that more recent versions provide you with a couple of benefits such as dragable screens or multi-monitor support.

Originally Posted by VladR

I didn't know that. But, how would that work and not crash (or throw error code) ?
This is how I open CGX in my code:

            move.l    4,a6
            move.l    #CyberGraphXLibName,a1        ; Name
            move.l    #41,d0                ; Version
            jsr    _LVOOpenLibrary(a6)        ; Open library
            move.l    d0,CyberGraphXBase        ; Store Ptr

Are you saying I can keep that code and it will just, somehow (automagically!), run on a system that has no actual CGX library (but just P96) ?

You can keep that code, but see above - that API is not going to extend anymore as CGfx is a dead end. How it works - P96 creates a cgx library once it is loaded, quite simple. But quite realisticly, Cgfx is dead as a dodo, so depending on this is really not looking into the future. P96 is still under support (all providing that there are also customers willing to support it by buying it).


The reason why the license model changed (back then - free for users, not free for hardware vendors - now just the reverse) is that certain vendors just stole the API without ever paying for it. Elbox is one of them, and Gunnar is another. Thus, please thank such people for making you as a user pay.

[VladR]

Originally Posted by Thomas Richter

Note, however, that more recent versions provide you with a couple of benefits such as dragable screens or multi-monitor support.



You can keep that code, but see above - that API is not going to extend anymore as CGfx is a dead end. How it works - P96 creates a cgx library once it is loaded, quite simple. But quite realisticly, Cgfx is dead as a dodo, so depending on this is really not looking into the future. P96 is still under support (all providing that there are also customers willing to support it by buying it).


The reason why the license model changed (back then - free for users, not free for hardware vendors - now just the reverse) is that certain vendors just stole the API without ever paying for it. Elbox is one of them, and Gunnar is another. Thus, please thank such people for making you as a user pay.

Thanks, that makes full sense now!

I guess I will just replace the few CGX calls during initialization of the gfx mode with P96.
And there's just one CGX call per frame (WritePixelArray) so that should be very straightforward to replace.