BlitzQuake

[Cowcat]

The mouse is freed going back to main menu on purpose. I made checks for menu options, player, etc to re-enable the handler (or esq key). Probably the bad redrawing could be intuition options like NoCareRefresh on window settings. If it's this, blame me. It doesn't happen on my hardware 040/PPC/Permedia. I will check that. On full screen, there's nothing touched: It works as old binary (no checks for windowmode). All the source of Blitz it's on Aminet, as minigl. Then some "cosmetic" things that I added and code from another port. Weird thing Paula sound.....works for me on both versions.
Of course, I will post my source mods but the core of things to be enhanced are on the original mgl & blitz. Thank you for testing !

[matthey]

Originally Posted by Cowcat

Deleted old post. New build.

The new build still doesn't update the window correctly. The mouse pointer on/off doesn't seem to work in window mode anymore. Still no sound.

With your 1st build, the mouse pointer would turn on and off when going to the menu but would sometimes get confused. It would sometimes turn on when going to game play and turn off when entering the menu (opposite of desired).

I tried the original BlitzQuake in window mode and it has the same window updating problems so it's not your bug or something you introduced. There were definitely sound problems in the original as well.

A nice feature might be to change the task priority to negative with SetTaskPri() when in the menu to help multitasking and change it back before returning to the game.

P.S. Anyone testing in window mode (on Workbench) needs to have WB in a screen mode that can do 3D. This would be "16 bit PC" for the Voodoo 3.

[Cowcat]

So keeping intuition as normal as minigl original code does that.
I only "fixed" this, didn't touch anything else.

More: Downloaded myself the file. Seems to be ok . Allright. Problems with audio for some systems as in the original, no proper ahi, etc, etc.
Will check SetTask. @matthey detail your hardware. If someone can give more updates on this please post.

[matthey]

Originally Posted by Cowcat

@matthey detail your hardware. If someone can give more updates on this please post.

Amiga 3000T
CSMK3 68060@75MHz
Mediator 3000T/4000T+Voodoo4
AmigaOS 3.9+
patched Warp3D.library and Voodoo drivers

What version of vasm are you using? There are new and significant optimizations and bug fixes in the newest version of vasm which can be downloaded from Frank's site. It should work with the older vbcc but would need compiling.

http://sun.hasenbraten.de/vasm/

[Cowcat]

ups......it is from last vbcc (vasm 1.5b.)

Oks. I remade the windowmode. Seems to have a bogus memory leak...

New vasm recompile to try (thanks for suggestion !, should I have known)......

There are old quake asm code that is compiled against old phxass/pasm. That was a question I had to ask to the author: A proper way to rewrite/use that for vasm. There are headers generated from "genasmheaders", and vars written like .float don't work for vasm (specially ppc). Probably a new needed rewrite for all that. Forgive my poor understanding.

[Cowcat]

vasm 1.6b or from CVS?

[matthey]

Originally Posted by Cowcat

ups......it is from last vbcc (vasm 1.5b.)

Yep, that's pretty old now. There are lots of changes since then (see history).

Originally Posted by Cowcat

Oks. I remade the windowmode. Seems to have a bogus memory leak...

Sometimes resources aren't given back right away. Did you use Avail flush?

Originally Posted by Cowcat

New vasm recompile to try (thanks for suggestion !, should I have known)......

Let me know if you have any problems compiling. The "Compilation notes" on Frank's page are pretty straight forward but a cross compiling environment can be a little confusing sometimes.

Originally Posted by Cowcat

There are old quake asm code that is compiled against old phxass/pasm. That was a question I had to ask to the author: A proper way to rewrite/use that for vasm. There are headers generated from "genasmheaders", and vars written like .float don't work for vasm (specially ppc). Probably a new needed rewrite for all that. Forgive my poor understanding.

I'll leave that question for Frank since he wrote vasm and the assembler optimizations in Quake .

Originally Posted by Cowcat

vasm 1.6b or from CVS?

The newest version of vasm source is in the tar ball marked "Daily source snapshot" on Frank's vasm page.

[Cowcat]

Sometimes Avail Flush. I have no crosscompiler. All in Amiga hardware since the beginning.
Compiled 1.6b, just for test. No problems. Will try "Daily" Thanks for your help & advice.

[matthey]

Originally Posted by Cowcat

Sometimes Avail Flush. I have no crosscompiler. All in Amiga hardware since the beginning.
Compiled 1.6b, just for test. No problems. Will try "Daily" Thanks for your help & advice.

Vasm 1.6b is recent if not the newest. There may be several builds of 1.6b with different changes before Frank bumps the version number if you periodically compile the newest source. Vasm 1.6b should drop the size of the 68k BlitzQuake executable by a noticeable amount as it compresses some fp immediates now.

Don't you compile BlitzQuake 68k with the WarpOS version of vbcc and vasm compiled for a 68k target? That would be slow compiling with a 68040@25MHz otherwise.

[Cowcat]

Of course m68k_warpos config

[matthey]

@Cowcat
Your new version of BlitzQuake68k worked better for me. The mouse pointer now turns on correctly when in the menu using your new window mode. The refresh is still messed up though. Audio never came on once in multiple retries. The 3D was as good as the old version of BlitzQuake. I was able to beat the demo where the old version would randomly crash sometimes before then. The speed is about the same. I did some timedemo tests this time with "timedemo demo1".

old GCC 2.95.3 version : 1st time 20.2 fps, 2nd time 24.3 fps
new vbbc 0.9b version : 1st time 20.1 fps, 2nd time 23.3 fps

GCC 2.95.3 probably produces the best code ever for the 68k. It's especially tough to beat in integer performance. I expect the new version of vbcc will best it in fp performance and should be a little improved in some cases with integer performance but there is no 68k instruction scheduler which would primarily benefit the 68060. We will have to see how that works out with mixed integer and fp like Quake. Note that this only applies to 68k compilers and not PowerPC. Vbcc was beating GCC 2.95.3 in many benchmarks for the PowerPC.

http://sun.hasenbraten.de/vbcc/index...iew=benchmarks

Thanks for the updates.

[Cowcat]

There was less than a 100 bytes between old vasm & new. Unreleased daily vasm (1.6c) produced same size code as 1.6b. Warpos minigl lib was exactly the same for 1.5,1.6b,1.6c. A couple of bytes for m68k on minigl between 1.5 & 1.6b. Really tight.
Soundwise, the code was done with AGA machines & not tested with A3000 (??). Weird.

Out of curiosity I tested on Morphos 1.4 PowerpUp version : You need to use AHI & seems to work perfectly, no dropout frequencies etc & you can adjust at taste. Another weird thing.

[matthey]

Originally Posted by Cowcat

There was less than a 100 bytes between old vasm & new. Unreleased daily vasm (1.6c) produced same size code as 1.6b. Warpos minigl lib was exactly the same for 1.5,1.6b,1.6c. A couple of bytes for m68k on minigl between 1.5 & 1.6b. Really tight.

There should be a bigger savings with the fp immediate compression in vasm. It is enabled by default in vasm but vbcc is still using -phxass mode. That means that -opt-fconst has to be turned on (added into any config producing 68k code) with this 68k fp optimization. Here is the text config file for vbcc that replaces vbcc:config/aos68k to enable the optimization.

http://www.heywheel.com/matthey/Amiga/aos68k

Make a backup of your old config but you should be able to use this config permanently for all 68k compiling. The -opt-fconst may be needed in other similar config files (in the same config directory) that output 68k code. I disassembled BlitzQuake and many of the fp constants would not compress (compared to the vbcc compiler itself where every fp constant compressed) so I wouldn't expect miracles but it still might save a few bytes. The new vbbc version of BlitzQuake is already 77,488 bytes smaller than Christian's GCC 2.95.3 version.

Originally Posted by Cowcat

Soundwise, the code was done with AGA machines & not tested with A3000 (??). Weird.

It shouldn't make any difference for the Paula sound output which never really changed on the Amiga.

Originally Posted by Cowcat

Out of curiosity I tested on Morphos 1.4 PowerpUp version : You need to use AHI & seems to work perfectly, no dropout frequencies etc & you can adjust at taste. Another weird thing.

Maybe the MorphOS guys fixed some AHI sound bugs.

[Cowcat]

Good point. It is needed -phxass option as a must?

[matthey]

Originally Posted by Cowcat

Good point. It is needed -phxass option as a must?

Yes, vbcc must use -phxass mode for now. The -opt-fconst is an optional optimization that has to be turned on if wanted in -phxass mode. Vbcc has 3 modes:

1) normal vasm mode
All safe optimizations are enabled including -opt-fconst.
2) devpac mode (with -devpac switch)
Optimizations that the Devpac assembler had enabled by default are used which I believe are mostly or completely disabled. The -opt-fconst optimization is not enabled by default.
3) phxass mode (with -phxass switch)
Optimizations that the PhxAss assembler had enabled by default are used. There are some improvements and differences as well. The -opt-fconst optimization is not enabled by default.

Vasm tries to be compatible in -phxass and -devpac modes with the old assemblers. Normal vasm mode tries to do the best job of optimizing by default as is safe and reliable. Vbcc started out using the PhxAss assembler and then switched to vasm with the -phxass switch. Eventually, vbcc is planned to switch to vasm mode but it's not a high priority and there isn't much to be gained. It's pretty easy to put a -opt-fconst optimization switch in the config file. The optimization has been tested and the new version of vbcc should have this option in the config file after installing. Anyone with an older version of vbcc can enable -opt-fconst for the 68k but it requires a newer version of vasm that has the optimization.

[Cowcat]

Allright:
the makefile had something like this for the asm files:
phxass q noexe m=68060 opt=2 i=devel:ndk/......

I used this:

vasmm68k_mot -Fhunk -m68060 -opt-speed -opt-allbra -showopt -x -nosym -I devel:ndk/...
And got pretty close size code like the old phxass ones. Don't remember if some of them got smaller.

A better options maybe?

[matthey]

Originally Posted by Cowcat

Allright:
the makefile had something like this for the asm files:
phxass q noexe m=68060 opt=2 i=devel:ndk/......

I used this:

vasmm68k_mot -Fhunk -m68060 -opt-speed -opt-allbra -showopt -x -nosym -I devel:ndk/...
And got pretty close size code like the old phxass ones. Don't remember if some of them got smaller.

A better options maybe?

Those options look fine to me. The assembler files should already have mostly optimized code although the desirable formatting may be different between PhxAss and vasm. Vasm has more "safe" optimizations enabled by default including the -opt-fconst optimization but they should never cause a problem. Note that the -opt-fconst optimization is not an easy one and many assembler programmers could miss it or leave it up to vasm to optimize. Also note that code size could grow compared to the PhxAss code with the -opt-speed although it's unlikely to be by much as most optimizations reduce the code size or keep it the same.

[SKOLMAN_MWS]

http://aminet.net/package/dev/asm/PtnAsm
http://aminet.net/package/dev/asm/PtnAsm-Update

[matthey]

Originally Posted by SKOLMAN_MWS

http://aminet.net/package/dev/asm/PtnAsm
http://aminet.net/package/dev/asm/PtnAsm-Update

Are you inferring more PowerPC assembler optimizations for BlitzQuake? I don't mind if you do. Vasm has a PowerPC backend and I expect it's pretty well maintained considering Frank Wille uses PowerPC. He seems to prefer to write assembler in 68k for some reason though.

[phx]

Originally Posted by matthey

He seems to prefer to write assembler in 68k for some reason though.

LOL
Do I?

There were as much PPC optimized functions in my AmigaQuake versions as there were for M68k...