English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 28 January 2014, 19:49   #21
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 271
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 !

Last edited by Cowcat; 28 January 2014 at 20:31.
Cowcat is offline  
AdSense AdSense  
Old 28 January 2014, 21:55   #22
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Cowcat View Post
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.
matthey is offline  
Old 28 January 2014, 22:18   #23
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 271
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.

Last edited by Cowcat; 28 January 2014 at 22:51.
Cowcat is offline  
Old 29 January 2014, 00:33   #24
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Cowcat View Post
@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/

Last edited by matthey; 29 January 2014 at 16:14.
matthey is offline  
Old 29 January 2014, 19:58   #25
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 271
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 is offline  
Old 29 January 2014, 20:10   #26
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 271
vasm 1.6b or from CVS?
Cowcat is offline  
Old 29 January 2014, 20:31   #27
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Cowcat View Post
ups......it is from last vbcc (vasm 1.5b.)
Yep, that's pretty old now. There are lots of changes since then (see history).

Quote:
Originally Posted by Cowcat View Post
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?

Quote:
Originally Posted by Cowcat View Post
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.

Quote:
Originally Posted by Cowcat View Post
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 .

Quote:
Originally Posted by Cowcat View Post
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.
matthey is offline  
Old 29 January 2014, 20:48   #28
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 271
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.
Cowcat is offline  
Old 29 January 2014, 21:01   #29
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Cowcat View Post
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.
matthey is offline  
Old 29 January 2014, 21:19   #30
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 271
Of course m68k_warpos config
Cowcat is offline  
Old 01 February 2014, 02:54   #31
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
@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.
matthey is offline  
Old 01 February 2014, 14:50   #32
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 271
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.

Last edited by Cowcat; 01 February 2014 at 15:49.
Cowcat is offline  
Old 01 February 2014, 17:29   #33
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Cowcat View Post
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.

Quote:
Originally Posted by Cowcat View Post
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.

Quote:
Originally Posted by Cowcat View Post
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.
matthey is offline  
Old 01 February 2014, 17:48   #34
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 271
Good point. It is needed -phxass option as a must?
Cowcat is offline  
Old 01 February 2014, 18:21   #35
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Cowcat View Post
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.

Last edited by matthey; 01 February 2014 at 18:28.
matthey is offline  
Old 01 February 2014, 18:37   #36
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 271
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?
Cowcat is offline  
Old 01 February 2014, 19:13   #37
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Cowcat View Post
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.
matthey is offline  
Old 01 February 2014, 19:50   #38
SKOLMAN_MWS
Registered User

 
Join Date: Jan 2014
Location: Poland
Posts: 100
http://aminet.net/package/dev/asm/PtnAsm
http://aminet.net/package/dev/asm/PtnAsm-Update
SKOLMAN_MWS is offline  
Old 01 February 2014, 23:01   #39
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
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.
matthey is offline  
Old 03 February 2014, 13:22   #40
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 986
Quote:
Originally Posted by matthey View Post
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...
phx 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
BlitzQuake - Flashing White Screen? fitzsteve support.Games 20 21 October 2010 23:49
Blitzquake (GLquake) mouse look Angus support.Games 0 11 October 2008 00:46
BlitzQuake Install Coolit support.Games 0 02 September 2005 21:33

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 01:51.


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