BlitzQuake

[jack-3d]

Just tested low res 320x240 (was 640x480)

A4000 (604e/200+Permedia2) = 40,8 (was 20.9)
A1200 (603e/330+Voodoo3) = 32,0 (was 28,5)

PPC is working fine, but I see some strange performance difference in 68k:

A4000 (060/50+Permedia2) = 14,8 (was 11,4)
A1200 (060/66+Voodoo3) = 13,6 (was 12,1)

Now the Warp3DPPC.library difference between original (100852 bytes) and new (62504) is "nothing". In both cases same fps.

Still I am very satisfied with stability and performance. I am happy you people started to create and optimize for WarpOS and Warp3D again

[jack-3d]

Reporting problem to Warp3Dppc.library

I just found a demo Another Dream Away by Madwizards crashes with it (it crashes right after the MaWi logo). When I put the 4.2 original library back, demo works fine from the bigining to the end. It is on Permedia2, most of the W3D demos were programmed on the Permedia2 chipset only.

[Cowcat]

@jack-3d
Yep, at least I didn't break the library. On the next unreleased one I notice a real difference but I need to do more tests. I only focus on the used functions for Blitz (or a couple more) but nowadays it doesn't make the usual ward3d demos faster or something like that. The way it works really depends of what kind of code/engine the program uses: A slow program cannot be faster no matter what you do to warp libs, but if it's a fast program, it can benefit from a less "saturated" or bad compiled library. Matthey and others are focused on fixing the massacre the 68k libs had plus putting their code knowledge on them. PPC libs are other very different chapter & suppossedly all that could be optimized 13 years ago stays the same nowadays & in practice all code is set on stone. But seeing that some code could be bypassed, opened some little oportunities to do some experimentation. But no, nothing like "tomorrow Blitz will be 10 fps faster" (maybe 2 fps faster ).

EDIT: I broke it !

[Cowcat]

Reporting problem to Warp3Dppc.library

That's what I wanted to read. So, more work !

Edit: That demo seems to work OK on my newest lib. I did try other "ada" demos on the older but not that one.

[Michael]

Just out of fun tried v5.6 GLQ 68k build under UAE and it works almost perfectly there too!
What's odd, on my config DEMO1 scores the same 29 FPS in 320, 640 and 800x600 modes.
However against the wall timerefresh is crazy/impossible 222 FPS.
What's the magic behind same 30 FPS limit on fast 68K with fast 3D and similar performance on 603/BV ?
Nevertheless the point was to see if it works fine, and interesting enough there is no purple dot problems in 320x window mode. What's at fault is still a mystery.

[Cowcat]

New (fixed ?) post of Warp3DPPC. Seems to work ok for @Jack-3d.

Unfortunately, if something is gained or not with this one, I can't test it properly: A lot of problems (voltage) with my Miggy butchers any further experimentation: Looking more to a multimeter those days than code.

[Michael]

So then, any chance to see TIMEREFRESH working? Based on Q2 findings?

[Cowcat]

I took another look at it: Did it months before when searching solutions within the Q2 source.
I really don't know. It is not exactly the same and looks like the problem with "icon" disc (not being drew in front of Quake principal image).

[ancalimon]

Wow! Didn't know there was a betatesting going for a warp3dppc.library

Will join the fun in two weeks

One thing I had in mind. When installing warp3d on a ppc machine, did it also install the 68k libraries? So is it ok to use Cosmos's warp3d updates for 68k with this?

[Cowcat]

@ancalimon
It's only a little experiment. And you don't need 68k w3d libraries for warpos binaries

[Michael]

Any chance to routing timerefresh to same rendering routine as timedemo ?
On the other hand, timerefresh uses a 'frozen' world.
Interesting enough, Q1 should have TIMEREFRESH ] too, but it does not make any speed difference, unlike Q2.
And it looks like we are waiting for an updated compile with new math lib ;-) That should fix some black issues.

[matthey]

Originally Posted by Michael

Any chance to routing timerefresh to same rendering routine as timedemo ?
On the other hand, timerefresh uses a 'frozen' world.
Interesting enough, Q1 should have TIMEREFRESH ] too, but it does not make any speed difference, unlike Q2.

The 3D engines of Q1 and Q2 are very different. The Q1 engine is highly optimized but not flexible and difficult to create levels. Faster CPUs allowed Q2 to be less optimized and more flexible.

Originally Posted by Michael

And it looks like we are waiting for an updated compile with new math lib ;-) That should fix some black issues.

There is a good chance that the "black issues" can be solved with the FPU initialization although it may be necessary to change the default rounding mode to round toward zero for the Permedia W3D driver. Some vbcc math lib functions have changed to better tolerate any rounding mode. It's still not recommended to use rounding precision less than double precision. The default rounding mode of to nearest (ties to even) and rounding precision of extended precision (maximum) should give the most accurate results.

[ancalimon]

What exactly do I have to do to try blitzquakewos on my CVisionPPC?

EDIT: Managed to run it. The graphics seem the same as software Quake unlike the other glquakewos version.

[Michael]

It's much prettier with GL glow effects and flares
And more importantly, stable,compatible with packs and fastest out there!

[Cowcat]

The graphics seem the same as software Quake unlike the other glquakewos version.

mmm......There's no graphics difference between old glquake & blitz, apart from faster render functions, effects, culling optimizations, assembly code, etc. Old PC version looks like that (I think )
If someone wants the same look than old glquakewos you only need to change gamma & probably use -oldalpha option for some transparency effects (that I implemented).
Voodoo owners have the option to use lightmaps paks for a better......look

[Cowcat]

12000+ views

So, here goes the full source.
I added a "-closeworkbench" option inside if it's needed for low mem display on full screen, etc.
vbcc, minigl from aminet, amitcp devs... Change the makefiles to your config-vbcc, cpu, etc, substitute the original minigl src with those files included & probably you have to rebuild the genasm bins that are inside.

Soon I will delete the older builds. Funny stuff : An old 714k crossdos floppy has been a key part for sharing this stuff.

[Cowcat]

New Warpos version:

New console options & some cleaning:
gl_classic_particles - retro feeling & could be combined with -quadtex when starting game.
r_shadows now works with vertexarrays & rotations are fixed (no shadow for gun & some flying stuff due to old engine)
custom fog - gl_fogred (blue/green), gl_fogstart, gl_fogend, gl_fogdensity

All values now get saved on config.cfg file.

Some fixes like blend lights when barrels explode, etc.

The new episode "dopa" from Machine Games works (but not timedemo !)

[jack-3d]

5.7 wow, thank you! Looking forward to get back from vacation and test it.

[Cowcat]

Customizing fog, retro particles & shadows now looks like this:

[ Show youtube player ]

[James]

Nice!
Are you going to update the 68k version too?