A while ago I added tentative support for AmigaOS3 (AGA) to PortablE's nice graphics system (which is called "cGfx" although it has nothing to do with CGX!), but I only recently got around to testing it's performance on my dusty 68030/40MHz accelerated A1200 (rather than an insanely fast WinUAE system).

Initial performance of my test demos was pretty dire, so I reduced screen resolutions (from 640x480 to 320x200), reduced screen depth (from 256 down to 64 or 8 colours), and disabled the music (which was using AHI). I also implemented real double-buffering, since blitting the next frame looked horrible (as you could see the individual bit-planes being blitted one at a time).

The end result is still not really good enough, as the frame rate is too low: My "StarsDemo" test looks kinda OK, but it isn't smooth enough. While my "SOTB" test only achieves 6 fps (also the colours are also messed-up, despite them looking fine under WinUAE, and sometimes it hangs on exit, but these cosmetic bugs aren't worth fixing unless the performance is going to be better).

You can have a try of these two demos yourself:
http://cshandley.co.uk/temp/PE_cGfx_tests.lha

I believe that these demos are fairly efficiently implemented, but they only use OS calls that will work equally well on Picasso96 & CyberGraphics. e.g. BltBitMap(), BltMaskBitMap(), ChangeScreenBuffer(), WaitTOF(), and so on.


So this all leads to the subject of this thread: Is it really possible to have fast full-screen graphics on an AGA machine using *only* graphics.library calls? Or do you have to resort to one of these cheats:

1. Only animate small areas of the screen (using Sprites or BOBs), with the rest of the screen either being static (using the flip-screen approach), or scrolled in relatively large jumps (as I recall Dune 2 & Sim City doing). This should already be possible using my "cGfx" graphics system, but it feels a bit disappointing.

2. Use some esoteric AGA chipset features, which are supported by graphics.library but that probably aren't supported by AmigaOS4 or MorphOS (?), such as dual playfields. This would allow a game to do some things better, but it would also require manually "emulating" those features on a graphics card. And you'd have to take great care that your usage of these chipset features *could* be sensibly 'emulated' on a graphics card, so that you would not need to rewrite all your graphics code. I'm not even sure if this is really possible.

3. Turn-off the OS, and directly hit the AGA chipset. You can use all the AGA chipset's fancy features for maximum efficiency, but there is no chance of your game working on AmigaOS4 or MorphOS. At least without completely rewriting your graphics code - typically a lot of work, and something you'd probably rather not to do.

_________________

@ChrisH

Using hardware sprites in system friendly games is almost undesirable. While it is possible to do so they are not easy to use efficiently and dont care about screen ordering or windows.

Forget BOBs in gfx.library. Is anyone really using that?

dynAMIte (great game written by UltraGelb in E) didnt use AGA features but was fast enough on AGA and took benefit of a gfx card. Sprites and other gfx in the game was plotted using CPU and written to gfx card using WriteChunkyPixels and WritePixelArray8() from graphics.library.

So, forget about using slow blitter and planar graphics. Render everything as chunky pixels and use AGA only as a framebuffer. If you have fast CPU (040 or better) it works and is compatible with gfx cards.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Quote:

Render everything as chunky pixels and use AGA only as a framebuffer.

Sorry to hijack, but can you maybe eloborate on this further (via email or posting an appropriate linkt)?
For my game I'm using only blitter functions and DrawImage. I'm really not quite used to the (for me horrible) Amiga-API but I'd like to speed things up as far as possible.

Thanks in advance!

@Reth

Unfortunately I dont have good resources for this. I have never written proper game myself (only bad ones) but instead of using blitter to copy your graphics you construct your gfx in fast ram using CopyMem() routines and you write your own sprite routines.

AGA has limited bandwidth and invoking a blitter is not exactly cheap (setting up blitter registers is relatively expensive job for a CPU) and chip ram is also very limited.

Instead if you render all your graphics in fast ram you have more bandwidth and more ram. And even better it is a gfx card compatible method. You either copy your chunky buffer to gfx card memory or to chip ram. Good thing is that you are not limited to hardware sprites but downside is that your game gets slower with more sprites on screen.

There are many good threads at English Amiga Board where more experienced coders could explain it better than I ever could

But you are probably going to need fast CPU with some fast ram to do this. If your gfx is not very complex 020 could be enough, tho.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@ChrisH

See Chris Green, former CBM graphics coders and game programmer comments here :
http://www.mways.co.uk/amiga/howtocode/text/introduction.php

He also did 2 examples :
http://aminet.net/package/demo/misc/tmapdemo
http://aminet.net/package/dev/misc/aaboing

Kamel

@itix

it really depends on what you plan to draw on the screen but with CGX in many situations it's faster to draw directly to gfx card mem various pixels in one go. It's more or less the same but you lock bitmap before writting data, write it and then unlock it, and you don't need to perform writepixelarray() because it's already on screen.

@Chris

With amiga custom chips if you plan to use blitter I would skip OS functions (specially mask ones) otherwise it will probably slow down everything too much. C2P is probably best with 040/060 since it can be done at copyspeed. Some sceners still use blitter even in 060 intros/demos (Blueberry IIRC) but that requires killing the OS and a lot of control since badly used it mostly slows down rather than helps. Copper-sync c2p is probably the optimal solution for AGA but it's difficult to implement and certainly requires killing the OS if you want to have any advantage over typical solutions, otherwise you would be interrupted in the moment you can write to chipmem at 7MB/s and that wouldn't be fun.

Last edited by Crumb on 07-Jun-2012 at 09:28 PM.

_________________
The only spanish amiga news web page/club: CUAZ

@ChrisH

It is possible to create system friendly games for AGA Amigas, however almost all game companies back in the Amiga gaming market days used hardware and assembler for maximum efficiency.

From my experience some of the tasks can be done using OS software solutions, like timers, audio, graphics primitives, but some tasks require extra speed.

Interesting is fact, that Blitter Objects, Virtual Sprites and AnimObs can be used, but... AmigaOS3.5 in some way screwed up these graphics subsystems (I'm talking seriously, they are bugged under AmigaOS3.5), so they are unusable on AmigaOS3.5. Didn't program them out on AmigaOS3.1, but from demos included on Amiga Developer CD they seems to be fine on that version.

Also Amiga Developer CD contains some tips for Amiga game creators and suggests using software solutions instead of inventing own, but not in all areas.

So conclusion is that OS solutions are OK and recommended on Classics but on that platform it is legal to use hardware in some areas like interrupts, blitter. Notice also that AmigaOS has some subsystems that use Amiga special features like View and ViewPort, which were deprecated in later versions of the OS, but Amiga games couldn't be that attractive without these features (fast scrolling etc.)

Examples of system friendly games:
- Dune 2
- Settlers

Last edited by RNS-Amiga-Scientist on 08-Jun-2012 at 01:38 AM.
Last edited by RNS-Amiga-Scientist on 07-Jun-2012 at 11:48 PM.

@RNS-Amiga-Scientist

Dune 2 is not very system friendly. It multitasks but if you try to use other application at the same time it interferes with the game.

Settlers is hitting the hardware directly. It has this peculiar feature that apparently disk access inside game is done using OS routines because when saving a game the system starts to multitask. But it is system friendly in sense you can return to Workbench without having to reboot your machine.

Amiga Developer CD docs for system friendly programs are bollocks.

@Crumb

Writing to the bitmap directly using LockBitmapTags() is indeed faster in most situations but it is for rtg Amigas only.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@all

Not sure but isn't Colonization system friendly?

_________________
Asus Maximus VII Ranger, i7-4790K@4.6, HyperX DDR3@1866, MSI GTX980, 120GB ssd, 1T, 2T hdd.

A friend of mine once coded this in assember:
http://aminet.net/package/game/misc/ADVMiniDash

It has worked perfectly on every classic Amiga that I have tried, but not on SAM+AOS4 any more.

(I do not remember how it handled multitasking or if it displayed via CGFX/P96, but anyway)

@itix
Care to try what it does on MOS HW?


btw. was there new low level GFX library (classics+NG) being developed by some people??? ?RNS-Amiga-Scientist rings some bells? but perhaps not related?

Last edited by KimmoK on 08-Jun-2012 at 07:12 AM.
Last edited by KimmoK on 08-Jun-2012 at 07:12 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@Jape

Yep, it seems to be. I remember getting that game and being surprised that it even used standard Intuition windows, menus and gadgets. Mind you, it didn't need any graphical speed at all so could take all the time it needed to draw things.

_________________
RobTheNerd.com | InstallerGen | SMBMounter | Atoms-X

@itix

Dune 2 uses input.device, only because of that you can't use keyboard on the Workbench, because game receives all keystrokes. But it doesn't kill Workbench and work on own screen (it can be even promoted) and only use hardware for blitter blits. Dune 2 is example of game which is complex (RTS) and can be fast even on A500. It is my personal favourite.

The Settlers also don't kill Workbench and is another example of complex game which run fast on A500. Both Dune 2 and Settlers are HD installable, another sign of system-friendliness

Why do you think Amiga Developer CD tips are "bollocks", give me an example if you have the source under hand. There are some really very useful tips for developers on this CD. And in fact this is the only trusty source for Amiga developers available out there.

@RNS-Amiga-Scientist

Ok, it explains Dune 2. But Dune 2 is not really fast on Amiga 500 when you get busy. Might try that game in MorphOS some day.

Settlers doesnt kill Workbench but you cant get to Workbench during game nor lets you run any other applications at the same time (they are there but multitasking is killed and it is using HW directly).

Bullfrog games were also semi-co-operatively multitasking.

Regarding ADCD tips being bollocks they were just guesses what the future OS would be. I dont recall any sensible tips there except not using HW directly. Would have to load my ADCD again but I dont have time for that until Sunday.

@Jape

Colonization is system friendly but music player bangs the hardware directly. Some other MicroProse games were also quite system friendly, at least Railroad Tycoon and Civilization run with the OS. But these kind of games dont have fancy graphics and in fact gfx in Civilization is little slow (if compared to 286).

Anyway, we are now off topic.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

Hm, confusing. Depending on whom you ask and depending on which board you read the recommendations differ: Either use system routines for GFX or write directly to the memory.

Currently I'm only using AOS-Routines (3.x compatible - hopefully). But since I only code and try on Peg2 AOS4.1 I cannot say whether the result would run in acceptable speed on 68040+ too (with and without GFX card).

@ChrisH

only a short comment... I tested your demos on my Aros 68k distribution andthey seemed to work (with a little flickering)

Version 1.2. is uploaded now

@Reth

So you have 68k development enviroment now :) Could you consider backport Netsurf to 68k?

;)

Last edited by utri007 on 13-Jun-2012 at 11:04 AM.

@itix

Civilization is actually slower than it ought to be mostly because it's tied to the vertical refresh. Find an NTSC version or trick the PAL version into NTSC by changing workbench to 60Hz and drag down the workbench screen. That 20% extra speed did wonders for the playability.

I always wanted to try it at even higher rate but never managed to get 69Hz working on my 1084(not S), even though a multitude of people claimed it would work that high (euro36 non-interlaced was 72Hz but could be tweaked down to around 69Hz). AGA of course.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@utri007

Didn't get that. What environment you're referring to? The last one I used has been GoldED Studio AIX and GCC on my A4000 (before that I used HiSoftC++ and really enjoyed it)!
Since several months/years I'm using Codebench on AOS4 only - hence the binaries are AOS4-only.

@olegil

That is interesting. Shame that I didnt know that when I was playing Civilization actively on my Amiga 500. Could have tried patching the game or the system.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@ChrisH

From going over your post a few tips appear from the top of my head.

Music:
If you use AHI which is fine make sure it is using Paula mode. This ensures you use hardware channels and not software mixing, which will kill your speed. Also, you need to make sure the module replayer routine using AHI actually replays it properly using AHI interrupts. Using any method resulting in software mixing is pointess on AGA because the Paula hardware has been perfeclty fine for years playing modules. AHI interrupt based module players are also cross compatible between OS3 and OS4.

Double buffering:
Intuition does support it though ChangeScreenBuffer() as you know but if you have your own routines working that's fine as Intuition's method can be confusing from what I have read. Just make sure you switch bitmaps and not blit the new one into place.

Blitting:
ECS can do blits up to 32768x32768 pixels. Not sure for AGA. But you can improve speed by using an interleaved bitmap. This will mean all the lines on the screen follow each other directly in one bitplane. So instead of a seperate bitplane for each colour making up a whole bitmap all the screen lines appear after the other as one complete bitmap. This means you can one blit operation for all bitplanes combined.

For example, a 320x256 sized screen with 8 bitplanes needs 81,920 bytes total of memory, and 10,240 bytes per bitplane. 40 bytes per line.

Interleaved, that is one bitplane needed, with a size of 320x2048 lines or 40 bytes times 2048 lines. That 32768x32768 or 4096 bytes by 32768 lines is more than enough!

Scrolling:
Combined with the above technique it should be perfeclty fine to scroll a screen. And BTW, ScrollRaster() is made for this. However, there is no need to use the blitter when you have hardware scrolling.

Hardware scrolling:
You can use ScrollVPort() if you grab the screens ViewPort and modify it. But it would be better uisng Intuition for more friendliness. Simple way to do this is to open a screen double the intended display width but with a mode of the intended width. Say a 640 width screen in lowres mode. Then use MoveScreen() or ScreenPosition().

Dual playfields:
Yes they can be done. You can set flags for these things when opening screens. And by OS3.1 Intuition had better support for these and other Amiga features.

Copper lists:
You can add a user copper list to a ViewPort and have all the lines in different colours. It's actually easy to do and can be better than banging directly as the OS will calcuilate all the hardware offsets for you. It will also update the copper list so when you drag the title bar it will scroll up and down with the screen!

This should get you going for starters. As you can see AmigaOS is quite competent at programming AGA. Did anyone try?