 Running Games and Apps. |
| Lets Write Games for Amiga - Use SAGA! | page 1 2
|
|---|
|
|---|
| | 
Olaf Schoenweiss
Posts 690
14 Sep 2020 15:43
| AMOS gets updated with AGA already (what is a big step already) If Vampire features (SAGA) is added in future is out of my knowledge But even if not, even with "only" AGA and enough RAM and processor speed you can do a lot with it already
| |
| | 
Kenji Irie
Posts 86
20 Sep 2020 22:31
| Hi Antony, just reading your posts. Great to hear you are keen on developing for the Vampires! I started coding for WinUAE before I got my V4. Actually, I was starting a game from scratch, and have a dual Win32/Amiga compile for the same code, so I can fully debug the non-proprietary stuff on a modern PC dev environment and then compile the same code for the Amiga under WinUAE. I simply used RTG to emulate the necessary screenmode that I would use with SAGA, until I got the V4 hardware. Since getting the V4 in April, I now dev mostly on Win32 debug, and then compile 68080 executable on PC, before FTPing to V4 with a single CLI command and running. This is a very quick coding/debug cycle, and I've had no problems with 080/AMMX coding. VBCC/Vasm is brilliant for cross-compiling - super fast compile on PC, and deployment and running on V4 within seconds. Good luck!
| |
| | 
Mateusz S.
Posts 53
20 Sep 2020 22:57
| But all SAGA features are only for V4 (for now). In my opinion would be better to create new games using RTG and utilizing cpu speed. That apps would be compatibile with more hardware including Vampires and new modern Turbo Cards like Warp or ACA.
| |
| | 
Antony Coello
Posts 154
20 Sep 2020 23:58
| Like I mentioned in another thread, it would be faster to write (the less critical part of the code) in C rather than having to do a big project in 100% assembly. However, up till now, even on a 68030 this can still be too slow, depending on system architechture (RAM/Bus speed/DMA contention,etc) and graphic subsystem implementation (RTG or other non direct hardware memory mapped GFX APIs). An example that I am familiar with is the Atari TT030 with an ISA graphics card: The NVDI3/4/5 graphics interface coupled with a slow VME<>ISA bus means a full speed game at any reasonable speed is not practically possible, even at lower bandwidth resolution/colour depth. With the speed of the Vampire, this could actually become possible now. All the 'issues' mentioned above are not as important any more provided the graphics subsystem programming interface isnt too abstracted/bloated. Though I can code 680x0 assembly, I am not familiar with Amiga GFX and sound subsystems, and may find just using a generic triple screen buffer system will be sufficient, rather than taking the time to learn all the Sprite/copper DMA timings and perculiarities (this would also cross port easier too, as this is how I currently have it set up). These old 'features' were good when the CPU was slow, but if the CPU is fast enough, they should maybe not be needed anymore? I dont know yet. However, I would like to look into SAGA for optimising for Vampire (hence the asking of the exact implementation that will appear on the V500/600 cores) if a more simple framebuffer sprite draw/erase system is not fast enough. @Kenji Irie: Thankyou for your tips with your development setup. I have a somewhat similar setup but currently with Devpac 3 and an Atari TT as the target system. I would be very interested in what you have done so far with your game and how much RTG differs from the SAGA subsystem. Do you have any website/blog? :)
| |
| | 
Gunnar von Boehn
(Apollo Team Member)
Posts 6263
21 Sep 2020 07:20
| Antony Coello wrote:
|
However, I would like to look into SAGA for optimising for Vampire (hence the asking of the exact implementation that will appear on the V500/600 cores) if a more simple framebuffer sprite draw/erase system is not fast enough.
|
The key difference of the Vampire to other accelerators is the much higher CPU speed and outstanding memory speed. The 68080 is many times faster even than heavily overclocked 68060. The Vampire reaches a memory performance of 500-600 MB/sec -
while 68060 CPU cards reach less than 10% of this.
AMMX our SIMD instruction extension have a number of Pixel instructions which are designed to make game maker live easier. The combination of AMMX and high memory speed allows you to make games reach much higher performance. For example our DIABLO game port for Amiga runs on Vampire significantly faster than on 1000Mhz PowerPC G4 machines.
| |
| |
Gunnar von Boehn
(Apollo Team Member)
Posts 6263
21 Sep 2020 07:41
| Mateusz S. wrote:
|
But all SAGA features are only for V4 (for now). In my opinion would be better to create new games using RTG and utilizing cpu speed. That apps would be compatibile with more hardware including Vampires and new modern Turbo Cards like Warp or ACA.
|
Making a game for all these card is not easy
as between these 3 cards are worlds.
The typical 68030 CPU ACA reaches ~ 10 Mips and 7 MB/sec speed to GFX card.
The Warp will reach with a normal 68060 CPU around 40Mips
and with an extrem >100Mhz 060 maybe ~80 Mips and maybe 50 MB/sec
But the Vampire has 150 Mips and 600 MB/sec speed.
If your mind that the Vampire can reach a speed of 600 MB/sec ... but if you want your game also run on the "others cards" lik ACA
then have to make your game run in 7 MB/sec ACA speed ....
This means you have limit your game to 1% of the Vampire speed.
I think making a game run on any RTG will limit the games you can develop a lot. For Chess games no problem but if you want to make a smooth running actions game?
| |
| |
Kenji Irie
Posts 86
21 Sep 2020 11:27
| Antony Coello wrote:
|
Like I mentioned in another thread, it would be faster to write (the less critical part of the code) in C rather than having to do a big project in 100% assembly.
Though I can code 680x0 assembly, I am not familiar with Amiga GFX and sound subsystems, and may find just using a generic triple screen buffer system will be sufficient, rather than taking the time to learn all the Sprite/copper DMA timings and perculiarities (this would also cross port easier too, as this is how I currently have it set up). These old 'features' were good when the CPU was slow, but if the CPU is fast enough, they should maybe not be needed anymore? I dont know yet.
@Kenji Irie:
I would be very interested in what you have done so far with your game and how much RTG differs from the SAGA subsystem.
Do you have any website/blog? :)
|
You had the exact same questions I had. Until this year, I had never coded in assembly. I have only coded extensively in C and its varients (and Matlab - basically C!). So I had not programmed any of the Amigas graphics or sound subsystems (and I still haven't coded anything especially for the blitter or copper, DMA, etc - but don't tell Gunnar!)
So, long story short: I've learnt some basic 68k assembly, and written the GFX drawing routines in them, and learnt AMMX on the way. But 99% of my game is written in C. No way could I do anything this complex in assembly.
Let me say that moving to SAGA from Amiga RTG was basically one line of code! In Amiga RTG you have a frame buffer, and you render that to the screen with WritePixelArray() or something like that. In SAGA, you simply redirect the frame pointer to your frame buffer - and that's it! You get the benefit of instant frame display, with no slowdown by copying the framebuffer to the RTG subsystem! So all of my game engine is coded in C, included object handling etc, with just the final rendering using assembly. I started with rendering and keyboard wrappers for 1) Amiga RTG so I could test on WinUAE before I had a Vampire, and 2) in Win32 so I could natively debug in Windows (Windows PC being so fast that it's all just C copying of pixels). And now I have 3) AMMX rendering routines for V4 (I've never needed WinUAE after getting V4. I debug on Win32, and compile and test on V4 for all native Amiga stuff now).
Key V4 parts for me: take advantage of super fast 68080 CPU, and take advantage of super fast memory and RTG, and take advantage of AMMX for ever more speed increase and super-nice effects. Plus, you get the bonus of 16-bit multi-channel sound.
This should link to the development vids for my game engine:
EXTERNAL LINK
I have been asked multiple times to support 060 Amigas - but there is no way that the fastest classic Amiga can move the shear amount of memory around fast enough. It could barely draw the background at 50Hz, let alone do anything else.
What is resolution/depth and framerate of your game? I can provide some immediate thoughts on viability for porting to V4.
Cheers.
| |
| |
Antony Coello
Posts 154
21 Sep 2020 13:36
| Kenji Irie wrote:
|
So I had not programmed any of the Amigas graphics or sound subsystems (and I still haven't coded anything especially for the blitter or copper, DMA, etc - but don't tell Gunnar!)
|
Well thats what I was thinking: stuff can be done directly to memory/framebuffer with this speed. You seem to have confirmed this.
Kenji Irie wrote:
|
No way could I do anything this complex in assembly.
|
In my experience, bigger projects take more design planning and judicious use of register assignment, but its not impossible. Timewise, its far more though! :)
Kenji Irie wrote:
|
Let me say that moving to SAGA from Amiga RTG was basically one line of code! In Amiga RTG you have a frame buffer, and you render that to the screen with WritePixelArray() or something like that. In SAGA, you simply redirect the frame pointer to your frame buffer - and that's it! You get the benefit of instant frame display, with no slowdown by copying the framebuffer to the RTG subsystem!
|
Great. Thats pretty much one of the things I wanted to know. It should be a (more or less) exact fit to what I have here already then.
Kenji Irie wrote:
|
Key V4 parts for me: take advantage of super fast 68080 CPU, and take advantage of super fast memory and RTG, and take advantage of AMMX for ever more speed increase and super-nice effects. Plus, you get the bonus of 16-bit multi-channel sound.
This should link to the development vids for my game engine:
EXTERNAL LINK
|
Nice. I do remember watching the one that pushed the screen sprites a while back. Impressive! :)
Kenji Irie wrote:
|
I have been asked multiple times to support 060 Amigas - but there is no way that the fastest classic Amiga can move the shear amount of memory around fast enough. It could barely draw the background at 50Hz, let alone do anything else.
|
I was a bit shocked at this statement, until I saw what you were actually doing! lol
Well, you arent exactly doing base/classic Amiga stuff here. No wonder the 060 struggles. :)
My game engine can be scaled to different resolutions/bitdepths, although the graphics will obviously have to be changed for the target res/depth required, or may look too udefined<>blocky.
Kenji Irie wrote:
|
What is resolution/depth and framerate of your game? I can provide some immediate thoughts on viability for porting to V4.
|
Well, see the answer above ;)
Currently, the game is set up for 1024x768@24bpp (which Im going to be changing to 8bpp for the final build, Its set currently for testing the memory and bandwidth loads with 24 bitplanes, but actually uses less than 256 colours).
The display engine is also (adjustable, but currently) 4 layer tile based.
As soon as I can get my A500 board CPU slot replaced (fingers crossed the 500V2 works then) I will start making moves to setting up and starting preliminary framework porting.
| |
| |
Kenji Irie
Posts 86
22 Sep 2020 10:18
| Antony Coello wrote:
|
Currently, the game is set up for 1024x768@24bpp (which Im going to be changing to 8bpp for the final build, Its set currently for testing the memory and bandwidth loads with 24 bitplanes, but actually uses less than 256 colours).
The display engine is also (adjustable, but currently) 4 layer tile based.
As soon as I can get my A500 board CPU slot replaced (fingers crossed the 500V2 works then) I will start making moves to setting up and starting preliminary framework porting.
|
Going 960x540x8 might be possible with 4 layers at 50 Hz, depending upon a number of factors. 24-bit is effectively 32-bit on the RTG/Vampire GFX, so moving 8-bit images should be 4 times faster than 24-bit, which will help you quite a lot. I'm happy to provide help where I can, if you want/need it. It would be easier to move discussion to Discord though, on the official Vampire channels and/or direct messaging.
| |
| |
Antony Coello
Posts 154
22 Sep 2020 12:45
| Kenji Irie wrote:
|
Going 960x540x8 might be possible with 4 layers at 50 Hz, depending upon a number of factors. 24-bit is effectively 32-bit on the RTG/Vampire GFX, so moving 8-bit images should be 4 times faster than 24-bit, which will help you quite a lot. I'm happy to provide help where I can, if you want/need it. It would be easier to move discussion to Discord though, on the official Vampire channels and/or direct messaging.
|
The other thing I didnt mention, is that I am actually using the option of alpha blending (hard and software versions). The soft version (even on a Pentium 4 class processor is too slow when used on a high percentage of the screen, so not sure how the Vampire will cope). Ok, you are right, we need to discuss further elsewhere. Is there a way I can contact you? Otherwise, I will shortly join the Vampire discord channel anyway. :)
| |
| | 
Vladimir Repcak
Posts 359
22 Sep 2020 20:28
| Kenji Irie wrote:
|
I have been asked multiple times to support 060 Amigas - but there is no way that the fastest classic Amiga can move the shear amount of memory around fast enough. It could barely draw the background at 50Hz, let alone do anything else.
|
Only very few 2D genres can scale down total number of sprites on screen without drastic butchering of gameplay.From the top of my head, Bullet Hell and Asteroids are the two most common genres, where you can butcher the Sprite count yet gameplay remains unaffected. Supporting 68040-68060 alongside Vampire is much more feasible in a 3D game as you simply reduce scene polycount , draw distance, effects and frame rate while keeping gameplay unaffected.
| |
| |
Kenji Irie
Posts 86
22 Sep 2020 20:58
| Vladimir Repcak wrote:
|
Kenji Irie wrote:
|
I have been asked multiple times to support 060 Amigas - but there is no way that the fastest classic Amiga can move the shear amount of memory around fast enough. It could barely draw the background at 50Hz, let alone do anything else.
|
Only very few 2D genres can scale down total number of sprites on screen without drastic butchering of gameplay.
Hi Vladimir, true. How are your games progressing? I haven't been following the forum for maybe 6 months, so keen to hear your progress.
From the top of my head, Bullet Hell and Asteroids are the two most common genres, where you can butcher the Sprite count yet gameplay remains unaffected.
Supporting 68040-68060 alongside Vampire is much more feasible in a 3D game as you simply reduce scene polycount , draw distance, effects and frame rate while keeping gameplay unaffected.
|
| |
| |
Kenji Irie
Posts 86
22 Sep 2020 21:03
| Antony Coello wrote:
|
The other thing I didnt mention, is that I am actually using the option of alpha blending (hard and software versions). The soft version (even on a Pentium 4 class processor is too slow when used on a high percentage of the screen, so not sure how the Vampire will cope).
Ok, you are right, we need to discuss further elsewhere.
Is there a way I can contact you?
Otherwise, I will shortly join the Vampire discord channel anyway. :)
|
A quick alpha-like implementation in AMMX looks good and is fast, though not sure I would want to apply to the whole screen during gameplay. Not sure how it would work with 8-bit indexed colours though - I am using 16-bit display. Discord would be best. ApolloTeam server. Nick "Quetzal". See you there!
| |
| | 
Nikos Tomatsidis
Posts 66
26 Sep 2020 16:38
| If you have noticed there is a follow up to "Reshoot R" in development called Proxima III. The "Reshoot R" coder "Richard" already compiled "Reshoot R" to AROS, ApolloOS 68k.
Recently I seen a picture of how Proxima III would look in high-res.
If you are smart you talk with Richard about a possible Vamp. version in high-res. It is for sure all about money. As there are sold quite a few vamp. cards I think the people using it are willing to put some money into something like this?
| |
|
|
|
