Oldskool wrote: ↑Mon Nov 25, 2024 7:40 am
Pretty cool indeed what you can do with a Mach card:
His videos are great stuff indeed!
I'm pretty sure the Nova driver is taking good advantage of the Mach32 accelerants for VDI calls since it's so very fast.
For hardware triangles in something like a game or demo I suspect it might make sense to do it on a low level to avoid potential VDI overhead?
But I think what I most would really like to get a chance to experiment with is using the et4000/w32i blitter in game scenarios.
mikro wrote: ↑Mon Nov 25, 2024 10:46 am
Not only for you. Maybe try to contact "Idek Tramielski" on AF, whether he couldn't include that code into the drivers?
That's a great idea! I'll do that once it's more presentable and cleaned up.
agranlund wrote: ↑Mon Nov 25, 2024 12:50 pmFor hardware triangles in something like a game or demo I suspect it might make sense to do it on a low level to avoid potential VDI overhead?
But I think what I most would really like to get a chance to experiment with is using the et4000/w32i blitter in game scenarios.
Yes, this would be great, wouldn't it. For me, from a game/demo making point of view, the biggest issue with those cards is that we don't have any API (well, except VDI...) to make them shine. OpenGL is for 3D, VDI is for desktop stuff (and uses maybe 10% of the card's capabilities) so we would need to steal something from ancient Linux/Unix world or invent something on our own (and hope that it would be attractive enough for others to use). The latter was tried by Didier but it didn't end very well.
All this talk about fancy pancy graphics acceleration and 3d these young kids nowadays want. In my time…..
Although it would be nice to see this 3D Raven on a Raven if we are talking demos.
But that’s probably more a sound xbios thingie holding mikro back.
There's nothing technical which would prevent this demo from working except the requirement of having 50 Hz screen refresh rate (yup, Amiga coders still sync their demos to VBL interrupt). It's true that I'd need to make a new build (remove C2P, perhaps create a custom video init) but that's not a showstopper.
Btw, if I had to port that demo today, I would have built it around SDL and it would work immediately (well, except the refresh rate issue) on every Atari clone.
agranlund wrote: ↑Mon Nov 25, 2024 12:50 pmFor hardware triangles in something like a game or demo I suspect it might make sense to do it on a low level to avoid potential VDI overhead?
But I think what I most would really like to get a chance to experiment with is using the et4000/w32i blitter in game scenarios.
Yes, this would be great, wouldn't it. For me, from a game/demo making point of view, the biggest issue with those cards is that we don't have any API (well, except VDI...) to make them shine. OpenGL is for 3D, VDI is for desktop stuff (and uses maybe 10% of the card's capabilities) so we would need to steal something from ancient Linux/Unix world or invent something on our own (and hope that it would be attractive enough for others to use). The latter was tried by Didier but it didn't end very well.
Isn't there already a TOS or MiNT port of SDL? I think so although my ST can't run it so I've not tried it.
Adding support for the best supported Raven compat card to (a fork of) SDL2 maybe? I'm not so sure upstream would want to integrate such niche retro hardware but surely SDL2 would bring the largest amount of open source software to the Raven above anything else out there?
SDL1.2 works, it's just a clone with a Nova graphics card and that's supported already.
I used it to build Tyrian and Doom.
Sound is not, but at this stage in time I would put that responsibility on the soundcard driver.
As a "temporary" measure I think the GUS driver should emulate the standard atari TOS4 sound api to let some old/existing things "just work".
That TOS4 API is completely sub optimal for something like a GUS (or even a Vampire V4SA) since it has no idea about fancy multi-channel hardware features or dedicated sound ram - but as a first step and fallback it would be nice.
Ideally someone would make a nice central sound API that is properly hardware-abstracted and understands modern concepts (including any number of devices of same or different kinds). Like Linux, Mac, Windows and even Amiga (with AHI).
Done correctly it could greatly minimize effort of making drivers, as well as application code that wants to play sounds. Letting the bulk of a lot but mostly generic heavy lifting be handled by the sound system in a single place. And then finally teach SDL to support that API too.
A considerable effort, and that imaginary someone would need to have quite a bit of time and dedication on their hands.
Maybe try to contact "Idek Tramielski" on AF, whether he couldn't include that code into the drivers?
