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
Information about the Apollo CPU and FPU.

Writing 3D Engine for 68080 In ASMpage  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 

Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
28 Dec 2019 07:05


Isnt c2p discussion a bit obsolete with:
 
  - Hmm RTG that can have as much mem that you allocate from 128 or 512mb, its ddr3 fast and I believe negates the c2p need?
  - Direct chunky modes that SAGA should support?
  - 11MB FAST RAM mapped as CHIP which V4 brings so effectively there is way more chip RAM to store gfx?
  - SAGA should have Blitter en par with 080 (like AGA one was for 020 :) so maybe that could be used to offload but other then c2p, drawing 2D?

So, if one would strive from Vamp and Kick from Classic, a OS friendly RTG P96 PiP and then later when on Vamp trying to hit SAGA? OS could be used, closed and metal banged, OS reopened when needed?


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
28 Dec 2019 07:50


Vladimir Repcak wrote:

That's quite a performance difference, plus bitplanes (no chunky). Such a release would certainly need completely new art assets and 3D engine (utilizing Blitter). 

Blitter on AMIGA is very weak for 3D.
Best you can do with it are draw some grid lines for a 3D game in C64 style (ELITE) in lowres.
 
I think its important to understand that Vampire and other Amiga have a huge performance gap.
Please look at the PERFORMANCE TAP to get a picture of this.
 
The average accelerate Amiga with 68030 @ 25-50MHz has 4-9 Mips
The rare  68060 accelerated AMIGAs have 40 Mips.
The VAMPIRE has 150 Mips.
 
In addition to this comes the memory speed difference.
On classic AMIGAs you have a bottleneck of bus bandwidth to GFX memory. Of 3-7 MB/s depending of your system.
The VAMP has 500 MB/s ... this is a very different playground.
 
One game which get the most out of such different performance will be a challenge.
 


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
28 Dec 2019 09:32


Gunnar von Boehn wrote:
 
  One game which get the most out of such different performance will be a challenge. 

Few please ;)

Plus RTG/P96 levels of performance of S3 Virge class+ of Amiga Classic gfx cards as default
EXTERNAL LINK 


Vladimir Repcak

Posts 359
28 Dec 2019 10:13


Mark Watson wrote:

Vladimir Repcak wrote:

  And - which one is better for coding - WinUAE of FS-UAE ?
 

 
  FS-UAE is easy to compile and add your own modifications / hooks.  WinUAE debugger works better under Windows.  FS-UAE debugger on windows required some patches and I still don't have it working perfectly.  Both have generally excellent emulation. I'd say WinUAE works better out of the box / features land first, FS-UAE is better when you want to customise things, or are not on windows.
 

Thanks for the perspective. I'm on Windows, so I currently installed UAE - boy is it a beast overloaded with features (looke list quite a few man-years were spent there) compared to the emu on Jag :)

As for debugging - over the last years I created an extensive set of debugging prints and frame slow-downs, so especially in higher res, debugging shouldn't be needed.

Also, it's a different kind-of dev approach - I tend to print all values during initial coding - double-checking as I write it (and execute builds every few minutes), so this way I almost never have to come back and spend 10x more time debugging.



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
28 Dec 2019 10:26


Vlad how about making a plan.

Do you think you can get your general 3D code running in short time in UAE?

Maybe we can even work together here a little?

If you have your CPU renderer running on UAE,
then its matter of copy file to Vamp to run it there.

We can then look into "tweak" like use S3 compressed texture.
Like discuss using 3D-Line-Rasterizer
And maybe we can also help you here.

What type of Demo do you plan to do?
Do you know the "Battle of Yavin" PC game?
Its an Indi game, and relative easy.

Do you recall this old arcade game?
EXTERNAL LINK 
It has a very simple game design which can be coded by a single person in short time...
It has also a very nice game play which makes fun.
Instatt using wire models we could use pretty nice textured models
make it look real nice.

Would something like this be fun for you?


Vladimir Repcak

Posts 359
28 Dec 2019 11:07


Vojin Vidanovic wrote:

Vladimir Repcak wrote:

  I'm quite confused about the OS choice. Looks like there's quite a few choices (and issues) there.
 

 
  Even more and its not best
 
 
Vladimir Repcak wrote:

  And the last thing we need is to implement features in OS-specific way - so I wanna try to access HW as directly as possible.
 

 
  For basic functions like opening windows, closing app etc. its most recommended to be OS friendly. For end results to bang the metal. Its possible to combine.
 
 

  Which is probably not a good idea for resolution. By RTG - what is usually meant - it's just libraries, correct ? Meaning - you have RTG under all variants of available OS ?
 

 
  Yes, for all modern OS incarnations and is de facto standard for 16-bit and 24-bit display of Amiga. Its OS extension beyond 8-bit screens for those with gfx cards.
 
 
 

  What about filesystem - is there some kind of API that is completely generic across all OS ?
 

 
  FS - Use system functions and it will adjust. Fastest is PFS.
 
  API - use ReAction OS 3.9 or MUI 3.8 / 5.0
 
 
 
  You mention AmigaOS - is that some kind of agreed-upon standard ?
 

 
  Basic CBM standards of 1994 + a lot of 3rd party build pieces of OS. When we say AOS here, we mean heavily patches OS 3.9. See AmigaOS versions on Wiki, and you will see how OS was growing in functions and ablities to be inclusive and expandable.
 
 

Thanks for the search terms. Each one resulted in some long threads on EAB that I will study over the next few days.

Even from my current limited understanding on all available options in terms of OS and libraries, it seems like it's entirely possible (and easy) for someone with Vampire to install a combination of OS+libs that will be incompatible in some way.

What exactly do you mean by "System functions" for FileSystem ? Is there some sort-of very low-level API (ideally, ASM) that all the other ones (PFS,FFS,SSF) are built upon ?


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
28 Dec 2019 11:35


EXTERNAL LINK 
I would recommend to not waste time on setting up your environment at all. But to get this as a quick start.


Vladimir Repcak

Posts 359
28 Dec 2019 11:38


Gunnar von Boehn wrote:

Vlad how about making a plan.
 
  Do you think you can get your general 3D code running in short time in UAE?

I certainly would love to. Preferably yesterday :)
Yesterday night I installed WinUAE, got some ROM and now I'm staring at the screen with animated floppy disk trying to figure what to do now. Found some YT vids on WinUAE with 12 episodes, so watching it now.
 
Gunnar von Boehn wrote:

  Maybe we can even work together here a little?
 
  If you have your CPU renderer running on UAE,
  then its matter of copy file to Vamp to run it there.
 
  We can then look into "tweak" like use S3 compressed texture.
  Like discuss using 3D-Line-Rasterizer
  And maybe we can also help you here.

I sure wouldn't mind some help in pointing in right direction as I'm in desperate need of that right now :)

Gunnar von Boehn wrote:

  Do you know the "Battle of Yavin" PC game?
  Its an Indi game, and relative easy.

I'm familiar with the StarWars scene (1977 movie), but not that particular PC game.
 
Gunnar von Boehn wrote:

  Do you recall this old arcade game?
  EXTERNAL LINK 
  It has a very simple game design which can be coded by a single person in short time...
  It has also a very nice game play which makes fun.
  Instatt using wire models we could use pretty nice textured models
  make it look real nice.
 
  Would something like this be fun for you?

Sure, I'm very familiar with this one. I spent a great deal of effort creating very fast unrolled line drawing methods on 6502.
I even recently played this on real arcade at PRGE 2 months ago.

Always wanted to make this particular sequence on Jaguar.

I cannot even begin to think how it could look with textured surfaces and at higher resolution. Apply some fog into the distance, some height-based shading and it'll look fantastic in motion!

This scene would certainly make a great test-bed for the 3D features of Vampire. I'm in :)

Gunnar von Boehn wrote:

  What type of Demo do you plan to do?

So, my latest game build from 8 weeks ago didn't enable all features (that I already had in summer) for PRGE (I ran out of time), but I could fly through 25 levels and had enemies spawning (up to 4) with XZ collision detection (just not following the track along YPOS - as that was disabled). So, it was entirely playable.



Vladimir Repcak

Posts 359
28 Dec 2019 11:58


Here's a short summary of what is running now:

- StunRunner environment - flatshaded with each track segment in different color (smoothly interpolating various shades)
- 25 levels
- each level has a displacement track curve (XY offset) along which the engine, at loading time, extrudes the track mesh. This allows to create the track by drawing simple 3D lines in 3dsmax

- RPG parameters (Level, HP, Armor, Damage)
- Procedural generation of RPG parameters (e.g. semi-random)
- You have access to all 25 levels at the start, but need to upgrade yourself many times to be strong enough to tackle each next level (RPG grinding)

- Audio - I have the AIFF player and some audio FX (just not the mixer, yet)

- There's 2 classes of enemies - shooting one and non-shooting one. Each has different RPG (HP, Level, Armor, Damage) and behavior characteristics (moving patterns - speed, ranges, etc.)

- Right before PRGE I implemented importing generic objects from 3dsmax, so now each level starts speeding up from the Hangar with animated door opening sequence

Great majority of code is 68000, only the 3 KB rasterizer (transform+draw+clip) is written in GPU RISC Assembler, everything else is 68000.

Now, I also have the quad rasterizer written in 68000, which I'd rather use instead of the GPU's triangle rasterizer, because it's much more generic and handles almost all clipping scenarios (there's limits how much clipping code I could fit into 3 KB code on RISC). I have tested the 68000 quad rasterizer on different data sets, so I reckon it shouldn't take more than a day or two to make it run with the current track 3D mesh.



Martin White

Posts 85
28 Dec 2019 12:31


Gunnar von Boehn wrote:

EXTERNAL LINK 
  I would recommend to not waste time on setting up your environment at all. But to get this as a quick start.

Isn't gcc 2.x way out of date now though? I guess not a problem if you are going to code in ASM :)

Is there a WinUAE config file available anywhere that matches V4SA as close as possible? I want to look at cross-compiling some things from VSCode and that would be a help. I'm not sure if I will get to that today, maybe later.

I want to get to the point of determining if my project is even viable on 68080 fairly quickly so that I don't hold up the other targets if it isn't.


Kamelito Loveless

Posts 260
28 Dec 2019 12:34


AmigaOS  can of course be programmed using 68k. To open/close read/write files you’ve the functions above available in the DOS library. When you launch your game from either the CLI or Workbench you load your assets kill the OS and continue your game by hitting the HW directly if you need to load or write a file during the game then you enable the OS and so on. There’s minimal code to Take over the system see Amiga how to code v7 for example, no need to use any library or wondering about    The file system used. Of your you could also use another layer of abstraction if you want but you’ll loose some performance.
  EXTERNAL LINK AmigaOS API
  EXTERNAL LINK How to code

EXTERNAL LINK Mini startup I don’t think it handle the launch from WB.

 


Vladimir Repcak

Posts 359
28 Dec 2019 12:43


A1200 coder wrote:
 
  3D-texturemapped games with an A1200+68060/AGA are possible, you need to use a c2p routine (lots available on aminet) which converts chunky pixels from fast ram (CPU-only memory) to the native planar format in chip ram (slow access gfx memory). 8-bit chunky pixels (giving 256 colors) is the most common format, but also e.g. 4-6 bit chunky pixels can be used to speed up the c2p routine. A 320x256 screen with 8-bit chunky pixels takes a lot of time to convert even with a 68060, thanks to the slow chip ram, so no fast games with that, 25 fps can be achievable in best case. With 4-bit chunky pixels (giving 16 colors) it may be possible to get 50/60 fps with a 68060, if the game is otherwise simple enough, e.g. using only flatshaded polygons.
Well, I could do some limited textured gfx on 1.79 MHz 6502, so certainly 68060 should be able to pull off much more. But why bitplanes on 060 ? Isn't 060 always in an RTG system anyway ?

Or does RTG merely remap the chunky to planar in SW ? If that's the case, then that would obviously suck tremendously from performance standpoint. I've done some bitplanes on PC, so I got a bit of experience with it and can't imagine some generic function to be remotely fast.

Perhaps I'm mixing RTG gfx card with just SW-based RTG drivers that rasterize on 060 ?

A1200 coder wrote:

  You may also try use some smart tricks like two 16 color dualplayfields (total ~32 colors), with blitter drawing some simple stuff in the other playfield (background and horizon) while CPU is drawing in the other playfield the objects which strictly come in front of all background with a c2p routine. While CPU and blitter cannot usually write at the same time into chip ram (gfx memory) without blocking the other one out, there will be some idle time when CPU is rendering the objects in chunky fast ram buffer, and blitter can then access chip ram undisturbed. Also clearing display memory with blitter fully concurrently with CPU accessing display memory is possible to do without disturbing access for both.

  You basically listed all the tricks I'm already doing on Jaguar :- ))))
I absolutely plan on doing separate background playfield (2D bitmap) and foreground (3D scene) on Amiga too. Though, on Jag, I didn't have to go down to 4-bit color depth, and 16-bit plus 8-bit was running just fine at 640x200.

Hopefully, the two-playfield setup is gonna run just fine on SAGA ?

A1200 coder wrote:

  On classic Amigas with better CPUs than the 68000, the blitter is too slow to be used for drawing and filling flatshaded objects. It is fast if you have only non-overlapping objects and empty backgrounds like in demos, but in games with more complex backgrounds and objects it's usually not much faster than a highly optimized 68000 CPU drawing routine. Because the blitter then needs to perform extra copy and clear passes when filling surfaces of objects.

Because I am doing this full-time, and burning through my savings, I can't simply devote 1 or 2 weekends to a separate render path like that. Maybe once I start generating income...

But, if at least 100 people with such config confirm interest, I don't mind creating a completely separate build for 060, 040 or hell even stock A500. Vampire first, of course...
 
A1200 coder wrote:

  But yeah, even on a 68060 system, it's still possible to make some use of the blitter for something useful, if it is done smartly. But also, like you can see, a classic Amiga needs different ways of coding than a Vampire system.
I've gone through some coding threads on EAB, where people experimented with various ways of using blitter for flatshading - it's definitely an exciting challenge !



Gunnar von Boehn
(Apollo Team Member)
Posts 6207
28 Dec 2019 13:03


Vladimir Repcak wrote:

Perhaps I'm mixing RTG gfx card with just SW-based RTG drivers that rasterize on 060 ?

Let me give you some example info

Old AMIGA Model 500..3000
Resolution 320x256
GFX mode Planar
Colors 16
3 MB/sec memory bandwidth free for drawing the screen

Old AMIGA Model 4000 and 1200
Resolution 320x256
GFX mode Planar
Colors 256
5 MB/sec memory bandwidth free for drawing the screen

Some AMIGA users have upgraded their system with GFX Expansion with Chunky mode. It depends on the model what memory bandwidth you have to them typically 3-8 MB/sec

So in short bandwidth is always low compared to what we talk about.



Vladimir Repcak

Posts 359
28 Dec 2019 13:05


Kamelito Loveless wrote:

AmigaOS  can of course be programmed using 68k. To open/close read/write files you’ve the functions above available in the DOS library.

Which specific library do you mean ?

Kamelito Loveless wrote:

When you launch your game from either the CLI or Workbench you load your assets kill the OS and continue your game by hitting the HW directly if you need to load or write a file during the game then you enable the OS and so on.
Does it make sense for me to disable the OS if I will need filesystem functionality upon every level reload ? Or is there a separate reason why it's useful ?

Kamelito Loveless wrote:

There’s minimal code to Take over the system see Amiga how to code v7 for example, no need to use any library or wondering about    The file system used. Of your you could also use another layer of abstraction if you want but you’ll loose some performance.
    EXTERNAL LINK AmigaOS API
    EXTERNAL LINK How to code
 
  EXTERNAL LINK Mini startup I don’t think it handle the launch from WB.
   
Thanks a lot for the v7.pdf. Great doc. I'll be studying it over next few days. Right now my head is exploding :)))

The Filesystem performance is not important for me, as I don't load files in the middle of the level.
Now, if I were to port my C++/DirectX endless terrain-streaming demo that only keeps 16x16 terrain chunks in RAM and streams the rest from HDD (if you have 65536x65536 terrain chunks - that's fine) - then it would be a different thing. But, we're not there yet :)



Vladimir Repcak

Posts 359
28 Dec 2019 13:15


Gunnar von Boehn wrote:

EXTERNAL LINK 
  I would recommend to not waste time on setting up your environment at all. But to get this as a quick start.

Oh, that's awesome - it's like a Virtual Machine with everything preinstalled !

It's been quite some time since I talked to a Hungarian :) Luckily, readme was in English.

I downloaded it, loaded in WinUAE, now need to figure out how to work that shell...


Vladimir Repcak

Posts 359
28 Dec 2019 13:23


Vojin Vidanovic wrote:

Isnt c2p discussion a bit obsolete
Yeah, we were talking about a possibility of a non-Vampire build (later, post release).

Vampire build will certainly not deal with bitplanes and will do things SAGA way.



Vladimir Repcak

Posts 359
28 Dec 2019 13:30


Gunnar von Boehn wrote:

Vladimir Repcak wrote:

  Perhaps I'm mixing RTG gfx card with just SW-based RTG drivers that rasterize on 060 ?
 

 
  Let me give you some example info
 
  Old AMIGA Model 500..3000
  Resolution 320x256
  GFX mode Planar
  Colors 16
  3 MB/sec memory bandwidth free for drawing the screen
 
  Old AMIGA Model 4000 and 1200
  Resolution 320x256
  GFX mode Planar
  Colors 256
  5 MB/sec memory bandwidth free for drawing the screen
 
 
  Some AMIGA users have upgraded their system with GFX Expansion with Chunky mode. It depends on the model what memory bandwidth you have to them typically 3-8 MB/sec
 
  So in short bandwidth is always low compared to what we talk about.
 

Thanks. This HW fragmentation is quite brutal. This is just like PC back in the day! Everybody had different:
- CPU
- RAM
- HDD
- GFX card

Good luck handling [with one build] all those various configurations...


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
28 Dec 2019 14:53


Vladimir Repcak wrote:
 
  Thanks. This HW fragmentation is quite brutal. This is just like PC back in the day! Everybody had different:
  - CPU
  - RAM
  - HDD
  - GFX card
 
  Good luck handling [with one build] all those various configurations...

Similar like CGA EGA VGA and 8-bit/16-bit sound cards.

So, its best to jump to Vamp with real 24-bit gfx metal to bang and 16-bit sound. Like jumping from ST/STE to Falcon 060 Videl.



Nixus Minimax

Posts 416
28 Dec 2019 18:56


AmigaOS is the operating system every Amiga came with. It comprises several libraries among which the most fundamental are exec.library, dos.library, intuition.library and graphics.library. They are always available from the Amiga ROM (the "kickstart"). The last version Commodore did was 3.1 which may be considered standard. Everything after it were basically variants of this version with various bugfixes and new bugs added. For what you are going to do even v2.0 would suffice.
 
  Disabling the OS is something like an Amiga tradition but it doesn't make too much sense here. Even with a 50 MHz 030 the OS idling in the background took only about 5% processor time. With an 080 that is 20 times faster the speedup gained by disabling the OS becomes totally negligible. And it's much cooler if multitasking is still working, network connections stay up and you can just put the game screen into the background.
 
  Now you will want chunky pixels. Since AmigaOS never supported chunky pixels, you will have to go through either cybergraphx or p96 among which I would recommend the first because P96 is compatible with the earlier cybergraphx. If you code for cybergraphx, your code will run on any Amiga system that has chunky pixels - the Vampires are the most powerful among these.
 
  I think you will find that AmigaOS is actually a pretty nice OS for its time and is particularly easy to code for in ASM.
 


Kamelito Loveless

Posts 260
28 Dec 2019 19:46


I meant dos.library.
  Disabling the OS is good for maximum performance if not then the OS or others programs running will have an impact on your program speed. Maybe with the Vampire it is not needed, you'll have to test with the OS active and see.
  See the link below at section 6.5 to see how to deal with files under AmigaDOS using 68k.

  EXTERNAL LINK 

posts 429page  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22