@Hypex Quote:

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.

OK, thanks, I'll try that. Any idea how big a difference it can make?

Quote:

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.

I was using Paula mode, but for some reason AHI music causes the game to 'hang' (music plays, but no graphics updates). Could be a bug on my part, but I have not looked into it yet...

Last edited by ChrisH on 16-Jun-2012 at 06:30 PM.
Last edited by ChrisH on 16-Jun-2012 at 06:27 PM.
Last edited by ChrisH on 16-Jun-2012 at 06:18 PM.

_________________
Author of the PortablE programming language.
I love using Amiga OS4.1 on my A1-X1000 & Sam440
Don't forget the official support forum for OS4!

@all
It seems the general consensus is to ignore the AGA chipset, compose the screen in FastRAM, and then copy the final result to the screen (buffer). I had not considered this, but I will look into it... (If I did this right, then I might be able to re-use most of my code on other non-Amiga systems, such as say Windows.)

Would WritePixelArray8() be a reasonable way to write a chunky 'bitmap' to the screen? I guess most people must have the NewWPA8 patch (or similar) already installed?

FWIW, my "sprites" are already software constructs (currently implemented using blitting).

_________________
Author of the PortablE programming language.
I love using Amiga OS4.1 on my A1-X1000 & Sam440
Don't forget the official support forum for OS4!

@ChrisH

I guess using wpa() is ok but perhaps you should also include a c2p routine by azure or kalms for people without the patch

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

@ChrisH

Interleaved bitplanes are mainly useful for opaque blits. It allows the entire blit to be completed in a single blit-node so it eliminates 7/8 blitter queue interrupts for an 8 bitplane screen. The blitter doesn't go any faster but the CPU doesn't get dragged into it as often, thus the speed-up.

For BOBs that are a multiple of 32-pixels, you're better off using CPU-blitting. The reason the CPU-based blitter routines are faster is that the blitter re-reads the mask plane for each bitplane for non-interleaved blits, and for interleaved blits makes a huge mask plane as big as the image itself so it wastes chip-ram and still needs to read the mask plane for each bitplane.

Here's an explanation of a planar CPU-blit: read the first mask plane row first, read the first bitplane, mask, write to destination. Read the second bitplane, mask, and write to the destination. Continue to all the other bitplanes and ONLY reread the mask when you're out of bitplanes for the row of pixels you're on. This method eliminates the need for tall mask-planes and is still faster than the blitter by a factor of 7/16 because the mask plane stays cached in a register. Also, these images can be kept in Fast RAM since the blitter doesn't access the source.

Also, if most of the blits are narrower than 32-pixels, you'll want to use chunky-pixels instead of planar. Also, there's no system-friendly way to insure that an interleaved bitplane allocation succeeded when using Intuition.library to open your screen. There is an undocumented bit in the header that you may have to check thus making your code slightly system-unfriendly, but it's the only way to insure proper running speed for bit-planar graphics.

_________________
Member of Total Chaos team.

@ChrisH

Quote:

OK, thanks, I'll try that. Any idea how big a difference it can make?

The main difference is you only need to do one blit for a whole section as it covers all planes. The Blitter still runs at the same speed but it's more efficient that way. Also, each screen line, now takes up 320 bytes for an 320 width 8 bit screen. Same as chunky does, except still formatted as planar in a bitmap.

Quote:

I was using Paula mode, but for some reason AHI music causes the game to 'hang' (music plays, but no graphics updates). Could be a bug on my part, but I have not looked into it yet...

Do you know if the AHI interrupts were used at all? Or just sending the samples from another timer?

Or a software mixer?

@ChrisH

Are you using to new version of AHI? Older versions works better with 68k. Latest versions are not optimices for 68k amiga's like older ones.

@ChrisH

Quote:

Are system-friendly AGA games possible on Classic Amigas?

Not under AmigaOS 3.x. Using a future version of AROS 68k, maybe.

_________________
Member of Total Chaos team.

@Samurai_Crow

Quote:

Not under AmigaOS 3.x

Seems a bit late to throw that in but why not?

Isn't there some example of such, wait what is it, oh have you heard of Total Chaos? I recall that as being an AGA system friendly game.

As OS friendly as a grandma could be.

@Samurai_Crow

ADoom is system friendly and runs more or less smoothly on 060+AGA

And I played Warcraft2 on Shapeshifter with 040+AGA (640x480) and it was playable too (and was both OS-friendly and multitasking)

Anyway I think AGA+OS can be OK for certain strategy/puzzle games that don't require fast graphics. Graphic adventures are good candidates too.

PS: sometimes you don't need to obtain 100% the performance of the target hardware and 80% is enough if you can multitask and run in a wider variety of configurations.

I remember demos like New World Child that IIRC multitasked and were quite impressive too.
http://ada.untergrund.net/?p=demo&i=71
Karate produced system friendly demos too IIRC. Krabob later created an evolved Karate version that allowed creating demos for more systems.

Last edited by Crumb on 19-Jun-2012 at 05:19 PM.
Last edited by Crumb on 19-Jun-2012 at 05:19 PM.
Last edited by Crumb on 19-Jun-2012 at 05:13 PM.

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

@Hypex

Total Chaos is so AGA friendly that it won't work with anything but AGA. I think what ChrisH was looking for was something that would work on both AGA and graphics cards.

@Thread

I've got a draft proposal of how to improve AROS 68k's graphics support but until I get a few comments on it on the AROS mailing list, I'm going to withhold judgment.

_________________
Member of Total Chaos team.

@Samurai_Crow

The fact is that there are already a few system friendly games, but this games use graphic.library and intuition to open screens, Erath2140, AsteroidsTR, Nemac 4, Nightlong68k, Puzzle Bobs, Strip Fighter for example, system friendly games don’t use any AGA special features like sprites, bobs, dual playfield.

One biggest problem is not that game displays graphics in AGA, the biggest problem is AUDIO, because I don’t know when audio.device was part of OS, but it was late, and AHI was not a standard, only some music players used AHI like AmigaAMP, AHI became a lot more popular later on, infect there was no MOD player when AmigaOS4 first came out that supported AHI and was 100% system friendly, HippoPlayer did have AHI support but it depended on some hardware timers or bad EClock values.

_________________
Software developer and forum troll.
Please check out my software:
Excalibur, Basilisk 2, AmigaInputAnywhere.

@Crumb

Quote:

And I played Warcraft2 on Shapeshifter with 040+AGA (640x480) and it was playable too (and was both OS-friendly and multitasking)

I played many 68k Mac games that weren't available for Amiga anymore under ShapeShifter on A1200/060/AGA working great and fully multitasking...
Civilization 2, Settlers 2, Warcraft I, Warcraft II, 3D action games Wolfstain 3D, Dark Forces, DN3D, Marathon, Full Throttle, DoT, Sam&Max... just to name few i remember and really enjoyed.
So if such complex games can run fine emulated, there should be possible make system-friendly AGA games possible on classic Amigas...

@Samurai_Crow
im not sure if majority of aros developers are concerned enough about 68k to comment on your proposals.
you might perhaps ask especially toni, what he thinks, because jason is too fresh to amiga to judge i bet. but i would guess toni will not care much as well, as he mostly cares about backward compatibility. also ive not hear much from both as of late.

you might also go ahead and implement it, as soon as you dont break anything none will complain.

@wawa

Thanks! I was kind of thinking that already but you've confirmed my suspicions.

_________________
Member of Total Chaos team.

@ExiE

I think the video driver for shapeshifter is called Savage the driver is optimized for number of CPU’s 030,040 and 060. I think the driver was created so that only the part of screens that where changed was updated or more often then parts that where not, I remember it was even possible to play QT video whit that driver.

I guess, it enabled graphics to be drawn in fast, and copied to chip mem, like itix was talking about.

Last edited by NutsAboutAmiga on 19-Jun-2012 at 07:31 PM.
Last edited by NutsAboutAmiga on 19-Jun-2012 at 07:30 PM.

_________________
Software developer and forum troll.
Please check out my software:
Excalibur, Basilisk 2, AmigaInputAnywhere.

@NutsAboutAmiga

Audio.device has been there since version 1.0 but most are using it only to get an exclusive access to the hardware.

@Exie

Shapeshifter display drivers are using CPU bound and faster than blitter based graphics.library routines.

_________________
Free IRC client for Amiga: www.amirc.org

@ChrisH

AMOS provided a high level programing language, what this means is that created for developers that do not won’t play whit registers or low level hardware stuff.

AMOS basic was the first basic Language that was usable to make games in, before there where Amiga Basic, maybe hisoft basic don’t remember, never used it.

The problem whit AMOS was that never supported AGA only OCS/ECS, I was waiting and hoping but it never came about.

If the sources of AMOS was available, and if the AMOS language part was not compiled into the exe files, then it might provide a nice hardware abstraction layer for system friendly Amiga Games.

While I did not like AMOS for lack of system friendly commands, and because I felt like total lamer writing programs in it, compared to some friends who was writing 680x0 assembler, I like BlitzBasic better but that’s beside the point, BlitzBasic almost works on AmigaOS4, it’s just a few bugs her and there that makes it total crap.

XAMOS is interesting project, but I’m afraid it will only give every one more crap games, we already have lost of crap games in SDL format.

_________________
Software developer and forum troll.
Please check out my software:
Excalibur, Basilisk 2, AmigaInputAnywhere.

@Samurai_Crow

Quote:

Thanks! I was kind of thinking that already but you've confirmed my suspicions.

if there was more aros 68k active.. ermm, lets call it "users" it would be easier to convince them to discuss that stuff, and support us more, not only that x86 garbage. ;P

@NutsAboutAmiga

Don't forget MegaBall AGA.

Works fine except for sound on OS4.

@Samurai_Crow Quote:

Interleaved bitplanes are mainly useful for opaque blits.

Unfortunately BltMaskBitMapRastPort() doesn't work at all with interleaved screen/bitmap (the wrong stuff is masked).

Quote:

Here's an explanation of a planar CPU-blit

This sounds like it might be worth trying, as less work than rewriting everything to use C2P.

Do I understand you right that it should be about 50% faster than blitting???

Quote:

Also, these images can be kept in Fast RAM since the blitter doesn't access the source.

If I start allocating bitmaps in Fast RAM, can I still use graphics.library calls for drawing to it? I guess I should be able to, with the exception of BltBitMap() type calls?

Quote:

Total Chaos is so AGA friendly that it won't work with anything but AGA. I think what ChrisH was looking for was something that would work on both AGA and graphics cards.

Kind of, yes. I don't mind replacing small sections of code for AmigaOS3/AGA, but I don't want to have to use AGA-only features that don't easily map onto graphics cards.

Basically I want my graphics abstractions to be the subset of what AGA & graphics cards can achieve, so that it can run fast on both. Rather than doing it the Hollywood way of offering anti-aliased CPU-intensive tricks that grind to a halt on a Classic Amiga (and even run kind slow on typical AmigaOS4 machines).

Last edited by ChrisH on 21-Jun-2012 at 06:25 PM.
Last edited by ChrisH on 21-Jun-2012 at 06:24 PM.
Last edited by ChrisH on 21-Jun-2012 at 06:21 PM.
Last edited by ChrisH on 21-Jun-2012 at 06:20 PM.

_________________
Author of the PortablE programming language.
I love using Amiga OS4.1 on my A1-X1000 & Sam440
Don't forget the official support forum for OS4!