Overview Features Instructions Performance Forum Downloads Products OrderV4 Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Running Games and Apps.

Lets Write Games for Amiga - Use SAGA!page  1 2 

Gunnar von Boehn
(Apollo Team Member)
Posts 4893
29 Apr 2020 08:24


This time of the year, some people are locked in, some people have some time ...

Maybe this is a great chance to write some small games for Amiga.

You will recall the many good old classic games like: Centipede, Falcon Patrol, River Raid

Those games were fun, easy to understand and actually fast and easy to develop.

How about rewriting them for SAGA using the nice new features like more colorful Sprites?

If we all work together here, we can quickly re-create a bunch of nice small games for Amiga.


Maurizio Tirone

Posts 16
29 Apr 2020 16:09


I have nothing against retrogaming, on the contrary, but talking about "Centipede" on Vampire makes me smile a little ...

If you allow me, I think you should urge to dare more about your beautiful creature called Vampire


Kamelito Loveless

Posts 115
29 Apr 2020 17:30


Nice idea and code snippets could be used to develop a game library.


Eric Gus

Posts 429
30 Apr 2020 07:01


Would love to but im waiting for a high level language like BlitzBasic, AMOS (ProX say) to have support.. I am really not up to asm these days .. just no time to dedicate to it.. otherwise yep, fully onboard with the idea though!


Gunnar von Boehn
(Apollo Team Member)
Posts 4893
30 Apr 2020 07:10


eric gus wrote:

Would love to but im waiting for a high level language like BlitzBasic, AMOS (ProX say) to have support..

There is no need to wait any longer.
You can today write a game with the languages already.



Michael Borrmann

Posts 133
30 Apr 2020 07:59


eric gus wrote:

Would love to but im waiting for a high level language like BlitzBasic, AMOS (ProX say) to have support.. I am really not up to asm these days .. just no time to dedicate to it.. otherwise yep, fully onboard with the idea though!

You can just use those things, and will have a massive speed boost with the vampire, anyway.




Antony Coello

Posts 45
30 Apr 2020 14:46


Gunnar; as soon as I manage to get a working Vampire system, I will start looking into crossporting my PC game framework.

I already know what Toni Wilen has said regarding Vampire emulation, but I dont suppose theres a software version of the 68080 core that I can hack into WinUAE so that I can test/take advantage of any of the '080/SAGA/AMMX extras in the meantime?


Gunnar von Boehn
(Apollo Team Member)
Posts 4893
30 Apr 2020 16:01


Antony Coello wrote:

  I already know what Toni Wilen has said
 

Tony has clearly his own interests, no doubt about this.
I can understand this.
But isn't just normal that he see other Amiga-developers as competition? I think this is understandable.


Eric Gus

Posts 429
30 Apr 2020 19:46


Michael Borrmann wrote:

 
    You can just use those things, and will have a massive speed boost with the vampire, anyway.
 

 
  Well thats my plan short of specific features added to a highlevel language.. Now I just need a V4 (or core3 on my v2 .. :-D .. lack of chipram is killing me on the v2 -- and I have zero interest in hacking my (actual own original first Amiga I ever bought) rev5 NTSC locked A500 to try to expand it, nope shes not going under the knife).


Antony Coello

Posts 45
30 Apr 2020 21:57


Gunnar von Boehn wrote:

  But isn't just normal that he see other Amiga-developers as competition? I think this is understandable.
 

 
  Perhaps I have it all wrong, but from what I took from his posts on the matter, it seemed the reason he has not put the work in to emulate the Vampire is that he did not want to chase a so called 'moving target'. I dont think he is direct competition. Some people like convenient emulation, others, it HAS to be the real hardware. Wouldnt it be in his interest to emulate Vampire at some point?
 
  Anyhow, back to the subject matter, what would be the ideal stepping stone for many, is if some of the Assembly/C compiler writers can be persuaded to include automatic 080/MMX compile optimisations/instruction swap-ins from standard 68xxx code. Then its just a matter of dealing with SAGA techniques/conversions.
 


Gunnar von Boehn
(Apollo Team Member)
Posts 4893
01 May 2020 02:24


Antony Coello wrote:

Perhaps I have it all wrong, but from what I took from his posts on the matter,

 
But is this is his true opinion or just an excuse?
 
Fact is that the 68080 CPU instruction set is clearly defined
and that the AMMX instruction did not changed since years.
So moving target is clearly not correct.

Also 68080 has compiler support and obviously can't be a moving target which changes behaviors - as otherwise the compilers would all break.
   
Fact is that Tony never even care to talk to us or ask for roadmap or if features are planned to be changed.
So I wonder how he would come to his wrong opinion?
 
   
Antony Coello wrote:

Anyhow, back to the subject matter, what would be the ideal stepping stone for many, is if some of the Assembly/C compiler writers can be persuaded to include automatic 080/MMX compile optimisations/instruction swap-ins from standard 68xxx code. Then its just a matter of dealing with SAGA techniques/conversions.
     

 
What do you mean by
automatic 080/MMX compile optimisations/instruction swap-ins
 
Its not fully clear to me what you understand under this.
Can you please give a concrete example?
 
AMMX is designed to solve problems which you can not easily solve with 68K instructions. Therefore there is not such thing as an 68k-Asm instruction matching 1:1 to this AMMX code.

I'm not sure how familiar you are with 68K ASM code.
AMMX does not "replace" existing 68k instructions.
There is no point in doing this.
AMMX does extend the 68K instruction set to solve problems people could not effectively tackle before.



Antony Coello

Posts 45
01 May 2020 10:38


Gunnar; I can guarantee I dont know as much about compilers or MC68k architecture as you, so forgive me any mistakes! ;)
 
  However, I still think it may still be relevant.
 
  I see VASM has compiler support. This is just for the new insructions which have to be coded in manually, obviously.
 
  As for 'swapping': perhaps I am stepping a bit too far with AMMX conversion, like you say, as its too far removed from 68k. But for 68xxx code, what I was describing/proposing, from the simplest viewpoint, like when eg someone would code:
 
  MOVE.L  #$xxxx,A0
 
  the compiler would swap it for:
 
  MOVEA.L  #$xxxx,A0
 
  Same with MOVEQ/ADDQ, etc. The compilers will be doing this addressing mode swap already, but not going as far as swapping of actual NEW instructions.
 
  This could be extended from the simplest adressing mode, attribute or instruction swap (as above) with a compiler pattern recognition if for example there are any new 080 instructions that can be used to replace a SPECIFIC SET of 68000-60 (longer/slower) instructions. This would be similar to higher level compiler directives.
 
  If this is not relevant or invalid, then forgive my ignorance and perhaps we can just settle for making do with collecting all your 080 code snippet examples into one document, so we can do what cannot be done above ourselves!
 
  I hope this makes sense to some degree. I have to admit though, I havent had a thorough look at the new 080 instructions, so perhaps there are absolutely no use cases which are applicable.
 
  As for Mr.Wilen; perhaps you are right. Its hard to tell some peoples motives sometimes. Externally, he doesnt appear to be against it..?
 
  Have you discussed Vampire emulation with any other emulation authors? (even modified Atari emulators may be suitable). I think the more exposure to the 080/AMMX/SAGA, the better. BUT I can totally understand if you would prefer not to have the core emulated and if this were to be the case I can see why from your perspective.
 
  As a 'real' example of the solutions the above would solve; I am sat here with a broken (possibly bad caps) A500/Vampire board and cannot make games for Vampire by any other method :(


Gunnar von Boehn
(Apollo Team Member)
Posts 4893
01 May 2020 11:11


Antony Coello wrote:

As for 'swapping': perhaps I am stepping a bit too far with AMMX conversion, like you say, as its too far removed from 68k.

Let me clarify some basis.
68080 makes already the old 68K instructions as fast as possible.

Its not that the old 68K MUL instruction takes 100 cycle but the new AMM-MUL takes 1 cycle.
And that you need replace the old instruction by the new one to get more speed.
We did already make the old MUL instruction as fast as possible (2 cycle) - therefore there is no need for an instruction replacement.

The new AMMX-MUL is a vector operations which does do 4 MUL in parallel - This makes the code faster, but for using this you also need to layout all the data in memory different.
This is normal for all VECTOR operations, same is needed for IBM PPC or INTEL x86. To benefit from vectorization you need to change the structure of the data in memory.

In short a programmer needs to decide to use vectorization where the data layout permits it.



Antony Coello

Posts 45
01 May 2020 14:25


Ok. I see.

So, I get the need for code change for the AMMX parallel operations. (Im guessing the setup is in some ways similar to aligning code for prefetch optimisation).

From what you are saying I now understand that the non-AMMX 080 instructions are the SAME as on 000-060 but (variably) much faster.

  Which would mean having to change code, not because it wouldnt work, but for the more optimal faster instructions which may be different to what was the fastest setup before.

Have I got it yet? ;)
 


Bartek Kuchta

Posts 4
29 Jun 2020 14:09


Hi Gunnar,

I would be interested. I'm happy to polish and improve 194x graphics so that we could finish the game:)

Kind Regards


Mateusz S.

Posts 12
14 Sep 2020 01:15


I would like to use just RTG, so the games would be compatibile with more hardware, I mean  especially the new wave  of  modern TurboCards for Amigas.
Here is a nice, very new thing that can encourage someone, a fully addon to the Visual Studio C, that compiles and debugs for Amiga by Bartman  and Abyss:
EXTERNAL LINK


Mårten Björk

Posts 4
14 Sep 2020 09:08


Gunnar von Boehn wrote:

eric gus wrote:

  Would love to but im waiting for a high level language like BlitzBasic, AMOS (ProX say) to have support..
 

  There is no need to wait any longer.
  You can today write a game with the languages already.
 

I started writing a new game in Amos. Not a port, a new dungeon crawler/explorer type of game. The game targets vamped/accelerated amigas as it consumes a lot of memory and also needs high performance. With AmosProX I get (experimental) AGA support. With my V4SA I get lots of memory and horse power. But I miss the ability to use high resolution screens. AMMX and 16-bit sound would be nice too.  :-)

I think that a SAGA version of Amos or Blitz really would boost the development of new SAGA games.


Olaf Schoenweiss

Posts 652
14 Sep 2020 09:38


Perhaps the Scorpion Engine is something for you

EXTERNAL LINK 
I tested it and the compiled games run on Aros 68k

As far as I remember the environment (based on Windows) uses aros roms for testing. So the games should also run on vampire. And the author perhaps could also support vampire features


Mårten Björk

Posts 4
14 Sep 2020 14:54


Thanks Olaf! I'll look into that.

If there was any development environment with Vampire features I would probably try it. The reason I started with AMOS now is that it is familiar. Dream scenario for me would be Vampire C# ;-)


Nick Fellows
(Apollo Team Member)
Posts 36
14 Sep 2020 15:18


I need kit first!

posts 21page  1 2