BlitzQuake

[Cowcat]

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...

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.

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

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.

[Michael]

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 ?

[Cowcat]

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.

[Michael]

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.

[matthey]

Originally Posted by Michael

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.

[Michael]

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?

[Cowcat]

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.

[Michael]

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.

[James]

Originally Posted by Michael

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).

Originally Posted by James

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.

[Michael]

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]

Interesting.... The about Q window shows AmigaQuake 1.31 and ProQuake when running mods.

[Michael]

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.

[Cowcat]

Hi !

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.

[Michael]

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

[James]

Originally Posted by Michael

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.

Originally Posted by Michael

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...

[Michael]

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)

[Cowcat]

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.

[Cowcat]

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.

[matthey]

@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.

[Cowcat]

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.