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?

Few please ;)

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

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.

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?

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 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.

- 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.

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.

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

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 !

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.

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 :)

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...

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

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.

  EXTERNAL LINK