English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 15 March 2014, 14:46   #81
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 289
Quote:
What other W3D libs?
Basically W3D 68k modded libs: Just a simple disassembly & re-assembly make them a little small & "optimized". High optimized are Matthey's.
Warpos W3D libs? Maybe in future...

Quote:
what's so special about copymem patches for 68k?
Refer to Readme of CopyMem & find out

All new Quake builds use now own vbcc inline assembly. One of the things done is that all memcpy code related is substituted by CopyMem calls (more optimized than regular system memcopy), but you can use whatever mem patch you like.
Better Matthey to explain all subjects related to this (see again readme of copymem).

IMHO the new 68k builds give me more framerates than gcc olds, but can't explore every corner of the game with an extremely slow 040/25 to do speed statistics.

Quote:
black squares
Yes. Mine sometimes is full black window/screen & blindy find the quit key or wait for next level (then it comes again)
Faster 68k cpus probably don't have that issue (still testing that). Same screen code like old blitz or wos........

Related to that (it's speed and system resources left), I changed some memory allocation for paula sound code. As I (think) said before, those output crashes didn't happen if you use -ahi. All Allocmem code now is AllocVec code (Sys_Alloc for Quake), so better memory tracking to flush when out (to my knowledge).

4 hours punishing new 68k build, in out & no problems/hits at all (At least yesterday/today morning)

So the new/future 060 should be "better": Then I will eat my own words with another bug

Quote:
broken transparent water
Only this? There are more bugs all over original code

As a side note: All quake sessions I test are done without raising any stack.
Cowcat is offline  
AdSense AdSense  
Old 15 March 2014, 20:02   #82
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 596
The new CopyMem patch is interesting, according to TestIt it is faster then CMQ by x3 times in last tests with small copy ops. But according to timedemo, Q performs slower!
Same conditions 40.6 v 41.6 seconds. Odd.

Still, new bugs/info on old problem.
In 320x240 window, 68K version has a lot of garbage purple pixels in console and weapon panel when timedemo is uses.
WOS version is less effected, but still has some purple or white pixels in console and the panel. The problem does not show up on higher res!

Black square... You know, if you quit before this, it seems to be ok.
If you quit after this happens on new level load ets... Then we crash
Without enforcer I get ExecLibrary... Sanity memory table allocation check failure requester
PS: my 060 should be good enough, not many real faster ones available.

The window depth gadget should not give any penalties since it is monitored by os anyway. And currently window manipulation works via windowtofront/back commodities.
It will be just a bit user friendlier. Other gadgets, yes, might impact performance.

Have you looked at the recent original GLQuake 1.13a source ?
Michael is offline  
Old 15 March 2014, 20:32   #83
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 289


Quote:
recent original GLQuake 1.13a source
Seeing now 1.13b. Problem with new mods are they go for higher textures, maps, effects, etc, so pretty much a killing for Classics.

Will enable gadgets,etc for window.

Hope this one has no hits on quit, besides others things.

Last edited by Cowcat; 11 June 2016 at 15:44.
Cowcat is offline  
Old 15 March 2014, 21:37   #84
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 596
True, high tech stuff is not important, besides they can only be enabled in the console if someone is really in to it, but some general fixes are always nice.
Michael is offline  
Old 16 March 2014, 03:17   #85
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Michael View Post
The new CopyMem patch is interesting, according to TestIt it is faster then CMQ by x3 times in last tests with small copy ops. But according to timedemo, Q performs slower!
Same conditions 40.6 v 41.6 seconds. Odd.
I tried CMQ060 and received the same results in fps and within 0.1 seconds as with CopyMem060 using Quake "timedemo demo1". I don't know what you did to get 1.6 seconds difference. They should be very close except for CopyMem060 being a little better at small copies (CopyMem040 is significantly faster than CMQ060 on a 68040 though).

@Cowcat
Your new 060 build works perfect here . No MuForce hits. Sorry, I've been busy with other things and the weather is getting nice.
matthey is offline  
Old 16 March 2014, 08:36   #86
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 596
060-b5-3 is much better.
Get 55.3 s / 16.5 fps in window mode 320x240 @ 16bit - default, no options

A few things to note, graphics corruption (purple pxls) only in 320 width, no problems with higher res, eg.400

Default priority for the game should be set to -3 for system friendly mode, did not effect the fps at all, but you can use the system as if nothing is hogging the cpu.

The black squares issue happens only once, on demo loop DEMO1 -> DEMO2
if left unattended it will work flawlessly on next loop

Seems to exit ok, but did hang with a black window once.
Oddly you can here quake sound if you press the keys, but nothing happens.

Stack... startup stack is 3200 here, max used stack is 670 out of auto increased stack of 786432. I wonder where all that stack is required. Maybe with TCP or when playing mods?
Michael is offline  
Old 16 March 2014, 12:27   #87
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 289
Quote:
did hang with a black window once.
It doesn't hang (see debugger). It's still there but not refreshed (weird). You can quit if blindy move key cursors till you guess quit menu & then "y". On it, but had to know if also happens with mediator + Voodoo users.

Anyways don't know of a BVision or CVision that is not attached to a PPC card -> go WOS.

@Matthey Ok mate! Not problem at all. Still trying new things and findings bugs.

Last edited by Cowcat; 16 March 2014 at 13:44.
Cowcat is offline  
Old 17 March 2014, 21:22   #88
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 596
Had some more fun today...

320 window mode is strange, corruption in 68K and WOS version.
But if you go 328 the problem disappears, something definitely wrong there.

Tried some extension packs

Rogue and Hypnotic seem to work just like normal Quake.

Malice is very nice and runs in 512x384 at top speeds!
In tunnels and not too crazy open spaces, 60 FPS!!! on Perm2!

Sadly it has some problems, external birds eye view is broken, the player falls into triangle hedgehog. At certain angles of view weapons in hand disappear.

QRally racing game, also works, but this one likes to hang on the first demo
loop when the camera flies over the cars and gives a view of the track.
Michael is offline  
Old 18 March 2014, 00:17   #89
James
Registered User

 
Join Date: Mar 2010
Location: Beckenham/England
Posts: 455
Quote:
Originally Posted by Michael View Post
Sadly it has some problems, external birds eye view is broken, the player falls into triangle hedgehog. At certain angles of view weapons in hand disappear.
You should move/delete the ID1/glquake drawer before running any partial/total conversion for the first time. This problem occurs when different models have the same name. You will now also have to delete the Malice/glquake and QRally/glquake drawers and try again (The official expansions use the same models).

Quote:
Originally Posted by James View Post
I run thousands of different games and programs on this setup though, and this seems to be the only program that causes this to happen...
Scratch this - realized I had only tested StormMesa 3D games and demos - all Warp3D programs have this same quirk.
James is offline  
Old 18 March 2014, 04:46   #90
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 596
Hmm... interesting... Will have to check... In theory they should use all the data from their own folder first.

Forgot one more thing, Malice console window is sexy transparent !
Michael is offline  
Old 18 March 2014, 05:10   #91
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 596
Interesting.... The about Q window shows AmigaQuake 1.31 and ProQuake when running mods.
Michael is offline  
Old 18 March 2014, 18:19   #92
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 596
Confirmed, clearing GLQuake cache dir cures Malice hedgehog problem.

Actually, it looks like it's not necessary to kill the ID1 dir cache for playing other mods, but you have to clear it when testing a different GLQuake build,
since the files produced are different sometimes, and hence we are asking for trouble.

Made a time refresh test on start screen with minimum size (160x120 ?)
Got an unbelievable 160 FPS! When can we have the screen update bug fixed ?
I just have to see it live. (Playing Descent at 50 fps makes you sick a little, since the textures flow so smoothly)

PS: Can't figure out how to switch views in Malice (behind the back view)
console reports unknown command when you press the keys, yet the demo works fine, so the view mode works.
Michael is offline  
Old 19 March 2014, 00:01   #93
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 289
Hi !

Quote:
The about Q window shows AmigaQuake 1.31 and ProQuake when running mods.
That's normal: It's a simple print with no vars to check.

Related to that:
All of those strings at the beginning that say "unknown command whatever" now are corrected (cvar_register-ed).
But versions mods like Malice, add new vars to the game that quake doesn't know. But nobody will die for this ()

Wonder why nobody fixed this for decades (no pun intended), as "brightness" slide option that /doesn't work/not needed there/ 'couse you use -highcontrast comand at start: Seems to be difficult to do a new gfx palette on the fly for now.

So all this little things are "cleaned". Even principal Quake Tile picture, now has a proper "Amiga version + MiniGL version" to show.

I understand why nobody cared: Very time consuming + better things to do in life

All of this things meanwhile finding unused functions that where left, bugs and odd things.
Testing+fixing.
Cowcat is offline  
Old 19 March 2014, 17:21   #94
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 596
Found one more thing to look at...
Q1Arena (Quake 3 Arena for Quake 1 remake) fails on the GL versions and just quits.
And Shell outputs: I_Error: Hunk_Alloc: bad size: -1073741824

But works perfectly with basic Amiga 2.30 version.

PS: New vars are not a problem, the problem was when they were self introduces after each rerun
Michael is offline  
Old 19 March 2014, 18:10   #95
James
Registered User

 
Join Date: Mar 2010
Location: Beckenham/England
Posts: 455
Quote:
Originally Posted by Michael View Post
Actually, it looks like it's not necessary to kill the ID1 dir cache for playing other mods, but you have to clear it when testing a different GLQuake build, since the files produced are different sometimes, and hence we are asking for trouble.
No, to be clearer (hopefully) on what I was saying before - The first time you run a partial/total conversion glQuake will build new models for it in its own drawer. If it finds different models with the same name in the ID1/glQuake drawer it will attempt to merge the two, resulting in some very odd looking graphics. As many conversions do use the same names it is always safer to remove the ID1/glQuake drawer before running them for the first time. Once all the models have been built it doesn't matter if ID1/glQuake exists as it will use the models already in the Mods drawer.

Quote:
Originally Posted by Michael View Post
Found one more thing to look at...
Q1Arena (Quake 3 Arena for Quake 1 remake) fails on the GL versions and just quits.
And Shell outputs: I_Error: Hunk_Alloc: bad size: -1073741824
This is also down to a bad model (at least for Amiga glQuake), delete the Q1Arena/glQuake drawer and let glQuake rebuild it. It should then work - up to a point, on one of the later levels the graphics get very "smeary" and soon after it crashes out... There are a few other glitches too, still well worth trying though...

Last edited by James; 19 March 2014 at 18:16.
James is offline  
Old 19 March 2014, 20:14   #96
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 596
James, you are correct again!
Clearing the GL directly helped to get the sucker running.

Does give out errors like this, probably something is misplaced
R_DRAW NO SPRITE FRAME 1.2.3.4

But I can't play more then 10 mins ;-(
It just hangs/freezes here with 1 second of sound looping.
Looks more like it happens when there is a big explosion near you, or just too many at the same time.

But otherwise I have not spotted to many problems, and the new (Q3) weapons look nice in GL versions with glares. (Shame, the plasma gun is only sprites)
Michael is offline  
Old 20 March 2014, 13:31   #97
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 289
Fancy stuff.

Little disk appeared again. Seems that there's (was) something with having original tile + characters + loading icon. That goes for all old glquake coders: A gl_lockmode change to MGL_LOCK_SMART/AUTOMATIC when icon function is called doesn't make a hit/crash, but it only appears on other screens, not in principal one with console characters (it is behind )

Something messed those 3 things going at same time -> the old "problem".

Yep: Window depth is available again as default, but I now leave an option to disable it just like it was on old builds (& because I want it).

Registered cvars at boot, and written Amiga version + more on principal tile. If someone has a better idea or thinks that is an heresy, please post.

Reduzed code (hope that didn't broke something), that leaves me more space for things: Getting closer in size to my first build, even using inline code now.

Hope to fix more things & gain "more".

P.S. Just a remainder: There's a quake console command "r_elim_areasizes" than can boost a little bit more speed depending on screen size used at cost of less definition (that was on old readmes)

"screenwidth*screenheight/75000, which corresponds to 1 pixel in 320x240 and 2.5 pixels in 512x384" -> r_elim_areasize 1.0 or 2.5

That gets written in config.cfg. To recall original one: "r_elim_areasize 0.5" on qconsole.
Attached Thumbnails
Click image for larger version

Name:	Blitz2014-a.jpg
Views:	165
Size:	300.7 KB
ID:	39464   Click image for larger version

Name:	Blitz2014-b.jpg
Views:	171
Size:	161.8 KB
ID:	39465  

Last edited by Cowcat; 20 March 2014 at 14:50.
Cowcat is offline  
Old 29 March 2014, 15:25   #98
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 289
A quiz for those who happen to have problems with new blitz m68k like black squares, full black screens, etc,etc.

Open a shell:
Go to (for example) your old w3d demos and run one of them like gears68k.exe
Close it.
Without closing the shell go to your quake dir and run it with desired options.

No problems . Use Snoopdos to see what is going on

Of course, that behaviour will be fixed on next release.
Cowcat is offline  
Old 30 March 2014, 07:14   #99
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
@Cowcat
You might be on the right track. Vbcc has a problem with initializing the FPU that Frank, ThoR and I are currently investigating. The FPU FPCR is retained from the last program used from a shell. This can be a problem if one of the previous programs opened one of the IEEE math libraries as they may change the FPCR. I have written a small program called InitFPU which initializes the FPU. Execute it as the last program before glQuake (or any other vbcc compiled programs that use the FPU directly) in the startup script or before executing glQuake from the shell. Let me know if there are any problems and if it fixes the black screens. The next version of vbcc should have a fix for this which is easy enough. There is a related problem with the mieee.lib that will be more difficult to fix and may delay the next release unfortunately.
Attached Files
File Type: lha InitFPU.lha (854 Bytes, 76 views)
matthey is offline  
Old 30 March 2014, 14:13   #100
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 289
Quote:
Vbcc has a problem with initializing the FPU
Yes. I thought it was a "feature" .

A lot of frustrating days trying to fix that with no luck & then saw that other programs compiled months before did the same.

Suddenly realized that it was working as supposed to be. Something I started before but didn't remember.

So, running old gcc blitz before new blitz........opened "mathieeedoubbas.library"

More Sherlock H. than programming. Now I open that library at beginning of quake code as a temporary fix.

I know there's a lot of hair pulling for new vbcc release. Keep on.

Last edited by Cowcat; 30 March 2014 at 15:16.
Cowcat 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 22 October 2010 00:49
Blitzquake (GLquake) mouse look Angus support.Games 0 11 October 2008 01:46
BlitzQuake Install Coolit support.Games 0 02 September 2005 22: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 21:38.


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