Cookiecut is usually needed for bobs in games, which is why I used it. The bobs are 32x32 on a six bitplane screen. I suspect the difference in speed is probably due to not needing cookiecut in your demo. If you can get away with just doing copy blits, you get a lot more bobs on screen.

To be fair, it was released around 2015 IIRC, so I can understand missing it 😉

Yeah, sadly this kind of thing was not commonly done back in the day. I can’t change the past, but some Amiga games released over the last year or two have actually used my mixing routines.

The Blitter in the A1200 is the same as the one in the A500. However, due to the AGA chipset being more efficient at displaying the screen, it still gets more cycles per frame and thus appears to be faster. AGA Sprites are improved over their A500 counterparts. Where the A500 was limited to Sprites that were 16 pixels wide, the A1200 could display Sprites at up to 64 pixels wide each. The A1200 also can choose which 16 colour bank(s) of colours to use for Sprites, meaning that in 32-128 colours the Sprites can have separate colours from the main screen, unlike the A500 where this was only possible if the screen used 16 or fewer colours. The Chipset still runs at 3.5MHz, though both the CPU, bitplanes and Sprites can now access memory in more than 16 bit chunks.

@@DutchRetroGuy THX for quick answer with good explain.

You can bring up the map by pressing the tab key.

Thanks!

Yeah, it’s a shame it seems to have stopped. RGCD’s annual cartridge release was a great C64 tradition 🙂

Thanks :)

@@DutchRetroGuy I’m a former Atari programmer who still does Atari programming for other’s games and as a for-fun thing wanted to learn how to code on Amiga, any reccomendations for 68000 compilers?

@@ecernosoft3096 that depends a bit on the language. For C/C++ there's either VBCC, Bebbo's GCC and Bartman's GCC (the latter two are more optimised than the first, but may have some limitations). For assembly, I personally use vasm & vlink, but I've heard great things about the Amiga Assembly extension for Visual Studio Code as well.

@@DutchRetroGuy I ended up finding stuff myself. Do you have a discord server?

@@ecernosoft3096 no, I do not have a Discord server at this time. But you can find me over on the Amiga Game Dev Discord, as well as several other Amiga related Discord servers.

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.

Thanks, as you see I don't upload that often - but there will be more videos. Eventually ;)

@@DutchRetroGuy Haha! Neither do I. I've been busy though- that's why. ... on my first Amiga program!

@@ecernosoft3096 great stuff, hope you're enjoying it :)

That depends. Console Sprites are more difficult to quantify than you might think, for instance the Mega Drive can display up to 80 Sprites (each up to 32x32 pixels). But the number of Sprites is static, meaning that the Mega Drive can display 80 Sprites, but that holds even if the game in question requires the Sprites to be 8x8 pixels rather than the maximum of 32x32. Consoles usually also have limits to the number of Sprites per scanline, which can make quantifying things even more messy. The Amiga Blitter is more flexible in that it doesn’t really matter what size a BOB is, as long as there are enough cycles available in a frame for the Blitter to draw it. The upshot is that the Blitter can likely outperform some of the 16 bit consoles if the objects displayed are very small, but it’ll definitely not manage if the objects displayed are closer to the consoles maximum Sprite sizes. If all you care about is number of objects and their size, you could choose to run your Amiga BOB engine in a very low colour mode (for example, 2 or maybe 4 colours on screen). If you do that, you can get a very large amount of objects on screen even with just the Amiga Blitter. However, if what you really want is a game that looks similar to the average 16 bit console game and has similar numbers of BOBs as such games has Sprites, you’ll almost certainly find that the Amiga won’t be able to match it. Then again, the Amiga is older than the 16 bit consoles as well, so this isn’t really that surprising.

Thanks for the great explanation. I always wondered, with the Amiga only having 8 sprites (without multiplexing), if there could be some fast bob engine instead, as the idea of blitter objects is rather unique to the machine I believe @@DutchRetroGuy

@@Asphodellife there were some other machines with a Blitter (notably the Atari STE, which can get impressive results when coded for properly). But it was a fairly rare thing in computers at the time. When the Amiga launched, I think (though I may be wrong here!) there was only one other consumer oriented system that a Blitter onboard and that was the extremely rare Mindset computer. I'm not entirely certain if the Blitter in that system was as capable, more capable or less capable than the Amiga one, though. Some later VGA/SVGA cards also came with Blitters, though the Blitter that they came with tended to offer only a subset of what the Amiga Blitter could do.

There are two main reasons these bobs are fast: - Drawing bobs with transparency on the Amiga takes twice as long as simply copying a rectangular bob. So these bobs are simply copied without using transparency. The downside is that the ostensibly transparent parts of the bob will overwrite anything behind them with background color, so it only works when we draw onto a blank background. - Normally, before drawing any bobs, we would first clean up any bobs that were previously drawn onto that buffer. However, if we know that we will completely overwrite the old bobs, we can skip this. However if two bobs partially overlap, one must be drawn using transparency and therefore cannot reliably overwrite itself. This gives us two significant restrictions. The first is that our bobs are only fast when they do not overlap, which is acceptable for some genres but not others. The second is that we must draw onto a blank background, which means our game might not be as pretty as if we used transparent bobs. So yes, you might be able to do it, but not necessarily.

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

No, I cross develop using my PC, so that is PyCharm on Windows 10. Technically there is nothing stopping you from running this on Amiga tough, assuming Python 3 and the modules I use are available on it.

@@DutchRetroGuy I don't know python I use C# now and C 30 years ago.. Borland Turbo C it was lol. Pity I can't use C# on the Amiga?

@@random_precision_software I don't think there's C# for the Amiga, though I could be wrong.

Not true

@@bronwaith It is true. Ex Atari employees left and founded a company named Amiga. Then, Commodore, unable to make a 16 bit system, bought Amiga, meaning Atari made it.

@@ecernosoft3096 The keyword here being "Ex". They were not working for Atari at the time, meaning Atari had nothing to do with it. Your argument is like saying that anything Atari created after Jack Tramiel took over Atari was actually made by Commodore because Jack Tramiel used to work at Commodore.

Ok, before you all spam me with “no it’s commodore” or “ex Atari employees” I fixed it.

@@DutchRetroGuy fixed.

Yeah, it's great game. It does really benefit from being run on at least an A1200 though, it gets quite sluggish on the A500. Though perhaps that's not all bad - gives you more time to react :)

Thanks! It's one of my favourite Amiga games from back in the day and I felt it deserved a nice review :)

On A500 clearing with the CPU and Blitter together is indeed quite a bit faster, but copy operations (i.e. restoring the background) are always slower than the Blitter if the CPU is also involved. This is due to the fact the CPU has overhead in reading the instructions (and reading/decoding additional word(s) for the address to use), which the Blitter does not have. Since both the CPU and the Blitter access memory 16 bits at a time and the CPU can’t use all DMA slots while the Blitter can.

Thanks for the info, I appreciate it. It's been so many years since I coded on A500, so it's quite possible the speed up was for clearing only.@@DutchRetroGuy

It’s a fair question. Honestly, I don’t know. If you’ve looked at my videos you’ll probably have noted that my upload schedule has changed pretty drastically over the years. There’s also the inescapable fact that there’s far less viewers for my gaming content than my programming content. I may or may not be doing more episodes of this and Dune 2. I can’t guarantee anything.

Oh well it was fun to watch anyway, and a shame that these aren’t more popular but I guess that’s what happens to a lot of older games and systems, the audience fades. Thanks for uploading these.

Figuring out these kind of techniques on your own is one of the great things about the old platforms. Great stuff that you made something like this yourself back in the day. As for not finishing, you should see my AmigaDev directory on my PC - so many unfinished or half baked ideas 😆

I think I first heard of the term when I saw the readme for one of the 3D Copper demo’s I saw back around 2000. It’s an interesting effect for sure.

Yeah, it is a great game! I still remember reading the manual cover to cover multiple times before getting it home - I bought the game on holiday and had to wait a week to play it. Was hard to wait so long, but it was so worth it 🙂

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

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.

Thanks :)

I started write mario kart in javascript. I need solve problem, how make procedure of drive opponents kart. Today i will go to bookstore. Maybe i will find a clue..

Thanks 😎

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.

No that's my code bugging out and creating odd effects ;)

Thanks!

That’s an interesting question because it really depends on how you look at it. When it comes to speedy 3D graphics for instance, you’re looking at a much earlier date than for 2D stuff. Considering only 2D for a moment, VGA was released in 1987 and could outdo the Amiga in terms of static images immediately (it may not have had HAM mode, but it did have many more shades of each colour to choose from). When looking at moving GFX (i.e. action games & demos), the Amiga held its own for longer. When I look at it myself, I’d argue you started seeing more impressive action games around 1990 and more impressive demos a little while after that (1993 perhaps?) - though there are always exceptions. I’m less aware of the PC demo scene so it may be that there’s better stuff from the early periods than I realise though! Looking at the very best (say a game like Lionheart), that wasn’t easy to beat - though I’d say a Super VGA enabled PC probably can outdo it, even though I’ve not seen examples of PC games like that from the era. So, it’s complicated 😅

@@DutchRetroGuy I was referring to 2d. I realize the amiga lacks 3d.

Hmm, didn’t know there were fan made maps… might have to check that out!

i think i said something wrong, i didnt mean patched by modifying the original game files. but instead, they added a memory resident program to read the game's ongoing data in the memory, so you run two programs, you can see it all over from youtube, i was able to play EoB finally few days ago after decades, EoB was the closest game to the game lands of lore 1. 90 degree fixed rotation RPGs, they are rare and unique

In the context of the Commodore Amiga, AGA stands for Advanced Graphics Architecture, which is the upgraded chip set Commodore used in the Amiga 1200, Amiga 4000 and CD32. See here for more information: en.m.wikipedia.org/wiki/Amiga_Advanced_Graphics_Architecture

The scan lines are just how I set up the emulator because I liked how they looked 😅

As far as I know, no Amiga game has ever been released on cartridge. Would've been interesting to see for sure!

There was some speculation when the inclusion of the PCMCIA slot for the A600 and A1200 was made public that this would allow cartridge games to be made, but I think such hopes were quickly doused by developers and/or Commodore because they would be too expensive (I don't know what the access speed would have been like either). There was never any other means of cartridge games appearing on the Amiga.

I remember an interview (CU Amiga I think) where it was discussed that cartridge was probably the future of Amiga; but that was actually still in the 'A500' time period. I think it was an interview with Readysoft about their Laserdisc conversions. @@danyoutube7491

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?

@@bramblemat1185 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?

@@bramblemat1185 so far, no games. Might try for one at one point, but we'll see :)

Thanks! Agony is indeed a graphical masterpiece, one of the best looking games on the Amiga 👍

Yeah, these things were a lot harder when you didn't have all the modern tools we have today!

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.

Thanks!

Yeah, the SNES and Genesis/Mega Drive had some definite advantages over the Amiga when it came to Sprite and Layer hardware :)

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

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