I wanted to add a few notes. Specifically about AGA- 1. The blitter is twice as fast. 2. There is half as much bitmap DMA (DMA used to render the bitmap) 3. Sprites can be up to 64 pixels wide 4. Dual layer mode has each layer at 16 colors. Overall, great video!
Thanks for the compliment. However, the Blitter on AGA is not any faster than the Blitter on OCS, it merely appears faster due to the ability of AGA to lower the bitplane DMA. Speaking of bitplane DMA, that can be lowered to 1/4th, not 1/2. The rest is all accurate (I've actually used 64 pixel wide Sprites in one of my examples before as a workaround for AGA not having the 7-bitplane trick).
@@DutchRetroGuy Wait, does the blitter only use 3.58 mhz DMA and *not* 7.16 mhz? Sounds rather stupid to me. And when I say faster I mean the clock speed, not the pixels per cycle. From what I know, you get 104,000 cycles per frame on a 1200 blitter with 8 bitplanes vs just 40,000 on ECS/OCS.
@@ecernosoft3096 sadly, the Blitter in the Amiga (and indeed the whole custom chip set) always runs at ~3.5MHz. There are about 71050 DMA/Chip RAM cycles available per frame for the custom chips to use on all PAL Amiga's, from the A1000 all the way to the A4000. The differences in speed are due to the amount of cycles used by bitplane DMA and the CPU bus width. On OCS, the CPU has 16 bit access to Chip RAM, on AGA (and the A3000) it has 32 bit access to Chip RAM. However, the Blitter itself only ever uses 16 bits. Bitplane DMA on OCS access is 16 bit, one word per cycle. On AGA however, Bitplane DMA access can be either one, two or four words per cycle (contrary to how Commodore presented it, AGA is actually still a 16 bit chipset. Like the A3000, it has a 'hack' to allow the CPU 32 bit access to Chip RAM, but the custom chips all work in 16 bits still - so the 64 bit wide Sprites & bitplane fetch of AGA internally is 4x16 bits presented as 1x64 bits). It should be noted however, that running AGA in it's 4x bitplane DMA fetch mode does give the Blitter many more cycles during bitplane DMA, which is perceived as an increase in Blitter speed. However, in reality, if you disable all bitplanes and other non/Blitter DMA, the Blitter will always top out at the same speed, regardless of whether you're using an A1000 or A4000. AGA was messy and therefore a bit complicated to explain ;)
@@DutchRetroGuy *comprehends* Seriously, even in AGA it doesn’t run in 7.16 mhz? They have 14.32 mhz RAM in the A1200. Sounds pretty darn logical to me. What I was at least originally thinking was rhat since the Amiga AGA chip RAM runs at 14.32 mhz because the 68020 (an actual 32 bit CPU mind you) there also runs at 14.32 mhz. This would mean that if you divide it by 2 you would get 7.16 mhz. This, is what I thought was what the blitter and Agnus ran at. Yea, you can fetch 32 bits per cycle with Agnus sure, taking only 16000 cycles of DMA (80x200=16000, I’m from NTSC land) or 20480 cycles in PAL. In a 7.16 mhz frame you get 120,000 cycles so the blitter (in my head) got 104,000 cycles minus Paula. This literally seems logical, you have 14.32 mhz RAM after all. Yes, the blitter is still 16 bit and not 32 bit (another missed opportunity) but you’d think this would be the case right? Of course, adding sprites in you get some extra DMA cycles. 64 pixel wide sprites take up 16 bytes of memory- this would be 4 32 bit read cycles so it would take 112 cycles per line instead of 80 for all 8 sprites. If the blitter here runs at 7.16 mhz then during the frame it would actually run at 5.37 mhz (7.16 - 1.79) and during VBLANK it would run at 7.16 mhz, again, minus Paula cycles because Paula exists.
@@ecernosoft3096 yeah seriously, the Amiga Chip set always runs at ~3.5MHz. Yes, this is not logical and yes, this does mean that AGA's performance gain is much less large than it should've been, but sadly it is the case. It is also one of the reasons why the CPU has such terrible bandwidth to Chip RAM, despite having 32 bit access. Commodore put very little R&D effort into AGA, the engineers were only allowed to upgrade one of the three chips, as management really wanted AAA instead (they chose to upgrade Denise to a full 8-bitplane chip, now called Lisa). The rest of the custom chips were only changed in so far as was needed to support the new features of Lisa.
Howdy , there was some tricks to display more than 32/64 colors on the Amiga without using HAM. I think the game Universe did use some tricks to approximate 256 colors on screen by altering the palette as the background was drawn or something like that. I would love to hear your take on that - hope you can cook up a video about that as well.
Quite true, there's a number of games (and certainly a whole bunch of demos) that use the Copper to change the palette in real time, which allows for many more colours on screen than normal. Not many did it well, but those that did it well are pretty good. As you mentionded, Universe is one, but another great example is LionHeart. A more subtle one is Pang, which uses Copper reloading to change the background colours, which in turn means it shows more colours than you might initially think.
@@DutchRetroGuy Thanks a bunch - I had a look at Lionheart (which I never played) and Pang (which I did play a little bit) and funny enough I never noticed this back then , but now that you mention it it seems like you are right. As far as I remember the Amiga had 4bit each for R,G and B and I believe (or have fantasized about) that some demos did some tricks to effectively color cycle between value (example) 10 and 11 very rapidly to give the impression of a color in between. Not sure how well that worked on 50Hz displays, but as said - I would really appreciate your take on this, but no pressure. Thanks a bunch for your videos, love every single one of them :)
@@SEngelsg I can think of three problems with that idea: 1) It will flicker. This may be okay for something energetic like Sonic the Hedgehog's shield, but not for some inert background decoration. 2) Most people used televisions as their display, and televisions were interlaced at the time. So the two colors you were switching between would appear in slightly different places. 3) A lot of Amiga games did not run at 50 fps. Often they would scroll the screen and move the sprites at 50 fps, which made them look nice and smooth, but the bobs were updated slower.
Note: worth looking at is the R-Type-style level of "Apidya" which looks incredible. A detailed, highly-animated, 4-colour background parallax layer. Presume this is done with repeated sprites. Very cleverly designed so that the graphics do not look like a repeating pattern. I think it's the best use of this technique I've seen.
@@DutchRetroGuy Also - this just occurred to me - how about "Kid Chaos"? What on earth is going on there? Loads of colours in both foreground and background layers - plus multiple scrolling speeds applied to the background. The whole thing shifting at a very fast pace. Seems utterly miraculous...
@@Midwinter2 as far as I know, Kid Chaos uses Dual Playfield mode and lots of Copper colour changes/Copper display shift changes. Very impressive visually, but oh so fiddly to get right.
Wow, performance looks amazing here. Beautifully smooth parallax scrolling (looks like 50 frames per second) plus tons of fast-moving bobs in the foreground. That's very impressive, by any standards.
@@DutchRetroGuy One more question, if you don't mind. I presume that the two sprite-based methods would not work if you wanted to add vertical scrolling as well as horizontal? But that vertical scrolling would be no problem with the blitter-based technique?
The palette trickery in the blitter background example, reminds me of the "OR Color" trick, used on the MSX2. It allowed developers to overlap 2 1-bit sprites, to achieve some pretty impressive looking results. Check out Metal Gear 2, for a fantastic example of this, in action. At a hardware level, the game is just changing the color for each monochrome sprite per-scanline, to pick from different colors in a carefully constructed palette.
@@DanTurner-x6z that is quite interesting. I’m not all that up to date on MSX/MSX2 abilities, but I did know about the 1-bit Sprites. Cool to hear they managed to create tricks to improve on this!
Excellent video. I kind of remember another method that involved the use of 5 bit planes where the second set of 16 colours was exactly the same as the first 16 colours. Pasting a large 2 bitplane bob (background layer) every frame allowed you to hardware scroll the whole screen with no colour distortions or errors.
Update: you should totally try the blitter background with AGA. If you do that, you can keep your standard 32 color game with an 8 color background OR a partially transparent foreground, or lighting etc
@@ecernosoft3096 yeah, AGA allows more colourful versions of this effect for sure. Rygar AGA actually has a 32 colour foreground and 8 colour background, using the Blitter for the 32/8 split.
Would be great to see how expensive a brute-force pure blitter 2 bitplane background is compared to these cleverer approaches, both in 16 color mode and 32 color mode (it would use the first 4 colors). That would leave nearly all colors plus all sprites, so knowing the "price" of that in comparison would be great. Also little comparisons like having the background layer not be fullscreen (for example, just a mountain range in the middle of the screen, lots of games did that) and how many more bobs you can get from doing that. Just some other ideas for parallax related videos you could do.
There's certainly more stuff that can be talked about when considering Dual Layer approaches :) I can probably give some clarity though, the Blitter cost for doing a 2 bitplane (rather than 1 bitplane) solution will cost an additional 8960 DMA cycles for the current 25FPS solution, or an additional 26880 DMA cycles for a 50FPS solution. The 50FPS solution is clearly too expensive, so I'll just focus on the 25FPS solution for the remainder of my answer. For a 4 bitplane screen, this change translates into losing ~4 BOBs@32x32 per frame and gaining ~2 BOBsat the same size due to dropping from 5 bitplanes to 4, for a total of 11 bobs per frame. As you point out, this would give you 8 additional Sprite colours. Note however that it would lower the total number of colours for the foreground/background also: from 20 to 16. If you want to go 5 bitplane, the costs get higher. You still lose the 8960 DMA cycles for the extra blitting, but don't gain the 4 vs 5 bitplane offset. Furthermore, 5 bitplane bobs are more expensive to draw. In total, you should expect to lose ~6 BOBs drawn per frame (@32x32), leaving 7. As for not going full screen, that roughly translates into a linear gain depending on how many pixels you drop. I.E. if you halve the effect size, you gain about half the cycles, which translates into about 2 BOBs @32x32. Note that in the case of the Blitter effect such an approach will complicate blitting of BOBs somewhat as there are now regions of the screen where blitting needs to take into account the Blitter effect and regions where it needs to work as normal.
In Powder we were using partial blitting to have less colors bobs (through localized bitplane on/off) but more performance - however was all in 25FPS but we were able to move a LOT of stuff, want to work on it?
It's very interesting. Is there a constraint as far as screen resolution is concerned ? I'm speaking about the max 288 pixels per line limitation, and the no more than 220 or 240 lines limitation. Also, you're not giving any infos about the CPU cycles left, with each solution you demonstrated, to know what's left for the logic of a game. Thanks for your video anyway, again, it was very well explained.
Thanks, I'll try to answer your questions :) There's not really a limit to the per line resolution, it's more of convenience. On the Amiga, if you want to use DMA to set up the Sprites and you want to use all 8 Sprite channels and you want to horizontally scroll, you're limited to 304 pixels horizontally or you'll lose 2 Sprite channels. You can set up the Sprites using the Copper (or CPU if you're particularly fond of pain) as well, but DMA is more convenient so most Amiga OCS/ECS games limit themselves to 304 or less pixels horizontally (there are of course exceptions). Reason to go to 288 is purely for aesthetic reasons, I think it looks nicer than 304 pixels set up such that Sprite DMA gets all 8 channels, which is slightly offset to the right on the screen. Regarding the amount of display lines, that's an old habit of mine - a full PAL screen would be 256 lines, but as I understand it, 240 lines will just about fit on an NTSC screen as well. A 256 line screen would get cut of partially for those users. So generally I limit myself to 240 lines so that people who don't have PAL can also see the full screen. Obviously, the bigger the screen, the bigger the Blitter/Copper overhead, but for the effects here the jump to 320x256 would not matter that much. About CPU overhead: main reason I didn't discuss it is that for most practical purposes the Blitter is the limiting factor in Amiga OCS/ECS games, not so much the CPU. But to give you some insight anyway, the effects use between ~30.000 and ~35.000 DMA cycles, including the bitplane display. This is about 42-49% of the total Chip RAM DMA bandwidth. Of this, the bitplane display takes between 17.888 and 22144 DMA cycles, or about 24-31% of Chip RAM DMA bandwidth. Note this is excluding the blitting of the BOBs themselves. For the CPU things are slightly better than you might think here, as it doesn't normally use all the Chip RAM DMA cycles available (it essentially runs at full speed if a 4 bitplane or less lowres screen is used), a quick back-of-the-enveloppe calculation then shows that it would lose between ~12000 and ~17000 DMA cycles. This is equivalent to exactly twice that in CPU cycles. The CPU has ~141000 cycles per frame, so it loses between about 8-12% of it's cycles to DMA cycle stealing from the effects. The rest of the CPU overhead is relatively small, the main overhead is the Blitter and Copper. The CPU is basically just setting up the blits and running a fairly simple main loop that updates the custom chip registers and call some control routines. Hope this helps :)
@@DutchRetroGuy Thanks a lot for this long and extremely well detailed answer ! How do you explain then that in a game like Shadow of the Beast when the main character changes direction, the frame rate drops from 50 fps to 25, because the sprite flipping is completed with the CPU ? I really don't get it : the 68000 should have plenty of CPU cycles left, available per frame, to perform the software flipping, without using more than the number of cycles left available per VBL. Is it that Shadow of the Beast isn't particularly well coded ? Thanks for your time, it's true I really appreciate the fact you know what you're talking about, and you can answer some questions I always had about the Amiga chipset.
@@Archimedes75009 hmm, that is indeed odd. I've gone and checked it in WinUAE with the Visual DMA Debugger to see what is going on here. It does seem to use nearly an entire frame to flip that single Sprite. That is extremely weird, a Sprite flip algorithm should really not be that slow. No idea what they did there, but it surely doesn't seem like an optimal solution!
@@Midwinter2 It's quite hard to spot because as far as I can tell it's only a single frame lost when you turn around. If there's no enemies nearby it's almost impossible to spot for me.
Many games did, yeah. As far as I know, Jim Power used both the Amiga's Dual Playfield mode and a Sprite background for a total of three layers - though it didn't use all Sprites for the effect. If I remember correctly, it only used 2 Sprites for a 32 pixel wide repeating pattern.
Hardware sprites can acrually use 16 colours. You just need to work on different bitplanes with blitter so colours 16-23 are a copy of 0-7 and 8-15 are mirrored into 24-31. We can use copper colour magic on background then.
As far as I can see, I'm limited in what bitplanes I can use because I use the Amiga's hardware scrolling with different values for playfield 1 and playfield 2. This splits the display up into bitplanes 1,3,5 and 2,4. I can currently choose either bitplane 2 or bitplane 4 for the Blitter bitplane, so it's either all colours that are multiples of 2 or 8 which get doubled. I can't easily use bitplanes 1, 3 or 5 because doing so would require using the Blitter to correct at least two bitplanes rather than just one, which would make the effect cost much more performance (which in turn would limit the number of objects that can be drawn in a frame even more). So yes, it can be done, but you'd drop to a very low number of Blitter Objects that can still be drawn at that point and I didn't see that as a good option myself. Regarding the Copper, it's free if the Blitter based background is used so it can indeed be used to increase the number of colours on screen fairly easily. I didn't do that here because I focus on one effect at a time in these videos to keep things more focused :)
@@AA-vf3eu Bitplane 5 can't be used because bitplane 5 horizontally scrolls along with bitplanes 1 & 3. If you want to use bitplane 5 you'd either need to Blitter correct bitplane 5 and one of bitplanes 1/3. Or Blitter correct bitplane 5 and one of bitplanes 2/4. This is because the Amiga scrolling hardware can't scroll individual bitplanes horizontally, only bitplanes 1,3,5 together and 2,4 together. If you use bitplane 2 or 4 for the Blitter this isn't a problem as both 2 and 4 scroll together so you don't need to double correct. Your solution could work for vertical scrolling though (as there bitplanes can be freely scrolled separately), so that is something to keep in mind.
@@DutchRetroGuy right now 4th bitplane belongs to single playfield operated by single scroll register. 5th bitplane belongs also to single playfoeld operated by single scroll register. I dont see a difference between them which would prefer on over the second
@@AA-vf3eu that is because you’re not considering the whole picture: the background layer consists of 2 bitplanes. These scroll at a different rate than the foreground. Since the bitplanes are coupled in how they scroll (2,4 and 1,3,5) the only viable way to combine bitplanes is to use 2 & 4. If you use 5, you either need to scroll 2,4 at the BG speed or 1,3,5 at the BG speed. In both cases you end up needing to correct at least 2 bitplanes with the Blitter - or accept fewer FG colours.
As a kid I loved my Amiga but I was alwasy annoyed that consoles such as the Genesis or SNES could easily outdo what the Amiga could do (not in all ways, but you know what I mean). Now I know why!
I'm not sure what you refer too here: do you mean the objects moving on the screen? In case you mean those, I've made them out of Blitter objects and update them using a fractional speed, which can seem a bit less smooth compared to an integer speed but does allow more speeds to choose from. If I updated them at whole integer values, they'd appear fully smooth. If you meant the background hardware Sprites, those only update at one pixel every other frame (to keep them slower than the foreground), which might make them less smooth - though it looks a lot better on a CRT than on an LCD screen. The programs itself runs at 50Hz though ;)
@@DutchRetroGuy your routines are reminiscent of jim power. but i was talking about c64 and amiga in general over the last decades. im not sure if the amiga was hard for devs. to get to grips with, like the atari jaguar. when you said fractional did you mean 8bits or did you mean floating points?
@@bramblemat Ah, I see what you mean now. The main reason for the difference in smoothness is that many Amiga games ran at 25Hz updates -sometimes even lower than that :( - rather than 50Hz. This allows you to get more on screen, but makes the GFX updates less smooth for sure. The two main reasons for this were that a lot of Amiga games were written for the Atari ST first (which had a much larger market share for most of the 16 bit era) and then converted, often in record time and without using the Amiga hardware to the fullest. The second reason is that you're right - the Amiga hardware is harder to get to grips with than the average console or other system. Using the hardware isn't that hard, but using it efficiently and effectively can get really quite tricky. Modern homebrew games made in assembly (lots aren't by the way) often do run at full 50Hz. About the fractional: the Blitter object coordinates are in 16:16 fixed point format, so not quite floating point, but still allowing for very precise speed control.
4:28 not really a unique feature if Atari 8 bit already had it . The real idea of copper is to reestablish the race with the beam while we use a 68k as CPU which really does not feel like it wants to race.
I am not an expert, just read that "Space Invaders" used this. Maybe this was actual like mode-7 where the background became the foreground? Texas Instruments made this easy to use chips. The "Product Owner" probably thought: "Why would the sprites be vertically aligned?". Even the interrupt on C64 cannot address x positions. Commodore did not want coders to write CPU loops to count cycles. So no repeated sprites. The official solution would need too much registers (cost of documentation). So, commodore omitted this one link which lets the sprite data rotate (instead of shift) on the Amiga. Now if there only was better documentation of die shots of GTIA where we could see this connection. Rotation registers should MHO appear as a left shifting register atop a right shifting register. It is actually pretty weird that pcEngine with its 16 sprites and single playfield cannot repeat sprites! Some patent? Or can it? @@DutchRetroGuy
No I think that you are right. PCengine is based on NES is based on Texas Instrument chips. That lineage never adapted this. Amiga is best!@@DutchRetroGuy
Fantastic Dizzy used a different way to create a 16 colour background from hardware sprites, the AGA version took it a step further... ruclips.net/video/mWpnBapugEQ/видео.html
True and an interesting approach for sure :) Risky Woods used the same idea for a 16 colour Sprite based background. Both it and Fantastic Dizzy are limited to a 64 pixel wide pattern, but that can still certainly look nice. Works well if you don't need many moving objects on screen as it does use a lot of Copper display time on OCS. AGA is a bit different, the 16 colour hardware sprite background is a chipset feature there, you can just set a single register and Sprites will repeat themselves horizontally after 256 pixels, which combined with 64 pixel wide Sprites under AGA lets you create a nice colourful repeating background layer for AGA games.
@@DutchRetroGuy I can't remember if I used the copper to write directly to the sprdat registers to 'draw' the image, I do remember trying that method though. I'd have to look at the copperlist to see what I did.
@@happycactusgames8239 interesting, you mean using "manual mode" sprites only? Or are you refering to something closer to the free-form sprite layer video I did a while back? Good stuff in either case, (ab)using the Copper for effects is certainly one of the nicer things about the Amiga :)
@@DutchRetroGuy I just watched your other video, yes, I remember updating the sprite data registers directly to render in different images to hardware sprites using the copper, but for Dizzy, it looks like I just reused the same data (so a 64 wide 16 colour image repeated) - it was probably just stealing too much dma time otherwise, as the main game was 32 colours (5 bitplanes) - I played around with a number of different ideas to get this ported from the sega genesis to the amiga without having to rework the graphics too much (the genesis had 4 palettes of 16 colours to play with!) - I loved abusing the amiga hardware...
![Kumamoto Masters Japan 2024 | Gregoria Mariska Tunjung (INA) [5] vs. Akane Yamaguchi (JPN) [2] | F](http://i.ytimg.com/vi/EIjZybhsWqA/mqdefault.jpg)
I wanted to add a few notes.
Specifically about AGA-
1. The blitter is twice as fast.
2. There is half as much bitmap DMA (DMA used to render the bitmap)
3. Sprites can be up to 64 pixels wide
4. Dual layer mode has each layer at 16 colors.
Overall, great video!
Thanks for the compliment.
However, the Blitter on AGA is not any faster than the Blitter on OCS, it merely appears faster due to the ability of AGA to lower the bitplane DMA.
Speaking of bitplane DMA, that can be lowered to 1/4th, not 1/2.
The rest is all accurate (I've actually used 64 pixel wide Sprites in one of my examples before as a workaround for AGA not having the 7-bitplane trick).
@@DutchRetroGuy Wait, does the blitter only use 3.58 mhz DMA and *not* 7.16 mhz? Sounds rather stupid to me.
And when I say faster I mean the clock speed, not the pixels per cycle.
From what I know, you get 104,000 cycles per frame on a 1200 blitter with 8 bitplanes vs just 40,000 on ECS/OCS.
@@ecernosoft3096 sadly, the Blitter in the Amiga (and indeed the whole custom chip set) always runs at ~3.5MHz. There are about 71050 DMA/Chip RAM cycles available per frame for the custom chips to use on all PAL Amiga's, from the A1000 all the way to the A4000.
The differences in speed are due to the amount of cycles used by bitplane DMA and the CPU bus width. On OCS, the CPU has 16 bit access to Chip RAM, on AGA (and the A3000) it has 32 bit access to Chip RAM.
However, the Blitter itself only ever uses 16 bits. Bitplane DMA on OCS access is 16 bit, one word per cycle. On AGA however, Bitplane DMA access can be either one, two or four words per cycle (contrary to how Commodore presented it, AGA is actually still a 16 bit chipset. Like the A3000, it has a 'hack' to allow the CPU 32 bit access to Chip RAM, but the custom chips all work in 16 bits still - so the 64 bit wide Sprites & bitplane fetch of AGA internally is 4x16 bits presented as 1x64 bits).
It should be noted however, that running AGA in it's 4x bitplane DMA fetch mode does give the Blitter many more cycles during bitplane DMA, which is perceived as an increase in Blitter speed. However, in reality, if you disable all bitplanes and other non/Blitter DMA, the Blitter will always top out at the same speed, regardless of whether you're using an A1000 or A4000.
AGA was messy and therefore a bit complicated to explain ;)
@@DutchRetroGuy *comprehends*
Seriously, even in AGA it doesn’t run in 7.16 mhz? They have 14.32 mhz RAM in the A1200. Sounds pretty darn logical to me.
What I was at least originally thinking was rhat since the Amiga AGA chip RAM runs at 14.32 mhz because the 68020 (an actual 32 bit CPU mind you) there also runs at 14.32 mhz. This would mean that if you divide it by 2 you would get 7.16 mhz. This, is what I thought was what the blitter and Agnus ran at. Yea, you can fetch 32 bits per cycle with Agnus sure, taking only 16000 cycles of DMA (80x200=16000, I’m from NTSC land) or 20480 cycles in PAL. In a 7.16 mhz frame you get 120,000 cycles so the blitter (in my head) got 104,000 cycles minus Paula. This literally seems logical, you have 14.32 mhz RAM after all. Yes, the blitter is still 16 bit and not 32 bit (another missed opportunity) but you’d think this would be the case right?
Of course, adding sprites in you get some extra DMA cycles. 64 pixel wide sprites take up 16 bytes of memory- this would be 4 32 bit read cycles so it would take 112 cycles per line instead of 80 for all 8 sprites. If the blitter here runs at 7.16 mhz then during the frame it would actually run at 5.37 mhz (7.16 - 1.79) and during VBLANK it would run at 7.16 mhz, again, minus Paula cycles because Paula exists.
@@ecernosoft3096 yeah seriously, the Amiga Chip set always runs at ~3.5MHz. Yes, this is not logical and yes, this does mean that AGA's performance gain is much less large than it should've been, but sadly it is the case. It is also one of the reasons why the CPU has such terrible bandwidth to Chip RAM, despite having 32 bit access.
Commodore put very little R&D effort into AGA, the engineers were only allowed to upgrade one of the three chips, as management really wanted AAA instead (they chose to upgrade Denise to a full 8-bitplane chip, now called Lisa). The rest of the custom chips were only changed in so far as was needed to support the new features of Lisa.
Howdy , there was some tricks to display more than 32/64 colors on the Amiga without using HAM. I think the game Universe did use some tricks to approximate 256 colors on screen by altering the palette as the background was drawn or something like that. I would love to hear your take on that - hope you can cook up a video about that as well.
Quite true, there's a number of games (and certainly a whole bunch of demos) that use the Copper to change the palette in real time, which allows for many more colours on screen than normal.
Not many did it well, but those that did it well are pretty good. As you mentionded, Universe is one, but another great example is LionHeart. A more subtle one is Pang, which uses Copper reloading to change the background colours, which in turn means it shows more colours than you might initially think.
@@DutchRetroGuy Thanks a bunch - I had a look at Lionheart (which I never played) and Pang (which I did play a little bit) and funny enough I never noticed this back then , but now that you mention it it seems like you are right. As far as I remember the Amiga had 4bit each for R,G and B and I believe (or have fantasized about) that some demos did some tricks to effectively color cycle between value (example) 10 and 11 very rapidly to give the impression of a color in between. Not sure how well that worked on 50Hz displays, but as said - I would really appreciate your take on this, but no pressure. Thanks a bunch for your videos, love every single one of them :)
@@SEngelsg I can think of three problems with that idea:
1) It will flicker. This may be okay for something energetic like Sonic the Hedgehog's shield, but not for some inert background decoration.
2) Most people used televisions as their display, and televisions were interlaced at the time. So the two colors you were switching between would appear in slightly different places.
3) A lot of Amiga games did not run at 50 fps. Often they would scroll the screen and move the sprites at 50 fps, which made them look nice and smooth, but the bobs were updated slower.
Note: worth looking at is the R-Type-style level of "Apidya" which looks incredible. A detailed, highly-animated, 4-colour background parallax layer. Presume this is done with repeated sprites. Very cleverly designed so that the graphics do not look like a repeating pattern. I think it's the best use of this technique I've seen.
Yeah, Apidya does use repeating Sprites for the animating parallax layer. An extremely cool and impressive use of this technique for sure!
@@DutchRetroGuy Also - this just occurred to me - how about "Kid Chaos"? What on earth is going on there? Loads of colours in both foreground and background layers - plus multiple scrolling speeds applied to the background. The whole thing shifting at a very fast pace. Seems utterly miraculous...
@@Midwinter2 as far as I know, Kid Chaos uses Dual Playfield mode and lots of Copper colour changes/Copper display shift changes. Very impressive visually, but oh so fiddly to get right.
@@DutchRetroGuy Ah, I see, thank you! That game is seriously impressive. Essentially performing like a top-tier Megadrive game...
Wow, performance looks amazing here. Beautifully smooth parallax scrolling (looks like 50 frames per second) plus tons of fast-moving bobs in the foreground. That's very impressive, by any standards.
Thanks!
It's indeed running at 50Hz. Foreground & objects update every frame, background scrolls at 1/2 the rate.
@@DutchRetroGuy Ah, interesting! The lower frame rate of the background layer is not apparent due to its slower speed.
@@Midwinter2 yeah, that's exactly the trick. No need to update something at full frame rate if you can't see the difference anyway :)
@@DutchRetroGuy Absolutely!
@@DutchRetroGuy One more question, if you don't mind.
I presume that the two sprite-based methods would not work if you wanted to add vertical scrolling as well as horizontal?
But that vertical scrolling would be no problem with the blitter-based technique?
Awesome awesome technical breakdown of Amiga graphics/coding techniques!
The palette trickery in the blitter background example, reminds me of the "OR Color" trick, used on the MSX2.
It allowed developers to overlap 2 1-bit sprites, to achieve some pretty impressive looking results. Check out Metal Gear 2, for a fantastic example of this, in action.
At a hardware level, the game is just changing the color for each monochrome sprite per-scanline, to pick from different colors in a carefully constructed palette.
@@DanTurner-x6z that is quite interesting. I’m not all that up to date on MSX/MSX2 abilities, but I did know about the 1-bit Sprites. Cool to hear they managed to create tricks to improve on this!
Great video! I would love to see a video on how Agony achieved all of the effects it had. It was a true masterpiece in Amiga tricks.
Thanks!
Agony is indeed a graphical masterpiece, one of the best looking games on the Amiga 👍
Excellent video. I kind of remember another method that involved the use of 5 bit planes where the second set of 16 colours was exactly the same as the first 16 colours. Pasting a large 2 bitplane bob (background layer) every frame allowed you to hardware scroll the whole screen with no colour distortions or errors.
Interesting notion, similar to what I’m doing, yes
Roondar, your videos are always very nicely done and I learn a lot. Bravo.
Thanks!
Great content as always, Roony... :)
Looking forward seeing new games implementing this.
Wish I knew this when I created my little game.
Thanks!
Hope you’re right 🙂
@@DutchRetroGuy Welp you have Game number 1 implementing it, except with AGA since I don't feel ECS/OCS has enough colors to work with here...
@@ecernosoft3096 nice! Looking forward to seeing what you come up with :)
Update: you should totally try the blitter background with AGA. If you do that, you can keep your standard 32 color game with an 8 color background OR a partially transparent foreground, or lighting etc
@@ecernosoft3096 yeah, AGA allows more colourful versions of this effect for sure. Rygar AGA actually has a 32 colour foreground and 8 colour background, using the Blitter for the 32/8 split.
Most interesting, thank you very much!
love the intro music.
Wonderful video, mate. - Antiriad
impressive work! thanks!
Nice, very detailed.
Would be great to see how expensive a brute-force pure blitter 2 bitplane background is compared to these cleverer approaches, both in 16 color mode and 32 color mode (it would use the first 4 colors). That would leave nearly all colors plus all sprites, so knowing the "price" of that in comparison would be great.
Also little comparisons like having the background layer not be fullscreen (for example, just a mountain range in the middle of the screen, lots of games did that) and how many more bobs you can get from doing that. Just some other ideas for parallax related videos you could do.
There's certainly more stuff that can be talked about when considering Dual Layer approaches :)
I can probably give some clarity though, the Blitter cost for doing a 2 bitplane (rather than 1 bitplane) solution will cost an additional 8960 DMA cycles for the current 25FPS solution, or an additional 26880 DMA cycles for a 50FPS solution. The 50FPS solution is clearly too expensive, so I'll just focus on the 25FPS solution for the remainder of my answer.
For a 4 bitplane screen, this change translates into losing ~4 BOBs@32x32 per frame and gaining ~2 BOBsat the same size due to dropping from 5 bitplanes to 4, for a total of 11 bobs per frame.
As you point out, this would give you 8 additional Sprite colours. Note however that it would lower the total number of colours for the foreground/background also: from 20 to 16.
If you want to go 5 bitplane, the costs get higher. You still lose the 8960 DMA cycles for the extra blitting, but don't gain the 4 vs 5 bitplane offset. Furthermore, 5 bitplane bobs are more expensive to draw. In total, you should expect to lose ~6 BOBs drawn per frame (@32x32), leaving 7.
As for not going full screen, that roughly translates into a linear gain depending on how many pixels you drop. I.E. if you halve the effect size, you gain about half the cycles, which translates into about 2 BOBs @32x32. Note that in the case of the Blitter effect such an approach will complicate blitting of BOBs somewhat as there are now regions of the screen where blitting needs to take into account the Blitter effect and regions where it needs to work as normal.
@@DutchRetroGuy Very clear! Thanks :)
In Powder we were using partial blitting to have less colors bobs (through localized bitplane on/off) but more performance - however was all in 25FPS but we were able to move a LOT of stuff, want to work on it?
Work on what? 🙂
It's very interesting.
Is there a constraint as far as screen resolution is concerned ?
I'm speaking about the max 288 pixels per line limitation, and the no more than 220 or 240 lines limitation.
Also, you're not giving any infos about the CPU cycles left, with each solution you demonstrated, to know what's left for the logic of a game.
Thanks for your video anyway, again, it was very well explained.
Thanks, I'll try to answer your questions :)
There's not really a limit to the per line resolution, it's more of convenience. On the Amiga, if you want to use DMA to set up the Sprites and you want to use all 8 Sprite channels and you want to horizontally scroll, you're limited to 304 pixels horizontally or you'll lose 2 Sprite channels. You can set up the Sprites using the Copper (or CPU if you're particularly fond of pain) as well, but DMA is more convenient so most Amiga OCS/ECS games limit themselves to 304 or less pixels horizontally (there are of course exceptions).
Reason to go to 288 is purely for aesthetic reasons, I think it looks nicer than 304 pixels set up such that Sprite DMA gets all 8 channels, which is slightly offset to the right on the screen.
Regarding the amount of display lines, that's an old habit of mine - a full PAL screen would be 256 lines, but as I understand it, 240 lines will just about fit on an NTSC screen as well. A 256 line screen would get cut of partially for those users. So generally I limit myself to 240 lines so that people who don't have PAL can also see the full screen.
Obviously, the bigger the screen, the bigger the Blitter/Copper overhead, but for the effects here the jump to 320x256 would not matter that much.
About CPU overhead: main reason I didn't discuss it is that for most practical purposes the Blitter is the limiting factor in Amiga OCS/ECS games, not so much the CPU. But to give you some insight anyway, the effects use between ~30.000 and ~35.000 DMA cycles, including the bitplane display. This is about 42-49% of the total Chip RAM DMA bandwidth. Of this, the bitplane display takes between 17.888 and 22144 DMA cycles, or about 24-31% of Chip RAM DMA bandwidth. Note this is excluding the blitting of the BOBs themselves.
For the CPU things are slightly better than you might think here, as it doesn't normally use all the Chip RAM DMA cycles available (it essentially runs at full speed if a 4 bitplane or less lowres screen is used), a quick back-of-the-enveloppe calculation then shows that it would lose between ~12000 and ~17000 DMA cycles. This is equivalent to exactly twice that in CPU cycles. The CPU has ~141000 cycles per frame, so it loses between about 8-12% of it's cycles to DMA cycle stealing from the effects.
The rest of the CPU overhead is relatively small, the main overhead is the Blitter and Copper. The CPU is basically just setting up the blits and running a fairly simple main loop that updates the custom chip registers and call some control routines.
Hope this helps :)
@@DutchRetroGuy Thanks a lot for this long and extremely well detailed answer !
How do you explain then that in a game like Shadow of the Beast when the main character changes direction, the frame rate drops from 50 fps to 25, because the sprite flipping is completed with the CPU ?
I really don't get it : the 68000 should have plenty of CPU cycles left, available per frame, to perform the software flipping, without using more than the number of cycles left available per VBL.
Is it that Shadow of the Beast isn't particularly well coded ?
Thanks for your time, it's true I really appreciate the fact you know what you're talking about, and you can answer some questions I always had about the Amiga chipset.
@@Archimedes75009 Interesting! I never noticed a frame-rate drop in Shadow of the Beast when changing direction! Must check it out...
@@Archimedes75009 hmm, that is indeed odd. I've gone and checked it in WinUAE with the Visual DMA Debugger to see what is going on here. It does seem to use nearly an entire frame to flip that single Sprite.
That is extremely weird, a Sprite flip algorithm should really not be that slow. No idea what they did there, but it surely doesn't seem like an optimal solution!
@@Midwinter2 It's quite hard to spot because as far as I can tell it's only a single frame lost when you turn around. If there's no enemies nearby it's almost impossible to spot for me.
Jim Power used a sprite background layer didn't it?
Many games did, yeah. As far as I know, Jim Power used both the Amiga's Dual Playfield mode and a Sprite background for a total of three layers - though it didn't use all Sprites for the effect. If I remember correctly, it only used 2 Sprites for a 32 pixel wide repeating pattern.
Amiga Magic!!
Wonderful
Nice Vid! Thank you.
Hardware sprites can acrually use 16 colours. You just need to work on different bitplanes with blitter so colours 16-23 are a copy of 0-7 and 8-15 are mirrored into 24-31. We can use copper colour magic on background then.
As far as I can see, I'm limited in what bitplanes I can use because I use the Amiga's hardware scrolling with different values for playfield 1 and playfield 2.
This splits the display up into bitplanes 1,3,5 and 2,4. I can currently choose either bitplane 2 or bitplane 4 for the Blitter bitplane, so it's either all colours that are multiples of 2 or 8 which get doubled.
I can't easily use bitplanes 1, 3 or 5 because doing so would require using the Blitter to correct at least two bitplanes rather than just one, which would make the effect cost much more performance (which in turn would limit the number of objects that can be drawn in a frame even more).
So yes, it can be done, but you'd drop to a very low number of Blitter Objects that can still be drawn at that point and I didn't see that as a good option myself.
Regarding the Copper, it's free if the Blitter based background is used so it can indeed be used to increase the number of colours on screen fairly easily. I didn't do that here because I focus on one effect at a time in these videos to keep things more focused :)
@@DutchRetroGuy but why we cant use 5th a blitter. It does not matter which plane is front and which is back
@@AA-vf3eu Bitplane 5 can't be used because bitplane 5 horizontally scrolls along with bitplanes 1 & 3.
If you want to use bitplane 5 you'd either need to Blitter correct bitplane 5 and one of bitplanes 1/3. Or Blitter correct bitplane 5 and one of bitplanes 2/4. This is because the Amiga scrolling hardware can't scroll individual bitplanes horizontally, only bitplanes 1,3,5 together and 2,4 together.
If you use bitplane 2 or 4 for the Blitter this isn't a problem as both 2 and 4 scroll together so you don't need to double correct.
Your solution could work for vertical scrolling though (as there bitplanes can be freely scrolled separately), so that is something to keep in mind.
@@DutchRetroGuy right now 4th bitplane belongs to single playfield operated by single scroll register. 5th bitplane belongs also to single playfoeld operated by single scroll register. I dont see a difference between them which would prefer on over the second
@@AA-vf3eu that is because you’re not considering the whole picture: the background layer consists of 2 bitplanes. These scroll at a different rate than the foreground. Since the bitplanes are coupled in how they scroll (2,4 and 1,3,5) the only viable way to combine bitplanes is to use 2 & 4.
If you use 5, you either need to scroll 2,4 at the BG speed or 1,3,5 at the BG speed. In both cases you end up needing to correct at least 2 bitplanes with the Blitter - or accept fewer FG colours.
Very very cool
As a kid I loved my Amiga but I was alwasy annoyed that consoles such as the Genesis or SNES could easily outdo what the Amiga could do (not in all ways, but you know what I mean). Now I know why!
Yeah, the SNES and Genesis/Mega Drive had some definite advantages over the Amiga when it came to Sprite and Layer hardware :)
is it just me or does the c64 hrdwr sprts seem smoother than amiga? is it a higher update?
I'm not sure what you refer too here: do you mean the objects moving on the screen?
In case you mean those, I've made them out of Blitter objects and update them using a fractional speed, which can seem a bit less smooth compared to an integer speed but does allow more speeds to choose from. If I updated them at whole integer values, they'd appear fully smooth.
If you meant the background hardware Sprites, those only update at one pixel every other frame (to keep them slower than the foreground), which might make them less smooth - though it looks a lot better on a CRT than on an LCD screen.
The programs itself runs at 50Hz though ;)
@@DutchRetroGuy your routines are reminiscent of jim power. but i was talking about c64 and amiga in general over the last decades. im not sure if the amiga was hard for devs. to get to grips with, like the atari jaguar. when you said fractional did you mean 8bits or did you mean floating points?
@@bramblemat Ah, I see what you mean now. The main reason for the difference in smoothness is that many Amiga games ran at 25Hz updates -sometimes even lower than that :( - rather than 50Hz. This allows you to get more on screen, but makes the GFX updates less smooth for sure.
The two main reasons for this were that a lot of Amiga games were written for the Atari ST first (which had a much larger market share for most of the 16 bit era) and then converted, often in record time and without using the Amiga hardware to the fullest. The second reason is that you're right - the Amiga hardware is harder to get to grips with than the average console or other system. Using the hardware isn't that hard, but using it efficiently and effectively can get really quite tricky.
Modern homebrew games made in assembly (lots aren't by the way) often do run at full 50Hz.
About the fractional: the Blitter object coordinates are in 16:16 fixed point format, so not quite floating point, but still allowing for very precise speed control.
@@DutchRetroGuy excellent , thank you. do you publish games?
@@bramblemat so far, no games. Might try for one at one point, but we'll see :)
4:28 not really a unique feature if Atari 8 bit already had it . The real idea of copper is to reestablish the race with the beam while we use a 68k as CPU which really does not feel like it wants to race.
I was unaware that the Atari 8 bit systems also allowed for horizontal Sprite multiplexing.
Interesting, thanks for the info.
I am not an expert, just read that "Space Invaders" used this. Maybe this was actual like mode-7 where the background became the foreground? Texas Instruments made this easy to use chips. The "Product Owner" probably thought: "Why would the sprites be vertically aligned?". Even the interrupt on C64 cannot address x positions. Commodore did not want coders to write CPU loops to count cycles. So no repeated sprites. The official solution would need too much registers (cost of documentation). So, commodore omitted this one link which lets the sprite data rotate (instead of shift) on the Amiga. Now if there only was better documentation of die shots of GTIA where we could see this connection. Rotation registers should MHO appear as a left shifting register atop a right shifting register.
It is actually pretty weird that pcEngine with its 16 sprites and single playfield cannot repeat sprites! Some patent? Or can it?
@@DutchRetroGuy
@@ArneChristianRosenfeldt as far as I know the PC-Engine can’t repeat Sprites, but I could, of course, be wrong.
No I think that you are right. PCengine is based on NES is based on Texas Instrument chips. That lineage never adapted this. Amiga is best!@@DutchRetroGuy
Fantastic Dizzy used a different way to create a 16 colour background from hardware sprites, the AGA version took it a step further... ruclips.net/video/mWpnBapugEQ/видео.html
True and an interesting approach for sure :)
Risky Woods used the same idea for a 16 colour Sprite based background. Both it and Fantastic Dizzy are limited to a 64 pixel wide pattern, but that can still certainly look nice. Works well if you don't need many moving objects on screen as it does use a lot of Copper display time on OCS.
AGA is a bit different, the 16 colour hardware sprite background is a chipset feature there, you can just set a single register and Sprites will repeat themselves horizontally after 256 pixels, which combined with 64 pixel wide Sprites under AGA lets you create a nice colourful repeating background layer for AGA games.
@@DutchRetroGuy I can't remember if I used the copper to write directly to the sprdat registers to 'draw' the image, I do remember trying that method though. I'd have to look at the copperlist to see what I did.
@@happycactusgames8239 interesting, you mean using "manual mode" sprites only? Or are you refering to something closer to the free-form sprite layer video I did a while back? Good stuff in either case, (ab)using the Copper for effects is certainly one of the nicer things about the Amiga :)
@@DutchRetroGuy I just watched your other video, yes, I remember updating the sprite data registers directly to render in different images to hardware sprites using the copper, but for Dizzy, it looks like I just reused the same data (so a 64 wide 16 colour image repeated) - it was probably just stealing too much dma time otherwise, as the main game was 32 colours (5 bitplanes) - I played around with a number of different ideas to get this ported from the sega genesis to the amiga without having to rework the graphics too much (the genesis had 4 palettes of 16 colours to play with!) - I loved abusing the amiga hardware...
@@happycactusgames8239 cool stuff, thanks for elaborating. Love to hear how the old games were made :)