Aloha. I've decided to expand my somewhat limited knowledge of how all the graphics bits hang together and I'm curious about CGX and P96 on classic. I'm going to continue reading all the SDK / docs I have but this may prove quicker in the meantime :)

I've come across comment about emulation of CGX under P96 (and possibly the other way around) and I was wondering if there's a "standard" way of using / detecting RTG? Does P96 automagically install "cybergraphics.library" stubs so you just code as though using CGX or is it something to do with "rtg.library"? I can't seem to find any definitive documentation on that yet. Or do you actually need to check for both CGX and P96 libraries and explicitly call whichever one is present?

Any help - or better yet, pointers to docs - gratefully received!

_________________
Karma: Positive

P96 always installs/creates a cybergraphics.library and going CGX was and still is the best way to ensure compatibility with various user installs.

As for detecting RTG, as long as you don't need High/True color modes you don't (nor should) do anything CGX. If do need it you just try and fail if it ain't there.

For optional functionality you could check the Bitmap*s depth and mode (I think CGX defines them for anything chunky).

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Awesome, thanks for the info. I would use the CGX functions for writing, say, 32-bit chunky pixels to a bitmap, assuming it is supported by the hardware / doesn't fail, right? Or does either library patch something in graphics.library to do the same? I've not seen anything above 8-bit chunky in the vanilla OS functions, so assuming it is stuck to max. 8-bit planar bitmaps - which makes total sense given that's all that AGA does.

_________________
Karma: Positive

If you need 16/32bit color mode you need to open cybergraphics.library anyways, if it fails you're on a OCS/AGA only system and need to bail out.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Got it - thanks for the clarification. I'm looking at the CGX docs now, having found my CD, so I shall go and see what damage I can do with a few test programs on the machine itself :)

_________________
Karma: Positive

@ All

Anyone here tried to hit the CybervisionPPC directly ?

I have Docs for the Permedia2, but can't find it directly,
maybe hiding in MMU tables .


Wol.

_________________
It is my conviction that killing under the cloak of war is nothing but an act of murder.~Albert Einstein

@Wol

I've certainly bitbanged the BVision plenty.

_________________
Doing stupid things for fun...

@Karlos

So does the same code work on a voodoo?

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Code written to bang Permedia metal? Of course not.

_________________
Doing stupid things for fun...

@Kronos

Quote:

For optional functionality you could check the Bitmap*s depth and mode (I think CGX defines them for anything chunky).

ISTR it can't be checked directly. The depth should equal 1 for 1 plane in packed as it only has one plane of depth. Technically, this is correct, as packed (or chunky) is one plane of pixels where the pixels are spread across the X width. As opposed to planar where they are spread across the depth or in Z planes.

A bitmap doesn't contain a direct width either but is in bytes per line. So, a 320 width packed bitmap, will have 320 bytes per line at 8 bpp. At 16 and 24 bpp (aligned to 32 bits), this would be 640 and 1280 across.

So finding the actual bpp can remain a mystery. It isn't helped that bitmaps never stored much extra data in the flags. Nor were expanded too.

Last edited by Hypex on 11-Dec-2022 at 02:01 PM.

@Hypex

I used CGX in my old projects. I found the most reliable way was to map the enumerated pixel format to whatever notion of depth was required.

_________________
Doing stupid things for fun...

@Karlos

LockBitMapTags has a conflict between CGX and Graphic.library
so I remove CGX stuff from source code, if I find it.

Last edited by NutsAboutAmiga on 11-Dec-2022 at 09:05 PM.
Last edited by NutsAboutAmiga on 11-Dec-2022 at 09:03 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Good for you. How is that relevant to anyone wanting to learn about cybergraphics

If you're writing RTG dependent code in 3.x because you specifically want chunky/15/16/24/32 bit packed pixels and you want to go fast (i.e. you want to write directly to VRAM) you use cybergraphics or p96 directly. And you don't even need to pick p96 at all because it provides the same CGX functionality. Stuff I wrote that was primarily designed on the CGX4 that ran on my Permedia worked flawlessly on the same OS with mediator and Voodoo, for example.

I can't say the reverse was ever true.

Last edited by Karlos on 12-Dec-2022 at 12:16 AM.
Last edited by Karlos on 11-Dec-2022 at 09:32 PM.

_________________
Doing stupid things for fun...

@Karlos

CGX and P96 is obsolete, everything you need is in graphics.library.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

You're talking typical NG myopic crap. Did the OP say they were using OS4? It may come as a huge surprise but people do still use, and choose to use 68K/3.x. Who knew?

Last edited by Karlos on 11-Dec-2022 at 11:14 PM.

_________________
Doing stupid things for fun...

@NutsAboutAmiga

Quote:

CGX and P96 is obsolete, everything you need is in graphics.library.

P96 is so obsolete it's still in active development! I've just made the switch from CGX for the BVision; sadly, graphics.library on OS3.x doesn't natively support anything higher than 8-bit planar, so I need the boost.

@Karlos
Quote:

It may come as a huge surprise but people do still use, and choose to use 68K/3.x.

I even stated this was on classic hardware in my original post!

_________________
Karma: Positive

@Drule

Its strange they did not include it in NDK3.2R4,
Of course, this complicates things for larger projects.
If you want to optimize for different OS’s.

Picasso96 is best supported for AmigaOS3.2
CyberGraphics is the native api for MorphOS
Graphic.library is the native api for AmigaOS4.1.

Configure scripts are not exactly optimal on AmigaOS.

There is of course SDL for cross platform development, but can be a bit bloated.
(More noticeable on lower end computers, if you’re working with tight restraints, it can be the differences between sound glitches or frame drops. )

Quote:

P96 is so obsolete it's still in active development!

http://wiki.icomp.de/wiki/P96_Driver_Development

Because rtg.library patches itself into graphic.library, they wanted to remove the patches, but the board drivers, chip drivers, boardinfo structure remains, so a little bit remains.

Picasso96.library / cybergraphics.library has becomes wrappers for graphics.library, so what ever you do it all ends up in graphic.library anyway.

Last edited by NutsAboutAmiga on 12-Dec-2022 at 01:16 AM.
Last edited by NutsAboutAmiga on 12-Dec-2022 at 01:12 AM.
Last edited by NutsAboutAmiga on 12-Dec-2022 at 01:07 AM.
Last edited by NutsAboutAmiga on 12-Dec-2022 at 12:57 AM.
Last edited by NutsAboutAmiga on 12-Dec-2022 at 12:56 AM.
Last edited by NutsAboutAmiga on 12-Dec-2022 at 12:42 AM.
Last edited by NutsAboutAmiga on 12-Dec-2022 at 12:39 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

Picasso96.library / cybergraphics.library has becomes wrappers for graphics.library, so what ever you do it all ends up in graphic.library anyway.

OK, so with that in mind, could you post a code example of how to render 32-bit ARGB with the graphics.library alone. I'm evidently missing something.

_________________
Karma: Positive

@NutsAboutAmiga

Quote:

Picasso96.library / cybergraphics.library has becomes wrappers for graphics.library, so what ever you do it all ends up in graphic.library anyway.

This only applies to the V54 graphics.library used in AmigaOS 4.1 FE and newer.

@Drule

You're not. He's missing the point that your target is 68K/3.x. Even when you point it out, he can't desist because despite his username, he clearly isn't nuts about Amiga. He's just spouting how it is in OS4 development today, fulfilling the stereotype of the obnoxious NG fanatic that can't even read a simple question before offering advice that doesn't apply. I have nothing against OS4 and even contributed to it in the past, but his response annoys me because it's exactly the sort of thing that gives these platforms a bad name.

So, sticking with 3.x and RTG, a couple of things I'll chime in with from the past. This may not apply to p96 but it was true in CGX.

First of all, if you want to get a VRAM resident bitmap that you can write to directly and also blit from or draw onto using the OS routines, you'll probably want to pass in the screen bitmap as a friend to the allocation call. Certainly nothing else I ever did resulted in a bonafide allocation of VRAM. The side effect of this is that your bitmap will also be the exact same pixel format as the screen one.

On which note, drawing pixel arrays can be slow. I found it much more performant to write my own pixel line conversion routines that would typically read from a source buffer in one format and write to the VRAM directly in the target. As laborious as this was when writing routines for each pair (it was library code so I was keen to support all formats), it was much faster. Worth checking if this is still the case though.

Last edited by Karlos on 12-Dec-2022 at 12:28 PM.

_________________
Doing stupid things for fun...