Quake 2 WorkShop

[Cowcat]

New builds of classic Hyperion source code. Did my best to modify the original gcc code to be vbcc "happy". Soon the new code will be uploaded

Note: The original comercial binary has undisclosed draw rutines that aren't on minigl aminet sources, so maybe those new builds are "slower".

Couldn't resist to add real windowmode for mouse (minor mod)

[matthey]

There a few downloads but it's awful quiet in here .

@Cowcat
I haven't had time to test the newest version as I'm working on getting the new vbcc 68k FPU libraries ready. If everything continues to go well, I may have something for you to try within the week. Also, Frank Wille is working on a fix of a PPC WarpOS varargs bug in vbcc if you didn't know already.

"The open PPC varargs issue seems fixed. A few days ago I debugged a crash of
vbccppc under WarpOS, which only occured because of the special memory
management (which I wrote myself) of the WarpOS kernel. Finally I found a
buffer overflow by 1 byte in string_expression() and I'm still waiting for
Volker's approval of my patch."

[jack-3d]

I will test today. Dont worry I will have for sure some feedback and most probably also questions and hints, but after the test. Also I will compare with Hyperion version.

[Cowcat]

@Matthey
Hi! Been busy these days & couldn't work on code or new release for you to test. Hope that is better than the first one & the missing features working.
Those builds are made with a "some weeks ago" testing vbcc version with your code already inside.
The warpos fix is most likely the bug I found time ago (a minor thing). Don't know to what extent the problem could be on other areas, but Phx built a fixed wos vbcc version that cured that "issue" (ctype.h nightmare).

@jack-3d
No problem: All is "testing" and probably slower than original one: The missing experimental minigl code. But looks great (specially the 68k version). You need a lot of CPU power: If BlitzQuake was ok on your system, think "half-fps".

Still a lot to be done code wise: Don't know if network works (?), no PC analog joystick (disabled), ref_gl.dll should clean textures and free memory (I think it doesn't do well), etc,etc.

Performance tips:
I use ref_glnolru.dll (faster).
gl_texturemode command "GL_NEAREST"
gl_drawparticles "0" (faster, but no "gore & blood")
There's a strange one: gl_ext_multitexture that is on "1" by default: Oddly enough when you set it on "0", you get light effects on shooting and seemed to me "faster": You need to refresh the dll to enable that effect (going to video menu & ESC).

Will make a 060 build soon: Hope that my hd doesn't burn with this heat wave: Already have a shock when it stopped suddenly to work...........

I prefer to have those builds "vanilla": There's no special optimizations, but I'm working a little on some experimental mouse handler similar to what we did on BlitzQuake.

[matthey]

@Cowcat
The beta version of the vbcc 68k FPU C99 math support can be found here:

http://eab.abime.net/showthread.php?p=969253#post969253

It includes some new functions and support that I'm sure you don't have but it's very early. You can try it out when you have the time.

[Cowcat]

@matthey
Alright !

[matthey]

@Cowcat
The latest 68060 build works about the same as the last I tested but a little faster probably because of the 68060 target. The speed is really good moving around but trying to aim during combat is still tricky as the cross hair point jumps around. The shading or lighting is still messed up on objects and enemies (not walls or floors). It seems stable although I didn't check for hits as I had TLSFMem running.

[Cowcat]

@matthey
Well, didn't see anything wrong about shading or lighting on Warpos version. Too slow for me to test 68k version (will try anyways), so don't know where the problem could be since is the same code for both. Bug 1
Aiming: Speed is the issue with this one: Too many things at the same time, maybe disabling particles do some favour to the aiming. However I don't like the approach made with the general event handling (IDCMP_MOUSEMOVE|IDCMP_DELTAMOVE) and the sys timing (it is what it is anyways). Not a Bug really

So part of the new experiments are towards new mouse handling or better event handling as I said. But that belongs to "new code" added to the original.

[Michael]

Any idea why it takes soooooo loooong to load ?
On a SCSI drive with FFS it takes a minute to load the first ID video, then a few minutes to load the game!
Q1 on the same drive takes 3 seconds to get to the game!

[FOL]

Originally Posted by Michael

Any idea why it takes soooooo loooong to load ?
On a SCSI drive with FFS it takes a minute to load the first ID video, then a few minutes to load the game!
Q1 on the same drive takes 3 seconds to get to the game!

FFS is SLOwwwwwwww.

[Michael]

FPS ?..... Loading the game takes more then 10 minutes! Something is patheticly wrong with the code or conflicting on my system. I remember it loaded slow when I tried it yaers ago, but not to this extend! Any ideas ?

[matthey]

Originally Posted by Michael

FPS ?..... Loading the game takes more then 10 minutes! Something is patheticly wrong with the code or conflicting on my system. I remember it loaded slow when I tried it yaers ago, but not to this extend! Any ideas ?

Loading is relatively slow even on my CSMK3 with 30MB/s HD. It's one of the few programs on the Amiga that isn't instantaneous loading in human time. Adding buffers may help but it's probably the game that is slow. Maybe the data is converted from little endian to big endian at load time. Naive conversions may be half the speed of smarter versions. For example:

byterev:
   ror.w #8,d0
   swap d0
   ror.w #8,d0
   rts

This is adequate to endian convert a few values but it's poor for converting a buffer. Inlined code that interleaves 2 endian conversions at the same time could be more than twice as fast on the 68060.

[Michael]

I don't know what's slow, but looking at the CPU load meters the CPU is not loaded, around 2-5% only during loading of Q2, this means that something else is going on, since all resources are free. I can even start Q1 in parallel without much trouble when Q2 is loading.

[Cowcat]

@Michael
On my system the WOS version displays the intro in less than 2 seconds, then loading the demo lasts 40 seconds. The 040 version loads the intro like 4-5 secs, and demo lasts 1:15 minute. There's no special waiting when first long cinematic loads (at beginning of game), although there's a "hiccup" when that one finishes and stays with console and cursor like waiting. A reload of game and going out, puts you in loading game mode.

Waiting for the cinematics is weird ...

SFS here, in an old HD (in fact same partition where Q1 Resides).
Dunno what it's the issue.

EDIT: 10 minutes waiting reminds me the "Mutant Camels" tape loading time on my still alive C-64.

[Michael]

Booted from a different backup system drive, and all is normal!
Loading takes a few secs, almost as quick as Q1.

Now time to find the culprit. Suspecting v44 exec from rom update.

My BV in 512x384 mode - timerefresh at start 32 FPS, and it works unlike Q1!

How do we do a timedemo in Q2?

[matthey]

Originally Posted by Michael

Booted from a different backup system drive, and all is normal!
Loading takes a few secs, almost as quick as Q1.

Now time to find the culprit. Suspecting v44 exec from rom update.

Perhaps something corrupt in your OS too. It would be good to try that setup again after a cold reboot.

Originally Posted by Michael

My BV in 512x384 mode - timerefresh at start 32 FPS, and it works unlike Q1!

How do we do a timedemo in Q2?

timedemo 1
map demo1.dm2

My Q2 demo installation didn't have the needed files and gave me an error when I tried though.

[Cowcat]

@Michael
It becomes a classic: Another big program (Q2) that is used to find system problems.

timerefresh at start 32 FPS, and it works unlike Q1!

I suspected that, and AHI works too (not as BlitzQ that is on fixed low frequency).

@matthey
Tested 040 version to find those light render problems: Don't see anything wrong on display, apart from the occasional disappear of some model for a split second due to slowness.
Anyone with the same problems ??

[matthey]

Originally Posted by Cowcat

It becomes a classic: Another big program (Q2) that is used to find system problems.

Including compiler problems .

Originally Posted by Cowcat

I suspected that, and AHI works too (not as BlitzQ that is on fixed low frequency).

Sound works well .

Originally Posted by Cowcat

@matthey
Tested 040 version to find those light render problems: Don't see anything wrong on display, apart from the occasional disappear of some model for a split second due to slowness.
Anyone with the same problems ??

I would expect Voodoo 3 owners to have the problem but maybe it's only a Voodoo 4 problem. Opening a big endian screen would explain the problem of distorted colors. Does Q2 open a little endian "PC" screen?

I have uploaded a new version of the c99 math libs for vbcc:

http://eab.abime.net/showthread.php?t=74692

Let me know if you compile anything with them.

[Cowcat]

Originally Posted by matthey

. Does Q2 open a little endian "PC" screen?

Don't know There are conversions done for image loading, but can't see If something like that happens for screen...

Still cleaning up source code, then will try new vbcc libs of yours on Q2

One thing I have to mention: For those who have and old config.cfg Q2 file from other versions, it should be cleaned or removed for this one. I enabled gl_vertex_arrays by default on those new builds (faster), so check out if it's on "1" on that script.

EDIT: By the way, the "black boxes" bug with BlitzQuake 68k on Permedia gfx, still happen on Q2, so you need matthey`s W3D_Permedia.library mod. Anyways those who have BPCC CVPPC, use WOS versions.....

[matthey]

Originally Posted by matthey

Does Q2 open a little endian "PC" screen?

Originally Posted by Cowcat

Don't know There are conversions done for image loading, but can't see If something like that happens for screen...

I was able to check. My Q2 screen is using a little endian "PC" screen mode so the Q2 distorted colors do not appear related to the pre-existing distorted colors bug in Elbox's 2D Voodoo driver with big endian modes on the Voodoo 4. I wonder if the original Q2 had the same problem or if this has been introduced in the new compiles?