Note this answer is NOT ideological. It is just about how things are ;-)
 
  Steffen Haeuser
 

(old)StormMesa could render as software or hardware but there was various bugs that make it erroneously fall back to software in some cases
So typically a game using hardware rendering could have some parts in the scene drawn as sofware so killing the performance
This is something we discovered with Wazp3D as it got an option (debug sepia) to show what parts are drawn with Wazp3D

Is there any tutorial sources about using maggie3D ?
There is the registers description for Maggie3D but setting up textures/mipmap/screen/zbuffer is not documented

Yes all register of Maggie are in the SAGADOC register documentation of Amiga registers

The Apollo Dungeon Crawler source is available so see you to use them.

I understand what you say,
I assume it does depend of course on your software and how many channels you use.
We all know that you can worst case, very easily burn the bigger part of a 68060 CPU with the extra overhead of AHI, audio mixing, audio conversion on Amiga.
   
 

Steffen Häuser wrote:

2) Actually directly sending the data to screen  ... It usually doesn't have a big impact on performance though

   
The overhead is very easy to see, and very easy to measure.
Its pretty clear how huge the impact on performance is on Amiga.
   
Your Amiga GFX cards are either Zorro2 or Zorro3.

The AMIGA Zorro2 Bus has a max speed of 3.5 MB/Sec
Performance of the Zorro3 bus varies, often 7-10 MB/sec
   
Lets say your screen is 640x480x32bit = 1.2 MB size per frame
 
Z2 3.5 MB/sec and one Frame is 1.2 MB - the problem is obvious.
Memcopy to a Z2 GFXcard will use 100% CPU time and only reach 3 FPS!!
 
Z3 7-10 MB/sec and one Frame is 1.2 MB - the problem is obvious.
Memcopy to a Z3 GFXcard will use 100% CPU time and only reach 6-8 FPS!!
   
I'm sure you agree with me that this is a major bottleneck - and avoiding it - is just great.

Speed was pretty irrelevant on the kind of games I do about if I run AHI or Paula or disable sound. Probably due to the nature of these games.

I have to admit Zorro2 is not something I consider as something people still use. And your calculation would only be relevant for software renderer anyways (somewhat relevant still, but less so).

Note that most games (at least those were source-code is available on AmigaOS) are in 16 Bit, not 32 Bit. Already halfs the size ;-)

And again - this is relevant in the way you calculate it for software rendering.

And also again - for certain kinds of games you do not have the option to go a different route. You cannot do a raycaster or other 3D FPS with individual objects and stuff. You still can optimize a lot of things by only calculating objects which are "in sight" (by using a BSP tree for example, or a portal renderer) - but a full screen update still needs to be done.

Again - for certain types of games you CANNOT avoid this bottleneck.
The best you can do is to use 3D Hardware. And the best to make this happen is - having a 3D API for the platforms you support so that you do not use to reevent the wheel every time...

B) Zorro GFX cards which all have the bottleneck we explained.
Only small resolution and limited colors are possible.
For example smooth Video playback in 640x480 is impossible because of the Zorro Bottleneck.

C) PCI cards with Bridges.
These bridges have the same bottleneck limitations as Zorro.
So you can also not do smooth video on them

D) Using Super-AGA
Has ~100 times higher throughput, removing this bottleneck.

But as you know the point of this discussion is about something completely different.
 
Of course a 3D APi helps porting sources - but the work is not done then. The point of our talk here, is that people can not just take a PC source - press one button - and expect to have a great running Amiga game.  This will result at best in a very bad port.
To make a good Amiga port a lot more needs be done.
   
 

Steve Ferrell wrote:

There's a lack of 68K assembly programmers out there and that won't get any better.

A person without 68k skills can not just take a PC OpenGL game execute "press one button to compile it" and have a good well tuned Amiga port.
If this would be possible then it would be cool - but this is not how programming works.
 
In Amiga history, there were many of "real bad ports".
Those games ran bad and looked terrible on Amiga.
They were a numbers of bad or not tuned at all conversions to Amiga.
Frankly the Amiga users hated them. We dont need more of those.
   
Good conversions / Good Amiga games need a lot effort,
they need real coding and they need tuning.
We all know games which were tuned with love to detail for Amiga.
And we all love and admire these Amiga games.
 
     

Steve Ferrell wrote:

Expecting programmers to bang hardware registers and hand tune every app

 
Yes, this is exactly how good Amiga ports are done.
To make a good Amiga game, you have to do a lot of hand tuning and you have to use all the Amiga advantages possible.
All good Amiga games are done exactly like this.
And if the game is not tuned for Amiga then the game will run very bad. Its really simple.

We all know this.

Different people might have made different experience.
My opinion is based on my personal experience.
If other people have made different experience, they might look at this from another angle.
This does not mean that different opinions are "right or wrong".
All I can do is provide my experience and explain it.

Even on an Amiga forum Zorro2 is old stuff not really relevant anymore. What is an Amiga ? It is a machine running AmigaOS natively.

For Amiga the following display options do exist

Modern games (now I am not talking on games types which actually profit of planar display - I am not doing such games) use Chunky display through Cybergraphx or P96 which all decent Amiga Hardware should support. Actually for the OS 4 version of Heretic 2 I did not even bother about keeping the HAM-c2p  thingy in I had in the original OS3.x version.

> C) PCI cards with Bridges.

Or PCI Cards fitting directly into the hardware (some Amigas support this, you know ? ;-) )
 
> D) Using Super-AGA
> Has ~100 times higher throughput, removing this bottleneck.
 
I'd suggest writing a CGX or P96 Driver for it. Even at a not-full functionality the c2p (I assume this is a planar mode ?) could be hidden in WritePixelArray. Or if no CGX or P96 some other API to avoid the need of an ugly direct hardware banging.

Then you get both good speed (if this speeds it so much as you say) and easy handling.

But also

- Software rendering where something like Super-AGA will be relevant will - as to games - only be relevant for a specific TYPE of games. Of course great that it exists, but for the type of games I create it will not really be relevant. Something like your 3D Chip (assuming one of my future games would run on your platform of course) would be MUCH more relevant. Software rendering is basically to expand the amount of supported systems, adding some lowend systems "were possible" (that's why for Heretic 2 for OS3.x I had a HAM-mode c2p added as option which converted the 16 Bit chunky data and displayed it on a HAM screen).

And optimizing the screen-copying (whether by chunky-copy or c2p) will only achieve minimal speedup (believe me, I know this, 20 years ago I created a lib called "chunkyppc.library". It's idea was basically - have a call for Open Screen, one for Close Screen, one for copying data on it - no complicated stuff like Screens, Windows, Bitmaps, etc. - all in one go. ASM optimized copy functions, and whether it is chunkycopy or c2p will all be handled internally.

Sadly the speedup - despite optimization - was much less than what I hoped for. On the other hand ONE speedup on C-language level or even better ALGORITHMIC level can have like 30% speedups... I found such a case recently. The speedup had NOTHING to do with either banging the hardware or using ASM - just with improving the algorithm (one which was called very often).

If you took offense to any of my comments, please take my sincere apologies. Nothing was meant in an offensive way.
 
  Thanks on the info regarding CGX/P96 on Vampire system. Very interesting! (Is Super-AGA still fixed to the old PAL/NTSC resolutions, if yes, which resolutions need to be supported, or is it allowing "standard resolutions" like 640x480, 800x600 etc. ? I assume no more Flicker in Interlaced Mode ? Sorry if these are dumb questions, I do not own a Vampire)
 
 
  On the doublebuffering discussion - for specific kinds of games you are right. For games based on Q2 engine you have a preparation buffer which is copied on-screen - both with and without doublebuffering. If you try to directly use video memory as the buffer (avoiding the copy step) you get a lot of flicker due to overdraw. For some games on such an engine it might be worse than for others (admit, never tried it on Q2 itselves like that). For H2 for example a copy step is absolutely needed, regardless of DBuf or not. Too much overdraw. Which essentially also causes the fps rate for Fullscreen and Workbench Window is exactly the same (myselves prefer playing fullscreen, in WB Window everything is smaller!)
     

Super-AGA does Support PAL/NTSC and other resolution:
Default MODE-IDs:
$01 = 320x200                       
$02 = 320x240                       
$03 = 320x256                       
$04 = 640x400                       
$05 = 640x480                       
$06 = 640x512                       
$07 = 960x540                       
$08 = 480x270                       
$09 = 304x224                       
$0A = 1280x720                     
$0B = 640x360                       
$0C = 800x600                       
$0D = 1024x768                     
$0E = 720x576                       
$0F = 848x480                       
$10 = 640x200 

Super-AGA does support Amiga PLANAR screen with 8 Planes, EHB, HAM6 and HAM8.

Super-AGA does support ATARI ST PLANAR format (1bit/2bit/4bit).

and Super-AGA does support the following Chunky formats

$01 = 8bit (indexed)               
$02 = 16bit R5G6B5                 
$03 = 15bit 1R5G5B5                 
$04 = 24bit R8G8B8                 
$05 = 32bit A8R8G8B8               
$06 = YUV                       

Thanks, this is extremely helpful. Sounds to me that no special handling would be needed for the case that I should support 68k in future software. A lot of these modes are supported in all my software ($2, $5, $0c, $0D coupled with $2 and $3 and $4 and $5 on the color side). But if one of the others is deemed important in most my projects it would be a matter of some minutes to add a new resolution mode. I really asked just to get information as to "what is important". Maybe the 320x200 would still important for lowlevel systems, and maybe the 640x512 as this is a really usual resolution on Amiga ?

I can do HAM8, but chunky looks much better (Heretic 2 for example in HAM8 looks not as good as it does in Chunky 16 Bit). All my recent games can handle all sorts of 16 Bit or 15 Bit modes existing - at least I think it was HAM8, might have been HAM6, can't remember, 20 years ago and stuff.

As to the other question you posted (on the copying)

basically these games (other games of course might do this different) draw something, then draw something on top, then again draw something on top. If this causes "flicker" depends on how much it is done in the game (talking on the non-doublebuffer mode).

Okay. You might try the "let's directly draw to the hardware, and use doublebuffering".

You are right.

That might skip the copying. But I think if I will be doing a 68k version in my of my future games, this is a modification which could be implemented in mere minutes.

Again thanks, had not thought of this ;-) Good that you asked.

Now that I think of it, I think my original H2 port had this option for the software renderer in fullscreen with some sort of obscure console variable ;-)

As to HAM8 vs. Chunky 16 Bit, is there a performance "preference" ? Or does it simply not matter which of them you choose, for matters of speed ?

For a First Person Shooter, in my opinion 16bit chunky(word) is much better than HAM.

I meant just for the sake of performance.

Please mind the 16bit mode is Chunky, not planar.

Steffen Häuser wrote:

I guess then the "way to go" for games really is chunkymode for SuperAGA too.

 
Yes I think this is most easiest and has good performance too.
As the PC source is coded for this already it should work "out of the box".
 

And yeah, should work out of the box.

Actually one thing I find most exciting on Super-AGA.

What do you think ? COULD Commodore in their final days have made (purely technical, not that they in the end were such a failure) something like Super-AGA ? Or was it only made possible by advances in chip-making which were not possible back then ?

As from all I read from you, it sounds like the logical followup on AGA.

If I read in comparision the info available on AAA and Project Hombre prototypes - well. For me Super-AGA sounds ways more exciting.

Thank you.

I think many features that Super-AGA provides were on to "todo" list by the Amiga developers.

- they wanted a Chunky modes.
- they wanted 16bit audio, they wanted more audio channel
- they wanted 3D acceleration