@ChrisH

Quote:

ChrisH wrote: @Samurai_Crow 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???

Just under 50%.
Quote:

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?

Nope. You'd better keep them in Chip RAM if you want to plot lines on them or something like that.
Quote:

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).

Yeah. Trying to get software to work on both AGA and other graphics cards are kind of tough. They just were never designed to be compatible with one another.

_________________
Member of Total Chaos team.

@ChrisH

Quote:

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

Apparently the Workbench opens in a interleaved mode if it can. But the AutoDocs don't say much about blitting with it. How did you set up your mask? And is your source BitMap also interleaved? Since it is a one bitplane mask it may have to be a straight non-interleaved mask. Since an interleaved mask makes no sense for one bitplane or a 1-bit mask.

Oh BTW, if you want to see the OS do hardware scrolling, set your Workbench to any low res mode. It wil open in high res width regardless and you can scroll across using the mouse. Works fine with OS3.1.

Quote:

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

The only problem using the CPU over the blitter, apart from not using hardware acceleration, is that you must deal with shifting the data yourself. That is, unless you copy a bitmap to a direct position aligned on an exact word, you will need to shift the data before merging it. Thus you will need to use LSR or LSL instructions. You could stick to C but you really need optimised ASM if you want to out do the blitter.

For C2P, it's really only worth it if you want to port a Doom game that uses chunky pixels. I also remember when some games would also invoke the blitter for chunky to planar conversion. C2P is IMO a last resort option. And if you are making a 2D game using C2P it isn't a real Amiga game anymore. The Amiga has hardware features for 2D games and they should be used. For example, with C2P, you miss out on hardware sprites, copper effects, blitting and using the hardware to scroll at 35ns or scroll any resolution by SuperHires increments. A game using C2P that has scrolling is just naff!

Last edited by Hypex on 22-Jun-2012 at 11:17 AM.
Last edited by Hypex on 22-Jun-2012 at 11:16 AM.
Last edited by Hypex on 22-Jun-2012 at 11:14 AM.

@Hypex

Quote:

The only problem using the CPU over the blitter, apart from not using hardware acceleration, is that you must deal with shifting the data yourself. That is, unless you copy a bitmap to a direct position aligned on an exact word, you will need to shift the data before merging it. Thus you will need to use LSR or LSL instructions. You could stick to C but you really need optimised ASM if you want to out do the blitter.

According to the GameSmith documentation, an '060 can plot 2 BOBs for every one the blitter plots. The '040 plots at the same speed as the blitter. Besides, who is ruling out hand-optimized assembly?

_________________
Member of Total Chaos team.

@Samurai_Crow

Quote:

According to the GameSmith documentation, an '060 can plot 2 BOBs for every one the blitter plots. The '040 plots at the same speed as the blitter.

Well it's good to see the blitter holds up well against the later CPUs. But at what clock rates? 25MHz? 50Mhz?

Perhaps if the blitter ran with the CPU clock rate it could have kept the pace.

Quote:

Besides, who is ruling out hand-optimized assembly?

I suppose it is not ruled out, but we are talking about PortablE. A language devised to be cross platform and portable across platforms. And one that is translated to C++ usually so inserting "hand-optimized assembly" might be harder than usual.

And, as the subject is asking, Chris wants a way for the OS to do all the hard work or at least tell the hardware what to do. Getting down to the assembly level would be too deep and would go against using the OS resources to achieve the original purpose.

@Hypex

The blitter needs some updating, that's for sure. I joined the NatAmi team to make sure that happened. Now we don't know how that turned out because the hardware guys all have teams of their own now.

At the 1998 Developer's Conference I asked why they didn't quadruple the clock speed of the blitter like they did with the fast-page mode of the Copper. All they could do was say "We should have but it never occurred to us at the time." So now we're stuck at a 3.5 MHz clock-speed blitter for the AGA chip set.

_________________
Member of Total Chaos team.

@Samurai_Crow

Quote:

According to the GameSmith documentation, an '060 can plot 2 BOBs for every one the blitter plots. The '040 plots at the same speed as the blitter. Besides, who is ruling out hand-optimized assembly?

Does this include overhead to set up a blitter operation? All custom chip access from a fast CPU is expensive...

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

@itix

The GameSmith CPU-assisted blitter engine would process blit-nodes off of the same blitter queue as the internal blitter queue routines. This means that the data was in Chip RAM for either the CPU or the blitter, and that the blitter operations were queued just like normal.

_________________
Member of Total Chaos team.

@Samurai_Crow Quote:

Quote: 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? Nope. You'd better keep them in Chip RAM if you want to plot lines on them or something like that.

I had been wondering about having the buffer in Fast RAM, but that is clearly a non-starter (I would have to manually draw everything, which means it would be of similar complexity to a C2P solution, except that I'd be manipulating bitplanes directly. i.e. A complete rewrite for OS3, which I was hoping to avoid).

The other alternative would be to keep the buffer in Chip RAM, and just "CPU-blit" bitmaps into it like you originally suggested. On something like my SOTB demo, where blitting bitmaps is the bottleneck, I'd presumably see (up to) twice the frame rate?? I guess that would be a nice result compared to the effort required, and should also keep 'chipset purists' relatively happy (compared to a complete C2P solution).

Although I do have to wonder how the real SOTB game managed to achieve it's effect on a lowly vanilla A500, if blitting bitmaps is too slow...

Quote:

According to the GameSmith documentation, an '060 can plot 2 BOBs for every one the blitter plots. The '040 plots at the same speed as the blitter.

How does that related to your earlier speed estimate for "CPU-blit"? Was your (nearly) 50% faster estimate based upon an '060? If yes, then it seems a "CPU-blit" is pointless on an '040 system, and I'm even aiming at an '030 (which is also what I actually have)?

Quote:

Trying to get software to work on both AGA and other graphics cards are kind of tough. They just were never designed to be compatible with one another.

I had hoped that using the graphics.library (which was originally designed around the Amiga chipset limitations) would be sufficient...

Last edited by ChrisH on 26-Jun-2012 at 06:19 PM.
Last edited by ChrisH on 26-Jun-2012 at 06:05 PM.
Last edited by ChrisH on 26-Jun-2012 at 05:58 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!

@Hypex Quote:

Quote: Unfortunately BltMaskBitMapRastPort() doesn't work at all with interleaved screen/bitmap (the wrong stuff is masked).' (snip) How did you set up your mask? And is your source BitMap also interleaved? Since it is a one bitplane mask it may have to be a straight non-interleaved mask. Since an interleaved mask makes no sense for one bitplane or a 1-bit mask.

It occured to me that I've seen similar-looking problems when I had the wrong width for my mask, so perhaps interleaving changes the width requirement (or changes the reported width)? The mask's width is the same as the width of the displayable (chip ram) bitmap, as reported by GetBitMapAttr() using BMA_WIDTH.

My mask is allocated by AllocBitMap() using BMF_STANDARD, as this is by far the simplest way to do it - my previous method used AllocRaster().

_________________
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

Quote:

Although I do have to wonder how the real SOTB game managed to achieve it's effect on a lowly vanilla A500, if blitting bitmaps is too slow...

It uses Copper split-screens and dual-playfield mode and sprites.

This site has CodeTapper's commentary of how it was done with a disassembly of the sprites and Copper-lists configuration to sort of reverse-engineer the whole process.

Quote:

I had hoped that using the graphics.library (which was originally designed around the Amiga chipset limitations) would be sufficient...

AmigaOS 3 was never designed to do extensive Copper-list supports. I'm thinking that an update for AROS 68k to make the Copper support more powerful would do the job. I don't want to attempt such a thing by myself, however.

Last edited by Samurai_Crow on 26-Jun-2012 at 06:51 PM.

_________________
Member of Total Chaos team.

@ChrisH

Quote:

On something like my SOTB demo, where blitting bitmaps is the bottleneck, I'd presumably see (up to) twice the frame rate?? I guess that would be a nice result compared to the effort required, and should also keep 'chipset purists' relatively happy (compared to a complete C2P solution).

Hehe, chipset purist, that's me. Well blitting bitmaps for your SOTB demo.. there's your problem! Okay on OS4 where you need to fake it on RTG but on OS3 you have the real thing. You need to set up a hardware scroller without blitting, that is tell the hardware what x offset to use and only blit in a new row of image blocks when needed. Or better still keep it all in a double bitmap so it just scrolls into place with no work. Having dual playfield would also help with parallex effects but it does cut the colours down as the bitplanes must be split in two.

Quote:

Although I do have to wonder how the real SOTB game managed to achieve it's effect on a lowly vanilla A500, if blitting bitmaps is too slow...[quote] Hardware scrolling, dual playfields and and copperlists. [quote]I had hoped that using the graphics.library (which was originally designed around the Amiga chipset limitations) would be sufficient...

Well I think it can be. You need to know how to program it and by doing so the hardware as well since it follows on from it. Look at AMOS. That can do it.

Quote:

It occured to me that I've seen similar-looking problems when I had the wrong width for my mask, so perhaps interleaving changes the width requirement (or changes the reported width)?

Yes it would. As per my explanation last page a normal bitmap will take up 40 bytes per line for a 320 width screen wih 8 pixels a byte per bitplane. With interleaved the width will increase per colour depth. My example, where a 320 width bitmap had all the planes for each row one after the other, would end up taking 320 bytes per row, with 8-bit colour depth. It's the modulo or amount of bytes that each line takes up in memory so the hardware knows where in a bitplane each line will start.

Quote:

The mask's width is the same as the width of the displayable (chip ram) bitmap, as reported by GetBitMapAttr() using BMA_WIDTH.

Yes that will report the pixel width. Which would be the same for both a standard and interlevaed bitmap. However peeking into the BytesPerRow in the BitMap structure will tell you the modulo and the different amounts depending on bitmap type.

Quote:

My mask is allocated by AllocBitMap() using BMF_STANDARD, as this is by far the simplest way to do it - my previous method used AllocRaster().

You really only need a raster itself, but the whole BitMap method will ensure proper alignment.

Last edited by Hypex on 27-Jun-2012 at 04:34 PM.
Last edited by Hypex on 27-Jun-2012 at 04:23 PM.

@Samurai_Crow

Quote:

AmigaOS 3 was never designed to do extensive Copper-list supports

What's wrong with the support it has? Infact since OS1.x it had support.

I've used the OS myself to create a user copper list. It works fine. Okay the OS sets up the start of it with the bitplane initial stuff, but you are free to do the rest and put your commands in place.

AFAIK OS3 didn't add much more except OS3 usually meant AGA as well so an advanced copper. Faster anyway. Of course, you still had to work with copper machine code, even with the macros, but since you need to poke the hardware regsters anyway it wasn't a big deal. And is simple enough to program.

Last edited by Hypex on 27-Jun-2012 at 04:35 PM.

@Samurai_Crow Quote:

It uses Copper split-screens and dual-playfield mode and sprites.

Ah, OK, much more complex than I had imagined. That at least explains why simple blitting can't achieve anything like the same performance. (And also why the grass layers do not overlap each other at all, with a rough top, which would have looked even nicer.)

P.S. I'm still hoping you can answer my earlier question related to the CPU (I'd rather not implement CPU-blit & then find it's useless on an '030). Hopefully I'm misunderstanding something you said (but I lack enough info to deduce what).


@Hypex Quote:

You need to set up a hardware scroller without blitting, that is tell the hardware what x offset to use and only blit in a new row of image blocks when needed. Or better still keep it all in a double bitmap so it just scrolls into place with no work.

That would require completely scrapping my existing graphics abstractions, start learning from scratch how to program the AGA chipset's obscure functions (by comparison with today's PC-like brute-force methods), then wrapper that in some abstractions that could plausibly be emulated with RTG, and then implement it again for RTG.

Unfortunately I don't have the time to do all that, so I'm just going to have to try what few optimisation opportunities I have, to improve the frame rate of the current implementation. If that isn't sufficient, then I shall have to either remove official support for graphics on AmigaOS3, or else add clear warnings that it's performance is not so great on AmigaOS3. Or I could just scrap AGA support altogether, and require a graphics card for AmigaOS3...

Quote:

Quote: It occured to me that I've seen similar-looking problems when I had the wrong width for my mask, so perhaps interleaving changes the width requirement (or changes the reported width)? Yes it would.

Would what? Change the (mask's) width requirement? In what way?

I've been hoping that I won't need to make a mask line as wide in bytes as the interleaved bitmap's line, as that would almost double the memory usage of a masked bitmap.

Last edited by ChrisH on 27-Jun-2012 at 09:01 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!

@Hypex

Quote:

Hypex wrote: @Samurai_Crow Quote: AmigaOS 3 was never designed to do extensive Copper-list supports What's wrong with the support it has? Infact since OS1.x it had support. I've used the OS myself to create a user copper list. It works fine. Okay the OS sets up the start of it with the bitplane initial stuff, but you are free to do the rest and put your commands in place. AFAIK OS3 didn't add much more except OS3 usually meant AGA as well so an advanced copper. Faster anyway. Of course, you still had to work with copper machine code, even with the macros, but since you need to poke the hardware regsters anyway it wasn't a big deal. And is simple enough to program.

What I'm trying to figure out myself, is a way to implement the macros and MrgCop() subroutine in such a way that an improved Copper could run off of the same macros.

Of course, since the only way to do bitplane pointer positioning with the MrgCop() instruction was to implement another screen and leave a one-pixel tall seam between the two screens. This makes system-friendly versions of the memory wrap-around trick used by tile scrollers like Turrican impossible to do without banging the hardware. (Incidently, they would write to the bitplane pointers from behind the right border to avoid the seam.)

My proposal is to take some knowledge of the DMA cycles used by the display and Copper and offset the bitplane values being written to by adding the amount that's already been plotted to the screen to have the bitplanes written to while they are being displayed. This way, only one row of pixels would have to be identical between the end of screen memory and the beginning.

If you don't know how single-buffered tile-mapping works on the AGA chipset, consult Georg's Scrolling Trick on the Aminet. Note also that the license has since been changed by the author so the information contained in the archive is now free to use.

_________________
Member of Total Chaos team.

@ChrisH

Quote:

ChrisH wrote: @Samurai_Crow P.S. I'm still hoping you can answer my earlier question related to the CPU (I'd rather not implement CPU-blit & then find it's useless on an '030). Hopefully I'm misunderstanding something you said (but I lack enough info to deduce what).

According to this thread on EAB, GameSmith is now on the public domain. If you use it's CPU-assisted blitting, the '030 will blit one BOB for every 2 BOBs the blitter blits, once the CPU has updated all the game logic and Copper information. If the blits are aligned to a 32-pixel boundary, you can go faster yet by avoiding the shift instructions.

Since GameSmith was only a rudimentary implementation of some of the principles of AGA game acceleration, I've been hoping to implement a game engine for AGA on AROS 68k for the simple reason that I could modify the underpinnings of MrgCop() on AROS so that it could do what I needed it to do.

Also, if you want to see GameSmith's Beast-scroller, the demo is in this Aminet link.

_________________
Member of Total Chaos team.

@Samurai_Crow Quote:

If you use it's CPU-assisted blitting, the '030 will blit one BOB for every 2 BOBs the blitter blits

In that case I can't see why anyone would ever use "CPU blitting" on anything less than an '040, and it would only make sense on an '060

So I think this means my only (rather minor) optimisation opportunity is using interleaved bitmaps.

P.S. I had not realised that GameSmith was a game engine. Some earlier posts make a bit more sense now!

Last edited by ChrisH on 28-Jun-2012 at 09:07 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!

@ChrisH

Quote:

That would require completely scrapping my existing graphics abstractions, start learning from scratch how to program the AGA chipset's obscure functions (by comparison with today's PC-like brute-force methods), then wrapper that in some abstractions that could plausibly be emulated with RTG, and then implement it again for RTG.

Not totally. For simple scrolling, with one screen layer, in any direction you can use the OS functions to change the X/Y screen coordinates. It's transparent to RTG because you can use Intuition functions. And would be best for both AGA and RTG as you don't need to get too deep with the scrolling routines and you let the OS handle it for you as efficiently as it can.

As can be demonstrated by the example I gave of opening a wide Workbench screen and scrolling around with the mouse.

For more complicated stuff like split screen scrolls, such as in SOTB, it would be hard to do. In theory you could open a stack of screens on top of each other and move each one around to do scrolling for different layers which should work for both RTG and AGA but it's still only one layer.

Quote:

Unfortunately I don't have the time to do all that, so I'm just going to ¸have to try what few optimisation opportunities I have, to improve the frame rate of the current implementation. If that isn't sufficient, then I shall have to either remove official support for graphics on AmigaOS3, or else add clear warnings that it's performance is not so great on AmigaOS3.

The problem lies of course in the routines that blit the different layers on screen where on AGA it would be best to scroll themn on screen. I can see it would be hard to optimsie the routines on AGA as they are made for blitting.

The only thing you could do is create AGA scrolling routines you could substitute for the blit routines. Or use sprites in the actual sprite routines. Or create something like "Layers" which would be different sections of the screen you could scroll around, where on AGA it would scroll and on RTG it would blit.

Or, just open an Intuituion screen with a dual playfield, set up a copper list like on AGA and see if OS4 or MOS can emulate it transparently. Hehe.

Quote:

Or I could just scrap AGA support altogether, and require a graphics card for AmigaOS3...

Hmmm, although you should be able to keep graphics in fast ram that way, I think the transfer speed to the framebuffer could be a bit slow. And it would seem bizarre to do this for a 2d scrolling¸ game.

Quote:

Would what? Change the (mask's) width requirement? In what way?

It would change the byte width. A mask, made of one standard bitplane, has 40 bytes per row. Since each line of the mask follows eachother. But compared to an interleaved bitmap, where each line of the bitplanes follows eachother, the byte width will be different. If there are 8 bitplanes interleaved for example, then the byte width will be 320, because 8 screen lines or rows of bitplanes takes up 320 bytes.

This note would give a clue from BltMaskBitMapRastPort:

bltmask - pointer to the single bit-plane mask, which must be the
same size and dimensions as the planes of the
source bitmap.

It should be able to deal with the mask being different. Since it would read the data form the BitMap and RastPort.

Quote:

I've been hoping that I won't need to make a mask line as wide in bytes as the interleaved bitmap's line, as that would almost double the memory usage of a masked bitmap.

It shouldn't be neccessary.

@Samurai_Crow

Quote:

What I'm trying to figure out myself, is a way to implement the macros and MrgCop() subroutine in such a way that an improved Copper could run off of the same macros.

Okay I see what you mean. I just checked my own E sources for using an OS copper and what I did was grab the ViewPort from ViewPortAddress(), Allocate a UCopList and fill it with instructions, insert it into ViewPort.UCopIns and call RethinkDisplay(). So I didn't use MrgCop() at all. I guess my code tries to be Intution friendly.

Quote:

Of course, since the only way to do bitplane pointer positioning with the MrgCop() instruction was to implement another screen and leave a one-pixel tall seam between the two screens. This makes system-friendly versions of the memory wrap-around trick used by tile scrollers like Turrican impossible to do without banging the hardware.

I don't know. If the plane pointers need changing later down the track I don't see why it can't be put in the user copperlist. I don't see a problem letting the OS setup the inital pointers.

One can always replace ViewPort.DspIns or replace the pointers but I don't think that would be needed.

Quote:

My proposal is to take some knowledge of the DMA cycles used by the display and Copper and offset the bitplane values being written to by adding the amount that's already been plotted to the screen to have the bitplanes written to while they are being displayed

That's quite an interesting and good idea.

Quote:

If you don't know how single-buffered tile-mapping works on the AGA chipset, consult Georg's Scrolling Trick on the Aminet.

I've had a bit of a read of that. It's amazing to see what lengths they went too to save time and make sure everything was top notch.

Last edited by Hypex on 09-Jul-2012 at 02:07 PM.
Last edited by Hypex on 08-Jul-2012 at 04:12 PM.

@ChrisH

Quote:

So I think this means my only (rather minor) optimisation opportunity is using interleaved bitmaps.

I agree. Another thing, that have donw already is to make sure the bitmap your are blitting from is in the same format as the one your're bliting too. That is, if you load them in using Datatypes, then make sure to specify a friend bitmap when allocating one. That will speed up the blits so no conversions take place.

@Hypex

RethinkDIsplay() calls MrgCop() internally plus a few other subroutines.

The reason bitplane pointers can't be modified in the UserCopperList is that they need to be offset vertically if screen dragging is left enabled.

_________________
Member of Total Chaos team.