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

[matthey]

Originally Posted by eXeler0

You sure? Don't think I've ever seen the original Q3 run on say something like a Pentium MMX without a 3d graphics card. I remember playing it on my PII 400MHz + nVidia TNT at the time. And I remember noticing improvements when I moved to TNT2. (Mostly when running in 24/32-bit color mode).

The PII was still MMX which was integer only, only 8x64 bit registers, couldn't use the FPU at the same time as MMX because of shared SIMD/FPU registers, etc. It didn't help much. Graphics had to go through a PCI or AGP bus and the GPU no doubt did a lot of the work. When I say playable I mean playable in Amiga terms which is low resolution 16 bit with 10-20 fps .

Originally Posted by eXeler0

Just speculating, but I expect the Apollo FPU beat the 060 by some margin. ;-)

I don't know. FPGA is at a disadvantage for wide operations and it could need many traps if only the FPU instructions listed at http://www.apollo-core.com/index.htm?page=instructions are available. Faster memory and full pipelining of the FPU aren't going to overcome huge bottlenecks elsewhere.

Originally Posted by eXeler0

Well, tbh that has already been done in the Apollo core, hasn't it? The IPC is improved over 060 even if compilers aren't up to speed yet.. Clock is higher, memory bandwidth by far exceeds anything previously seen on Amiga.
FPU is still shrouded in mystery though.

Yes. The Apollo core has better integer performance than the 68060 which helps FPU performance. Most FPU using code is mixed integer/fp code. Much of it can be executed in parallel.

Originally Posted by eXeler0

Compiler optimizations should come one day, but then I suppose the easiest solution is the brute force alternative. The cost of performance is passed on to the buyer. (Meaning, were paying top dollar for Apollo core in an Arria 10 FPGA. But then we magically have a 400MHz 060 and we can screw all optimizations ;-)

It doesn't look like there are many new instructions besides the SIMD instructions and they are integer only which doesn't help most 3D. Maybe the sound could be mixed with them but it is not exactly CPU hogging.

The only new instructions which most compilers would use much are the ColdFire MVS/MVZ instructions. MOVEX would be used rarely.

[Ratteler]

So the second part of this question is... any good Blender 3D Game Engine to Quake 1 or Quake 2 converters.

I would love to make some 3D style games in BGE and make them available for Vampired Amigas.

[eXeler0]

Originally Posted by matthey

The PII was still MMX which was integer only, only 8x64 bit registers, couldn't use the FPU at the same time as MMX because of shared SIMD/FPU registers, etc. It didn't help much. Graphics had to go through a PCI or AGP bus and the GPU no doubt did a lot of the work. When I say playable I mean playable in Amiga terms which is low resolution 16 bit with 10-20 fps .

I'd love to see someone try (NovaCoder, come baaack ;-), but until the Apollo core moves to Arria10 FPGA I doubt it will run at any kind of interactive frame rates.

Here are the minimum specs (for Q3) apparently..

CPU:
Pentium® 233 Mhz MMX®processor with 8 MB Video Card
Or Pentium II 266 Mhz processor with 4 MB Video Card
Or AMD® 350 Mhz K6®-2 processor with 4 MB Video Card

RAM:
64 MB RAM

GPU:
3-D Hardware Accelerator with full OpenGL® support

...........

So regardless of the CPU speed and SIMD version, it requires an OpenGL 3d card with at least 4MB.


I read this as if it can not be a straight port, but more of a rewrite where some stuff simply needs to be replaced..
(Ok, now we need that guy who made use of the DSP in an Atari Falcon 030 to run Quake;-)

[matthey]

Originally Posted by eXeler0

I'd love to see someone try (NovaCoder, come baaack ;-), but until the Apollo core moves to Arria10 FPGA I doubt it will run at any kind of interactive frame rate.i

If an Arria10 would allow a single precision floating point SIMD then that would likely be enough.

Originally Posted by eXeler0

3-D Hardware Accelerator with full OpenGL® support

It may be worthwhile to write a Warp3D driver (giving OpenGL support) using a single precision floating point SIMD. No single precision floating point SIMD equals no Quake III on an FPGA CPU. An FPGA can simulate a SIMD easier than a wide FPU. It just needs a big enough FPGA, especially for floating point.

[James]

Blaze - using the WinQuake engine.

http://www.moddb.com/games/blaze/videos/water-facility

[eXeler0]

Originally Posted by matthey

If an Arria10 would allow a single precision floating point SIMD then that would likely be enough.



It may be worthwhile to write a Warp3D driver (giving OpenGL support) using a single precision floating point SIMD. No single precision floating point SIMD equals no Quake III on an FPGA CPU. An FPGA can simulate a SIMD easier than a wide FPU. It just needs a big enough FPGA, especially for floating point.

You mean they should have copied AMD's 3dNow! Instead of Intel's MMX? ;-)


Skickat från min HTC One via Tapatalk

[matthey]

Originally Posted by eXeler0

You mean they should have copied AMD's 3dNow! Instead of Intel's MMX? ;-)

More like SSE actually. 3DNow was supposedly first to use floating point in the SIMD but it was partially to avoid the x87 FPU (not nearly as nice as the 68k FPU) and was spartan in functionality. SSE is the standard commonly used with lots of existing code. Altivec was another option which commonly uses single precision and which the Apollo-core SIMD was patterned after early on but there isn't as much code for it. The PPC is archaic at the hardware level which designers didn't think would be a problem because compilers would generate all the code but a good portion of SIMD code has been hand coded in assembler.

[eXeler0]

Originally Posted by matthey

More like SSE actually. 3DNow was supposedly first to use floating point in the SIMD but it was partially to avoid the x87 FPU (not nearly as nice as the 68k FPU) and was spartan in functionality. SSE is the standard commonly used with lots of existing code. Altivec was another option which commonly uses single precision and which the Apollo-core SIMD was patterned after early on but there isn't as much code for it. The PPC is archaic at the hardware level which designers didn't think would be a problem because compilers would generate all the code but a good portion of SIMD code has been hand coded in assembler.

MMX kind of disabled the x87 by hijacking registers but what about AMMX and a future 68k FPU. I'm not sure I get this part. The Apollo core AMMX gives you 32 registers. How will this affect the future FPU.
If the Pentium MMX couldn't use the FPU for Float the I get the problem, but if Apollo Core AMMX and FPU registers don't "clash" then you should be able to use both at the same time?

btw, Just saw that BigGun is welcoming coders that could optimize stuff (primarily video and audio players) for AMMX. So maybe we'll be seeing some benefits pretty soon. Riva player could become quite powerful I imagine.


Skickat från min HTC One via Tapatalk

[matthey]

Originally Posted by eXeler0

MMX kind of disabled the x87 by hijacking registers but what about AMMX and a future 68k FPU. I'm not sure I get this part. The Apollo core AMMX gives you 32 registers. How will this affect the future FPU.
If the Pentium MMX couldn't use the FPU for Float the I get the problem, but if Apollo Core AMMX and FPU registers don't "clash" then you should be able to use both at the same time?

AMMX shouldn't affect the FPU as it is not attached to it. FPU instructions do originate in the integer units but i doubt this will cause a problem for now. AMMX instructions could cause problems with the integer register accesses but I don't know how this is implemented. Perhaps there is no problem at the low clock speed of a processor in FPGA. The design is suspect for the future though if floating-point is added to the SIMD unit (which would give floating point in the integer unit registers) or processor speeds increase with an ASIC. Code maintainability is also decreased by joining units.

Originally Posted by eXeler0

btw, Just saw that BigGun is welcoming coders that could optimize stuff (primarily video and audio players) for AMMX. So maybe we'll be seeing some benefits pretty soon. Riva player could become quite powerful I imagine.

We will see but I don't expect much. A working FPU is more exciting because it would enable existing Amiga code to run.