BlitzQuake
 

First, a better video:
http://www.youtube.com/watch?v=HhV38...&feature=share

Second:
Got permission from other author of the original code to upgrade Blitz with new code of him (thanks Phx). Testing more ppcasm code that didn't work on the original source (in video). Don't really know ppcasm but I make it work :crazy

The original code is untouched (don't want to piss someone). I just added that windowmode-playing feature, and updated audio and asm code.

I can build a m68k version with those new features if it is requested (no miracles for m68k for speed). Probably try with gcc. Unlikely a ppc gcc version (somebody with a proper one buildchain?), but it's getting very close to original gcc.

As previously commented, I made a version than works for those BVision PPC users with problems with the original build as myself. And then more things ;)

Just learning to program myself with Amiga. New "official" build in future.

if someone could fix the ahi on this for 68k machines i would be interested.

you know,if you can:)

What was the problem?. Dificult to see whats going on my 040/25mhz side: It's like a 4 fps slideshow and stuttering sound effects. Seems like an old vbcc version of mine was 1 frame faster than the gcc one :blased........I'm on it anyway (vbcc 68060 version maybe ?)

Ahi is stuck at 11500 kHz IIRC so sounds like crap. Even on 16bit sound cards.

@Cowcat
Is there any chance the source could be made available or uploaded to Aminet? BlitzQuake/glQuake has one of the best and most thorough Warp3D implementations and is one of the most optimized Amiga games, at least for the 68k. It's a great benchmark program too. The big problem with 68k performance is the horrible optimization of the Warp3D drivers. They have about twice as many instructions as needed :(. I made optimized patched versions of the Warp3D.library and Voodoo drivers which helped noticeably and fixed some bugs. I get 25fps at 640x480x16 on my 68060@75MHz with Mediator+Voodoo 4 which is fully playable. I might be interested in playing around with, debugging and optimizing the source but it would mostly be 68k side. The PowerPC side could see some benefits from bug fixes though.

There is a newer unreleased version of vbcc that 0.9b that has *many* improvements and bug fixes. I was waiting on a bug fix for fp (all sizes) to unsigned 32 bit int conversions when Frank Wille must have become busy with Solid Gold. Maybe Dr. Volker Barthelmann hasn't had time to fix the bug in the 68k backend also. We were working on c99 math support for vbcc 68k+FPU but I was stalled by the lack of an important bug fix as I was starting testing. Frank was wanting to release an update last year for vbcc so maybe he just needs another reminder since you have been talking to him anyway ;).

i get 25 fps on mine.(yes,thats on 68k)


as steve(fitzsteve) has mentioned the sound is rubbish and stuck at 11,500 i think this was because the auther didnt know much about ahi to fix it.
i think he mentioned that in the docs somewhere.
normal non ahi sound through paula is fine...


it would nice to see some improvement in the sound quality and maybe some optimizations the render end.

Yes, unfortunately he had no enough time for vbcc in the last months. So I focussed myself on... different projects. ;)


I didn't forget that, but a release doesn't make sense until Volker fixed the open bugs.
There were also many improvements for the Atari target over the last year, including a ColdFire version.

Yep. Sound code from Phx Warpos last port, to my ears, improve paula output but unfortunately AHI seems to have the same problems posted.

Still working on a m68k port: My "windowmodeplay" happens to stall the program (going in out of main menu, etc): Too much for 040/25mhz & probably could happen the same on Warpos. A happy accident playing with menu.c code allowed that. Not very professional, & amateurish but worked for me. It's a simple rutine that checks if we are in "-windowmode" and disables mousepointer & mouse handler, then enables it again. Brutal?, maybe, but it works as seen on video (or maybe for people who downloaded the last version).

I need to fix things to post the whole code here, just to be sure it compiles properly for both versions. Time.

Would it be possible to get this to work with CV64/3D? There is a 15bit Warp3D driver, it supports very little via the S3Virge Chip with only 4mb VRAM, I think Decent in Warp3D is the only game that actually works with it!

But maybe Quake on the lowest possible settings?

I played Quake and Quake II back in the day with an 8mb Voodoo II :)

@fitzsteve
The first thing you could check is if minigl lib runs on your system. You have to compile one for yourself & see if their demos work. No minigl, no glquake :sad

Hi!

Yes, Warp3D works on my system, I can see the Gears Demo albeit very slow!

I have also in my system 040@40mhz (WarpEngine) I'm sure really it wont be fast enough for any serious playability but would be nice to see as proof of concept.

Oks. But I mean programs that were compiled with minigl static lib. Sure Warp3D and Gears Demo run, but Gears Demo from minigl last OS3 source code, or others on your hardware I really don't know.

I'm happy to hear the update is not forgotten or abandoned. You did find some constructive use of your time so I won't complain :).

The CV64/3D might be tricky to get running. The Virge has many hardware limitations and odd behaviors. The Virge Warp3D driver was not updated to the latest version of Warp3D so it's kind of patched in with some functionality lacking. The good news is that the 68k optimization of the Warp3D Virge driver is better than for the Voodoo or Permedia. You will want to run OxyPatcher/CyberPatcher/MuRedox as with most fp programs because of the missing FINT/FINTRZ on the 68040. You might try with and without my patched Warp3D.library which should work with the Virge driver and provide a minor speedup. It may be possible to get the CV64/3D to run Quake at reduced quality but it would probably require testing with the board in the developers machine. It's probably a time eater too.

The pre Aminet release of GLQuake works on my A1500 with 68040 and CV64/3D. It runs slower than software Quake though. Try it for yourself:

Attachment 38822

@Cowcat

I would love to try out a new 68k version. Any chance you could add in cdplayer.library support :D

http://aminet.net/package/util/libs/cdplayer_lib_ahi

With this it would be possible to play audio from a CD image, or when there is no audio link between the CD drive and the computer. AwinQuake already supports this:

http://aminet.net/package/game/shoot/awinquake
http://aminet.net/game/shoot/awinquake_src.lha

Unfortunately the cdplayer.library version on Aminet has some problems, but this previous version was working well:

Attachment 38823

Hi James!

Thanks for that, I'll try it out :great

I see you're local, did you see my post's about our little Computing meet up on Sat 1st Feb? It's in Otford, Kent if you'd like to come along and bring an Amiga or two with you!

Reply in my thread if you're interested:

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

Steve.

@James
It's gonna be a long year :crazy The cdlib could be an interesting feature to add, but a little one compared to a new vbcc or warp3d patched libraries (patch for PPC ones?) . I will look to that in future. Now I need to redo a proper m68k build :banghead

Hello

I suppose BlitzQuake textures will use too much VRAM for the CV64-3D...
But I am not sure .... so give it a try with the smaller res screen possible to economize memory (320x200x15bits ?)


>The pre Aminet release of GLQuake works [...] CV64/3D. It runs slower than software [...]
Perhaps due to the fact that all texs cant fit in VRAM so Warp3D copy them from RAM to VRAM for all drawing operation

>BlitzQuake/glQuake has one of the best and most thorough Warp3D implementations
I agree : BlitzQuake perform very well on Wazp3D/WinUAE/OpenGL renderer
BlitzQuake is certainly the best Warp3D prog ever


Alain Thellier - Wazp3D

does anyone know how much vram blitzquake uses?

it might answer a few questions.

No idea. Command option -maxsize it was ment to allow lower ram conditions for Virge users. It didn't work properly, at least on my hardware (you get trashed display at menu, etc). I made it work 'couse my permedia is half busted and has problems. I use -maxsize 128

Window mode has problems clearing and redrawing the window here. The game works otherwise. The mouse seems to be freed in the main menu. I tried in fullscreen and the game seems to work fine. The vbbc compile works better than I would have expected given some of the bugs we found. There is maybe a few more minor gfx glitches although the gcc compile has a few artifacts as well. The speed is a little worse overall but it's faster in some places. The executable size is smaller with vbcc which is nice. The new vbcc will have some more optimizations for the 68k and 68060 in particular so it may well pull even in 68k code generation to GCC 2.95.3 which Christian Michael used in the last version of BlitzQuake.

The Paula sound didn't work at all but it sometimes doesn't with the old version of BlitzQuake.

The best and fastest chance for speedups and new features is to let Alain Thellier look over the source. He knows Warp3D inside and out having written a complete software replacement. He knows which Warp3D functions are fastest and which can be replaced by faster versions. He may be able to spot slowdowns in Warp3D algorithms. He knows 3D like no other Amigan. If you could get him interested and let him see the code, he would probably just make suggestions and offer a function replacement from time to time. I think everyone is glad to see that you resurrected the project and have time to play with it. I hope you recognize and use all the resources you have available.