English Amiga Board Amiga Lore


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 24 March 2016, 08:15   #1
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,391
Best open source, mod-able RTG-friendly FPS Engine running on 68k?

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 :-)
eXeler0 is offline  
AdSense AdSense  
Old 24 March 2016, 14:35   #2
James
Registered User

 
Join Date: Mar 2010
Location: Beckenham/England
Posts: 421
Quote:
Originally Posted by eXeler0 View Post
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.

Click image for larger version

Name:	PrydonGate_Scaled.png
Views:	251
Size:	395.4 KB
ID:	47994
James is offline  
Old 24 March 2016, 16:10   #3
ajk
Registered User
ajk's Avatar
 
Join Date: May 2010
Location: Helsinki, Finland
Posts: 850
Quake or QII would probably be the most interesting since they are well known and also true 3D engines.
ajk is offline  
Old 24 March 2016, 16:32   #4
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,391
Quote:
Originally Posted by ajk View Post
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.
eXeler0 is offline  
Old 24 March 2016, 16:56   #5
James
Registered User

 
Join Date: Mar 2010
Location: Beckenham/England
Posts: 421
Quote:
Originally Posted by eXeler0 View Post
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...
James is offline  
Old 24 March 2016, 18:49   #6
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,391
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 .
eXeler0 is offline  
Old 24 March 2016, 19:10   #7
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 39
Posts: 1,357
Quote:
Originally Posted by eXeler0 View Post
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.
gulliver is offline  
Old 24 March 2016, 20:20   #8
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,391
Quote:
Originally Posted by gulliver View Post
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)

Last edited by eXeler0; 24 March 2016 at 20:54.
eXeler0 is offline  
Old 24 March 2016, 21:07   #9
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,006
Quote:
Originally Posted by eXeler0 View Post
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.

Quote:
Originally Posted by eXeler0 View Post
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.
matthey is offline  
Old 24 March 2016, 22:17   #10
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,391
Quote:
Originally Posted by matthey View Post
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?
eXeler0 is offline  
Old 24 March 2016, 23:00   #11
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,006
Quote:
Originally Posted by eXeler0 View Post
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.

Quote:
Originally Posted by eXeler0 View Post
(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.
matthey is offline  
Old 25 March 2016, 11:13   #12
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,391
Quote:
Originally Posted by matthey View Post
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).
eXeler0 is offline  
Old 25 March 2016, 17:36   #13
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,006
Quote:
Originally Posted by eXeler0 View Post
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.

Quote:
Originally Posted by eXeler0 View Post
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.
matthey is offline  
Old 25 March 2016, 18:55   #14
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,391
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.
eXeler0 is offline  
Old 25 March 2016, 19:45   #15
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,006
Quote:
Originally Posted by eXeler0 View Post
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.

Quote:
Originally Posted by eXeler0 View Post
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.
matthey is offline  
Old 25 March 2016, 20:38   #16
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,391
Quote:
Originally Posted by matthey View Post
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. 😁
eXeler0 is offline  
Old 25 March 2016, 21:17   #17
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,006
Quote:
Originally Posted by eXeler0 View Post
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.
matthey is offline  
Old 25 March 2016, 21:31   #18
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,391
Quote:
Originally Posted by matthey View Post
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.....?
eXeler0 is offline  
Old 25 March 2016, 23:20   #19
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,006
Quote:
Originally Posted by eXeler0 View Post
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 .

Quote:
Originally Posted by eXeler0 View Post
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.
matthey is offline  
Old 28 March 2016, 15:00   #20
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,391
Does Blitz Quake support the extended size maps?
eXeler0 is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
cannot open rtg.library AGS support.WinUAE 6 02 April 2015 18:41
68k + Picasso (RTG) Demos ?? Amiten Amiga scene 14 27 August 2013 17:39
68k & 060 friendly code... korruptor Coders. Tutorials 5 05 February 2011 15:46
RTG FPS Question Ed Cruse support.WinUAE 5 28 October 2008 17:07
If I have WinUAE running on a 50 or 100Hz screen in PAL mode (50 fps), [more] fmcpma support.WinUAE 3 27 August 2006 11:17

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 06:49.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.34242 seconds with 12 queries