Best open source, mod-able RTG-friendly FPS Engine running on 68k?

[eXeler0]

As the title says...
So many attempts, half-done stuff out there. I need some help finding the best one :-)
I'm guessing the answer is some version of the original quake engine?
Q2 is probably the last in line that could run comfortably on upper end 68k + RTG.
Trapped 2/3 sources seem lost in cyberspace.... Then there's a whole bunch of interesting but abandoned efforts (like TKG RTG, XGloom)..
Suggestions? The objective here is to identify the best platform for future Vampire-friendly mods :-)

[James]

Originally Posted by eXeler0

I'm guessing the answer is some version of the original quake engine?

Yes! The variety and quality of Quake mods is amazing, and you don't even have to buy Quake to use them:

http://eab.abime.net/showthread.php?t=80168

Here is one great example, Prydon Gate - a Diablo style RPG.

[ajk]

Quake or QII would probably be the most interesting since they are well known and also true 3D engines.

[eXeler0]

Originally Posted by ajk

Quake or QII would probably be the most interesting since they are well known and also true 3D engines.

This much we already know😉, but there are several projects out there within the quake realm. There are a bunch of quake ports and even some hacks to increase map size etc. some are for AGA some for RTG etc.
The answer I'm looking for is really a bit more specific.. *this* particular port of this engine with this patch etc... Working editors etc.

[James]

Originally Posted by eXeler0

The answer I'm looking for is really a bit more specific.. *this* particular port of this engine with this patch etc... Working editors etc.

The best Quake engine is quite obviously the glquake port by CowCat, but it needs Warp3D.

http://eab.abime.net/showpost.php?p=...&postcount=166

AFAIK all Quake ports require FPU, does Vampire even support that yet? Quake 2 is less useful because all mods need porting, and it has much less current support than the original Quake. As for editors, I know of nothing for Quake 2, but Quake on Amiga has Quest for Map editing, Demolicious for demo editing, PakMan for editing pak files, and a couple of QuakeC ports. You would of course be better off using PC software...

[eXeler0]

Thanx @James
I'm looking for something that will run on the final version of Vampire. FPU should be there and P96. But warp3d is surely a no go .

[gulliver]

Originally Posted by eXeler0

Thanx @James
I'm looking for something that will run on the final version of Vampire. FPU should be there and P96. But warp3d is surely a no go .

But Warp3D should be no issue on a Vampire if you use the cpu bound Wazp3D which is in Aminet.

[eXeler0]

Originally Posted by gulliver

But Warp3D should be no issue on a Vampire if you use the cpu bound Wazp3D which is in Aminet.

Ah, cool. Did not know about that one. For some reason it states support for 020-040 but not 060. Hope it will run on Vampire. Questions remains if a port that requires warp3d and was supposed to run on 3d hardware really can "fly" on CPU only.
Has anyone here tried the quake port that needs warp3d with wazp3d instead? If so, what kind of performance can you get on 060? (If it works)

[matthey]

Originally Posted by eXeler0

Ah, cool. Did not know about that one. For some reason it states support for 020-040 but not 060. Hope it will run on Vampire.

Wazp3D works on the 68060. There is probably no 68060 executable because the 68060 is likely too slow for most uses besides debugging and testing (Wazp3D is mostly used with fast emulation or on the PPC). A 68020 or 68040 compiled executable will almost always work on the 68060. The 64 bit result integer MUL and DIV instructions will be trapped which is slow. The Apollo core should have these instructions built in so no slow down. You will need a reasonably bug free FPU though.

Originally Posted by eXeler0

Questions remains if a port that requires warp3d and was supposed to run on 3d hardware really can "fly" on CPU only.
Has anyone here tried the quake port that needs warp3d with wazp3d instead? If so, what kind of performance can you get on 060?

I haven't tried QuakeGL/BlitzQuake on my 68060@75MHz with Wazp3D but but I expect the performance would be poor. Using the software renderer for Quake would most likely be faster although uglier and probably limited to less colors (256). I updated some of the assembler routines used for Cowcat's QuakeGL back to Frank Wille's Quake where they came from. It compiles using vbcc and runs at reasonable speeds (512x384x8 RTG is a little sluggish but playable). Wazp3D would get you 16 bit support which looks much better but it wouldn't matter if it was a slide show. Again, you need a working FPU in either case.

[eXeler0]

Originally Posted by matthey

Wazp3D works on the 68060. There is probably no 68060 executable because the 68060 is likely too slow for most uses besides debugging and testing (Wazp3D is mostly used with fast emulation or on the PPC). A 68020 or 68040 compiled executable will almost always work on the 68060. The 64 bit result integer MUL and DIV instructions will be trapped which is slow. The Apollo core should have these instructions built in so no slow down. You will need a reasonably bug free FPU though.



I haven't tried QuakeGL/BlitzQuake on my 68060@75MHz with Wazp3D but but I expect the performance would be poor. Using the software renderer for Quake would most likely be faster although uglier and probably limited to less colors (256). I updated some of the assembler routines used for Cowcat's QuakeGL back to Frank Wille's Quake where they came from. It compiles using vbcc and runs at reasonable speeds (512x384x8 RTG is a little sluggish but playable). Wazp3D would get you 16 bit support which looks much better but it wouldn't matter if it was a slide show. Again, you need a working FPU in either case.

Thanx Matt,
Ye until that FPU shows up in the Vamp, an overclocked 060 +8-bit AGA would be used as test bed, for that, poor FPS is OK I guess.
However, when the FPU *does* appear in the apollo-core, I expect it to be much faster than the one in 040/060.
(Also, by then we might have some other interesting screenmodes to try out. I believe Apollo also has superior memory bandwidth and speed compared to something like Permedia 2 cards of the time (AGP1 maxes out at 250MB/s or something like that, and most Cards had 4 or 8MB RAM))
However, to get the most out of the Apollo-core I suspect parts would need to be re-written in assembler to make full use of the additional Apollo instructions?

[matthey]

Originally Posted by eXeler0

However, when the FPU *does* appear in the apollo-core, I expect it to be much faster than the one in 040/060.

I worry more about the FPU compatibility than the speed. I would prefer an extended precision FPU rather than a double precision FPU which was last I heard (faster and saves logic but potentially less compatible). I doubt the loss of precision would affect the Quake source but it could very well affect fp support like the 68040sp/68060sp/mu68040.library/mu68060.library and compiler support which may need major rewrites for the Apollo core FPU (algorithms for extended precision can be simpler). When I left, it didn't sound like there would be enough room in the FPGA for all 68060 FPU instructions. Missing instructions could be trapped but would further reduce performance for existing code. Also, I have seen no attempt to create or document standards or gain support for changes outside of a few people.

Originally Posted by eXeler0

(Also, by then we might have some other interesting screenmodes to try out. I believe Apollo also has superior memory bandwidth and speed compared to something like Permedia 2 cards of the time (AGP1 maxes out at 250MB/s or something like that, and most Cards had 4 or 8MB RAM))
However, to get the most out of the Apollo-core I suspect parts would need to be re-written in assembler to make full use of the additional Apollo instructions?

SIMD/vector instructions could give a huge speed boost to the Apollo gfx. They would be like a fast Amiga blitter but with more versatility. The performance potential of enhancements is definitely there but Gunnar's "standards" seem to always change, never are documented and have no 3rd party support. He is a one man show and you get what he gives you.

[eXeler0]

Originally Posted by matthey

I worry more about the FPU compatibility than the speed. I would prefer an extended precision FPU rather than a double precision FPU which was last I heard (faster and saves logic but potentially less compatible). I doubt the loss of precision would affect the Quake source but it could very well affect fp support like the 68040sp/68060sp/mu68040.library/mu68060.library and compiler support which may need major rewrites for the Apollo core FPU (algorithms for extended precision can be simpler). When I left, it didn't sound like there would be enough room in the FPGA for all 68060 FPU instructions.
----><8

AFAIK very few real time engines use Double Precision Float (and only very recently). Don't think a lot of ppl are going to render or do CAD on their Vampires, to double precision seems overkill tbh. For compatibility reasons may be it can be solved with some clever libs. Idk
First time I hear they are running out of space in the FPGA, but then again, the rumors about the expansion port on the V1200 allowing bigger FPGAs maybe makes a bit more sense now :-)
(Not that I'm complaining, I wouldn't mind paying $100 more to get the more advanced FPGA right away on the 1200 version, though I'm pretty sure it's not gonna happen).

[matthey]

Originally Posted by eXeler0

AFAIK very few real time engines use Double Precision Float (and only very recently). Don't think a lot of ppl are going to render or do CAD on their Vampires, to double precision seems overkill tbh. For compatibility reasons may be it can be solved with some clever libs. Idk

The default fp precision in C is double precision. Using single precision fp can cause programs to fail which expect double precision. Most Programs and algorithms could be created to use single precision fp or fixed point math but it is more work. Most existing 3D software and engines use some double precision fp. Without double precision fp, these do not get ported. OpenGL ES is one of the few exceptions (used in embedded systems, smart phones, pads, etc.) which supports integers and single precision fp. Lack of at least double precision would cause almost all Amiga programs using fp to not work properly (the double precision parts could be done in software but very slowly). Even double precision fp could cause problems on the Amiga where extended precision fp is using the extended precision to simplify algorithms.

Most FPUs support double precision. The 68k and x86 FPU supported extended precision. FPUs are becoming less popular as SIMD units and GPUs are doing more of the fp work. Many SIMDs and GPUs are single precision fp only but supporting double precision fp is becoming more common. Most of the data being processed remains single precision fp.

Originally Posted by eXeler0

First time I hear they are running out of space in the FPGA, but then again, the rumors about the expansion port on the V1200 allowing bigger FPGAs maybe makes a bit more sense now :-)
(Not that I'm complaining, I wouldn't mind paying $100 more to get the more advanced FPGA right away on the 1200 version, though I'm pretty sure it's not gonna happen).

I wouldn't say they are "running out of space" in the FPGA. They want to fill the FPGA with useful logic which may make it look like they are "running out of space" before they optimize. Majsta is using a pretty good sized FPGA now. Implementing an FPU and/or SIMD would eat up space quickly though. A full extended precision 68060 compatible FPU (a good standard) would be expensive. Even a single precision fp SIMD would be very expensive. Right now, they are doing SIMD like instructions with integer only (probably to save logic). Eventually, a full modern processor design would need a bigger FPGA but that may only make sense if planning for an ASIC.

The higher end accelerators (1200 and big box Amiga) and stand alone FPGA Amiga boards probably could sell for a higher price. I don't think you are the only one who would opt for a larger faster more expensive FPGA (perhaps with SerDes for SATA), more memory (up to 1GB), USB and ethernet. The accelerator for 68000 systems is more price sensitive though.

[eXeler0]

So questions remain then about what sort of compatibility we will get from the Apollo-core FPU?
From a real world scenario, what approach would benefit the community best in your opinion @matthey ?
By real world scenario, I mean that we can make a pretty good guess which software that currently requires FPU is going to be used most frequently by the Vampire users. I think something like running quake is much higher on the wish list compared to running 3d raytracing software etc.

[matthey]

Originally Posted by eXeler0

So questions remain then about what sort of compatibility we will get from the Apollo-core FPU?
From a real world scenario, what approach would benefit the community best in your opinion @matthey ?

I would prioritize compatibility over performance. Most Amiga interest is currently retro so we need compatibility. Most old software will not be updated and new software will be limited at first. I would stay with an extended precision FPU which is highly backward compatible with the 68060 (very similar to 68040 FPU but with hardware FINT/FINTRZ instructions). This would make the support software much easier for people like ThoR (Mu libraries author and favors a more compatible extended precision FPU also) and me (improved C99 68k FPU support for vbcc). This option may not leave room in the FPGA for a powerful SIMD unit but at least there is software written for the FPU.

Originally Posted by eXeler0

By real world scenario, I mean that we can make a pretty good guess which software that currently requires FPU is going to be used most frequently by the Vampire users. I think something like running quake is much higher on the wish list compared to running 3d raytracing software etc.

Lightwave would be used more if it was faster. It contains many 6888x only instructions (trapped by default with 68040/68060 FPU) so it would not be blazing speed but it should be much faster using the Apollo core than on most current Amigas. Of course the games would be popular too. By the way, both Lightwave and Quake I/II need double precision floating point.

[eXeler0]

Originally Posted by matthey

I would prioritize compatibility over performance. Most Amiga interest is currently retro so we need compatibility. Most old software will not be updated and new software will be limited at first. I would stay with an extended precision FPU which is highly backward compatible with the 68060 (very similar to 68040 FPU but with hardware FINT/FINTRZ instructions). This would make the support software much easier for people like ThoR (Mu libraries author and favors a more compatible extended precision FPU also) and me (improved C99 68k FPU support for vbcc). This option may not leave room in the FPGA for a powerful SIMD unit but at least there is software written for the FPU.



Lightwave would be used more if it was faster. It contains many 6888x only instructions (trapped by default with 68040/68060 FPU) so it would not be blazing speed but it should be much faster using the Apollo core than on most current Amigas. Of course the games would be popular too. By the way, both Lightwave and Quake I/II need double precision floating point.

About that... I stopped using 3d software on Amiga about 1998. I had a good connection with McKenzie who developed Imagine. But right about then I felt I pushed the software as far as it went. I had a Blizzard 060 with 80MB RAM just to be able to render stuff. The last big project I did on Amiga was a render that took almost 11 days!! Yes for a single image.. After that I gave up and moved on to 3dsmax on PC and render times were dramatically better.

IMO To use the Vampire for any kind of serious rendering should today be considered as just plain CRAZY :-)
I think my overclocked 4.1GHz i7 is way to slow and that one is about a 1000 times faster than a 50MHz 060 (give or take). Even the best version of Vampire will be maybe a single percentage of a modern cpu. And then of course even the fastest CPUs are slow compared to GPU renderers (Octane, vray RT etc. )

My logic behind this reasoning is that it's the resulting experience that counts. If the Vampire makes it possible to run DukeNukem in 640*480. @30fps then that is usable and good. Reducing rendering times from 10 days to 3 days is still a couple of magnitudes to slow to be enjoyable.
"Stick to the stuff you can do well" - kind of thing. 😁

[matthey]

Originally Posted by eXeler0

My logic behind this reasoning is that it's the resulting experience that counts. If the Vampire makes it possible to run DukeNukem in 640*480. @30fps then that is usable and good. Reducing rendering times from 10 days to 3 days is still a couple of magnitudes to slow to be enjoyable.
"Stick to the stuff you can do well" - kind of thing.

Some people would say the fps games at 640x480x16 and less than 100 fps are completely rubbish too. Sometimes there is simple rendering and modelling that are useful (certainly more useful than most games). There is some useful productivity software for the Amiga that uses floating point. They probably aren't going to beat major productivity software on other platforms but they may still be useful and even good at some things. Most of the old software can be found for cheap or free. We can compile most software with old and new compilers if the hardware is compatible with existing Amigas. As outdated as the Amiga is in performance, the 68k+FPU is an adequate standard architecture for most modern software.

[eXeler0]

Originally Posted by matthey

Some people would say the fps games at 640x480x16 and less than 100 fps are completely rubbish too. Sometimes there is simple rendering and modelling that are useful (certainly more useful than most games). There is some useful productivity software for the Amiga that uses floating point. They probably aren't going to beat major productivity software on other platforms but they may still be useful and even good at some things. Most of the old software can be found for cheap or free. We can compile most software with old and new compilers if the hardware is compatible with existing Amigas. As outdated as the Amiga is in performance, the 68k+FPU is an adequate standard architecture for most modern software.

Don't get me wrong, I'd love to have a great FPU with maximum compatibility in Apollo but if we have to make a choice Id like to look at real world use case to know what to prioritize. And I have a feeling that games will be used 10 to 1 compared to productivity software that uses FPU.
But if we can have it all, that would be fantastic. 👍
I hope we'll hear some good news about the FPU soon.
I'm not expecting a Quake port specifically for Apollo like the one on Atari Falcon where this guy swapped some FP stuff to run on the DSP.. 😃
Or.....?

[matthey]

Originally Posted by eXeler0

Don't get me wrong, I'd love to have a great FPU with maximum compatibility in Apollo but if we have to make a choice Id like to look at real world use case to know what to prioritize. And I have a feeling that games will be used 10 to 1 compared to productivity software that uses FPU. But if we can have it all, that would be fantastic.

Having it all would be a full hardware compatible extended precision 6888x FPU and new SIMD unit with single and double precision fp support. I'm only asking for a more practical 68060 compatible extended precision FPU and an SIMD with single precision fp .

Originally Posted by eXeler0

I hope we'll hear some good news about the FPU soon.
I'm not expecting a Quake port specifically for Apollo like the one on Atari Falcon where this guy swapped some FP stuff to run on the DSP.. 😃
Or.....?

If we get a 68060 compatible enough FPU then I would expect existing software only Quake Amiga versions to be playable with an Apollo core, maybe even at 640x480. No modification required.

[eXeler0]

Does Blitz Quake support the extended size maps?