Running Games and Apps. |
SAGA Sprites | page 1 2 3 4 5
|
---|
|
---|
| | ![](gfx/user1181.gif) A1200 Coder
Posts 74 07 Sep 2020 13:49
| The SAGA sprites could continue with the tradition of having attached sprites. Two sprites combined gives 256 colors - as I believe that someone will complain anyway that sprites can only have 16 colors. Indeed, in this popular Raiden 2 arcade shooter (1993) the player ship sprite has 32 colors, even though it looks quite simple. Or offer directly an 8/24-bit palette for sprites.
| |
| | ![](gfx/user805.gif) Samuel Crow
Posts 424 07 Sep 2020 16:12
| A1200 coder wrote:
| The SAGA sprites could continue with the tradition of having attached sprites. Two sprites combined gives 256 colors - as I believe that someone will complain anyway that sprites can only have 16 colors. Indeed, in this popular Raiden 2 arcade shooter (1993) the player ship sprite has 32 colors, even though it looks quite simple. Or offer directly an 8/24-bit palette for sprites. |
32 colors is BOB territory but the bullet sprites are a realistic target. Remember the blitter is massively faster than on AGA.
| |
| | ![](gfx/user1181.gif) A1200 Coder
Posts 74 07 Sep 2020 16:38
| Samuel Crow wrote:
|
A1200 coder wrote:
| The SAGA sprites could continue with the tradition of having attached sprites. Two sprites combined gives 256 colors - as I believe that someone will complain anyway that sprites can only have 16 colors. Indeed, in this popular Raiden 2 arcade shooter (1993) the player ship sprite has 32 colors, even though it looks quite simple. Or offer directly an 8/24-bit palette for sprites. |
32 colors is BOB territory but the bullet sprites are a realistic target. Remember the blitter is massively faster than on AGA.
|
Yes, of course much can be done with AMMX, but that means not much will be done with sprites then. Problem is also with truecolor games, sprites cannot be used for anything else than simple bullets and such with just 16 colors each.
| |
| | ![](gfx/user2.gif) Gunnar von Boehn (Apollo Team Member) Posts 6207 07 Sep 2020 16:43
| Of course different people can here have different opinions. I personally recall that all ATARI ST games had in total just 16 colors. This means 16 colors for all sprites and all background together. And also many Amiga games had in total just 16 colors. And other games had in total 32 colors.If you recall this then having 16 own colors per each sprite ... seems actually relative many for me. With SAGA now the Sprites have 16 own palettes each 16 colors. This means you have extra 256 colors just for sprites. If you compare this with successful Arcade machines like PC-Engine or NEOGEO then having 16 colors sprites and 256 extra color for sprites is state-of-the-art.
| |
| | ![](gfx/user1860.gif) Antony Coello
Posts 153 07 Sep 2020 17:54
| Also, remember, you are at the start of the Vampires lifespan. Remember the 1985 Amiga games? Most were not great because programmers did not REALLY know how to push the hardware. Give it time and things can be tweaked, exact timings for palette switch tricks and all the other things that are learnt about a system will come out. On top of that, the actual SAGA HW designers are still around to answer questions or, in extreme cases, can possibly slightly alter the functioning of the HW to streamline any programming holdups.
| |
| | ![](gfx/user1181.gif) A1200 Coder
Posts 74 07 Sep 2020 21:09
| Gunnar von Boehn wrote:
| Of course different people can here have different opinions. I personally recall that all ATARI ST games had in total just 16 colors. This means 16 colors for all sprites and all background together. And also many Amiga games had in total just 16 colors. And other games had in total 32 colors. If you recall this then having 16 own colors per each sprite ... seems actually relative many for me. With SAGA now the Sprites have 16 own palettes each 16 colors. This means you have extra 256 colors just for sprites. If you compare this with successful Arcade machines like PC-Engine or NEOGEO then having 16 colors sprites and 256 extra color for sprites is state-of-the-art.
|
Yes, of course SAGA sprites will win most hardware from the late 80's and early 90's, but was talking about the situation when background has 16-24 bit color. Take for example your "Dragon Crown" demo. Then 16 color sprites will be a problem. With just a 256 color background, the 16 color sprites will not likely be a problem in most cases. Depends on the use case though.
| |
| | ![](gfx/user1429.gif) Kamelito Loveless
Posts 260 07 Sep 2020 21:45
| Samuel Crow wrote:
|
A1200 coder wrote:
| The SAGA sprites could continue with the tradition of having attached sprites. Two sprites combined gives 256 colors - as I believe that someone will complain anyway that sprites can only have 16 colors. Indeed, in this popular Raiden 2 arcade shooter (1993) the player ship sprite has 32 colors, even though it looks quite simple. Or offer directly an 8/24-bit palette for sprites. |
32 colors is BOB territory but the bullet sprites are a realistic target. Remember the blitter is massively faster than on AGA.
|
I thought that the Blitter on the Vampire was running at the same speed as on AGA.
| |
| | ![](gfx/user1429.gif) Kamelito Loveless
Posts 260 12 Sep 2020 13:36
| If I’m not mistaken it was the Natami which should have a SuperBlitter many time faster than the Amiga on not the Vampire.
| |
| | ![](gfx/user805.gif) Samuel Crow
Posts 424 13 Sep 2020 22:16
| Kamelito Loveless wrote:
| If I’m not mistaken it was the Natami which should have a SuperBlitter many time faster than the Amiga on not the Vampire.
|
The Vampire v2 didn't have room for any Blitter at all and used the second thread of the CPU to execute hyperthreaded software blitting using AMMX.
| |
| | ![](gfx/user2020.gif) Mateusz S.
Posts 53 14 Sep 2020 22:52
| Gunnar von Boehn wrote:
| SAGA has some new Sprite features. SAGA support all SPRITE modes of AGA. These are: 8 Sprites channels FMODE=00 => 16pix * 4color FMODE=01/10 => 32pix * 4color FMODE=11 => 64pix * 4color SAGA supports in addition 32pix with 16 color each. This means SAGA can show 16 color sprites without need to spend 2 of them in attache mode. SAGA Sprites can be normally re-used. SAGA Sprites can be re-started with Copper. New Feature is SAGA sprite have own 256 color regs. This means Sprite can share Screen colors - or select their own palette.
|
Hi, how this SAGA replecement of blitter, copper, sprites works? I mean when classic games are running and we are connected to to Amiga native video output, I assume that Amiga native chips are used, right? So when SAGA sprites etc. features are used? Automaticaly when using RTG output? Or we need to code everything in asm to utilize that features? Thanks.
| |
| | ![](gfx/user2.gif) Gunnar von Boehn (Apollo Team Member) Posts 6207 15 Sep 2020 06:57
| Mateusz S. wrote:
| Hi, how this SAGA replecement of blitter, copper, sprites works?
|
SAGA is the improved recreation of the AMIGA AGA chipset. SAGA is the chipset used in the V4. SAGA recreates each part of AMIGA chipset but also improves it. Lets explain this in detail: Copper, original AGA features recreated and 32bit mode added. 32bit mode makes coding of 32pointer updates much easier. Sprites, original AGA features recreated and new features added. SAGA can show more sprites and they can have more colors. Also SAGA has more colors for the sprites. And Sprites can be coded indirectly (with PTR) this makes sprite programming so much easier now. Audio, original AGA PAULA recreated plus new features added. New added are more channels, bigger sample support and 16bit sample support. A full music WAVE can now be played with one command. Planes, original AGA plane features recreated plus on top Chunky support, 16bit mode and truecolor modes are added. Blitter, original AMIGA Blitter recreated and a new safety feature added which prevents programs to accidentally mess up an unfinished blit. PIP feature which allows showing a screen inside a window. This is very useful for Video playback on WB. Coherent DMA feature. This allows DMA for Ethernet and other units which is automatically coherent with the CPU. This prevents coding errors and removes the need for slow PREDMA and POSTDMA calls.
| |
| | ![](gfx/user2020.gif) Mateusz S.
Posts 53 15 Sep 2020 11:58
| Gunnar von Boehn wrote:
| SAGA is the chipset used in the V4.
|
Ok, so standalone V4 must use SAGA chipset, because it doesn't have legacy AGA chipset inside. I understand. But V1200 card also has the SAGA chipset. What about it? I know it uses SAGA features for RTG output. But what about that improved and recreated features of blitter, copper etc.? I guess classic games on A1200 won't use it, right? especially when we are connected to the Amiga video output, right? What if somebody would like to use improved SAGA features? Can classic games be forced to use the improved SAGA chipset? Thanks.
| |
| | ![](gfx/user2.gif) Gunnar von Boehn (Apollo Team Member) Posts 6207 16 Sep 2020 05:33
| Mateusz S. wrote:
| Sandalone V4 must use SAGA chipset, because it doesn't have legacy AGA chipset inside. I understand. But V1200 card also has the SAGA chipset. What about it? I know it uses SAGA features for RTG output.
|
The V1200 has today not the full SAGA chipset. It V1200, V500, V600 only have a part of SAGA activated. The idea is that in the future such cards could activate the whole SAGA ... this is what we call the "GOLD 3" core.
| |
| | ![](gfx/user2020.gif) Mateusz S.
Posts 53 16 Sep 2020 06:08
| Gunnar von Boehn wrote:
|
Mateusz S. wrote:
| Sandalone V4 must use SAGA chipset, because it doesn't have legacy AGA chipset inside. I understand. But V1200 card also has the SAGA chipset. What about it? I know it uses SAGA features for RTG output. |
The V1200 has today not the full SAGA chipset. It V1200, V500, V600 only have a part of SAGA activated. The idea is that in the future such cards could activate the whole SAGA ... this is what we call the "GOLD 3" core.
|
Got it. Thanks for answers.
| |
| | ![](gfx/user1860.gif) Antony Coello
Posts 153 16 Sep 2020 16:37
| Gunnar von Boehn wrote:
| SAGA is the improved recreation of the AMIGA AGA chipset. The V1200 has today not the full SAGA chipset. It V1200, V500, V600 only have a part of SAGA activated. The idea is that in the future such cards could activate the whole SAGA ... this is what we call the "GOLD 3" core.
|
So does that mean the V500/600 WILL infact be getting the SAGA in core 3 gold? :) And to clarify, is SAGA backward compatible with AGA?
| |
| | ![](gfx/user1397.gif) Vojin Vidanovic (Needs Verification) Posts 1916/ 1 16 Sep 2020 23:27
| Antony Coello wrote:
| So does that mean the V500/600 WILL infact be getting the SAGA in core 3 gold? :) And to clarify, is SAGA backward compatible with AGA? |
Yes, but:TAKES TIME - It will happen in some "future manner" of 6-12 months or so, no announced date. PREPARE WELL- Flashing that core is likely to lose some functionality, FPU and or RTG, will be known once factual back-porting from v4 is done, due to constrains of V2 FPGA. Thus, its advised to prepare separate WB install with e.g. no RTG P96 and such software, res up to 640x, 040-no FPU executables ... and some AGA titles to test (dont expect them all to work with alpha and such, even with later ones, takes time to perfect the beat. WB AGA sw seem to work far better then games, games are tricky in timings etc. COMPATIBILITY IS MATTER OF FIXING -Its not currently 101% AGA backward compatible, but team is working on it. To see how compatible it is, you can follow V4SA test results (some games currently fail or have glitches). Some mature form of V4 core will be back porting basis, so as V4 grows GOLD3 potential of backward compatibility grows YOU WILL GET SOME, MORE IN FUTURE- You will get those shiny new toys that some new Vamp only software could exploit - faster Blitter, megs of chip RAM, maybe even 16 bit sound. And surely "all in one Digital Video and Audio" output. Much more chip RAM and all in one out as well as limited AGA compatibility are immediate gains. New SAGA sprites, faster blitter and more colours, 16 bit sound (Oh my God!) would need a complete rewrite and could be only expected to be used by recompiled software. Its good new e.g. Eagle Player now uses 16 bit V4 sound I expect it could work on GOLD3, as example of "new brighter future". You can even now try limited alpha release with 640x res, no FPU,no RTG https://gold3.apollo-accelerators.com/#openModal Future is bright :) And is kind of magic to see A500-A600 run AGA and even real SAGA :) P.S. What makes a bit of fuss is that SAGA is mentioned even on current V2 models, but it currently means fast and nice RTG. In V4-GOLD3 manner it means enhanced chipset recreation. Hope this helps to have realistic or more realistic expectations.
| |
| | ![](gfx/user1860.gif) Antony Coello
Posts 153 17 Sep 2020 15:22
| Vojin Vidanovic wrote:
|
Antony Coello wrote:
| So does that mean the V500/600 WILL infact be getting the SAGA in core 3 gold? :) And to clarify, is SAGA backward compatible with AGA? |
Yes, but: TAKES TIME - It will happen in some "future manner" of 6-12 months or so, no announced date. PREPARE WELL- Flashing that core is likely to lose some functionality, FPU and or RTG, will be known once factual back-porting from v4 is done, due to constrains of V2 FPGA. Thus, its advised to prepare separate WB install with e.g. no RTG P96 and such software, res up to 640x, 040-no FPU executables ... and some AGA titles to test (dont expect them all to work with alpha and such, even with later ones, takes time to perfect the beat. WB AGA sw seem to work far better then games, games are tricky in timings etc. COMPATIBILITY IS MATTER OF FIXING -Its not currently 101% AGA backward compatible, but team is working on it. To see how compatible it is, you can follow V4SA test results (some games currently fail or have glitches). Some mature form of V4 core will be back porting basis, so as V4 grows GOLD3 potential of backward compatibility grows YOU WILL GET SOME, MORE IN FUTURE- You will get those shiny new toys that some new Vamp only software could exploit - faster Blitter, megs of chip RAM, maybe even 16 bit sound. And surely "all in one Digital Video and Audio" output. Much more chip RAM and all in one out as well as limited AGA compatibility are immediate gains. New SAGA sprites, faster blitter and more colours, 16 bit sound (Oh my God!) would need a complete rewrite and could be only expected to be used by recompiled software. Its good new e.g. Eagle Player now uses 16 bit V4 sound I expect it could work on GOLD3, as example of "new brighter future". You can even now try limited alpha release with 640x res, no FPU,no RTG https://gold3.apollo-accelerators.com/#openModal Future is bright :) And is kind of magic to see A500-A600 run AGA and even real SAGA :) P.S. What makes a bit of fuss is that SAGA is mentioned even on current V2 models, but it currently means fast and nice RTG. In V4-GOLD3 manner it means enhanced chipset recreation. Hope this helps to have realistic or more realistic expectations.
|
Well, I have already asked for some concrete documentation to clear V2/V4 differences and SAGA and 080 implementation. Im sure that it will be on its way eventually. (I know there are sporadic posts here and there exploring 080/SAGA features. I was thinking more a definitive reference manual). As it happens, I am very busy with 'real life' issues ATM (havent even got the V2 500 working in my Amiga yet), but at some point, I would like to port my game and associated framework, which is optimal at around a Pentium 2 class processor, so roughly this should work without too much change on the V2/V4. (Other than the bits of rewrite in MC68xxx assembly and the rest in C if the Vampire is quick enough to cope). When that time comes (a good while yet), I would like some sort of set goalposts for the HW and some good documentation, if I am to take advantage of the Vampire and not just have a generic 680x0/OCS/ECS/AGA version.
| |
| | ![](gfx/user2.gif) Gunnar von Boehn (Apollo Team Member) Posts 6207 18 Sep 2020 06:19
| Vojin Vidanovic wrote:
|
Antony Coello wrote:
| So does that mean the V500/600 WILL infact be getting the SAGA in core 3 gold? :) And to clarify, is SAGA backward compatible with AGA? |
Yes, but: TAKES TIME - It will happen in some "future manner" of 6-12 months or so, no announced date.
|
Lets prevent misunderstanding here. Our goal is to revive AMIGA. This means we want to make new AMIGAs which are 100% compatible and are much faster then old models, and have new better features. SAGA (Super AGA) is an improved AGA chispet, which includes the original AGA and adds on top a number of upgrades and improvements. Many of these improvements aim to make coding for Amiga easier. SAGA is integral part of our Standalone. The V2 accelerator share the "RTG" part. Please understand that the V4 standalone FPGA is twice as big as the V2/600/500 accelerator FPGA. Its obvious that both FPGA types can not hold the same content. We can clearly NOT promise that SAGA with all features comes to V2. We have made a "test-Gold3" version a long time ago, but to make it fit in the V2 we had to disable the FPU.
| |
| | ![](gfx/user1168.gif) Saladriel Amrael
Posts 166 18 Sep 2020 07:40
| Technically it is well understandable and, I presume, understood by most of the people that has enough techinical background and follows these forums accurately. Also, I think it would be very good to give the two subversions of SAGA (RTG Only and RTG+Legacy Compatible +Improved Chipset) two (sloghtly?) different names, so that there can't be misunderstandings by the people interested to buy the product.
| |
| | ![](gfx/user1860.gif) Antony Coello
Posts 153 18 Sep 2020 14:31
| Well Im sure we can all appreciate that the Vampire team will try to fit what they can into the V2 core and I thank them for that. To put my previous post another way, what would be nice is to know the exact target architecture before I start porting. Its not simply a case of ticking a Vampire box in the compiler. Things need to be designed carefully in to compensate for things beforehand. There are timing optimisations to think of, target graphics chipset, wether to use blitter or not (Gunnar says NO!), more assembly if the architecture is not as fast as expected, more C if it is, etc. Currently, it seems the team will decide by a FB 'customer vote' as to what gets included in the smaller V2 core, so we either have to wait for the results, or if coding right now, write more generic code which does not take advantage of the features that will or will not be included. This isnt a rant, I just would like to make the best use possible of the end V2 core...whatever it end up being.
| |
|
|
|