Amiga.org
Amiga computer related discussion => Amiga Gaming => Topic started by: NovaCoder on August 24, 2012, 01:54:31 AM
-
My new 68k port of Quake based on WinQuake (http://quake.wikia.com/wiki/WinQuake)
video (http://www.youtube.com/watch?v=lcNmWZRqFbQ&feature=youtu.be)
Requirements:
060 AGA/RTG (cyberGFX API)
I'm still paying with this port in my (limited) spare time and hope to get some more speed out of it.
I'm currently working on (yet) another 060 AGA port, more news when I get it up and running. I might have something to show in time for the next Amiga meeting in Melbourne on the 6th of September.
I've already ported both ScummVM (http://www.youtube.com/watch?gl=SN&feature=relmfu&hl=fr&v=jyICKyz4BoY) and BOOM (http://www.youtube.com/watch?gl=SN&feature=relmfu&hl=fr&v=3XG7-U5HdpI) to AGA.
-
Good work!!
-
Cheers, will give it a whirl. :pint:
-
Nice work, keep it up!
Wish I had a 060 setup just to try it.
-
WOW! That looks amazingly smooth for a 68xxx processor. I wish you only the best on finishing up.
By the by, will there be a network/multiplayer option? I'm not holding my breath since I figure the hardware is getting taxed to the max as it is. ;)
-
To NovaCoder:
Is that AGA in your video?
-
WOW! That looks amazingly smooth for a 68xxx processor. I wish you only the best on finishing up.
By the by, will there be a network/multiplayer option? I'm not holding my breath since I figure the hardware is getting taxed to the max as it is. ;)
No sorry, no network or multiplayer support will be added. I find with my AGA ports it's best to only support the single player game mode.
-
To NovaCoder:
Is that AGA in your video?
Yes just good old double-buffered AGA, RTG would be slightly quicker.
-
@NovaCoder
Again here : seven emulated 060 instructions on this game !
Slow down because the 68060.library is not fast you know...
-
What about Cyberpatcher/Oxypatcher? I remember once playing Quake (on 060) and wondered how it crawled. I had accidentally disabled Oxypatcher. I think the speed drop was more than 50%.
-
Use the last version of OxyPatcher => v3.14
-
What about Cyberpatcher/Oxypatcher? I remember once playing Quake (on 060) and wondered how it crawled. I had accidentally disabled Oxypatcher. I think the speed drop was more than 50%.
Cyberpatcher/Oxypatcher/Redox solve most of the slowdown but take some memory and introduce another potential failure point. They should not be necessary. Any compiler supporting the 68060 and compiled for the 68060 should not use trapped instructions that are not available in the 68060. Exceptions should be reported to the compiler maintainers.
-
Any compiler supporting the 68060 and compiled for the 68060 should not use trapped instructions that are not available in the 68060
That's the theory !
The reality is very different...
-
That's the theory !
The reality is very different...
Yea, theory != reality or the world would be much different ;). Does the latest GCC generate trapped 68060 instructions when compiled for the 68060? The latest vbcc should not at least. It's targeted for embedded devices where there might not be enough memory for the 68060 software support library. The newest GCC versions seem to be targeted for bloated environments with high level languages where speed isn't important any more because it's going to be slow regardless :/.
-
AmiQuake is compiled using gcc version 3.45 and for 060 only, best version we've got I'm afraid :(
-
what environment you are working under? are you crosscompiling on x86? if so you might use gcc4.5.0 from bernd rosch. the result binary might be faster than what you get. vbcc shoul be naturally even better.
-
I have to say, that's an impressive speed for 68K/AGA!
One thing I'd love to see is a quake port that uses Warp3D as the rasterizer. Not a GLQuake port on MiniGL (GLQuake was, by John Carmack's own admission a suboptimal hack), but the vanilla Quake with it's original 3D transformation pipeline with just the rendering stage delegated to warp3d. This should be able to bypass a number of inefficiencies both in the GLQuake code and in MiniGL.
-
what environment you are working under? are you crosscompiling on x86? if so you might use gcc4.5.0 from bernd rosch. the result binary might be faster than what you get. vbcc shoul be naturally even better.
I use AmidevCPP, I could try gcc4.5.0 but the later 68k versions are rumored to be even slower than the older versions. I've never really got anywhere with vbcc, I could give that another go I guess.
-
I have to say, that's an impressive speed for 68K/AGA!
Cool thanks, I've just uploaded v1.07 to AmiNet and it's even quicker on my machine :)
I'll do a new video when I get the time....
-
Cool thanks, I've just uploaded v1.07 to AmiNet and it's even quicker on my machine :)
I'll do a new video when I get the time....
You say it will work on RTG too, right?
-
@NovaCoder
Again here : seven emulated 060 instructions on this game !
Slow down because the 68060.library is not fast you know...
Surely that depends on where they are. If they are in some inner loop, yes, if they are in some initialisation code or something called infrequently, does it matter so much?
@novacoder
Being 68060 only, is there any reason it wouldn't actually run on 68040 too? Are you doing any supervisor mode stuff or relying on any other 060-only features?
-
Yep I normally add RTG support to my AGA ports because people ask for it, I don't actually have an RTG Amiga so it doesn't really make much difference to me.
I use the CyberGFX API for RTG because it's very fast, P96 should also support it via emulation but it probably won't be as quick as a real CyberGFX card.
-
@NovaCoder
GCC 3.4.0, last time I checked, was calling utility.library for integer math like 32x32=64 which is good. The library function call is a little slower than an inline but then utility.library can be patched with the fastest 68060 specific code like ThoR's Mu 68060.library does for 32x32=64. I believe GCC 3.4.0 was a special Amiga specific GeekGadgets version of GCC. Perhaps you can try GCC 3.4.0 with AmidevCPP to see if the utility.library is used?
I did some DMIPS test compiles that showed vbbc (vc -cpu=68060 -O2) at 55 DMIPS error free with 68060@60MHz and GCC 3.4.0 (gcc -fomit-frame-pointer -noixemul -m68060 -O2 -mregparm=4) at 56 DMIPS with register passed function variables that generated several bugs. Vbcc was using stack passed variables. The DMIPS code used no 64 bit integer math, which if trapped in GCC could make vbcc faster. The testing was with the latest version of vbcc and the latest beta version of vasm (has some nice peephole optimizations added as well as bug fixes). Vbcc is getting better but it's still not very GCC compatible, it has some bugs above -O1 (although -O1 has much better performance than GCC -O1) and it's slow to compile.
GCC 2.95.3 is still probably the best at code generation. It handles the trapped instructions with local replacement functions (no utility.library). I believe the newest 68k GLQuake is compiled with this as it is one of the best optimized 68k programs I've seen. It's very rare that I find a 68k program that I look through the disassembly and not grimace. Unfortunately, GCC 2.95.3 is not very compatible with newer versions of GCC.
@Karlos
68060 compiled code I've seen should run without problems on a 68040 although at a slower speed. Using the utility.library for integer 32x32=64 is nearly as fast for the 68040 but the missing FINT/FINTRZ in the 68040 for floating point is a performance killer. What were the Motorola Engineers thinking? Programs using floating point should provide separate 68040 and 68060 compiled versions because of this.
-
@NovaCoder
@Karlos
68060 compiled code I've seen should run without problems on a 68040 although at a slower speed. Using the utility.library for integer 32x32=64 is nearly as fast for the 68040 but the missing FINT/FINTRZ in the 68040 for floating point is a performance killer. What were the Motorola Engineers thinking? Programs using floating point should provide separate 68040 and 68060 compiled versions because of this.
I'm curious to test it under petunia :) It only advertises 68020/68882, but implements most of the additional instructions, AFAIK.
-
I'm curious to test it under petunia :) It only advertises 68020/68882, but implements most of the additional instructions, AFAIK.
I would imagine it will run at very acceptable speed. The floating point may only be double precision instead of extended precision in some cases but that won't matter for games. The 68k used like Java/Android byte code is a good way to get improved code density out of the PPC ;). If we get the Hyperion folks to continue 68k support, we could mend the biggest split in the Amiga. Otherwise, Hyperion is going to wake up one day and find AROS has more users than AmigaOS 4.x.
-
I would imagine it will run at very acceptable speed.
If my experiments with DoomAttack on my BlizzardPPC are any measure, perhaps. That ran 640x400 faster than my 040 does 320x200.
[youtube]AQ1t5q3xmYk[/youtube]
-
If my experiments with DoomAttack on my BlizzardPPC are any measure, perhaps. That ran 640x400 faster than my 040 does 320x200.
Yea, that looks like high end 040 or low end 060 speed. DoomAttack at 640x400 (looks much nicer than 320x200 by the way) has no perceivable slow down on my 060@75MHz while 640x480 has enough hesitation in heavy combat to making it difficult to aim.
-
Surely that depends on where they are. If they are in some inner loop, yes, if they are in some initialisation code or something called infrequently, does it matter so much?
Trapped instructions are slow all the time, everywhere and anywhere !
Watch by yourself !
Hopefully, OxyPatcher accelerate a lot, but still 5.6 time slower than a 32x32 routine untrapped...
Explanations :
Trapped mulu64 via the 68060.library: 1852
Real routine mulu64 untrapped : 6
Trapped mulu64 via the 68060.library and OxyPatcher running : 28
Real routine mulu64 untrapped with OxyPatcher running : 5
Ouch !
-
As promised, here's a quick video of the latest build -> AmiQuake (http://www.youtube.com/watch?v=jZ9qDw8A5So)
-
you have to change by hand any emulated instructions
-
@novacoder
Nice work... maybe on a 50mhz 060 runs smooth too.
-
As promised, here's a quick video of the latest build -> AmiQuake (http://www.youtube.com/watch?v=jZ9qDw8A5So)
Since it's so smooth already, any chance you might add some CPU chewing RGB -> HAM C2P as an experiment?
I'd love to see that!
-
Trapped instructions are slow all the time, everywhere and anywhere !
I know they are slow, but depending on where they are called, it really may not matter. Even a thousand trap-and-emulate calls aren't a problem if they only happen when loading a level, for example. You simply aren't going to notice (or care about, even if you do) a few hundred microseconds wasted.
If, on the other hand, you are doing a trap-and-emulate every time you do a perspective correction inside your texture mapping loop, it's going to suck abominably.
Ideally, there'd be no emulated instructions but in practise, context is everything.
-
Since it's so smooth already, any chance you might add some CPU chewing RGB -> HAM C2P as an experiment?
I'd love to see that!
Quake in 4096 colors? Sign me up! :)
-
Quake in 4096 colors? Sign me up! :)
I was thinking more of the sort of 18-bit C2P routines that you can find on aminet, but even HAM6 would be neat.
-
@novacoder
Nice work... maybe on a 50mhz 060 runs smooth too.
No, not quite there yet, I'll keep hacking away in my spare time to make it faster. I have other more interesting projects waiting to be started so I can't spend all my time on it ;)
I did have a look a doing HAM8 C2P for my ScummVM port but could never get it to render properly :(
A more interesting update would be Graffiti, when Jens eventually updates the Indivision AGA Mrk2 with Graffiti support (maybe even 16bit chunky support) then we can have some fun.
-
I did have a look a doing HAM8 C2P for my ScummVM port but could never get it to render properly :(
Seriously, that would be a really nice touch.
-
I was thinking more of the sort of 18-bit C2P routines that you can find on aminet, but even HAM6 would be neat.
Oh I spoke in jest; Quake has an 8-bit pallet and would hardly benefit from 12-bit :)
Tell me more of these 18-bit routines, though. I'm a coding newborn and didn't touch anything on the Amiga post AmigaBasic though so be gentle.
-
Oh I spoke in jest; Quake has an 8-bit pallet and would hardly benefit from 12-bit :)
Actually, it would as clickboom's original port demonstrates with it's slow but pretty 16-bit option.
The reason being that although the textures are 8 bit, they are shaded with light maps to produce the end result which results in many more shades than can be displayed. These are quantized back to the game palette, resulting in a loss in fidelity.
Tell me more of these 18-bit routines, though. I'm a coding newborn and didn't touch anything on the Amiga post AmigaBasic though so be gentle.
A number of routines are available courtesy of various demoscene coders that can convert an RGB chunky framebuffer in formats from 12-bit up to full 24-bit into suitable HAM planar displays.
-
I thought I'd do some videos of recordings of myself playing the game this time which gives a better idea of how it actually runs on my machine with the latest release.
NovaCoder vs Chthon (http://www.youtube.com/watch?v=VfSIL5MxkXU)
Amiga AGA Quake - Citadel (http://www.youtube.com/watch?v=4BC8aNt9MJo)
-
Wow, thats quite playable. Nice to see :)
-
Yep still could do with a little fps but it's getting harder to get any more speed out of it now :(
-
It would be nice to see a 16bit PPC version.
-
Have you included the asm parts of the Frank Wille Quake version ?
-
Have you included the asm parts of the Frank Wille Quake version ?
No not yet but I might do it in the future if I can get it working
-
I cannot get working Frank Wille Quake port on my 1200 under AGA : cannot open screen or something like that...
-
Video time again, this will be my last release for a while as I'm now working on a new AGA project (more details soon I hope).
AmiQuake V1.10 (https://www.youtube.com/watch?v=kh32EW1l9UM)
Future plans:
When I get the time I'm going to try and back-port some Quake 2 updates which may give it a little more (the Quake 2 engine was based on Quake 1).
I also want to stop it leaving all the dead body parts there for ever, currently by the end of the level you are tripping over severed heads which can't be helping the frame-rate.
-
thats waht I like in old games : dead bodies ! now even with all the horsepower of cpu, dead bodies disappear after a few seconds, which is unrealistic and bad in my opinion...
even worse is the respawn of these same enemies...
I understand it is to have something playable on our miggys but in general I find this crap !
-
I cannot get working Frank Wille Quake port on my 1200 under AGA : cannot open screen or something like that...
I get the same error, odd, because I have played it on my a1200 before
-
Version v1.11 on it's way to AmiNet now...
This is a video I just took of of how it now plays on my 1200 -> a video (http://www.youtube.com/watch?v=QjphnQSd2m8)
This is the last update I'm going to do this port of Quake, my next version will include back-ported code from Quake 2 AGA (because the Quake 2 code looks prettier).
-
Awesome work. If only ID had put in the effort back in the 90s, I wouldn't have bought a PC. Can I suggest you get a tripod for the camera though :crazy:
-
Awesome work. If only ID had put in the effort back in the 90s, I wouldn't have bought a PC. Can I suggest you get a tripod for the camera though :crazy:
Yes I do need to get a decent camera, my silly mobile phone is not up to it. I was thinking about getting one of those Hero Cams.
-
Yes I do need to get a decent camera, my silly mobile phone is not up to it. I was thinking about getting one of those Hero Cams.
Get the 4K (4096 x 2160) version :) you might need to sell a few organs first though... I use £40 1080p usb webcams cos I'm a cheapskate
-
this may sound dumb, but do you have both PAL & NTSC monitor drivers in Devs/Monitors? cos it works ok for me unless one of them (and it can be either) is removed... ie. selecting NTSC will not work with out both the NTSC & the PAL drivers pressent... this seems to be a bug in GUI as I have started it in PAL on a PAL A4000 from Shell with no monitor drivers in Devs.
-
I cannot get working Frank Wille Quake port on my 1200 under AGA : cannot open screen or something like that...
you need both the PAL & NTSC monitor drivers in devs/monitors if you launch it from the gui.
-
you need both the PAL & NTSC monitor drivers in devs/monitors if you launch it from the gui.
Yes, you'r right ! The game is running now !!
-
Maybe of topic, but I found this auction.
http://www.ebay.com/itm/Quake-CDROM-Game-by-Clickboom-for-Amiga-1200-2000-3000-4000-very-rare-/150989399479?pt=UK_PC_Video_Games_Video_Games_JS&hash=item2327ab65b7
Interesting, although is it really worth the asking price? :)
-
Just read your post on EAB that says HSMathLibs are required for best performance. Can you confirm this? Seems to run pretty good on my system without them! :cool:
I was going to purchase these libs at some point anyway for use with VistaLite. How much of a boost does it give to AmiQuake?
-
Just read your post on EAB that says HSMathLibs are required for best performance. Can you confirm this? Seems to run pretty good on my system without them! :cool:
I was going to purchase these libs at some point anyway for use with VistaLite. How much of a boost does it give to AmiQuake?
It's funny, I only noticed that that made a difference because I've just swapped to a Blizzard 1260 and didn't have them running.
Yes purchase those libs, they don't cost much and it's always nice to support 68k developers.
The actual speed boost to AmiQuake in terms of FPS is very small but it makes a big difference in the rotation speed so makes the game feel much better to play in my opinion.
-
Something (hardware ?, software ?) is wrong with Quake on our Amiga Classic...
Please watch this video (Quake on Atari Falcon with CT60@100 in 320x200 256 colors) :
http://www.youtube.com/watch?v=gXHkx4k1mkQ
The game run very very much faster with the optimised routines from Frank Wille (Quake68k)
;)
-
Something (hardware ?, software ?) is wrong with Quake on our Amiga Classic...
The faster RAM etc probably helps... I can't see if it has a gfx card in the PCI slot.
-
The faster RAM etc probably helps... I can't see if it has a gfx card in the PCI slot.
I think it's the native TOS screen...
-
Any compiler supporting the 68060 and compiled for the 68060 should not use trapped instructions that are not available in the 68060. Exceptions should be reported to the compiler maintainers.
He is using GCC on a 680x0 processor so he is banned from getting support from the GCC team. Have you ever heard of any Amiga person getting a bug fixed in GCC 680x0 code generation in the last 15 years?
Oxypatcher or VBCC FTW!
Or compile Quake with gcc v2.95.x
-
Maybe we need a 680x0 LLVM compiler to move beyond GCC.
-
@NovaCoder
What C/C++ compiler are you using ?
-
@NovaCoder
What C/C++ compiler are you using ?
I'm using gcc v3.40, I've found it to be the best version to build for 68k.
New version just uploaded to AmiNet. I applied the lessons learnt from porting Quake 2 which have resulted in a 10% speed boost!
It now runs as fast as I remember it on my old Pentium (using software mode) when it first came out.
[youtube]gQJCStfkcc0[/youtube]
Not bad for AGA is it?
:)
-
I'm using gcc v3.40, I've found it to be the best version to build for 68k.
New version just uploaded to AmiNet. I applied the lessons learnt from porting Quake 2 which have resulted in a 10% speed boost!
It now runs as fast as I remember it on my old Pentium (using software mode) when it first came out.
[youtube]gQJCStfkcc0[/youtube]
Not bad for AGA is it?
:)
Excellent! Can't wait to try this... just waiting for the chaps at Aminet to eat their breakfast and lunch (or recover from a hangover maybe? Or maybe they're playing Quake!):
"Latest packages, last 14 days"
"Note: no uploads will be moderated until sunday afternoon."
-
Here are some videos I just did of Malice running on my Blizzy 1260 using the latest version of AmiQuake AGA :)
[youtube]jyYtHo6V-vE[/youtube]
[youtube]o93LV8OQGOk[/youtube]
[youtube]-wHtSWptGiM[/youtube]
-
Here are some videos I just did of Malice running on my Blizzy 1260 using the latest version of AmiQuake AGA :)
[youtube]jyYtHo6V-vE[/youtube]
[youtube]o93LV8OQGOk[/youtube]
[youtube]-wHtSWptGiM[/youtube]
Ahhh shucks - if only 68060's had been cheaper back in the day - the landscape we see today might have been a different kettle of fish. Imagine if the CD32 had been equpped with one. I see stuff like this and it makes me want to find an 060 card - but in reality its just not worth the outlay just so that I can experience what could have been.
Kudos to your work though - its impressive stuff!
N ...
-
Wow!
-
I use AmidevCPP, I could try gcc4.5.0 but the later 68k versions are rumored to be even slower than the older versions. I've never really got anywhere with vbcc, I could give that another go I guess.
sorry to answer to an old post but binary compiled with 4.5.0 should be actually faster than 3.6.x, i guess, as this was the worst afair. matt probably knows better.
though, actually i wanted to sk where to download the binaries, especially quake. ive something to test. why not put them on aminet btw?
-
sorry to answer to an old post but binary compiled with 4.5.0 should be actually faster than 3.6.x, i guess, as this was the worst afair. matt probably knows better.
I have heard that the newest versions of GCC are generating better code quality now. I don't know if that applies to the 68k. The GCC FPU support for the 68040+ was never complete as trapped/emulated FPU instructions were used. I doubt the newest version of GCC has improved FPU support. NovaCoder uses AmiDevCpp which generates Amiga hunk executables and is quick for developing. The newest versions of GCC only generate 68k ELF executables like AROS 68k uses. There are advantages and disadvantages to the different compilers:
GCC 2.95.3
+ best integer code generation quality
+ Amiga specific support including Amiga hunk format
+ fast compiling
- GCC support is not modern
GCC 3.4.0
+ Amiga specific support including Amiga hunk format
GCC 3.6.x
+ most modern GCC used by AmiDevCpp
+ Amiga hunk format
GCC 4.x
+ modern and sophisticated GCC support
- no hunk format or Amiga support
- no AmiDevCpp
- slow to compile
vbcc 0.9d (yet unreleased)
+ Amiga specific support including Amiga hunk format
+ best 68040/68060 FPU support
+ should work using AmiDevCpp
- below average integer code generation quality
- slow to compile
- limited GCC compatibility
It's not an easy call. NovaCoder is probably using the easiest and fastest Amiga 68k porting and development environment. He is getting good results even if a little better code quality may be possible with more effort.
though, actually i wanted to ask where to download the binaries, especially quake. ive something to test. why not put them on aminet btw?
The Amiga executables are on Aminet:
http://aminet.net/search?query=AmiQuake
They do not include the full game files which may not be included in the license. They are also very large. I use the demo files from the DOS demos for testing. They are easy to find.
-
thx, matt, one thing though, the 4.x.x versions i had from bernd up to 4.5.0 could be used from under devcpp, it felt a little hacky tough.