Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Running Games and Apps.

How About Starting a Wiki for Amiga Game Devs?page  1 2 3 4 5 

Samuel Crow

Posts 424
03 Apr 2020 22:59


@Olle

EXTERNAL LINK can be called from C and is written in C.  C is faster than Blitz if you use Bebbo's GCC 6.5 cross compiler but this library is the graphics card version.  The Amiga-native version hasn't been written.


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
04 Apr 2020 00:02


Samuel Crow wrote:

  and is written in C.
 

 
Have you looked at the code?
What do you think about it?




Manfred Bergmann

Posts 226
04 Apr 2020 09:22


Olle Haerstedt wrote:

 
Samuel Crow wrote:

 
Olle Haerstedt wrote:

    Porting BlitzBASIC ASM libs to C would be a cool alternative to give people access to fast graphics routines from C, while getting rid of the BASIC limitations (good for prototyping, bad for bigger projects).
   

    There's a guy on GitHub making an Amos interpreter and putting the runtime in RetroMode.library for AmigaOS 4.x.  Will that help?
 

 
  I'm sure it will help someone, haha? What's the use-case? Running 68k AMOS games on OS4? AMOS is just like BB a beginner-friendly language that's good for learning and prototyping, but more serious projects will turn to C/C++/ASM, afaik.
 
 

 
  I don't agree on that.
  BlitzBasic/AmiBlitz kind of has the same language structures like C has and similar possibilities of structuring code. No OO like C++. But C++ is  a PITA anyway and shouldn't have gotten this popularity.
  Also AmiBlitz has a super IDE.
  AMOS might be a different case and is much simpler than BB.


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
04 Apr 2020 10:49


Manfred Bergmann wrote:

I don't agree on that.

I feel we all have a different look on this topic.

1) Some people look for "playdoh" coding environment.
They want something for beginners, very easy to use, and they not care for performance, and not worry to get the most of out Amiga.

2) Some people look for coding a game in C.
They want to save learning ASM, and they hope C would not eat too much of the performance.

3) Other will use ASM as only ASM gives you perfect control of what you do.

 

Lets look at the library code that Sam posted.

Lets look at "screencopy" function


  for(src_horizontal_ptr=src_vertical_ptr;src_horizontal_ptr<src_horizontal_end;src_horizontal_ptr++)
  {
    *destination_horizontal_ptr++ = *src_horizontal_ptr;
  }

What do we see here?
The copy copies BYTE per BYTE.
The copy does one COMPARE and a Conditional Branch per Byte.
This is simple written and this is super slow code.
You get 8BIT performance here.
A game coder aiming for good speed would never do this.

For bigger copies, or whole screen copies an experienced coder would calcukate the number of LONGs to copy and then do a copy which copies 32Bit or 64bit per loop.
Such a tuned copy would in fact run 8 times faster.




Ray Couzens

Posts 93
04 Apr 2020 10:52


This is a very interesting discussion.

There is clearly a division of ideas here. 

As an Amiga user who likes the backward compatibility of the 68080 chip, then I would be concerned if AROS/Apollo moved away from this compatibility.

On the other hand, I can see how some people might like the idea of a more up-to-date Amiga system, 64-bit, multi-processor etc. Which may offer more future proofing.  I guess a Vampire supporting both options would be expensive, and is there any need?

My question is, what would happen if AROS moves away from 68K legacy support?  Would we be left with a version of AROS that is not updated?  Maybe the Apollo team could maintain the 68K AROS and further polish it for the Vampire?




Gunnar von Boehn
(Apollo Team Member)
Posts 6197
04 Apr 2020 11:03


Ray Couzens wrote:

  My question is, what would happen if AROS moves away from 68K legacy support?  Would we be left with a version of AROS that is not updated?  Maybe the Apollo team could maintain the 68K AROS and further polish it for the Vampire?
 

 
Lets be crystal here:
 
To me AMIGA always was the trinity of
  - great in ASM to code 68K CPU
  - smart and elegant Amiga chipset
  - elegant and swift OS
Only this trinity of virtues is for me worth to follow.
 
 
Lets look and compare:
OS 4,
  - has no nice and elegant to program CPU anymore
  - has no smart and elegant Amiga chipset
  It only has a "copy" of the Amiga OS
  = So this has not the real Amiga Spirit
    and is in my opinion not worth to follow
 
 
AROS on x86,
  - has no nice and elegant to program CPU anymore
  - has no smart and elegant Amiga chipset
  - has no compatibility to real Amiga programs!
  It has a remake/copy of the Amiga OS - but its less tuned and less elegant than the original
= So this has not the real Amiga Spirit,
    and is in my opinion not worth to follow
 
 
AROS on 68K,
  + has the nice and elegant to program CPU !!
  + has the smart and elegant Amiga chipset !!
  + has compatibility to real Amiga programs!
  It has a remake/copy of the Amiga OS
  - but its less tuned and less elegant than the original
= This nearly has full Amiga Spirit.
  This is IMHO the way forward.
  And if we all together fix the remaining issues or AROS,
  and then remove some bloat and make it REALLY compatible
  to the original then this is the right solution.
 
 
I think the world is big enough for 2 AROS branches.
One branch aiming for REAL 100% Amiga OS compatibility.

2nd Branch aiming for taking over the x86 market from Windows and Linux and blowing Apple out of the water.
The goals are clearly not the same of the two.
 


Ray Couzens

Posts 93
04 Apr 2020 11:10


Gunnar von Boehn wrote:

  I think the world is big enough for 2 AROS branches.
  One branch aiming for REAL 100% Amiga OS compatibility.
  2nd Branch aiming for taking over the x86 market from Windows and Linux and blowing Apple out of the water.
  The goals are clearly not the same of the two.
 

Great, that is what I would have hoped for!  The Vampire Amiga user gets the best of both.  Thanks for the detailed answer.


Manfred Bergmann

Posts 226
04 Apr 2020 11:27


Gunnar von Boehn wrote:

 
Manfred Bergmann wrote:

  I don't agree on that.
 

 
  I feel we all have a different look on this topic.
 
 

 
  What I meant was that BlitzBasic is not for beginners as Olle claimed.
  The compiler can be called on command line as well if people don't like AmiBlitz IDE or it's editor.
  There are also IDEs for ASM, like AsmOne, or Devpac which are kind of "playdoh" as well, no? :)


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
04 Apr 2020 11:35


Manfred Bergmann wrote:

  There are also IDEs for ASM, like AsmOne, or Devpac which are kind of "playdoh" as well, no? :)
 

 
My point is the understanding of what you do and is going on.
 
Lets go back to the screen example.
If I as coder use Screencopy() function in any high level then this abstract the lower stuff from you.
 
+ This clearly helps beginners.
- And it at the same clearly hinders good developers.
 
"playdoh" functions which take the details from you, will at first glance make stuff simple and easier but also will have hidden costs and make stuff impossible to reach.
 
But to each his own - and the right tool also depends on your goal.
Whats your goal "BardTale"? or "80-column Voxel" or "Getting the best our of Amiga"?
 
Your goal will define what tool is best for it.

Coding is like cooking.
A real chef cook will want to have do all on his own.
He will want to cut all the fresh vegies himself and not take any stuff from cans.
He will cook all the sauces and soups himself and not use any cans.

But if your goal is not 50 FPS, but story like in Bardstale,
then you better invest your time in reading fantasy novells and getting the background story real nice developed.




Manfred Bergmann

Posts 226
04 Apr 2020 11:47


+1


Ray Couzens

Posts 93
04 Apr 2020 13:34


I think when I get my Vamp will surely have a go at learning ASM.  No pain no gain as the saying goes. The trick is to start simple and work upwards.


Olle Haerstedt

Posts 110
04 Apr 2020 13:56


For the wiki discussion: A wiki will contain what ever people put into it. Right now, what's interesting for me is C and ASM development with MIT license. BB and AMOS info is plentiful already, imo. But anyone can contribute with whatever they want, of course. :)
     
For other discussions: The business perspective is missing. If anyone would ever make a commercial game for Amiga again, they would want to make it as portable as possible since the Amiga install base is tiny. For that, the ASM code has to be as small as possible, since it's time consuming to write, not portable and requires exotic, expert in-depth knowledge. It's very cool haxxor 1337 impressive coding skill, but makes 0 business sense unless the install base is huge, like Playstaion, XBox or Nintendo DS. A super-optimized SDL lib for Amiga could make sense to make your brillant new Amiga game run on PC and whatever. :) Especially since 68k with 080 finally is fast enough. Maybe the Vampire can be adapted to make SDL run smooth? Extra power to the blitter? No idea.


Ray Couzens

Posts 93
04 Apr 2020 14:17


Olle Haerstedt wrote:

For the wiki discussion: A wiki will contain what ever people put into it. Right now, what's interesting for me is C and ASM development with MIT license. BB and AMOS info is plentiful already, imo. But anyone can contribute with whatever they want, of course. :)
       
  For other discussions: The business perspective is missing. If anyone would ever make a commercial game for Amiga again, they would want to make it as portable as possible since the Amiga install base is tiny. For that, the ASM code has to be as small as possible, since it's time consuming to write, not portable and requires exotic, expert in-depth knowledge. It's very cool haxxor 1337 impressive coding skill, but makes 0 business sense unless the install base is huge, like Playstaion, XBox or Nintendo DS. A super-optimized SDL lib for Amiga could make sense to make your brillant new Amiga game run on PC and whatever. :) Especially since 68k with 080 finally is fast enough. Maybe the Vampire can be adapted to make SDL run smooth? Extra power to the blitter? No idea.

I understand where you are coming from.  For many programs that  I may write, using C, or other high level language would probably make me more productive.  In this case, a Vampire optimised graphics Lib would certainly help. 

I would think the 68080 is already optimised a great deal therefore, the most gains would come from optimising the code.  In this case, a graphics lib written in ASM would be very good for many programmers using C or other high level language.



Manfred Bergmann

Posts 226
04 Apr 2020 17:22


Gunnar von Boehn wrote:

Manfred Bergmann wrote:

  There are also IDEs for ASM, like AsmOne, or Devpac which are kind of "playdoh" as well, no? :)
 

 
  Coding is like cooking.
  A real chef cook will want to have do all on his own.
  He will want to cut all the fresh vegies himself and not take any stuff from cans.
  He will cook all the sauces and soups himself and not use any cans.
 

Actually a pretty nice figure.

But he will not make the ingredients himself, like grow the tomatoes, etc.
Maybe he will (like we do at home), but it would also be OK, to buy them from a good shop.
He will also have to be a team-player, or a good boss.
Which means we also don't always want to reinvent the wheel. Sometimes It would be good to re-use software components.


Andrew Copland

Posts 113
04 Apr 2020 19:47


Gunnar von Boehn wrote:

  I feel we all have a different look on this topic.
 
  1) Some people look for "playdoh" coding environment.
  They want something for beginners, very easy to use, and they not care for performance, and not worry to get the most of out Amiga.
 
  2) Some people look for coding a game in C.
  They want to save learning ASM, and they hope C would not eat too much of the performance.
 
  3) Other will use ASM as only ASM gives you perfect control of what you do.

No, no, no, and no.
This is so annoying, people are not advocating using C because they're useless gimps who don't care about performance and can't master the l33t ASM language of the Amiga coding gods.

They're just using it to write the bulk of the code which is NOT performance sensitive, and then replace the performance critical parts with ASM only where necessary.

Y'know, like dev's have always done! On the Amiga itself!

The idea being that instead of having to "master" a difficult topic you can instead give people already optimised libraries in languages & build systems that they're probably familiar with.
Just let them get on with doing what they want.

It's about removing obstacles from people paths. That way they'll eventually hit a performance wall and THEN they can optimise the problem away.

Most of the time they won't ever need to get down to ASM because it'll be algorithmic 99% of the time anyway!

Gunnar von Boehn wrote:

  Lets look at the library code that Sam posted.
 
  Lets look at "screencopy" function
 

    for(src_horizontal_ptr=src_vertical_ptr;src_horizontal_ptr<src_horizontal_end;src_horizontal_ptr++)
    {
    *destination_horizontal_ptr++ = *src_horizontal_ptr;
    }
 

 
  What do we see here?
  The copy copies BYTE per BYTE.
  The copy does one COMPARE and a Conditional Branch per Byte.
  This is simple written and this is super slow code.
  You get 8BIT performance here.
  A game coder aiming for good speed would never do this.
 
  For bigger copies, or whole screen copies an experienced coder would calcukate the number of LONGs to copy and then do a copy which copies 32Bit or 64bit per loop.
  Such a tuned copy would in fact run 8 times faster.

This is such an elitist attitude, take an entire library someones written, find a bad example in it and then use it as an example of how bad the whole thing is.

Go onto his GitHub, suggest a fix and where it can be used. Even better write a simple patch/PR with an optimised memcpy, which is what you just described and is NOT Amiga ASM specific, and perhaps a few replacements.

Job done, people are always learning, it's more important to help them than tear them down for simple mistakes.

In fact this is a counter argument to yours, because anyone using this library are getting hit with that performance penalty, but once it's changed he'll release a new library version and suddenly everyone benefits from it without having to make any changes to their programs.


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
04 Apr 2020 20:49


Andrew Copland wrote:

   
Gunnar von Boehn wrote:

      Such a tuned copy would in fact run 8 times faster.
   

   
    This is such an elitist attitude,
 

   
Andrew, I think you look from a different angle then me.
If you code for a Gigaherz machine and not care for performance then you can use C , and can happily use such not tuned libraries.
But what do these coders know about AMIGA?
 
But if you want a game to perform good on classics,
or for the game to work at all on a 7Mhz A500  - then you might want another approach.
You call this "Elite"? I would call this people which know how to code.
   
 
For me Amiga was always "learning and understanding" how the Amiga works.
Understanding means for me knowing how the hardware works.
To opposite to this is "hiding information" with layers.
Hiding information = hiding learning = hiding knowledge.

I don't think that hiding knowledge is good at all.
I think that "hiding" is weakening the programmer
as as more you hide from the programmer as less you enable him.
 
 
I prefer share what I know.
I'm happy to teach people how the Amiga chipset works.
My vote is for teaching people...
Does this make sense to you?


Samuel Crow

Posts 424
04 Apr 2020 21:38


Gunnar von Boehn wrote:

  Lets look at the library code that Sam posted.
 
  Lets look at "screencopy" function
 

    for(src_horizontal_ptr=src_vertical_ptr;src_horizontal_ptr<src_horizontal_end;src_horizontal_ptr++)
    {
    *destination_horizontal_ptr++ = *src_horizontal_ptr;
    }
 

 
  What do we see here?
  The copy copies BYTE per BYTE.
  The copy does one COMPARE and a Conditional Branch per Byte.
  This is simple written and this is super slow code.
  You get 8BIT performance here.
  A game coder aiming for good speed would never do this.
 
 
  For bigger copies, or whole screen copies an experienced coder would calcukate the number of LONGs to copy and then do a copy which copies 32Bit or 64bit per loop.
  Such a tuned copy would in fact run 8 times faster.

And a call to CopyMem() in Exec will be checked for alignment as well, therefore preventing crashes as well as being patched for the version of the CPU it's running on.  A G4 will likely be able to use AltiVec for 128 bits per iteration.


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
04 Apr 2020 22:05


Samuel Crow wrote:

And a call to CopyMem() in Exec will be checked for alignment as well, therefore preventing crashes as well as being patched for the version of the CPU it's running on.  A G4 will likely be able to use AltiVec for 128 bits per iteration.

About which OS are you talking here?


Samuel Crow

Posts 424
04 Apr 2020 22:38


Gunnar von Boehn wrote:

Samuel Crow wrote:

  And a call to CopyMem() in Exec will be checked for alignment as well, therefore preventing crashes as well as being patched for the version of the CPU it's running on.  A G4 will likely be able to use AltiVec for 128 bits per iteration.
 

  About which OS are you talking here?

The link I gave was for AmigaOS 4.1 but should be an easy port because it's not in PPC assenbly, but C.


Olle Haerstedt

Posts 110
04 Apr 2020 22:54


Don't modern compilers perform pretty aggressive loop vectorization? Or maybe that's what AltiVec is?

posts 83page  1 2 3 4 5