Really good idea :) Don't know why I never see your channel recommended to me as I google search copper/blitter stuff all the time. A 4 colour parallax layer would be fine for a conversion of Salamander (Konami 1986) as the background parallax works fine with 4 colours. About a year ago I was wondering what could you do with the heavily improved AGA sprites and one idea was to do SNES resolution (256 pixels wide) triple parallax in conjunction with AGA dual playfield with minimum 48 colours per scanline and I would just modify the sprite data pointer for the 4 static sprites. I never tried redrawing one 16 colour 64 pixel wide AGA sprite using your method because I am still learning about the advanced copper stuff. It was for a test engine for Thunderforce 3 from the Megadrive for Amiga 1200. I think my first project for the copper actually writing code will be some sort of picture viewer that does automatic highly realistic water ripple effect at a set height on screen but will come back to your idea to re-use a sprite to make the conversion of Thunderforce 3 easier as the Megadrive is the same horizontal resolution as Amiga and not SNES.
There's several ways to implement re-using sprites on the screen. For action heavy games such as Thunderforce my particular implementation might not be the best idea because it's quite resource intensive. However, if you're targetting AGA you might be interested to know the hardware actually directly supports a form of horizontal Sprite re-use. You can set up the sprites such that they automatically repeat 256 pixels to the right with just one register write. This can be very useful for backgrounds, albeit with either a 4 colour or 256 pixel/16 colour limitation.
@@DutchRetroGuy I was hoping only re-using one sprite to make up the extra 64 pixels from 256 to 320 pixels wide would be OK and still leave enough DMA time for a relatively normal game engine but I am no Amiga coder really, more of an engineer finding interesting uses for all the goodies inside the custom chips. You could use 3+transparent colour sprites for a simple AGA port of Salamander the Konami shmup, you get 8 64 pixel wide sprites and that leaves you 3 spare for score/status ovelay so no need to re-use sprites just update the sprite pointers for all 5 every other second 16 times (the parallax 3 colour backround is just a geometric grig of 16x16 pixel tiles). People didn't really use the AGA sprites, shame because pairing two sets of 16 colour AGA sprites gives you a perfect and superfast SF2 beat em up style game engine for SNES/Megadrive quality fighters without using anything like the DMA it would take to do that via the blitter...plus a lot simpler to code.
@@madcommodore you can re-use a single Sprite, but you can't change the contents. The chipset only allows reloading of 16 pixel Sprites :( By the way, AGA Sprites are (IMHO) the single most underrated feature of AGA. When used well, they're a game changer.
@@DutchRetroGuy Ah well then I guess it has to be a 256x256 pixel screen if you want 16-64 colour parallax background using the AGA largest width sprites. Even with only 4 large AGA 16 colour sprites per scanline you can do some pretty interesting games I agree, but I don't think any games were that amazing on A1200, most were worse than Turrican 3 I played on my old Amiga :)
@@madcommodore yeah, AGA was sadly rather underutilized. The A1200/CD32 were simply too little, too late. And I'm saying that while the A1200 is my favourite Amiga by far (and one I think is routinely underrated).
Excellent video & info! I'm also curious did anyone use the method you discovered in a demo or a game. New things have come to light! Perhaps we should start making games for Amiga again. (been a while)
Thanks! I don't personally know of any games that use this method. It does seem a bit unlikely though, given how much of the Amiga's resources are used just to display this. As for making games... A number of people actually are actually making games for the Amiga again these days, some of them are quite good ;)
Well, take comfort in the knowledge that as an Amiga coder I can only look in envy at the C64's tile based backgrounds, just how few cycles interrupts take and how much more generally useful the C64 Sprite hardware is compared to the Amiga one :) Both are awesome machines regardless of their limits!
Just discovered your videos - very interesting, thank you! I got an Amiga in 1986 and am still a fan. I'd like to put a couple of questions to you, if you don't mind... This is in relation to the Amiga game "Myth - History in the Making". I like the game a lot - except for one thing: the scrolling. It falls just short of being smooth and that spoils the game for me. Do you think it would be possible to achieve smoother scrolling on that game - without having to compromise the rest of the game? I ask this because there exist other games that place similar demands on the Amiga that have perfectly smooth scrolling. e.g. First Samurai, Risky Woods, Rubicon, Robocop 2 etc. A secondary question: Two of the levels take place in underground caves (the 1st level and the 3d). I always felt they were crying out for a parallax layer for the cave wall in the background - which uses only four colours. Do you think the parallax method you describe in this video could achieve that - and still maintain a smooth frame rate? Thanks in advance.
Hi, thanks for your comment and question. I've tried to answer it, but it ended up a wall of text. Sorry! Myth is a 25PFS game, it runs at half frame rate. Looking at the game, I see there's a ton of CPU use going on, for what (on the surface) seems to be a simple game. On the other hand, hardware scrolling is actually being used (at a variable speed, but updating only once every other frame) and the game smartly sets up the screen to lower DMA use during the top panel. It uses the Blitter, but no hardware sprites seem to be used at all. So, can this be done better? Well, the issue is that I don't know what the CPU use is all about. It could be that Myth is deceptive: it seems simpler than it is, there's good reasons to use so much CPU. It could also be that the CPU use (and/or Blitter use, which also seems a touch on the high end for what is actually on screen) is just not done very efficiently. If it's the former, smoothing out scrolling is unlikely: the game uses about a frame and half of CPU per screen update (so, it's bound to run at 25FPS or lower). If it's the latter, then it could possibly be done if a coder was determined enough and decided to rewrite the entire core game loop. There is at least one clear optimisation that can be made: using hardware sprites as part of the game instead of using just the Blitter. That should speed up the game considerably. But unless the high CPU use is addressed somehow, this by itself won't be enough. As for the Sprite Layer as I present it, I'm sad to say it won't work. My version of this effect uses a significant amount of system resources, adding it to existing games is very unlikely to not affect their frame rate negatively. There is a less resource intensive version of this effect (i.e. a Sprite Layer with a repeating pattern), which was used by many games and that might work. But still, even that costs a fair share of resources so wouldn't likely work in the case of Myth.
@@DutchRetroGuy Thank you very much for taking the time to reply. I have been wondering about this question for a long time and you've really put me out of my misery! What you've said is extremely informative (I have no problem with a wall of text, by the way!). My problem is that I'm not very familiar with programming, so I'm comparing and contrasting from a layman's perspective. A couple of notes: (1) I can see that there is a lot going on in some levels of "Myth" - especially the first level: lots of largish, animated characters moving around, a fire effect, background torches, multi-directional scrolling, so it's understandable that a high frame rate would be difficult to achieve. (2) Normally, I find that games that are said to be running at 25FPS move perfectly smoothly to my eye - and a solid 25FPS is what I'd like to see in "Myth". But it appears to me that is running at a slightly lower rate - to my eyes it looks to be about 20FPS, which is fine - but not quite at the target, if you get me. (2) The other thing that puzzles me is that even on levels that are making far less demands in terms of graphics and animation, the scrolling does not improve at all. (3) None of this is improved in the AGA version. You would think it would have been simple enough. (4) The high demands on the Amiga that I mentioned in Point (1) are also being made in "First Samurai", i.e. lots of largish, animated characters on screen, fire effects, torches (plus other effects, waterfalls, particles etc), multi-directional scrolling - and yet the whole thing moves as smoothly as you could wish. Anyway, I'll leave it there. Apologies for writing my own wall of text! Thank you again - I greatly appreciate your response.
@@Midwinter2 no problem, I don't mind theorycrafting Amiga stuff :) Anyway, I think the reason the scrolling seems odd isn't the refresh rate (which does appear to be 25FPS to me). It's rather that it doesn't scroll at one speed - Myth speeds up and slows down scrolling, which can give the impression of lower frame rates. In other words, the slow/odd scrolling seems to be more by artistic design than limitations of the system. Well, that's my take anyway. I could be wrong, I didn't disassemble the whole games or anything ;)
@@DutchRetroGuy I just checked: Myth framerate is 16.66fps, but when there are more than 5 animated objects on screen it drops to 12.5fps... That's why you feel the scrolling is not smooth. IMHO it's not well programmed... Myth is a 16 colors game, with a game area of 320x150 pixels but it uses from 3 to 4 frames to update the screen! I see no reason why it uses so much time to update the screen unless it uses just the CPU, without Blitter, like your typical Atari ST conversion. If it uses the Blitter, then this could mean that the CPU code that manages the game logic is very inefficient... This type of game should run at least at a steady 25fps on the Amiga OCS. There are plenty of nice platform games with multi-directional 50fps smooth scrolling on the Amiga (Turrican series, BC Kid, Leander, Super Frog, Zool, Robocod, Lionheart, Bubba'n'Stix, Soccer Kid, etc.) and some of them use some clever parallax effects too...
Amazing!! that's really cool effect. May I suggest, there got to be a "only HW sprites compo" for OCS Amigas and invite the people to make magic? Like the compo we got for C64.
Thanks for the kind comment! As for game/demo compo's, I'm sadly not going to be running any. But perhaps someone else sees this and likes to give it a shot!
Wait, so you're having the Copper load new data into the sprite slot just after it's drawn, all within one scanline? Effectively, horizontal sprite multiplexing? DAMN, SON! I've heard of sprites being muxed vertically but not horizontally.
Yeah, that's exactly what it is ;) Though to be fair here, all I've added is the changing image data, sprites repeating across the background to form a pattern has been done before.
Interesting video. I've always found Amiga sprites to be a little... underwhelming, but this shows what can be done. Would you please cover AGA sprites that are allegedly 64 pixels wide?
There's no allegedly about it, AGA sprites can be either 16, 32 or 64 pixels wide and can be either low-res, hi-res or super-hires. I may do a video on AGA sprites later down the line though, as there are some interesting things to be said about them :) By the way, I have the same feeling about Amiga sprites. They're very close to being brilliant, but also quite far away. The built-in hardware multiplexing is great, as is the ability to have them be any height. But the limited number of them and how thin OCS sprites are is quite underwhelming.
@@DutchRetroGuy The reason it confuses me is I've had the A1200 back in the day, and I don't remember this being a thing. When ppl said that AGA sprites are 64 pixels wide, I just assumed they're the same width physically, but in hires / superhires. Must be some downside to it, so looking fwd to that video. Cheers
@@JohnnyReb1976 actually, 64 pixel wide sprites were used in a number of AGA games (For example: Aladdin, The Lion King both use them). But you are correct there is a drawback. The AGA chipset allows you to have more Blitter cycles (meaning the Blitter seems to run faster). However, this cannot be easily mixed with displaying sprites if you also want to scroll horizontally. So many games on AGA didn't use sprites.
Nice video! You could try to show more colors on screen splitting the image into multiple horizontal slices, with palette switches during vertical scan. For example, you could modify 8 times during vert scan to allow 512 colors on screen without artifacts as HAM has. That do not require complex operations for moving parts. This is also the so called EHB Sliced mode. Course you must race the beam with copper lists.
Thanks! I agree, using the Copper to add additional colours would be possible. However, for this series (ok, it only has one part but that should change eventually :P), I try to show just one effect at a time. This keeps the example source code easier to read and keeps the written/spoken explanation focussed on one subject. Maybe I'll do a video on Copper rainbow effects one day though ;)
Dual Playfield uses 6 bitplanes and so takes 50% more DMA cycles for bitplanes than 4 bitplane mode (as used here) does. Sprite multiplexing is still possible, but the free form trick I've used can only work with 4 bitplanes or less). I'm not too sure many games used both a multiplexing Sprite layer and Dual Playfield to be honest, the extra layer would be nice, but generally the loss of colours in Dual Playfield means developers used the Sprites to add a splash of extra colour instead of an extra layer. Should be possible though :)
@@DutchRetroGuy My idea is to use 4 multiplexed sprites as background layer, back playfield as foreground layer, front playfield as exclusive enemy bobs layer, and finally remaining 4 sprites for player character. So the result should be a parallax scrolled screen with 3 colors background, 7 colors foreground, 7 colors for enemies (plus eventually bullets and explosions), 7 colors for player character. If it remains some dma, it could be possible to use copper for increasing colors in background and foreground layers
@@ProfenixStudio that should work, yeah. The one thing to keep in mind with DPL and Sprite multiplexing is that you only get 1 Copper move for every 16 pixels during bitplane DMA (which is why the free form layer can’t work as it needs two). Other than that it’s no different from any other Sprite layer.
@@ProfenixStudio I think you’re right, yes. I do think Leander limits the height of the Sprite layer in the background, though. Not sure if that is for performance or for artistic reasons, however.
On your WWW I have sent you a large explanation how you can improve this effect using less DMA, but i have no response. Can you check it? BTW. Great work!
I have seen that and send you an e-mail back in which I explained that I'd answer it when I got the time. Sorry for the delay. So let's answer it here :) Yes, you are correct that you can improve the DMA load of the effect by about 17% by using the sprite channels differently. Which is a good improvement, but still makes it far too 'heavy' for use in most games as you gain only about 2700 DMA cycles by doing so (which is about 3,8% of the Amiga's total per frame). I hadn't thought of this optimisation when I made this, but it's cool to hear other people thinking about this as well :) You also ask about needing many Copperlists. The effect as I've made it does not use 8 Copperlists, but rather four. The trick is to not store eight copies, but rather build up an entirely new Copperlist (plus a copy of this new one) over a 32 frame period. During these 32 frames you show the two you already have and update only the sprite's positions. Using 8 Copperlists would not improve performance, but rather make it worse as it would quadruple the number of bytes you need to push per frame for the new sprite data. The rest of your e-mail concerns the OCS Rygar port and I'm sorry to say it, but I don't really think optimisation was the problem here at all. Rather a too enthusiastic team that forgot to take into account the system's overall limits in terms of how many bobs it can draw per frame. If you merely show a 32 colour display without sprite layer, you're already limited to about 15 bobs @32x32 (this scales based on size so 30 bobs of 32x16, etc) per frame. Add in a repeating sprite background and you lose 3 or 4 of them. Add in game logic and you lose a few more. But the Rygar port was aimed at 64 colours (EHB), which is even slower, so you lose even more bobs. It was an uphill struggle to begin with. I think the problem was wanting too much - a port using Dual Playfield and using sprites for the main character & weapon would've been much more doable - even though it would obviously not look as nice. Note: the above is no dig against the coder or artists involved in any way, they are certainly capable enough and I think what we got for OCS was pretty good, all things considered! I certainly enjoyed seeing it come together and it was part of the inspiration to do this effect :)
Do you think a near accurate port of the megadrive version or Strider is possible on the A500. Same size sprites and parallax with reduced colour but still running at 50hz?
I took a look at the Strider longplay for the Mega Drive. I'm reasonably confident you could get a close to perfect port @50Hz on the A1200. On the A500 however, I honestly don't think you'd manage at 50Hz. Do note I just eye balled it, so perhaps someone else might think differently.
You could definitely do better than the US Gold version. If you look at Leander, that's about the closest thing I can think of. That's from a masterful coder. There'd still be some compromises beyond colours, like screen movement during the massive boss fights... But it could be more than six frames a second and with teeny tiny sprites! AGA could be close to arcade perfect. But, while I love good arcade ports, we live in an era of emulation so why not just play those. I'd rather people make new fan games or original IPs based inspired by those old favourites. Then you can play to the Amiga's strengths graphics wise while borrowing gameplay elements from the classics
it's a pity you didn't create a "demoscene-demo" with this first and then made this video. now when you have explained it, you don't need to do a demo :)
Ah, I'm afraid the limits of my artistic talent have been fully reached with the background layer you see there. I'll stick with "informational" content about the Amiga for now ;)
@@DutchRetroGuy well, tech-demos are the coolest thing on amiga, especially when you find new ways to do it! Join a demogroup, or cooperate with one, and get others to do the graphics and music for you! I surely would appreciate new ideas like this in demos. :)
i think is good. but dma time is bad because this is why you are basically running 6 bitplanes total. 4 for main screen and 2 for sprite layer. plus you are manually reload sprites with new data. thats more dma taken.... so 3 colors for back ground. more with simple copper changes. but none the less. 6 bit planes of dma time plus cpu,blitter,and copper to achive effect. so over head is greater than 6 bitplane dualplayfield. im not saying its bad. i still like it. just is dma hungry. so it has to suit the task it used for.... . that's what different modes are for. all depends on type of game mode.
easyerthanyouthink Indeed, this effect uses an awful lot of DMA time, I even acknowledge this in the video. It’s more of a ‘how far can I push Sprites’ experiment than a super useful new screen mode. That said, in some cases it can probably be useful. You could limit the effect size for instance, or use it when there is less need for heavy Blitter usage. In essence it’s just another trick to consider in the large toolbox of trick for the Amiga ;)
totally. sorry i forgot you said that. yes, your video you state it is just a fun thing you did and had not seen it in any game. it good be but i have not seen it either. this video just got me excited. the humble sprites of the amiga were total rubbish relative to the machine. but the best coders out there really new how to do awesome things with them. eg you just did this. im pretty sure codetapper did very similar to this. and im sure some others may have. but like you said., i dont think there is any game with it. i tried multiplex 1 sprite 10 times in the same scan line. it worked. but a cant remeber how many bitplane i was using at the time. amd tried multiplex chains sprites 16color with new data in second set and it worked sort of then sprite corruption crept in and rand out of dma time. cant remember how wide but it didnt do what i wanted.
Actually you can see at 4:49 how many DMA cycles are taken by copper (yellow), bitplanes (blue) and sprites(red). As you can see not so many are left for Blitter(green) not to mention CPU (grey). However you still have so many unused DMA cycles (black) left so plenty area for optimisation ;-) (joke)
@@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.
god bless winuae dma debugger , what a god send ! love it amiga sprite multiplexing, I have play with that a lot. yeah soon as you kinda push the limits it gets a bit tricky, then for effort for time has to be balanced yes you do get performance gains but at the sacrifice of complexity and insanity. check out codetappers site. all about spite effects, but you probably have already. he showed me a shadow of the beast style type thing arcade parlax scroller he did and it was totaly awesome. dual playfield is good for some things but 4bitplanes and sprites better for more colors and less DMA bandwidth ! it all realtive to the game you want to do and the effect! copper,blitter,sprites, totaly love it. nice video
Nice to hear you liked the video. You are correct, the big plus of the Amiga is the many different ways you can go about ways. It's a great system for those who like to experiment and think out of the box!
Nice video !!! Thx for sharing source as well :)
You're welcome!
Impressive routine. Seeing 68k ASM took me back to my teens & 20's! Thanks :) I am looking forward to reading the source code.
You're welcome, glad you enjoyed it :)
I totally dig your videos and how you present it. Thank you!
Thanks!
Thanks, very interesting and nicely illustrated.
Thanks!
Really good idea :) Don't know why I never see your channel recommended to me as I google search copper/blitter stuff all the time. A 4 colour parallax layer would be fine for a conversion of Salamander (Konami 1986) as the background parallax works fine with 4 colours. About a year ago I was wondering what could you do with the heavily improved AGA sprites and one idea was to do SNES resolution (256 pixels wide) triple parallax in conjunction with AGA dual playfield with minimum 48 colours per scanline and I would just modify the sprite data pointer for the 4 static sprites. I never tried redrawing one 16 colour 64 pixel wide AGA sprite using your method because I am still learning about the advanced copper stuff. It was for a test engine for Thunderforce 3 from the Megadrive for Amiga 1200. I think my first project for the copper actually writing code will be some sort of picture viewer that does automatic highly realistic water ripple effect at a set height on screen but will come back to your idea to re-use a sprite to make the conversion of Thunderforce 3 easier as the Megadrive is the same horizontal resolution as Amiga and not SNES.
There's several ways to implement re-using sprites on the screen. For action heavy games such as Thunderforce my particular implementation might not be the best idea because it's quite resource intensive.
However, if you're targetting AGA you might be interested to know the hardware actually directly supports a form of horizontal Sprite re-use. You can set up the sprites such that they automatically repeat 256 pixels to the right with just one register write. This can be very useful for backgrounds, albeit with either a 4 colour or 256 pixel/16 colour limitation.
@@DutchRetroGuy I was hoping only re-using one sprite to make up the extra 64 pixels from 256 to 320 pixels wide would be OK and still leave enough DMA time for a relatively normal game engine but I am no Amiga coder really, more of an engineer finding interesting uses for all the goodies inside the custom chips. You could use 3+transparent colour sprites for a simple AGA port of Salamander the Konami shmup, you get 8 64 pixel wide sprites and that leaves you 3 spare for score/status ovelay so no need to re-use sprites just update the sprite pointers for all 5 every other second 16 times (the parallax 3 colour backround is just a geometric grig of 16x16 pixel tiles). People didn't really use the AGA sprites, shame because pairing two sets of 16 colour AGA sprites gives you a perfect and superfast SF2 beat em up style game engine for SNES/Megadrive quality fighters without using anything like the DMA it would take to do that via the blitter...plus a lot simpler to code.
@@madcommodore you can re-use a single Sprite, but you can't change the contents. The chipset only allows reloading of 16 pixel Sprites :(
By the way, AGA Sprites are (IMHO) the single most underrated feature of AGA. When used well, they're a game changer.
@@DutchRetroGuy Ah well then I guess it has to be a 256x256 pixel screen if you want 16-64 colour parallax background using the AGA largest width sprites.
Even with only 4 large AGA 16 colour sprites per scanline you can do some pretty interesting games I agree, but I don't think any games were that amazing on A1200, most were worse than Turrican 3 I played on my old Amiga :)
@@madcommodore yeah, AGA was sadly rather underutilized. The A1200/CD32 were simply too little, too late.
And I'm saying that while the A1200 is my favourite Amiga by far (and one I think is routinely underrated).
Excellent video & info! I'm also curious did anyone use the method you discovered in a demo or a game. New things have come to light! Perhaps we should start making games for Amiga again. (been a while)
Thanks!
I don't personally know of any games that use this method. It does seem a bit unlikely though, given how much of the Amiga's resources are used just to display this.
As for making games... A number of people actually are actually making games for the Amiga again these days, some of them are quite good ;)
Very interesting, thanks.
As a C64 coder I can only look in envy at how much you're able to do in a rasterline on Amiga.
Well, take comfort in the knowledge that as an Amiga coder I can only look in envy at the C64's tile based backgrounds, just how few cycles interrupts take and how much more generally useful the C64 Sprite hardware is compared to the Amiga one :)
Both are awesome machines regardless of their limits!
Just discovered your videos - very interesting, thank you! I got an Amiga in 1986 and am still a fan. I'd like to put a couple of questions to you, if you don't mind...
This is in relation to the Amiga game "Myth - History in the Making". I like the game a lot - except for one thing: the scrolling. It falls just short of being smooth and that spoils the game for me. Do you think it would be possible to achieve smoother scrolling on that game - without having to compromise the rest of the game? I ask this because there exist other games that place similar demands on the Amiga that have perfectly smooth scrolling. e.g. First Samurai, Risky Woods, Rubicon, Robocop 2 etc.
A secondary question: Two of the levels take place in underground caves (the 1st level and the 3d). I always felt they were crying out for a parallax layer for the cave wall in the background - which uses only four colours. Do you think the parallax method you describe in this video could achieve that - and still maintain a smooth frame rate? Thanks in advance.
Hi, thanks for your comment and question. I've tried to answer it, but it ended up a wall of text.
Sorry!
Myth is a 25PFS game, it runs at half frame rate. Looking at the game, I see there's a ton of CPU use going on, for what (on the surface) seems to be a simple game. On the other hand, hardware scrolling is actually being used (at a variable speed, but updating only once every other frame) and the game smartly sets up the screen to lower DMA use during the top panel. It uses the Blitter, but no hardware sprites seem to be used at all.
So, can this be done better? Well, the issue is that I don't know what the CPU use is all about. It could be that Myth is deceptive: it seems simpler than it is, there's good reasons to use so much CPU. It could also be that the CPU use (and/or Blitter use, which also seems a touch on the high end for what is actually on screen) is just not done very efficiently.
If it's the former, smoothing out scrolling is unlikely: the game uses about a frame and half of CPU per screen update (so, it's bound to run at 25FPS or lower). If it's the latter, then it could possibly be done if a coder was determined enough and decided to rewrite the entire core game loop. There is at least one clear optimisation that can be made: using hardware sprites as part of the game instead of using just the Blitter. That should speed up the game considerably. But unless the high CPU use is addressed somehow, this by itself won't be enough.
As for the Sprite Layer as I present it, I'm sad to say it won't work. My version of this effect uses a significant amount of system resources, adding it to existing games is very unlikely to not affect their frame rate negatively. There is a less resource intensive version of this effect (i.e. a Sprite Layer with a repeating pattern), which was used by many games and that might work. But still, even that costs a fair share of resources so wouldn't likely work in the case of Myth.
@@DutchRetroGuy Thank you very much for taking the time to reply. I have been wondering about this question for a long time and you've really put me out of my misery!
What you've said is extremely informative (I have no problem with a wall of text, by the way!). My problem is that I'm not very familiar with programming, so I'm comparing and contrasting from a layman's perspective. A couple of notes: (1) I can see that there is a lot going on in some levels of "Myth" - especially the first level: lots of largish, animated characters moving around, a fire effect, background torches, multi-directional scrolling, so it's understandable that a high frame rate would be difficult to achieve. (2) Normally, I find that games that are said to be running at 25FPS move perfectly smoothly to my eye - and a solid 25FPS is what I'd like to see in "Myth". But it appears to me that is running at a slightly lower rate - to my eyes it looks to be about 20FPS, which is fine - but not quite at the target, if you get me. (2) The other thing that puzzles me is that even on levels that are making far less demands in terms of graphics and animation, the scrolling does not improve at all. (3) None of this is improved in the AGA version. You would think it would have been simple enough. (4) The high demands on the Amiga that I mentioned in Point (1) are also being made in "First Samurai", i.e. lots of largish, animated characters on screen, fire effects, torches (plus other effects, waterfalls, particles etc), multi-directional scrolling - and yet the whole thing moves as smoothly as you could wish.
Anyway, I'll leave it there. Apologies for writing my own wall of text! Thank you again - I greatly appreciate your response.
@@Midwinter2 no problem, I don't mind theorycrafting Amiga stuff :)
Anyway, I think the reason the scrolling seems odd isn't the refresh rate (which does appear to be 25FPS to me). It's rather that it doesn't scroll at one speed - Myth speeds up and slows down scrolling, which can give the impression of lower frame rates.
In other words, the slow/odd scrolling seems to be more by artistic design than limitations of the system.
Well, that's my take anyway. I could be wrong, I didn't disassemble the whole games or anything ;)
@@DutchRetroGuy Interesting. Thanks again!
@@DutchRetroGuy I just checked: Myth framerate is 16.66fps, but when there are more than 5 animated objects on screen it drops to 12.5fps... That's why you feel the scrolling is not smooth. IMHO it's not well programmed... Myth is a 16 colors game, with a game area of 320x150 pixels but it uses from 3 to 4 frames to update the screen! I see no reason why it uses so much time to update the screen unless it uses just the CPU, without Blitter, like your typical Atari ST conversion. If it uses the Blitter, then this could mean that the CPU code that manages the game logic is very inefficient... This type of game should run at least at a steady 25fps on the Amiga OCS. There are plenty of nice platform games with multi-directional 50fps smooth scrolling on the Amiga (Turrican series, BC Kid, Leander, Super Frog, Zool, Robocod, Lionheart, Bubba'n'Stix, Soccer Kid, etc.) and some of them use some clever parallax effects too...
Amazing!! that's really cool effect. May I suggest, there got to be a "only HW sprites compo" for OCS Amigas and invite the people to make magic? Like the compo we got for C64.
Thanks for the kind comment!
As for game/demo compo's, I'm sadly not going to be running any. But perhaps someone else sees this and likes to give it a shot!
Wait, so you're having the Copper load new data into the sprite slot just after it's drawn, all within one scanline? Effectively, horizontal sprite multiplexing? DAMN, SON! I've heard of sprites being muxed vertically but not horizontally.
Yeah, that's exactly what it is ;)
Though to be fair here, all I've added is the changing image data, sprites repeating across the background to form a pattern has been done before.
Interesting video. I've always found Amiga sprites to be a little... underwhelming, but this shows what can be done. Would you please cover AGA sprites that are allegedly 64 pixels wide?
There's no allegedly about it, AGA sprites can be either 16, 32 or 64 pixels wide and can be either low-res, hi-res or super-hires.
I may do a video on AGA sprites later down the line though, as there are some interesting things to be said about them :)
By the way, I have the same feeling about Amiga sprites. They're very close to being brilliant, but also quite far away. The built-in hardware multiplexing is great, as is the ability to have them be any height. But the limited number of them and how thin OCS sprites are is quite underwhelming.
@@DutchRetroGuy The reason it confuses me is I've had the A1200 back in the day, and I don't remember this being a thing. When ppl said that AGA sprites are 64 pixels wide, I just assumed they're the same width physically, but in hires / superhires. Must be some downside to it, so looking fwd to that video. Cheers
@@JohnnyReb1976 actually, 64 pixel wide sprites were used in a number of AGA games (For example: Aladdin, The Lion King both use them).
But you are correct there is a drawback. The AGA chipset allows you to have more Blitter cycles (meaning the Blitter seems to run faster). However, this cannot be easily mixed with displaying sprites if you also want to scroll horizontally. So many games on AGA didn't use sprites.
Nice video! You could try to show more colors on screen splitting the image into multiple horizontal slices, with palette switches during vertical scan. For example, you could modify 8 times during vert scan to allow 512 colors on screen without artifacts as HAM has. That do not require complex operations for moving parts. This is also the so called EHB Sliced mode. Course you must race the beam with copper lists.
Thanks!
I agree, using the Copper to add additional colours would be possible. However, for this series (ok, it only has one part but that should change eventually :P), I try to show just one effect at a time. This keeps the example source code easier to read and keeps the written/spoken explanation focussed on one subject.
Maybe I'll do a video on Copper rainbow effects one day though ;)
Thanks to you for your contributions and retro LABs.
looking great :)
Thanks!
WooW!
How many dma cycles takes dual playfield? It is possible and reasonable using it with sprite multiplexing (with and without Free form trick)?
Dual Playfield uses 6 bitplanes and so takes 50% more DMA cycles for bitplanes than 4 bitplane mode (as used here) does. Sprite multiplexing is still possible, but the free form trick I've used can only work with 4 bitplanes or less).
I'm not too sure many games used both a multiplexing Sprite layer and Dual Playfield to be honest, the extra layer would be nice, but generally the loss of colours in Dual Playfield means developers used the Sprites to add a splash of extra colour instead of an extra layer.
Should be possible though :)
@@DutchRetroGuy My idea is to use 4 multiplexed sprites as background layer, back playfield as foreground layer, front playfield as exclusive enemy bobs layer, and finally remaining 4 sprites for player character. So the result should be a parallax scrolled screen with 3 colors background, 7 colors foreground, 7 colors for enemies (plus eventually bullets and explosions), 7 colors for player character. If it remains some dma, it could be possible to use copper for increasing colors in background and foreground layers
@@ProfenixStudio that should work, yeah. The one thing to keep in mind with DPL and Sprite multiplexing is that you only get 1 Copper move for every 16 pixels during bitplane DMA (which is why the free form layer can’t work as it needs two). Other than that it’s no different from any other Sprite layer.
@@DutchRetroGuy I think Leander game does something similar. Right?
@@ProfenixStudio I think you’re right, yes. I do think Leander limits the height of the Sprite layer in the background, though. Not sure if that is for performance or for artistic reasons, however.
On your WWW I have sent you a large explanation how you can improve this effect using less DMA, but i have no response. Can you check it? BTW. Great work!
I have seen that and send you an e-mail back in which I explained that I'd answer it when I got the time. Sorry for the delay.
So let's answer it here :)
Yes, you are correct that you can improve the DMA load of the effect by about 17% by using the sprite channels differently. Which is a good improvement, but still makes it far too 'heavy' for use in most games as you gain only about 2700 DMA cycles by doing so (which is about 3,8% of the Amiga's total per frame).
I hadn't thought of this optimisation when I made this, but it's cool to hear other people thinking about this as well :)
You also ask about needing many Copperlists. The effect as I've made it does not use 8 Copperlists, but rather four. The trick is to not store eight copies, but rather build up an entirely new Copperlist (plus a copy of this new one) over a 32 frame period. During these 32 frames you show the two you already have and update only the sprite's positions.
Using 8 Copperlists would not improve performance, but rather make it worse as it would quadruple the number of bytes you need to push per frame for the new sprite data.
The rest of your e-mail concerns the OCS Rygar port and I'm sorry to say it, but I don't really think optimisation was the problem here at all. Rather a too enthusiastic team that forgot to take into account the system's overall limits in terms of how many bobs it can draw per frame.
If you merely show a 32 colour display without sprite layer, you're already limited to about 15 bobs @32x32 (this scales based on size so 30 bobs of 32x16, etc) per frame. Add in a repeating sprite background and you lose 3 or 4 of them. Add in game logic and you lose a few more.
But the Rygar port was aimed at 64 colours (EHB), which is even slower, so you lose even more bobs. It was an uphill struggle to begin with. I think the problem was wanting too much - a port using Dual Playfield and using sprites for the main character & weapon would've been much more doable - even though it would obviously not look as nice.
Note: the above is no dig against the coder or artists involved in any way, they are certainly capable enough and I think what we got for OCS was pretty good, all things considered! I certainly enjoyed seeing it come together and it was part of the inspiration to do this effect :)
@@DutchRetroGuy ok i have sent you a bigger question regarding Rygar
Do you think a near accurate port of the megadrive version or Strider is possible on the A500. Same size sprites and parallax with reduced colour but still running at 50hz?
I took a look at the Strider longplay for the Mega Drive. I'm reasonably confident you could get a close to perfect port @50Hz on the A1200. On the A500 however, I honestly don't think you'd manage at 50Hz.
Do note I just eye balled it, so perhaps someone else might think differently.
You could definitely do better than the US Gold version. If you look at Leander, that's about the closest thing I can think of. That's from a masterful coder. There'd still be some compromises beyond colours, like screen movement during the massive boss fights... But it could be more than six frames a second and with teeny tiny sprites!
AGA could be close to arcade perfect.
But, while I love good arcade ports, we live in an era of emulation so why not just play those.
I'd rather people make new fan games or original IPs based inspired by those old favourites. Then you can play to the Amiga's strengths graphics wise while borrowing gameplay elements from the classics
Geweldig gedaan, ik ga eens even je website bewonderen.
Dankjewel, met een beetje geluk volgt er voor het einde van het jaar een volgend deel :)
Can anybody help me.I'm looking PP hammer tilemaps
it's a pity you didn't create a "demoscene-demo" with this first and then made this video. now when you have explained it, you don't need to do a demo :)
Ah, I'm afraid the limits of my artistic talent have been fully reached with the background layer you see there. I'll stick with "informational" content about the Amiga for now ;)
@@DutchRetroGuy well, tech-demos are the coolest thing on amiga, especially when you find new ways to do it! Join a demogroup, or cooperate with one, and get others to do the graphics and music for you! I surely would appreciate new ideas like this in demos. :)
i think is good. but dma time is bad
because this is why
you are basically running 6 bitplanes total. 4 for main screen and 2 for sprite layer. plus you are manually reload sprites with new data. thats more dma taken....
so 3 colors for back ground. more with simple copper changes.
but none the less. 6 bit planes of dma time plus cpu,blitter,and copper to achive effect.
so over head is greater than 6 bitplane dualplayfield.
im not saying its bad. i still like it. just is dma hungry. so it has to suit the task it used for.... .
that's what different modes are for.
all depends on type of game mode.
easyerthanyouthink Indeed, this effect uses an awful lot of DMA time, I even acknowledge this in the video. It’s more of a ‘how far can I push Sprites’ experiment than a super useful new screen mode. That said, in some cases it can probably be useful. You could limit the effect size for instance, or use it when there is less need for heavy Blitter usage.
In essence it’s just another trick to consider in the large toolbox of trick for the Amiga ;)
totally. sorry i forgot you said that. yes, your video you state it is just a fun thing you did and had not seen it in any game. it good be but i have not seen it either. this video just got me excited. the humble sprites of the amiga were total rubbish relative to the machine. but the best coders out there really new how to do awesome things with them. eg you just did this. im pretty sure codetapper did very similar to this. and im sure some others may have. but like you said., i dont think there is any game with it.
i tried multiplex 1 sprite 10 times in the same scan line.
it worked. but a cant remeber how many bitplane i was using at the time. amd tried multiplex chains sprites 16color with new data in second set and it worked
sort of then sprite corruption crept in and rand out of dma time.
cant remember how wide but it didnt do what i wanted.
Actually you can see at 4:49 how many DMA cycles are taken by copper (yellow), bitplanes (blue) and sprites(red). As you can see not so many are left for Blitter(green) not to mention CPU (grey). However you still have so many unused DMA cycles (black) left so plenty area for optimisation ;-) (joke)
You say Commodore but this is in fact just branding. The Amiga was made by *Ex* Atari employees.
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.
god bless winuae dma debugger , what a god send !
love it amiga sprite multiplexing,
I have play with that a lot. yeah soon as you kinda push the limits it gets a bit tricky, then for effort for time has to be balanced
yes you do get performance gains but at the sacrifice of complexity and insanity.
check out codetappers site. all about spite effects, but you probably have already.
he showed me a shadow of the beast style type thing arcade parlax scroller he did and it was totaly awesome.
dual playfield is good for some things
but
4bitplanes and sprites better for more colors and less DMA bandwidth !
it all realtive to the game you want to do and the effect!
copper,blitter,sprites, totaly love it.
nice video
Nice to hear you liked the video. You are correct, the big plus of the Amiga is the many different ways you can go about ways. It's a great system for those who like to experiment and think out of the box!
Dual playfield still uses less dma than this method. Not to mention it faster to blit it.