The reason for this is very simple.
I think there is only a low number of coders left in the AMIGA scene. Also many coders have wife and kids and maybe lack the time to focus on a big game effort.
And I think of remaining AMIGA coders even less have real 3D experience. This all explains why the amount of new games coming out for ANY AMIGA model is there very very low.
 
On the other hand for a game coder this is a very nice community.
The people love games, and are loyal to the AMIGA and I think as good game will get very good support from the people.

Can you imagine Ultra-fast racer at such framerate ? The fluidity ?

Now, of course, on Jaguar, I had literally just couple road polygons, merely flatshaded, at 90 fps and it was 320x200. But it was a full redraw of framebuffer, every single pixel.

For sure 100 Hz at lowest detail (will look like crap, but as an option - why not?) is possible on Vampire. Let the user decide what he wants - not just a single pre-set config of details.

While LCDs in general suck tremendously compared to CRT, there are some 200 Hz PC monitors that can do 100 Hz *almost* as good as old CRT monitors (the difference between 60 and 100 is very visible there).

Alright, so I'll insert a separate render codepath. This will be easier than on Jag, as I don't have to create separate GPU RISC chunk - it's all just going to be 68k code anyway, so it's literally just a different render routine.

If we figure out the row of dozen(or so) parameters for P96, it should, in theory, work without any driver work involved - correct ?

I'm asking because on Jaguar, that's something I designed from the get-go (once I got to implementing 16:9 support) and due to Blitter working totally in parallel with GPU traversing the edges, it didn't matter much whether it fills the 4:3 or 16:9 or 21:9 format - there was very little performance difference.

At the moment, 4:3/16:9/21:9 is just a compile-time option, but gimme day or two, and it will be run-time choice.

Now, on Vampire, if we don't have a second chip doing the scanline fill in parallel, it will result in linear performance decrease, but I guess I should keep that option. Who knows how it will run...

I have a 21:9 monitor in my room where my Amigas are and it displays the PAL modes of V4 just fine. I have every confidence that once setup it will display on the 21:9 in other modes too. So sure, with the correct output from UMC I don't see why it wouldn't be able to run a 21:9 mode. The beauty of the 21:9 monitor is that it can run the V4 and another machine side-by-side at the same time with each input having 1280x1024. Don't ask me how it does that in 1080 lines, but it works very well indeed. I used to do that all the time with my A1200 + Indivision.

Now, i very much doubt V4 is going to be able to run at the native 2560x1080 and even if it could at some low refresh rate I suspect the Workbench experience would be poor due to icon draw times, window drag and so on. But lower 21:9 resolutions scale pretty well on the screen hardware so, why not?

Stefano Briccolani wrote:

Usually the Amiga asm coders tends to aim their games to the stock machines (unespanded a500 and a1200).

I understand that. I have the same emotional connection to Atari. So, last year, I also rewrote my engine to work on Lynx (6502C) and have it running on classic Atari 800XL as well (6502), on top of Jaguar.
But I don't have that same "break" for Amiga - so I can just jump right to the top.

Stefano Briccolani wrote:

A brand new Vampire specific 3d title can be a rule changer for the matter, so I hope you give it a try and produce the first vampire killer app

I did the grunt work over last 3 years (Higgs compiler, gameplay experimenting), so it's not like I'm starting from scratch. Once I get my Vampire board, it shouldn't take more than 2-3 weeks to get the game up&running.
After that, I'll need about a month to just keep playing with engine upgrades, benchmarks and general excitement of new platform.

From long-term perspective, it's certainly worth a shot.

I've been a coder for a living for 30 years now but I have really struggled with Amiga for some reason. I want to develop for it but every time I try I get stuck very, very quickly. My aging head has little capacity to learn ASM so I am using C. I seem to make more progress every time I try but I still soon get stuck.

I'm working on a project at the moment for other platforms and I am encouraged by the amount of SDL titles that I see ported to Vampire. So I can quietly confident of making some progress in that direction. I know everyone will scream that SDL is not the way to go for Amiga but if it's there and it get's me going then why not?

This is where having just 8-bit FrameBuffer starts to really help :)

A very good question! I will have to investigate, and probably better to wait until I have the ability to update my core (delivery will be late tomorrow hopefully). My 21:9 is now just a spare monitor. I loved it but eventually I got fed up with games not supporting 21:9 properly so replaced it with a 27" Freeseync 16:9 model.

My 21:9 is a Dell u2913WM. Nothing fancy but has a lot of inputs and good features (PBP for example!)

My 16:9 is a Dell 2719DGF.

For some reason I always try other and yet always seem to come back to Dell monitors.

For classic Amigas I have tried lots of different things including CRT but have ended with a pair if BenQ 5:4 LCDs. They would be perfect for Vampire it wasn't for the fact they only have VGA input.

I suspect each manufacturer will implement that differently - I have some TVs that correctly detect 4:3, for some I must change it via remote.

However, because I'm rewriting that portion of the renderer for Vampire anyway, might as well do it right from the start.

Maybe an Acer G276HL like in wiki 15khz LCD support because of multiple input...

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).
On the other hand, it would be possible to express interest in such port via pre-orders and if , say, 200 people go for it, it could be done.
That's quite far down the road, at this moment...

One of the differences to Jaguar is the initialization of gfx mode.
At this moment, I only need to find out how to initialize the gfx mode, the rest of my code should [in theory] work just fine.

  I found the following code sample on AmiNet:
EXTERNAL LINK 
- it starts 320x240 in chunky mode (exactly what I need)
- runs under aga, cgx or Picasso

Is this a set-up that will transfer easily to Vampire eventually ? Or should I look for something else entirely ? Shouldn't it be RTG, perhaps?

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.

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 ?

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

You mention AmigaOS - is that some kind of agreed-upon standard ?

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.

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.

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.

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.

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.

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.