OpenArena Message Boards

OpenArena Contributions => Development => Topic started by: sago007 on July 01, 2008, 02:03:07 pm



Title: Binaries for 0.8.x test thread
Post by: sago007 on July 01, 2008, 02:03:07 pm
The Road to Stable Binaries for 0.8.x

Note these binaries should work with both 0.8.1 and 0.8.5, but not 0.8.0 or older

New 0.8.x binaries: http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-22.zip
Source (incl. svn files so they can be easily updated): http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-22.tar.bz2

Updated 2011-07-25:
Includes modifications from ioquake3 revision 2097 and 2098.

Updated 2011-04-17:
Includes new changes from fromhell's rendering patch.

Updated 2011-03-07:
Synced to ioquake3 1910
Orange color in console

Updated 2010-08-30:
g_humanplayers are now set by the engine with this patch (http://bugzilla.icculus.org/show_bug.cgi?id=4702#c2)

Updated 2010-08-21:
sv_public is no longer read only
Added sv_dorestart that forces a restart (including reload of all items) on next map_restart.

Updated 2010-07-04:
Synced to ioquake3 rev1788
Stopped trying to avoid checking all files for pure check, too much trouble
FreeBSD patch by kamikaze ( http://openarena.ws/board/index.php?topic=3723.0 )

Updated 2010-04-24:
Synced to ioquake3 rev1783
No longer checks qagame.qvm in pure mode allowing for serverside only mods in pk3-files
No longer strips '\n', '\r' and ';' from say and say_team
serverstatus fixed

Updated 2010-01-15:
Applied patch: http://files.poulsander.com/~poul19/public_files/oa/dev081/OORefFlare.patch

Updated 2010-01-03:
Updated ingame icons.

Updated 2010-01-02:
Updated to latest ioquake3 revision
Changed the client representation of serverstatus to not show client numbers (I will add actual client numbers in the game code), they where wrong
The mouse acceleration thing must be positive or mouse acceleration will be disabled. (as pointed out by Falkland)

Updated 2009-12-12:
Updated to latest ioquake3 revision (dedicated server now has voip)
Added console patch from other thread. (con_height has been slightly changed and renamed)

Updated 2009-11-27:
Updated to ioquake3 revision 1753
Made a small workaround to circumvent a bug in the new cvar system. (I have reported the bug upstream and hope to get a correct solution some day)

Updated 2009-11-05:
Backported ioquake3 r1730 and r1731
New icon

Updated 2009-10-28:
Based on very resent ioquake3 version
Uses SDL 1.2.14 and sets the new environment virable in Windows to allow Caps Lock and Num Lock to be bound as keys.

Updated 2009-05-06:
Based on some resent ioquake3 version
Some openAL problems fixed
I increased the config max size as suggested somewhere from 16 Ki to 128 Ki

Updated 2009-03-15:
Based on ioquake 1.36 release candidate
Multiple players behind a cheap NAT router now works again
Removed CVAR sv_strictAuth (now used anyway)
Added CVAR sv_public (server sends heartbeats even if it is a listening server)


Title: Re: Binaries for 0.8.0 test thread
Post by: fromhell on July 01, 2008, 11:15:02 pm
stickied because testing is damn important

I haven't committed my media changes yet but I shall shortly, as missionpack is starting to be more 'complete' menu side


Title: Re: Binaries for 0.8.0 test thread
Post by: fromhell on July 04, 2008, 02:15:13 am
Icons are still q3's


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 04, 2008, 08:25:22 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on July 04, 2008, 12:23:06 pm
Icons are still q3's
In my self-satisfaction of remembering the .h-image file I forgot that some of the icons are still in an real image format.

The reference for x86 machine code optimization is gcc manual : http://gcc.gnu.org/onlinedocs/
Read this for reference to FORTIFY_SOURCE : http://fedoraproject.org/wiki/Security/Features#FORTIFY_SOURCE

I wonder that is the optimal choice for compatibility? Should -mtype be generic or i386?

After reading the Makefile through I found one really annoying thing: WINDOWS 9x/nt/2000 are no longer supported. I believe they have problems with the IPv6 support at least it is the network code that fails to compile if I re enable them. Windows 2000- users might need there own binary.


Title: Re: Binaries for 0.8.0 test thread
Post by: damocles on July 04, 2008, 12:46:43 pm
-march should generate code for a specific processor or architecture (e.g. i486, x86_64) -- no backwards compatibility guaranteed (http://rpbouman.blogspot.com/2007/01/gcc-march-and-mtune.html).

-mtune (formerly -mcpu) optimizes for a specific processor, but allows backwards compatibility -- doesn't touch the ABI and the set of available instructions (http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/i386-and-x86_002d64-Options.html).

(For example, -march=i486 -mtune=i686 will be optimized for Pentium Pro and above, but will easily run on a 486 (*cough*) or Pentium clones if necessary.  I believe this is the default for Slackware.)

May not be consistent with your architecture or GCC version (http://www.gentoo.org/doc/en/gcc-optimization.xml).  (I've had software "designed to run on Pentium and K5" completely break on a K6-2...)


Title: Re: Binaries for 0.8.0 test thread
Post by: fromhell on July 04, 2008, 01:47:05 pm
After reading the Makefile through I found one really annoying thing: WINDOWS 9x/nt/2000 are no longer supported.
oh shit
i can't drop support for 9x in openarena
ioq3 is breaking more and more than before. A fork of the ioq3 source is starting to be more of a good idea.


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 04, 2008, 02:12:00 pm
----


Title: Re: Binaries for 0.8.0 test thread
Post by: fromhell on July 04, 2008, 02:13:16 pm
is this processor specific optimizations possible for the win32 build?

Because if so then I have some 486s, Cyrix's and K6's to test OA on ;)


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 04, 2008, 03:11:13 pm
----


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 05, 2008, 04:15:50 pm
----


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 05, 2008, 08:38:32 pm
----


Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on July 06, 2008, 05:43:06 am
Looks like there are lots of svn commits on ioquake3 right now.

Looks like it is mainly bug fixes. Except a new icon that I have to remember.


Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on July 07, 2008, 11:36:43 am
I am still waiting for ioquake3 to settle before posting the next binaries.

I have decided to join some ioquake3 mailing lists to keep me up to date with the problems.


Title: Re: Binaries for 0.8.0 test thread
Post by: jackoverfull on July 07, 2008, 03:31:05 pm
hi.

i'll be at home for a couple of days, so i'll try to provide a mac version of these binaries too. since here i haven't a tiger build machine ready i'll probably build everything  later and upload the bins on saturday.

regarding ipv6 on macs, it is well supported by every system currently supported by my builds, so there shouldn't been problems on that front.

chosen a period for the release? on this topic, i have to warn that i'll be often away until september and i will not be able to guarantee any build until then.


Title: Re: Binaries for 0.8.0 test thread
Post by: jackoverfull on July 07, 2008, 04:07:49 pm
ok, i've been too pessimistic. ;-)

binaries built, seems to be working.

going to test stereo visuals and ogg, trying to find a way to test ipv6 and voice chat.

no real problems during the build itself, had to avoid 10.3.x "normal" compatibility due the lack of openal on that system, as usual, but it should run on 10.3.9 anyway, as usual.
there is something really odd in the script that assemble the application package: it built an intel-only application (and i'm still on ppc...). i suppose, anyway, that's an ioq3 problem, since the patch file doesn't seem to interfere with that script. will see what's wrong later.
as you wrote, sago007, the app has an q3 icon.

i should be able to upload an assembled universal application package, whit all libraries included, in the next hours, hopefully.


Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on July 07, 2008, 04:10:30 pm
jackoverfull:
Some of the problems you mention appears to be solved in the current svn version and I can see the 10.2 and 10.3 version problem is discussed on the mailing list.


Title: Re: Binaries for 0.8.0 test thread
Post by: jackoverfull on July 07, 2008, 04:22:27 pm
sorry: could not find that. can you link, please?

anyway, i just saw that they chose to remove the support to 10.2. surely a good choice, since apple doesn't support it anymore herself...

tested r_anaglyphMode, seems to work fine (no glasses to test it "really", at the moment), although the cross-air remains a single one (but i read on ioq3 wiki that's normal and that's there is a fix).

r_stereoEnabled doesn't seem to do much after the restart, but i'm not sure that i'm supposed to notice anything without the glasses.

anything else to test about stereo visuals?


Title: Re: Binaries for 0.8.0 test thread
Post by: jackoverfull on July 07, 2008, 04:23:27 pm
ah, i was forgetting that...

i notice lines like these ones coming up frequently in the console:
Code:
previous mouse acceleration: 0.500000
restoring mouse acceleration to: 0.500000


Title: Re: Binaries for 0.8.0 test thread
Post by: jackoverfull on July 07, 2008, 05:32:09 pm
to enable ipv6 i should use net_enabled 2 or net_enabled 4, then restart, right?

i see that i have to do a full engine restart to have that working. seems to be ok, will try to host an ip6 test match in the next days, if i'll find the time.

anyway, i see that the default for net_enabled is "3", but i don't know what this means: there is no "3" here: http://svn.icculus.org/quake3/trunk/README?view=markup&pathrev=1342

and, about full engine restarts...

i didn't restart completely the engine when i was testing r_stereoEnabled. it needs a full engine restart too. and once enabled it causes my system to Kernel Panic, without even showing me the classical "you need to restart your system" box that os x shows in that situations.

looking to the log, i see that it has something to do with my graphic card (ati mobility radeon 9200). this (a graphic card extension failure) may explain the absence of that box. and, maybe, this is one of the problems that leaded the ioq3 team to mark r_stereoEnabled as "unsupported".

appending the log...

Code:
Tue Jul  8 01:20:56 2008


Unresolved kernel trap(cpu 0): 0x300 - Data access DAR=0x0000000000000000 PC=0x00000000009D5170
Latest crash info for cpu 0:
   Exception state (sv=0x2a515280)
      PC=0x009D5170; MSR=0x00009030; DAR=0x00000000; DSISR=0x40000000; LR=0x009D50DC; R1=0x2A5A39D0; XCP=0x0000000C (0x300 - Data access)
      Backtrace:
0x03FA1010 0x00731A94 0x007F13E0 0x0080732C 0x007F16BC 0x0080744C
         0x007EE6F4 0x0080750C 0x007FFBF8 0x00800900 0x00820244 0x007FD670 0x00378B8C 0x0008DC1C
         0x0002C1C8 0x00024C94 0x000B2DCC 0x0512050B
      Kernel loadable modules in backtrace (with dependencies):
         com.apple.ATIRadeon8500(5.2.8)@0x7eb000->0x82efff
            dependency: com.apple.iokit.IONDRVSupport(1.5.2)@0x762000
            dependency: com.apple.iokit.IOPCIFamily(2.4.1)@0x728000
            dependency: com.apple.iokit.IOGraphicsFamily(1.5.2)@0x73c000
         com.apple.driver.AppleMacRiscPCI(3.4.0)@0x9d0000->0x9d9fff
            dependency: com.apple.iokit.IOPCIFamily(2.4.1)@0x728000
         com.apple.iokit.IOPCIFamily(2.4.1)@0x728000->0x73bfff
Proceeding back via exception chain:
   Exception state (sv=0x2a515280)
      previously dumped as "Latest" state. skipping...
   Exception state (sv=0x3170a000)
      PC=0x94EFC438; MSR=0x0000F030; DAR=0x000FE000; DSISR=0x0A000000; LR=0x94F03360; R1=0xBFFEE8D0; XCP=0x00000030 (0xC00 - System call)

BSD process name corresponding to current thread: WindowServer

Mac OS version:
9D34

Kernel version:
Darwin Kernel Version 9.3.0: Fri May 23 00:51:20 PDT 2008; root:xnu-1228.5.18~1/RELEASE_PPC
System model name: PowerBook6,5
panic(cpu 0 caller 0xFFFF0003): 0x300 - Data access
Latest stack backtrace for cpu 0:
      Backtrace:
         0x0009B498 0x0009BE3C 0x00029DD8 0x000AF210 0x000B2A78
Proceeding back via exception chain:
   Exception state (sv=0x2a515280)
      PC=0x009D5170; MSR=0x00009030; DAR=0x00000000; DSISR=0x40000000; LR=0x009D50DC; R1=0x2A5A39D0; XCP=0x0000000C (0x300 - Data access)
      Backtrace:
0x03FA1010 0x00731A94 0x007F13E0 0x0080732C 0x007F16BC 0x0080744C
         0x007EE6F4 0x0080750C 0x007FFBF8 0x00800900 0x00820244 0x007FD670 0x00378B8C 0x0008DC1C
         0x0002C1C8 0x00024C94 0x000B2DCC 0x0512050B
      Kernel loadable modules in backtrace (with dependencies):
         com.apple.ATIRadeon8500(5.2.8)@0x7eb000->0x82eff`


Title: Re: Binaries for 0.8.0 test thread
Post by: jackoverfull on July 08, 2008, 05:15:42 am
now i see what's wrong in the assemble script: it expects ioquake3.xx bins, but the binaries are now called openarena.xx. it will be easy to fix.
it was only the system reporting incorrectly that the application was an intel one: it didn't contain a binary at all.

i see also that the dedicated intel server has been built, but the ppc one not.

i'm assembling a client-only test application for both ppc and intels, once i've finished i'll leave, i hope that i'll have the time to investigate and test a bit in the next few days, but i will not really be able to work on anything for at least 4 weeks, probably more.


Title: Re: Binaries for 0.8.0 test thread
Post by: jackoverfull on July 08, 2008, 05:30:26 am
here it is: ppc/intel client-only build.

http://www.jackoverfull.com/giochi/openarena/oabin-test-2008-07-01-mac.zip

i'm leaving right now, see you soon.


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 08, 2008, 03:09:52 pm
----


Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on July 08, 2008, 03:18:04 pm
- VoIP seems to have a high impact on data transmission : probably users with low (or not too low) bandwidth simply will not be able to use it.

- Users that have a router not supporting Ipv6 and use linux , at least can use ipv6 over ipv4 tunnel , but surely they will have problems with name resolution.

- Ipv6 support and VoIP should be tested in a "real" multiplayer environment ( A lan has 10 , 100 or 1000 Mb/sec of bandwidth )


- ioquake3 claims that it VoIP will not use more than 2 kb/sec while sending or receiving and will be automatically disabled if rate is not 25000+.

- It appears that IPv6 is discussed at the ioquake3 malling list. There will be a few changes to it and the author of dpmaster is in the discussion. (currently no master server software supports IPv6)

- You are right


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 09, 2008, 09:30:06 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 09, 2008, 09:44:15 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 13, 2008, 11:11:10 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: fromhell on July 17, 2008, 03:14:06 am
- Framerate counter reports 2x the framerate it actually is
- SDL input is still quite slow in low framerates (try com_maxfps 30, and maneuver around oa_dm3, it is obivous)
- Crash when quitting through the console


Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on July 17, 2008, 05:40:50 am
I'll try to compile a new sdl.dll I think that I might have missed some libraries then it was compiled. I am not able to do it until next week though.


Title: Re: Binaries for 0.8.0 test thread
Post by: Mr. Oho on July 17, 2008, 07:02:03 am
After reading the Makefile through I found one really annoying thing: WINDOWS 9x/nt/2000 are no longer supported.
oh shit
i can't drop support for 9x in openarena
ioq3 is breaking more and more than before. A fork of the ioq3 source is starting to be more of a good idea.

Yeah realy. Besides it makes you wonder what exotic crap api they had to use to break support for 2000...


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 17, 2008, 08:27:05 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 17, 2008, 08:56:28 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: Mr. Oho on July 17, 2008, 10:27:34 am
Yeah realy. Besides it makes you wonder what exotic crap api they had to use to break support for 2000...

It's normal : by their point of view they are trying to have a functional ioq3 version running on Vista

Hmpf they must be in a different universe from me... Seriously breaking support for something thats almost identical to xp in favor of this pice of bloat... no comment :[


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 17, 2008, 02:11:07 pm
----


Title: Re: Binaries for 0.8.0 test thread
Post by: Mr. Oho on July 17, 2008, 02:36:31 pm
Well , Microsoft has interrupted distribution of Windows Xp last June

True but that doesnt mean everyone has to support their sorry excuse of resource waste ;)


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 19, 2008, 06:07:18 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: fromhell on July 20, 2008, 04:34:23 am
- Framerate counter reports 2x the framerate it actually is
- SDL input is still quite slow in low framerates (try com_maxfps 30, and maneuver around oa_dm3, it is obivous)
- Crash when quitting through the console

You MUST specify the platform when u've encountered these problems

Gee everyone knows I use Windows. I have to do my development on that.


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 20, 2008, 06:16:56 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: fromhell on July 20, 2008, 01:40:12 pm
hey that ubuntu sucks thread down in club nub


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 20, 2008, 01:44:32 pm
----


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 21, 2008, 05:17:50 pm
----


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 22, 2008, 09:08:21 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on July 25, 2008, 09:58:19 am
I have just uploaded some new binaries.

Build on SVN 1432
Icons have been fixed (I hope)
IPv6 removed (based on info from the ioquake3 mailing list it looks like it is going to be changed soon and this might end up being incompatible) (This might also fix Windows 2000 and older support)
Sago's Custom Windows Mouse Acceleration Hack


About Sago's Custom Windows Mouse Acceleration Hack:
This is a workaround the mouse acceleration bug found in the Windows version of the game
Mac OS X is already using a hack like it
If the game or computer crashes the mouse acceleration will not return.
It might break earlier versions of Windows that did not have mouse acceleration. Possible killing the speed instead (please test on a non productive system... and please do not use Windows 98 as a production system)
The Windows API is not documented very well, my hack might create a huge disaster with possible lethal damage as a result. Please wear protective gear while testing!


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 25, 2008, 11:55:00 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on July 25, 2008, 02:16:59 pm
The oachanges file in the zip archive has been updated with tr_bloom.c

I am mostly interested in eventual network problems (have I done something nasty while removing IPv6 support)

How many Windows versions works with the hack. I have only tested on Windows 2003. The Windows API documentation tells that the mouse speed is stored in mosueInfo[2] but it is really the acceleration that is stored there and I fear that on pre-Windows XP machines there are only two values in that array. I don't think it is a particular safe way to access such values but I think it is the Windows way.


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 25, 2008, 04:50:20 pm
----


Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on July 26, 2008, 06:48:15 am
Instead of removing IPv6 support , a better solution could be to temporary declare net_enabled cvar as CVAR_CHEAT or CVAR_ROM and lock the value to 1 , so forcing OA to use IPv4 only and not use IPv6 even if present . That's logically WRONG , but the final result could be acceptable.

A problem (besides pre-winxp) is that our version will never be able to access a IPV6 master server. The ioquake3 IPv6 implementation is currently being changed meaning that our 0.8.0 version will be incompatible with the future versions.

However if it wasn't for the pre-winxp problem I would properly not have touched it.


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 26, 2008, 08:23:08 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on July 26, 2008, 08:36:25 am
I would prefer to have a "#if IPv6" around everything IPv6 related and it annoys me that it is not the case. VOIP can be enabled and disabled that way.


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 26, 2008, 08:54:29 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: fromhell on July 28, 2008, 06:05:57 am
The mouse does feel a little better, but in slow framerates it's still quite sluggish.

Crash on exit / double fps counter still exists.



Title: Re: Binaries for 0.8.0 test thread
Post by: pulchr on July 28, 2008, 06:52:29 am
is there an .exe-file of the new binaries (0.8.0) so i can try out the mouse feeling?

i'd like to feel if there's been any change with the mouse and i'm useless at compiling something myself :(

but i'd like to help out with some input :)



Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on July 28, 2008, 06:58:34 am
is there an .exe-file of the new binaries (0.8.0) so i can try out the mouse feeling?

Yes the zip file contains the binary including the Windows exe files.


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on July 28, 2008, 08:47:58 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: pulchr on July 28, 2008, 03:30:28 pm
i tested the 0.8.0 test binaries with the rest of the 0.7.7 game (copied over but did not overwrite the 0.8.0 files).

using these binaries the mouse feels so much better than the 0.7.7 version. haven't played that much yet but it feels close to the 0.7.1 mouse that i like. could be the same, need some more playtesting first. (i'm using windows xp).

eddit: spelling and nau haz moor infoz


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on August 04, 2008, 06:32:34 am
----


Title: Re: Binaries for 0.8.0 test thread
Post by: fromhell on August 04, 2008, 06:54:41 am
but then we'd need msvc anyway, which compiles exes and forces dependencies shell functions that only exist on Windows 2000 and XP. Screw that.


Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on August 04, 2008, 08:09:56 am
I don't think it is tested on older versions of Windows but since they don't have IPv6 support I doubt a simple header will fix it as some system calls will be missing.

Has anyone tested the first binaries: http://brie.ostenfeld.dk/~poul19/public_files/oa/dev080/oabin-test-2008-07-01.zip to see if they run on Windows 98 etc.


Title: Re: Binaries for 0.8.0 test thread
Post by: woekele on August 04, 2008, 08:49:58 am
I think they're adding a USE_IPV6 flag to ioq3. So this should be solved soon.


Title: Re: Binaries for 0.8.0 test thread
Post by: fromhell on August 04, 2008, 11:35:02 pm
Has anyone tested the first binaries: http://brie.ostenfeld.dk/~poul19/public_files/oa/dev080/oabin-test-2008-07-01.zip to see if they run on Windows 98 etc.


Title: Re: Binaries for 0.8.0 test thread
Post by: damocles on August 05, 2008, 01:57:32 am
sago, see the MSDN docs -- include ws2tcpip.h and also wspiapi.h

freeaddrinfo was added to XP; the above will fall back to wspiapi.h's inline code on pre-XP.



Not working for the same reason on NT 4.0.  (Also won't detect Voodoo3 since 0.7.6, probably having to do with this (http://openarena.ws/board/index.php?topic=1880.0) and that (http://openarena.ws/board/index.php?topic=1881.0), but this is beyond our current scope -- don't worry about this part too much.  (Sorry, I've been away from this machine and other places for a month, and considered it unimportant (Voodoo3's OpenGL 1.1 is somewhat broken for windowed apps, and, uh... it's NT 4.0).))


Title: Re: Binaries for 0.8.0 test thread
Post by: fromhell on August 05, 2008, 02:39:58 am
Also won't detect Voodoo3 since 0.7.6,
Voodoo3 has been confirmed to work (http://openarena.ws/shots/oldcard/3dfxvoodoo3/) in OA 0.7.6, in WinXP at least. Voodoo Banshee and Voodoo2 also work fine as well. It does do 16-bit color because that's all it's capable of (but if the card also does 32-bit color, it won't ever use 16-bit color :( )

A video card chipset compatibility chart in the wiki could be useful.


Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on August 05, 2008, 03:04:45 pm
Binary with IPv6 and a wspiapi.h (that I found somewhere): http://brie.ostenfeld.dk/~poul19/public_files/oa/dev080/openarena.1437.exe.zip

I just want to know if it can run.

EDIT: And I know about the icons.


Title: Re: Binaries for 0.8.0 test thread
Post by: damocles on August 05, 2008, 04:34:42 pm
Binary with IPv6 and a wspiapi.h (that I found somewhere): http://brie.ostenfeld.dk/~poul19/public_files/oa/dev080/openarena.1437.exe.zip

I just want to know if it can run.

EDIT: And I know about the icons.


sago, wspiapi.h works now, but cannot detect OpenGL at all (TNT2 Vanta, same NT 4.0 SP6a).  Therefore, will not run.

Code:
ioq3+oa 1.35_SVN1437M win_mingw-x86 Aug  5 2008
----- FS_Startup -----
Current search path: ...
----------------------
3882 files in pk3 files
execing default.cfg
couldn't exec q3config.cfg
couldn't exec autoexec.cfg
Hunk_Clear: reset the hunk ok
----- Client Initialization -----
Couldn't read q3history.
Your network rate is too slow for VoIP.
Set 'Data Rate' to 'LAN/Cable/xDSL' in 'Setup/System/Network' and restart.
Until then, VoIP is disabled.
----- Initializing Renderer ----
-------------------------------
QKEY building random string
QKEY generated
----- Client Initialization Complete -----
----- R_Init -----
SDL_Init FAILED (No available video device)
----- CL_Shutdown -----
RE_Shutdown( 1 )
-----------------------

Minor:
  • Using a config that was already there (070?) resulted in nothing mentioned about VoIP (nothing in between "Client Initialization" and "Initializing Renderer").  I could be wrong.
  • (Previously, on the Voodoo3, 0.7.6/0.7.7 would simply fall back to MS GDI Generic (equivalent of r_allowSoftwareGL indirect).)





Windows 2000 (warning: I could also be wrong about the following):

Will run, but will then drop back to desktop after video mode switch, if you are running a clean install, without a Application Data/OpenArena/baseoa from 0.7.x already present.  (Does not seem to generate one, either.)  Stops at "Sound initialization complete" independent of SDL/OpenAL.



Will run and continue to intro and menu if you already have a config.  (Naturally, finds 43 IPv4 servers, and then lists zero detected.  Offline single player is fine...)
Code:
--- Common Initialization Complete ---
Winsock Initialized
Hostname: ...
IP:
Opening IP6 socket: [::]:27960
WARNING: NET_IP6Socket: socket: WSAEAFNOSUPPORT
WARNING: Couldn't bind to a v6 ip address.
Opening IP socket: 0.0.0.0:27960
Sys_StringToSockaddr: Error resolving ff04::696f:7175:616b:6533: An address incompatible with the requested protocol was used.
WARNING: NET_JoinMulticast6: Incorrect multicast address given, please set cvar net_mcast6addr to a sane value.
Requesting servers from master dpmaster.deathmask.net...
CL_ServersResponsePacket
43 servers parsed (total 43)
----- CL_Shutdown -----
OpenAL capture device closed.
RE_Shutdown( 1 )
-----------------------


Title: Re: Binaries for 0.8.0 test thread
Post by: fromhell on August 06, 2008, 12:39:24 am
Binary with IPv6 and a wspiapi.h (that I found somewhere): http://brie.ostenfeld.dk/~poul19/public_files/oa/dev080/openarena.1437.exe.zip

I just want to know if it can run.

EDIT: And I know about the icons.
It runs in Windows98se, OpenGL functions, game can be started


Title: Re: Binaries for 0.8.0 test thread
Post by: CFQ on August 08, 2008, 07:24:45 pm
----


Title: Re: Binaries for 0.8.0 test thread
Post by: damocles on August 12, 2008, 10:14:55 pm
sago, the binaries from serverfixFor080.zip and a compiled ioquake3serverFix2.tar.bz2 (http://brie.ostenfeld.dk/~poul19/public_files/oa/dev080/ioquake3serverFix2.tar.bz2) explicitly needed in_mouse "-1" to be able to run and detect OpenGL on NT 4.0 (without GLimp_Init() - could not load OpenGL subsystem above).  This is not true for stock 0.8.0, even with in_mouse "-1".  (Haven't tried Voodoo3 yet, but it's probably the same.  Also happened once in Windows 2000, attempting to compile above...)

(previous stuff about networking code omitted, but notice the blank SYS_ShowIP "IP: " in the Windows 2000 log above)

Source can now be compiled with Ubuntu 8.10 64 bit version.
IPv6 master server support (not that we have one).
Possible JIT for more architectures (I have not read the ioquake3 mailing too carefully so it might not actually be in the engine yet). 
Mainly for those that have problem with newer Linux distributions.
I will not be able to test the 0.8.1+ binaries for a while.


Title: Re: Binaries for 0.8.0 test thread
Post by: sago007 on September 03, 2008, 04:04:54 am
The Road to Stable Binaries for 0.8.x

This is the serverfix binaries, just with a new source packet (without game logic code).

Source: http://brie.ostenfeld.dk/~poul19/public_files/oa/dev080/openarena-engine-source-0.8.x-1.tar.bz2
Original serverFix bins: http://brie.ostenfeld.dk/~poul19/public_files/oa/dev080/serverfixFor080.zip
Linux i386 binaries with better compatibility (compiled on Sarge): http://brie.ostenfeld.dk/~poul19/public_files/oa/dev080/openarena-engine-bin-0.8.x-1-i386.zip

The source directory does not include headers needed for cross-compiling of pre-Windows XP binaries.

Unfortunately I don't have access to an old 64 bit machine to make compatible binaries for that arch. I might release a special pre-Windows XP exe since that header appears to create problems for some.

Bumping


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: sago007 on January 06, 2009, 01:33:52 pm
Source can now be compiled with Ubuntu 8.10 64 bit version.
IPv6 master server support (not that we have one).
Possible JIT for more architectures (I have not read the ioquake3 mailing too carefully so it might not actually be in the engine yet). 
Mainly for those that have problem with newer Linux distributions.


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Neon_Knight on January 06, 2009, 03:01:35 pm
Downloaded new binaries, testing...


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Cacatoes on January 07, 2009, 10:31:38 am
I tried to run a server ( http://dpmaster.deathmask.net/?game=openarena&server=88.160.192.237:27961 )
It is not listed in game browser, nor with dpmaster's page (  http://dpmaster.deathmask.net/?game=openarena ) still, the server is accessible.

It's meant to be a CTF server.
One of the changes I noticed is the name of the game (the mod), openarena instead of baseoa.

Maybe there is something wrong with contacting dpmaster (due to ipv6 ?), I'll check the logs when I can.


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: sago007 on January 07, 2009, 11:38:27 am
Thanks for that rapport. I can see that the heartbeat function has changed but I don't know why it doesn't sends heartbeats. The appears to be hard coded now that might not be that brilliant.

EDIT:
Note that the new binaries again require dedicated = 2 to send heartbeats. The -1 does not (I might have said they did but they don't)


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Cacatoes on January 07, 2009, 12:47:39 pm
I use +set_dedicated 2, so that should be fine ...

Log when starting server :
Code:
ioq3+oa 1.35 linux-i386 Jan  6 2009
----- FS_Startup -----
Current search path:
/home/oa/.openarena/baseoa/z_q3dm6ishv3.pk3 (8 files)
/home/oa/.openarena/baseoa/z_q3dm6ish-ctf.pk3 (9 files)
/home/oa/.openarena/baseoa/z_hydronex2.pk3 (23 files)
/home/oa/.openarena/baseoa/z_blitzkrieg2.pk3 (8 files)
/home/oa/.openarena/baseoa/z_am_mckinleyish.pk3 (12 files)
/home/oa/.openarena/baseoa/z_am_lavactfxl.pk3 (8 files)
/home/oa/.openarena/baseoa/z_am_lavactf.pk3 (8 files)
/home/oa/.openarena/baseoa/z_am_lavaarena.pk3 (12 files)
/home/oa/.openarena/baseoa/z_am_galmevish2.pk3 (20 files)
/home/oa/.openarena/baseoa/schism-b2.pk3 (54 files)
/home/oa/.openarena/baseoa/ps9ctf.pk3 (11 files)
/home/oa/.openarena/baseoa/ps5ctf.pk3 (11 files)
/home/oa/.openarena/baseoa/oa_lun3dm2_b1.pk3 (89 files)
/home/oa/.openarena/baseoa/oa_koth2_b3.pk3 (48 files)
/home/oa/.openarena/baseoa/oa_ctf4ishum1.pk3 (4 files)
/home/oa/.openarena/baseoa/oasago2f9.pk3 (11 files)
/home/oa/.openarena/baseoa/oasago2f8.pk3 (10 files)
/home/oa/.openarena/baseoa/hydronex2.pk3 (12 files)
/home/oa/.openarena/baseoa/cubecubecube.pk3 (11 files)
/home/oa/.openarena/baseoa
/opt/openarena/baseoa/pak6-misc.pk3 (229 files)
/opt/openarena/baseoa/pak5-TA.pk3 (139 files)
/opt/openarena/baseoa/pak4-textures.pk3 (1753 files)
/opt/openarena/baseoa/pak2-players.pk3 (669 files)
/opt/openarena/baseoa/pak2-players-mature.pk3 (231 files)
/opt/openarena/baseoa/pak1-maps.pk3 (100 files)
/opt/openarena/baseoa/pak0.pk3 (1042 files)
/opt/openarena/baseoa

----------------------
4532 files in pk3 files
execing default.cfg
execing q3config_server.cfg
couldn't exec autoexec.cfg
Hunk_Clear: reset the hunk ok
--- Common Initialization Complete ---
IP: 127.0.0.1
IP: 192.168.0.1
IP6: ::1
IP6: fe80::240:f4ff:fe63:f2ba%eth0
Opening IP socket: 0.0.0.0:27960
WARNING: NET_IPSocket: bind: Address already in use
Opening IP socket: 0.0.0.0:27961
execing server2.cfg
net_ip will be changed upon restarting.
execing maprotation2.cfg
g_gametype will be changed upon restarting.
g_gametype will be changed upon restarting.
------ Server Initialization ------
Server: oasago2f9
Hunk_Clear: reset the hunk ok
----- FS_Startup -----
Current search path:
/home/oa/.openarena/baseoa/z_q3dm6ishv3.pk3 (8 files)
/home/oa/.openarena/baseoa/z_q3dm6ish-ctf.pk3 (9 files)
/home/oa/.openarena/baseoa/z_hydronex2.pk3 (23 files)
/home/oa/.openarena/baseoa/z_blitzkrieg2.pk3 (8 files)
/home/oa/.openarena/baseoa/z_am_mckinleyish.pk3 (12 files)
/home/oa/.openarena/baseoa/z_am_lavactfxl.pk3 (8 files)
/home/oa/.openarena/baseoa/z_am_lavactf.pk3 (8 files)
/home/oa/.openarena/baseoa/z_am_lavaarena.pk3 (12 files)
/home/oa/.openarena/baseoa/z_am_galmevish2.pk3 (20 files)
/home/oa/.openarena/baseoa/schism-b2.pk3 (54 files)
/home/oa/.openarena/baseoa/ps9ctf.pk3 (11 files)
/home/oa/.openarena/baseoa/ps5ctf.pk3 (11 files)
/home/oa/.openarena/baseoa/oa_lun3dm2_b1.pk3 (89 files)
/home/oa/.openarena/baseoa/oa_koth2_b3.pk3 (48 files)
/home/oa/.openarena/baseoa/oa_ctf4ishum1.pk3 (4 files)
/home/oa/.openarena/baseoa/oasago2f9.pk3 (11 files)
/home/oa/.openarena/baseoa/oasago2f8.pk3 (10 files)
/home/oa/.openarena/baseoa/hydronex2.pk3 (12 files)
/home/oa/.openarena/baseoa/cubecubecube.pk3 (11 files)
/home/oa/.openarena/baseoa
/opt/openarena/baseoa/pak6-misc.pk3 (229 files)
/opt/openarena/baseoa/pak5-TA.pk3 (139 files)
/opt/openarena/baseoa/pak4-textures.pk3 (1753 files)
/opt/openarena/baseoa/pak2-players.pk3 (669 files)
/opt/openarena/baseoa/pak2-players-mature.pk3 (231 files)
/opt/openarena/baseoa/pak1-maps.pk3 (100 files)
/opt/openarena/baseoa/pak0.pk3 (1042 files)
/opt/openarena/baseoa
 
----------------------
9064 files in pk3 files
Loading vm file vm/qagame.qvm...
...which has vmMagic VM_MAGIC_VER2
Loading 1207 jump table targets
VM file qagame compiled to 1429722 bytes of code
qagame loaded in 2839104 bytes on the hunk
------- Game Initialization -------
gamename: baseoa
gamedate: Oct 20 2008
------------------------------------------------------------
InitGame: \sv_dlURL\http://download.tuxfamily.org/openarena/autodownload\sv_floodProtect\0\sv_maxPing\0\sv_minPing\0\sv_maxRate\25000\sv_minRate\0\sv_hostname\^^66ROFL^^77 CHATROOM\dmflags\0\fraglimit\50\timelimit\20\g_gametype\4\sv_privateClients\2\sv_maxclients\12\sv_allowDownload\1\g_maxGameClients\0\capturelimit\8\g_delagHitscan\1\elimination_roundtime\120\elimination_ctf_oneway\0\g_needpass\0\version\ioq3+oa 1.35 linux-i386 Jan  6 2009\protocol\71\mapname\oasago2f9\gamename\baseoa\g_obeliskRespawnDelay\10\g_rockets\0\g_instantgib\0\g_humanplayers\0
Gametype changed, clearing session data.
0 teams with 0 entities
18 items registered
-----------------------------------
------- BotLib Initialization -------
loaded weapons.c
loaded items.c
loaded syn.c
loaded rnd.c
loaded match.c
------------ Map Loading ------------
trying to load maps/oasago2f9.aas
loaded maps/oasago2f9.aas
found 80 level items
-------------------------------------
24 bots parsed
56 arenas parsed
AAS initialized.
-----------------------------------
Hitch warning: 745 msec frame time
Resolving dpmaster.deathmask.net
dpmaster.deathmask.net resolved to 64.22.107.125:27950
Sending heartbeat to dpmaster.deathmask.net
]

Next try :

Code:
...
Hitch warning: 839 msec frame time
Resolving dpmaster.deathmask.net
dpmaster.deathmask.net resolved to 64.22.107.125:27950
Sending heartbeat to dpmaster.deathmask.net
Hitch warning: 1005 msec frame time

Still nothing.

Tried with +set_dedicated -1 :

Code:
...
-----------------------------------
Hitch warning: 640 msec frame time
Hitch warning: 736 msec frame time
]


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: sago007 on January 25, 2009, 06:19:10 pm
2009-01-26
New binaries. Apart from the openAL thing only ioquake3 changes.

gamename problem fixed
appears on master server (I have tested, don't know why the previous one didn't)
openAL is now dynamically bound again


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Cacatoes on January 29, 2009, 08:47:53 am
Really minor issue, but when using keyboard to scroll between menu options, they don't go in the right order.

Edit: Oops, wanted to post on this topic http://openarena.ws/board/index.php?topic=1908.0 instead.

But for this one, I at least can say server binaries do work ;)


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: sago007 on February 04, 2009, 04:17:22 pm
Just updated the binaries to 0.8.x-4

g_password and g_humanplayers was not sent correctly causing filtering based on those to fail.


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Neon_Knight on February 09, 2009, 10:51:51 am
Another report, from Freesoft, serveradmin, this seems to happen on 0.8.0 too, but not before. I don't know if this happens with other servers too, plus I don't know if this is the place to post it:

- With the commandline ./oa_ded.i386 +set dedicated 2 +set net_port 27960 +exec server.cfg, server loads until it gets "frozen" on half of the loading. Then he has to press Enter to get it working. I've attached two screenshots from the console in Ubuntu 8.10, one on the "frozen" state and the other is after it. Server specs are the following:

Processor: AMD DUAL CORE 5200+ X2
RAM: 2Gb DDR 800Mhz
HD: SerialATA 80 Gb
SO: Ubuntu 8.10 Ibex

- In the same server, it only loads without doing nothing with the same commandline if the default config is on, if server.cfg isn't on /.openarena/baseoa.

Those are tested with the new binaries too.


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: sago007 on March 14, 2009, 08:19:56 pm
@Neon_Knight Without the config causing the problem it can be hard to debug.

Oh and I have just uploaded some new binaries. Congratulations to the people behind non-PAT NAT routers that could not play on the same server - the problem was fixed in ioquake3 svn 1506.


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: christooss on March 25, 2009, 06:06:52 am
NeonKnight I got same problem. I solved it with removing WAIT in server conf file. Its after the maplist loop.


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: sago007 on May 05, 2009, 04:18:25 pm
Jsut upped a new version. Latest ioquake3 svn and increased the max config size.

EDIT:
The Windows version appears to run a bit worse for me. Reasons unknown.


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Falkland on June 24, 2009, 09:02:52 am
I am using a little tweaked engine based on the ioquake3 rev 1574 that includes oa-08x-7 changes plus some other patches :

https://bugzilla.icculus.org/show_bug.cgi?id=3693 -> QL's mouse accel code : Small enhancement that offers a better tweak for the mouse accel (offset and accelpower) without breaking the regular accel. edit : STATUS -> RESOLVED FIXED . The patch was merged into the ioquake3 trunk ( http://svn.icculus.org/quake3?view=rev&revision=1725 )

Quote
This patch comes with an alternate set of cvars to configure and tweak mouse acceleration. Nothing fundamentally new but it's a bit easier to setup mouse acceleration, and it's an option offered in QUAKE LIVE which I'm contributing to the GPL'ed quake3 source already.

Below is a bit of documentation I posted about the system.

TTimo

--

I've been using an experimental mouse acceleration code for a while, and decided to make it available to everyone.

Don't be too worried if you don't understand the explanations below, this is mostly intended for advanced players:

To enable it, set cl_mouseAccelStyle 1 (0 is the default/legacy behavior)

New style is controlled with 3 cvars:
sensitivity
cl_mouseAccelOffset
cl_mouseAccel

The old code (cl_mouseAccelStyle 0) can be difficult to calibrate because if you have a base sensitivity setup, as soon as you set a non zero acceleration your base sensitivity at low speeds will change as well. The other problem with style 0 is that you are stuck on a square (power of two) acceleration curve.

The new code tries to solve both problems:

Once you setup your sensitivity to feel comfortable and accurate enough for low mouse deltas with no acceleration (cl_mouseAccel 0), you can start increasing cl_mouseAccel and tweaking cl_mouseAccelOffset to get the amplification you want for high deltas with little effect on low mouse deltas.

cl_mouseAccel is a power value. Should be >= 1, 2 will be the same power curve as style 0. The higher the value, the faster the amplification grows with the mouse delta.

cl_mouseAccelOffset sets how much base mouse delta will be doubled by acceleration. The closer to zero you bring it, the more acceleration will happen at low speeds. This is also very useful if you are changing to a new mouse with higher dpi, if you go from 500 to 1000 dpi, you can divide your cl_mouseAccelOffset by two to keep the same overall 'feel' (you will likely gain in precision when you do that, but that is not related to mouse acceleration).


Mouse acceleration is tricky to configure, and when you do you'll have to re-learn your aiming. But you will find that it's very much forth it in the long run.


https://bugzilla.icculus.org/show_bug.cgi?id=3780 -> Upgrade unzip.c from version 0.01 alpha to 1.01e (as it is , it needs to be adapted to the latest ioq3 revision ; " ZDIR=$(MOUNT_DIR)/zlib " needs to be inserted in the Makefile ; it could be a security fix , since ioq3 could be vulnerable to ALL bugs of unzip < 1.01e) Edit -> STATUS : RESOLVED FIXED : the patch was merged in ioquake3 svn trunk

https://bugzilla.icculus.org/show_bug.cgi?id=3928 -> Use system cpp instead of q3cpp ( edit : maybe not useful for building the engine ... edit2 : confirmed , I used it for building oax ) Status : RESOLVED WONTFIX

https://bugzilla.icculus.org/show_bug.cgi?id=4012 -> Remove islower, isupper, and isalpha functions EDIT -> STATUS : RESOLVED WONTFIX

https://bugzilla.icculus.org/show_bug.cgi?id=4075 -> Use native OpenSSL MD4 & MD5. Edit -> STATUS : RESOLVED WONTFIX. The patch was rejected because of licence issue as stated by Sago . Anyway I'm still using it until a better implementation will be provided

https://bugzilla.icculus.org/show_bug.cgi?id=3776 -> OpenAL system reports errors inappropriately Edit : STATUS : RESOLVED FIXED . The patch was merged.

http://www.tremfusion.net/~amanieu/alcapture.patch -> OpenAL capture implementation by a Tremfusion developer

http://q3defrag.org/files/dfengine/src/dfengine_1.07.diff -> Rewriting of the Huffman algorithm ( it needs to be exctracted from the global patch and adapted to the latest ioquake3 revision )

https://bugzilla.icculus.org/show_bug.cgi?id=3637 -> QVMs are allowed to dereference NULL ( it needs to be adapted to the latest ioquake3 revision ) Edit : STATUS -> RESOLVED WONTFIX ...


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Falkland on June 24, 2009, 12:42:20 pm
Updated to ioquake3 revision 1578

Added the following patches to the previous list :

- https://bugzilla.icculus.org/show_bug.cgi?id=3325 -> Auto load of bots in skirmish fails if unknown bot name Edit : STATUS -> RESOLVED FIXED

- https://bugzilla.icculus.org/show_bug.cgi?id=3721 -> GL cleanup patch ( it needs to be tweaked for correctly applying to the latest ioquake3 ) EDIT : skipped .... see http://openarena.ws/board/index.php?topic=1933.msg26531#msg26531

- http://odin.mercenariesguild.net/quake3/smp_r1515.patch -> !IMPORTANT : fully and working SMP support to ioquake3 back again directly in a single binary client , without having to build the SMP binary ( http://www.ioquake.org/forums/viewtopic.php?f=2&t=125#p861 )

- https://bugzilla.icculus.org/show_bug.cgi?id=3323 -> math routine performance tweaks ( 2 patches : to be tweaked to correctly applying to ioquake3 ) EDIT : I've tweaked one of them a bit more . EDIT2 -> STATUS : RESOLVED WONTFIX

- https://www.tremfusion.net/hg/tremfusion/rev/72e11d3997f4 -> Check page size for NULL catching Edit : STATUS -> RESOLVED WONTFIX.


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: sago007 on July 02, 2009, 06:36:00 pm
- https://bugzilla.icculus.org/show_bug.cgi?id=3325 -> Auto load of bots in skirmish fails if unknown bot name
That is not an engine patch. A version of this is already in baseoa.


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Falkland on July 03, 2009, 08:51:15 am
- https://bugzilla.icculus.org/show_bug.cgi?id=3325 -> Auto load of bots in skirmish fails if unknown bot name
That is not an engine patch. A version of this is already in baseoa.

Eheh ... my mistake ... sry ( I use those patches for both ioquake3 and OA ) :)

Anyway , since the engine should not really need cgame , game and ui section why don't remove from the engine source tree ?


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: sago007 on July 03, 2009, 10:07:09 am
Anyway , since the engine should not really need cgame , game and ui section why don't remove from the engine source tree ?
I do not keep a source tree

I have cleaned the source of game, cgame, q3ui and ui before uploading the tar-ball but not for these test binaries. A few of the header files are still needed for the interface.


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Falkland on July 22, 2009, 11:18:00 am
This patch seems to solve some looped-sound issues for me : https://bugzilla.icculus.org/show_bug.cgi?id=4022 Edit : STATUS -> RESOLVED FIXED

I've applied also this : https://bugzilla.icculus.org/show_bug.cgi?id=3965 Edit : STATUS -> RESOLVED FIXED


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Falkland on July 24, 2009, 07:03:19 pm
- We don't have an authorization server for gamekeys management : just made a patch that remove auth support from the server engine


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Falkland on July 29, 2009, 10:56:43 am
https://bugzilla.icculus.org/show_bug.cgi?id=3767 -> Some protection from malicious qvms

Proposed patch on ioquake3 bugzilla -> http://bugzilla-attachments.icculus.org/attachment.cgi?id=1857


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Falkland on July 29, 2009, 04:14:27 pm

- https://bugzilla.icculus.org/show_bug.cgi?id=3721 -> GL cleanup patch ( it needs to be tweaked for correctly applying to the latest ioquake3 )


This patch seems not to give any significant improvement and it seems also to produce some renderer issue , so I'd skip this patch unless it will be applied at ioq3 or the author will provide a new one and will explain exactly what it does.


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: sago007 on August 11, 2009, 10:01:38 am
I'm sorry that I don't reply much but I am quite busy at the moment and will continue to be until the 7th of September.

Some spread thoughts:

openssl - Believed to be GPL incompatible meaning we or any distro cannot distribute the binaries. End uses can apply the patch if they want but a patch that binds to libgcrypt might be an idea. Not that I would distribute a Linux binary with gcrypt as an extra requirement but distros could.

"patch that remove auth support from the server engine" - defining BUILD_STANDALONE will be faster and it no longer has the problem from 0.7.6


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Falkland on August 11, 2009, 10:11:55 am
"patch that remove auth support from the server engine" - defining BUILD_STANDALONE will be faster and it no longer has the problem from 0.7.6

Agree here : after seeing that the authorization sections are delimited by the STANDALONE macro , I've successfully tested the BUILD_STANDALONE for building an UrT engine updated to the latest ioq3 rev : the code is smaller and it works without any problem.


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Falkland on August 20, 2009, 10:11:38 am
Two weeks ago or so there was a commit on the linux kernel git tree that added the compiler switch -fno-delete-null-pointer-checks to the Makefile CFLAGS :

Quote
Add '-fno-delete-null-pointer-checks' to gcc CFLAGS

Turning on this flag could prevent the compiler from optimising away
some "useless" checks for null pointers.  Such bugs can sometimes become
exploitable at compile time because of the -O2 optimisation.

See http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html

An example that clearly shows this 'problem' is commit 6bf67672.

 static void __devexit agnx_pci_remove(struct pci_dev *pdev)
 {
     struct ieee80211_hw *dev = pci_get_drvdata(pdev);
-    struct agnx_priv *priv = dev->priv;
+    struct agnx_priv *priv;
     AGNX_TRACE;

     if (!dev)
         return;
+    priv = dev->priv;

By reverting this patch, and compile it with and without
-fno-delete-null-pointer-checks flag, we can see that the check for dev
is compiled away.

    call    printk  #
-   testq   %r12, %r12  # dev
-   je  .L94    #,
    movq    %r12, %rdi  # dev,

Clearly the 'fix' is to stop using dev before it is tested, but building
with -fno-delete-null-pointer-checks flag at least makes it harder to
abuse.

Code:
--- a/Makefile
+++ b/Makefile
@@ -343,7 +343,8 @@ KBUILD_CPPFLAGS := -D__KERNEL__
 KBUILD_CFLAGS   := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
                   -fno-strict-aliasing -fno-common \
                   -Werror-implicit-function-declaration \
-                  -Wno-format-security
+                  -Wno-format-security \
+                  -fno-delete-null-pointer-checks
 KBUILD_AFLAGS   := -D__ASSEMBLY__
 
 # Read KERNELRELEASE from include/config/kernel.release (if it exists)

As I understand certain versions ( or all versions ) of gcc skip some checks of NULL pointers because of the -O2 . I don't know if it's so also with -O3 , but since -O3 = -O2 plus other optimization flags , I guess it's the same .

Maybe it can be useful adding this compiler switch also the the OPTIMIZE string in the engine Makefile : it does not add any overhead and/or it's not producing not standard code or any other kind of specific optimization.

It only forbids the compiler to skip some kind of NULL pointer checks. I know that the engine code is not big enough to have this kind of problems just everyday , but adding that switch doesn't have any cost.


Title: Re: Binaries for 0.8.x (0.8.1+) test thread
Post by: Falkland on October 26, 2009, 05:28:21 pm
Other useful compiler/linker switch that do not optimize but could increase security ( at least on linux platform ) :

 -fstack-protector
 -fstack-protector-all
 -pie (-fPIE)
 -D_FORTIFY_SOURCE=2
 -Wl,-z,relro
 -Wl,-z,now

-fstack-protector-all is working only on Ubuntu 8.04.3 for me but not on debian SID ( it causes both client and server to crash with a sig fault ) but it could be a problem related to my machine so it could need to be tested over other machines.

-pie -fPIE ( Position Independent Execution ) is currently not supported by ioquake3 and as a consequence by oa engine code.

I am currently using all the switches with the exception of  -pie (-fPIE) to compile my client and with the exception of -pie (-fPIE) and -fstack-protector-all to compile the server engine running locally on my SID box.

For a short explanation :

- http://wiki.debian.org/Hardening
- https://wiki.ubuntu.com/Security/Features

Edit : in case someone has missed the point ... the multiplatform hack coded originally for Urban Terror does not work in its original version on Fedora because Fedora is all compiled by default using at least -D_FORTIFY_SOURCE=2 -fstack-protector in the CFLAGS and the source code of the hack needs some modifications ( not so easy ) to produce a working binary.

 -Wl,-z,relro -Wl,-z,now are linker flags and their use could help making the engine pointers' interception at least a bit more diifficult ... their use is explained here : https://wiki.ubuntu.com/Security/Features#RELRO

If we could have Position Independent Execution support over the engine , I think that READY_TO_USE hacks on linux platform could become completely dumb.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: sago007 on October 28, 2009, 08:30:23 am
In lack of time I have just updated to newer ioquake3 and added an environment variable.

I cannot tell everything that has changed but there are some security fixes too.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: Falkland on October 28, 2009, 01:01:47 pm
In lack of time I have just updated to newer ioquake3 and added an environment variable.

I cannot tell everything that has changed but there are some security fixes too.

CD Key check and pak0 check don't need to be removed if BUILD_STANDALONE=1 is defined in the Makefile.local ... I'm testing it over OA , UrT and SG and it works fine.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: sago007 on October 28, 2009, 03:19:11 pm
CD Key check and pak0 check don't need to be removed if BUILD_STANDALONE=1 is defined in the Makefile.local ... I'm testing it over OA , UrT and SG and it works fine.
BUILD_STANDALONE=1 broke some custom things and I don't have the time to find out what (I know it has something to do with the CD key check but last time I made a list minute change it caused all servers to deny joining players).


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: Falkland on October 28, 2009, 03:48:22 pm
BUILD_STANDALONE=1 broke some custom things and I don't have the time to find out what (I know it has something to do with the CD key check but last time I made a list minute change it caused all servers to deny joining players).

IDK what the problem was exactly about , but I guess they fixed the thing : I've removed the part of your patch that comments the CDkey check control and the pak0 check control and built the engine ( the last one is based on ioq3 rev1713 ) with BUILD_STANDALONE=1 and it's still working well without any problem ... also with UrT and SG. And with BUILD_STANDALONE=0 the engine worked perfect with UrT by passing +set com_standalone 1 +set fs_game "q3ut4" +set fs_gamepath "$HOME/.q3ut4" at commandline.

BTW , I've tested this patch proposed on ioq3 bugzilla http://bugzilla.icculus.org/show_bug.cgi?id=4322 ; apparently ( but maybe no ) it saves many CPU cycles and gives much more stable fps for me.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: sago007 on October 29, 2009, 08:37:16 am
BTW , I've tested this patch proposed on ioq3 bugzilla http://bugzilla.icculus.org/show_bug.cgi?id=4322 ; apparently ( but maybe no ) it saves many CPU cycles and gives much more stable fps for me.
Seems right to me but I don't want to apply such patches myself... the original code might be to fix an error in some driver and I have no way of testing that.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: Neon_Knight on October 29, 2009, 05:42:54 pm
oa_ded.exe has the Q3 icon... :S


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: Falkland on November 02, 2009, 03:34:41 pm
gcc >= 4.3.x adds also the flag -ftree-vectorize on the optimization level 3 ( -O3 ) : the compiler will try to produce SIMD compliant ( SSE/SSE2) code and the final binary could/will not run on a machine not SSE/SSE2 compliant ( < Pentium 3 ).

-fno-tree-vectorize has to be explicitely added to the OPTIMIZE string to eventually revert this behaviour, even if I don't think there's still someone running the game over a P2 machine.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: sago007 on November 05, 2009, 04:47:05 pm
Updated again... new icons... and a few small backports (including a different win32 ipv6 mcast address).


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: Falkland on November 07, 2009, 11:55:51 am
BTW , I've tested this patch proposed on ioq3 bugzilla http://bugzilla.icculus.org/show_bug.cgi?id=4322 ; apparently ( but maybe no ) it saves many CPU cycles and gives much more stable fps for me.

The status of this BUG has changed to RESOLVED WONTFIX : I've played Q3 , OA and UrT with a patched engine for each game ... the patch causes an enough serious rendering problem _only_ on q3dm14 (at least on my system, but anyway the all thing just adjusts itself in a few seconds of playing ) and not always ... but as a I stated , it significantly saves CPU cycles with the main obvious benefit of less CPU overheating (at least on my system) and as a consequence with less fps dropping ... I hope that ioq3 devs will improve this patch and/or will produce other patches to use much more GPU than CPU.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: sago007 on November 07, 2009, 12:04:10 pm
I hope that ioq3 devs will improve this patch and/or will produce other patches to use much more GPU than CPU.
I hope so too. The idea looks good.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: sago007 on November 27, 2009, 11:59:46 am
It is almost two weeks since the last functionality enhancement and that is the longest break in new functionality for some time.

Unfortunately I quickly discovered that the new CVAR system deleted the single player progress for no reason at all. After some error investigation I found that g_spScoresX was not read from q3config.cfg because it has both the flag CVAR_ARCHIVE and CVAR_ROM set and the new CVAR system will reset all CVAR_ROM values even if they are supposed to be archived. This bug affects baseq3 too and I have reported it upstream. My workaround is simply to not ignore the value from q3config if it is an archive cvar.

EDIT:
There might be more problems with the new CVAR system, some old fixes has been mover or removed and they might have had a purpose. I have tested for the most obvious problems and have not discovered another bug in baseoa but other mods might have problems.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: Falkland on November 27, 2009, 01:15:58 pm
I think this was caused by the fix they've applied to solve also the config pollution between the baseq3->mods/mods-baseq3 switch :
-  http://bugzilla.icculus.org/show_bug.cgi?id=2819
-  http://icculus.org/pipermail/quake3-bugzilla/2009-November/001350.html


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: andrewj on November 29, 2009, 02:19:28 am
I am testing the latest source (openarena-engine-source-0.8.x-10.tar.bz2) but I get the problem where the main menu doesn't show up, just a blank screen.  Thankfully I can exit via the console (which is not drawn either).

It seems the UI VM is calling trap_GetCDKey(), but the code for that in client/cl_ui.c is disabled and hence it causes a 'bad UI system trap' error, which in turn causes the UI VM to be unloaded and I guess it gets reloaded and the cycle repeats.

The following patch works for me, but I think the proper fix would be to prevent the UI VM code from using the CDKEY functions (remove all the CD key stuff).
Code:
Index: client/cl_ui.c
===================================================================
--- client/cl_ui.c      (revision 1753)
+++ client/cl_ui.c      (working copy)
@@ -963,15 +964,17 @@
        case UI_MEMORY_REMAINING:
                return Hunk_MemoryRemaining();
 
+       case UI_GET_CDKEY:
 #ifndef STANDALONE
-       case UI_GET_CDKEY:
                CLUI_GetCDKey( VMA(1), args[2] );
+#endif
                return 0;
 
        case UI_SET_CDKEY:
+#ifndef STANDALONE
                CLUI_SetCDKey( VMA(1) );
+#endif
                return 0;
-#endif
       
        case UI_SET_PBCLSTATUS:
                return 0;       


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: sago007 on November 29, 2009, 08:21:16 am
I don't know how that patch works. The engine is not build with the standalone flag for the same reason.

Preventing the UI from touching the trap function will not work. Because players might use mods where it is not an option.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: andrewj on November 30, 2009, 12:45:26 am
Oh, sorry I thought BUILD_STANDALONE=1 was required in the makefile to build the OA binaries.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: sago007 on December 12, 2009, 10:36:29 am
Updated binaries. Just compile parameter from ioquake3 and console patch from Falkland's other thread.

The console height cvar has been moved around in the code to fit better and has been renamed to cl_consoleHeight to match the naming convention for all other console cvars.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: Neon_Knight on December 12, 2009, 11:08:14 am
What about creating a GoogleCode page for these binaries, just like with OAX?


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: iSubaru on December 12, 2009, 12:00:28 pm
Oh finally some steps to new version to make brutal testing :D
I'm on it gimme just a few seconds to check boards and I will do some scouting in it
I can't wait to see what's new by my own eyes :)

EDIT #1
Oh my O_O
This is so great! looked through menu for now and everything looks good, too bad it's not official release yet but with this things done I feel it's matter of "few" days :)
I think I saw new possition in weapons ;] I can't wait to test it out muhahaha <cough> I mean <giggle> :P

EDIT #2
There is a bug :P
When I have started LAN game I couldn't move (Connection interrupted) until someone from enemies made hit on me, even 2 restarts of arena didn't helped
also dunno what about target cursor, I have set it colours but it changes only depending on HP
bots AI is rewritten or something because on Bring it on they are better :D
new maps yay!
that's all for now


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: Falkland on December 12, 2009, 06:38:12 pm
2 bugs in the latest engine binaries/sources :

- a minor bug about the window icon which is the old one ( oa081 )

- an enough serious bug but strictly connected to an eventual final user action , anyway : the new mouseaccel function imported in ioquake3 and previously coded and introduced in QL is in general better than old one because it's more tunable .

It introduces 2 new cvars ( quote from the updated ioquake3 README )

Quote
 cl_mouseAccelStyle                - Set to 1 for QuakeLive mouse acceleration behaviour, 0 for standard q3
  cl_mouseAccelOffset               - Tuning the acceleration curve, see below
...

QuakeLive mouse acceleration (patch and this text written by TTimo from id)
  I've been using an experimental mouse acceleration code for a while, and
  decided to make it available to everyone. Don't be too worried if you don't
  understand the explanations below, this is mostly intended for advanced
  players:
  To enable it, set cl_mouseAccelStyle 1 (0 is the default/legacy behavior)

  New style is controlled with 3 cvars:

  sensitivity
  cl_mouseAccel
  cl_mouseAccelOffset

  The old code (cl_mouseAccelStyle 0) can be difficult to calibrate because if
  you have a base sensitivity setup, as soon as you set a non zero acceleration
  your base sensitivity at low speeds will change as well. The other problem
  with style 0 is that you are stuck on a square (power of two) acceleration
  curve.

  The new code tries to solve both problems:

  Once you setup your sensitivity to feel comfortable and accurate enough for
  low mouse deltas with no acceleration (cl_mouseAccel 0), you can start
  increasing cl_mouseAccel and tweaking cl_mouseAccelOffset to get the
  amplification you want for high deltas with little effect on low mouse deltas.

  cl_mouseAccel is a power value. Should be >= 1, 2 will be the same power curve
  as style 0. The higher the value, the faster the amplification grows with the
  mouse delta.

  cl_mouseAccelOffset sets how much base mouse delta will be doubled by
  acceleration. The closer to zero you bring it, the more acceleration will
  happen at low speeds. This is also very useful if you are changing to a new
  mouse with higher dpi, if you go from 500 to 1000 dpi, you can divide your
  cl_mouseAccelOffset by two to keep the same overall 'feel' (you will likely
  gain in precision when you do that, but that is not related to mouse
  acceleration).

  Mouse acceleration is tricky to configure, and when you do you'll have to
  re-learn your aiming. But you will find that it's very much forth it in the
  long run.

  If you try the new acceleration code and start using it, I'd be very
  interested by your feedback.

There was a fix for this function in QL : if the final user should set cl_mouseAccelOffset to zero , there would be a division per zero in the code causing the loss of mouselook.

I guess some user has found it after creating an easy script/macro to decrease/increase the cvar in-game and noticed the loss of the mouselook after the cvar reached the zero value.

Here's the code :

Code:
...
/*
=================
CL_MouseMove
=================
*/

void CL_MouseMove(usercmd_t *cmd)
{
...

// sensitivity remains pretty much unchanged at low speeds
// cl_mouseAccel is a power value to how the acceleration is shaped
// cl_mouseAccelOffset is the rate for which the acceleration will have doubled the non accelerated amplification
// NOTE: decouple the config cvars for independent acceleration setup along X and Y?

rate[0] = fabs(mx) / (float) frame_msec;
rate[1] = fabs(my) / (float) frame_msec;
power[0] = powf(rate[0] / cl_mouseAccelOffset->value, cl_mouseAccel->value);                   <---------------
power[1] = powf(rate[1] / cl_mouseAccelOffset->value, cl_mouseAccel->value);                   <---------------

...


Anyway this is an ioquake3 bug so it should be reported there , but if they will not provide a fix we could code a workaround to not allow setting cl_mouseAccelOffset to zero.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: sago007 on January 02, 2010, 07:01:41 pm
Just two updates with in a couple of hours.

Updated to newer ioquake3 revision.
Ingame icon updated
The mouse acceleration thing Falkland mentioned
Some serverstatus changes


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: Falkland on January 03, 2010, 04:02:10 pm
Fix for the CVAR_ARCHIVE / CVAR_ROM issue : http://icculus.org/pipermail/quake3-commits/2010-January/001677.html

The comment in the code is enough explicative itself :

Quote
...
   // There is code in Cvar_Get to prevent CVAR_ROM cvars being changed by the
   // user. In other words CVAR_ARCHIVE and CVAR_ROM are mutually exclusive
   // flags. Unfortunately some historical game code (including single player
   // baseq3) sets both flags. We unset CVAR_ROM for such cvars.
...

EDIT : anyway this is more a VM fix rather than an engine fix ... sry for mistake.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: sago007 on January 10, 2010, 03:32:23 pm
EDIT : anyway this is more a VM fix rather than an engine fix ... sry for mistake.
Actually I believe it is an engine fix and therefore I have already fixed in the engine...

It is an obvious hack by id. There was never any correct solution. ioquake3 has a point that CVAR_ROM and CVAR_ARCHIVE is exclusive but the previous ioquake3 where CVAR_ROM was prioritized over CVAR_ARCHIVE was obviously wrong.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: Falkland on January 10, 2010, 04:09:14 pm
... and therefore I have already fixed in the engine...

Yes , I know ... I just reported about the ioquake3 fix.
 


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: sago007 on January 15, 2010, 10:15:07 am
Applied http://files.poulsander.com/~poul19/public_files/oa/dev081/OORefFlare.patch

Compared to the original OORefFlare I have reduced brightness to half because there are no menu entry to reduce it to a playable value otherwise.
The new flares are automatically used if r_flares is set to 1 (still off by default)

Some might want to test motionJPEG because the memory functions are changed slightly and I have no idea what they do.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: sago007 on April 24, 2010, 03:43:27 pm
Updated 2010-04-24

Note:
The removal of qagame.qvm from pure check has not been verified to work.
say and say_team allows ';', but the VM still demands that "" are used.


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on April 25, 2010, 03:10:25 am
After uploading the server binary to my own server I discovered the first problem with "-15". The 64 bit version is build on a newer version of glibc that is hardly supported anywhere yet. The windows and 32 bit versions should not have these problems as they are compiled in a dedicated environment.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: Falkland on April 28, 2010, 09:22:45 am
The removal of qagame.qvm from pure check has not been verified to work.

This change requires another mechanism to check at least that players don't use their own qagame.qvm.
Maybe a MD5 or SHA hash.


Title: Re: Binaries for 0.8.x (0.8.5) test thread
Post by: sago007 on April 28, 2010, 09:57:51 am
This change requires another mechanism to check at least that players don't use their own qagame.qvm.
Maybe a MD5 or SHA hash.

It SHOULD not matter because qagame is not used by the client. And even if it was the server would force the client to use the original qagame because it still cannot use a file the server does not have. Only the server skips the pk3-file.

I am not entirely sure why it is part of the check (the reason I write "SHOULD"). There are some suggestions in the code that it should never have been part of the check, because it is excluded from the qvm ccheck. But it is indirectly included in the part of the code that checks sums of the other files because it is not a txt, dat or such file.


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on July 05, 2010, 11:02:34 am
Updated yesterday (-16). I have stopped working on the qagame.qvm exception for the time being. It still believe it is a good idea but not worth the trouble right now.


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on August 22, 2010, 06:05:58 am
Updated to -17.

I have added a CVAR sv_dorestart that allows mods to tell the engine that a full restart is required. For example then g_instagib is changed in the middle of the game. This is based on the information from andrewj's message: http://openarena.ws/board/index.php?topic=3875.msg34394#msg34394


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on August 30, 2010, 03:03:27 pm
Update to -18

g_humanplayers are now set by the engine. This means that Q3-mods now show human players in the list.

I have not tested it. I applied this patch http://bugzilla.icculus.org/show_bug.cgi?id=4702#c2 by Zack "ZTurtleMan" Middleton.

Please spread the rumor to the people hosting mods that does not support g_humanplayers so we can test.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on August 31, 2010, 02:27:24 am
Update to -18

g_humanplayers are now set by the engine. This means that Q3-mods now show human players in the list.

I have not tested it. I applied this patch http://bugzilla.icculus.org/show_bug.cgi?id=4702#c2 by Zack "ZTurtleMan" Middleton.

Please spread the rumor to the people hosting mods that does not support g_humanplayers so we can test.

Sorry for my ignorance... what is g_humanplayers exactly? :-/


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on August 31, 2010, 04:32:49 am
Sorry for my ignorance... what is g_humanplayers exactly? :-/
Its the CVAR the ingame server list uses to see how many human players there is on a server.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on August 31, 2010, 05:23:30 am
So, when you set "only humans" option in the server browser on or off, the program reads g_humanplayers or another cvar (that olds the number of total players), right?

Is the new feature that, if the old mod does not contain the "only humans" option, it will read g_humanplayers instead of the cvar with the total number?

But this would seem a client-side feature, and you talked about server admins... ???

And if the "only humans" feature is supported (a mod for oa instead of for q3a), will it still be possible to select it on or off?


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on August 31, 2010, 09:17:16 am
Remember there are two sides to show how many humans that are playing:
1. The server must tell the client how many humans that are (previously done by baseoa by setting g_humanplayers, from -18 by the engine)
2. The client must read the value (done by baseoa)

It is (1.) that has been improved, so old mods now advertise the number of humans too. However only the baseoa server browser (or compatible) can show the value.

Currently servers running old mods will always say that there are 0 humans even if there are more.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on August 31, 2010, 10:38:50 am
Maybe now I understand:
1) An OA server rurring baseoa (or a modern mod designed for OA) sends two variables, one with the total players number, and one with the number of humans.
2) An OA server running a mod for Q3A (that did not have the "only humans" option) sends only a variable, the one with the total players number.
- Thus:
3) An OA client that is already using a Q3A mod, when browsing servers, always sees the total number (independently if the server runs the same mod or something else), because the client doesn't look for g_humanplayers, but only the other CVAR.
4) An OA client server browser, from baseoa (or a modern OA mod), selects wich of the two variables show, changing the "only humans" option. But if the server runs an old mod, it does not send g_humanplayers cvar, so, if "only humans" is enabled in the client, it will always see 0 players for that server (thus, hiding the server!).

Right?
I wonder if also the deathmask server browser is affected.

And the new improvement makes all the servers (even if using an old mod) send also the g_humanplayers cvar, so the baseoa client (point 4) will be able to list them correctly even if "only humans" is active. Point 3 remains unaffected.
Am I right?


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on September 02, 2010, 02:08:13 pm
Ok Sago, I did a rapid test.

I launched a dedicated server running the BFG10K Arena mod for Q3A.
Added a bot.
Launched an OpenArena client and connected to the server.
Checked on dpmaster (http://dpmaster.deathmask.net/?game=openarena) web page:
- With the oa_ded.exe provided with OA 0.8.5, it says Players 2/16 and g_humanplayers
0
.
- With the od_ded.x86.exe just downloaded (v. -18), it says Players 2/16 and g_humanplayers 1.

Thus, the fix seems to work! :-) Nice work, Sago!  :)

PS:
I had to do the try from dpmaster web page, because of I don't have a second PC to do the check from a second OpenArena client.
I only tried oa_ded.x86.exe, not the other executables...


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on March 07, 2011, 03:49:47 pm
New binary up today. It has been a while. Has some problems compiling the windows version but at last it compiled successful.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on March 08, 2011, 01:49:15 am
Good. I will try it to check out if it fixes the problem of the missing crosshair when enabling anaglyph 3d mode...


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on March 08, 2011, 01:58:42 am
Good. I will try it to check out if it fixes the problem of the missing crosshair when enabling anaglyph 3d mode...
This is not engine specific, the crosshair is drawn by gamecode.


Title: Re: Binaries for 0.8.x test thread
Post by: Cacatoes on March 08, 2011, 05:08:02 am
Any idea on how we can get the list of commit descriptions from a revision to another ? I'll search, I'd like to get an idea of a changelog.

Secondly, I've seen ioq3 has accepted a few patches, some by Simon McVittie, which help in making ioq3 and OA compatible. For instance, one allows to set protocol number on command line.
Wouldn't it be wise for OA to profit that flexibility, and is it already the case ?


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on March 08, 2011, 05:24:19 am
Good. I will try it to check out if it fixes the problem of the missing crosshair when enabling anaglyph 3d mode...
This is not engine specific, the crosshair is drawn by gamecode.
Then, could you please take a look to it?

PS: also some HUD info on the upper right corner are messed up.
http://images4.wikia.nocookie.net/__cb20100616171047/openarena/images/a/a3/R_anaglyphmode_1.jpg


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on March 08, 2011, 06:12:48 am
Still can't apply my renderer patch (http://openarena.ws/board/index.php?topic=1908.msg34971#msg34971)?


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on March 09, 2011, 11:50:40 am
Still can't apply my renderer patch (http://openarena.ws/board/index.php?topic=1908.msg34971#msg34971)?
No

I might go throw it in the weekend and apply it by hand if I can find the time.


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on March 13, 2011, 04:42:39 pm
I don't know if you replied this, but... what about opening a googlecode account for this? There's already one for OAX and one for OAStat. Do a googlecode account cost something?


Title: Re: Binaries for 0.8.x test thread
Post by: Cacatoes on March 13, 2011, 07:46:07 pm
Nah it's free, like most of the opensource forges.

Normally you wouldn't open several accounts for a single project's use. I think you can have like separate trees if you need to work on several parts of a project.


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on April 17, 2011, 10:32:06 am
Still can't apply my renderer patch (http://openarena.ws/board/index.php?topic=1908.msg34971#msg34971)?
Applied manually in 0.8.x-21


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on May 28, 2011, 07:28:08 pm
No more deprecated builds?

I mention that because currently thanks to ipv6, there's no way it can run on Win9x or Win2000 not even with Kernelex on 9x. Even worse, there's no error message explaining why, even in stderr.txt. Just fails right after the video init. Windows 2000 complains about a missing function in ws2_32.dll (windows sockets 2).


Darkplaces still works on Win9x as of the March 2011 builds (as well as it is still working on Voodoo2s). A technically superior engine working makes this situation look funny.


Currently i'm installing MinGW/Msys to build OA again.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on June 03, 2011, 01:06:25 am
OK a little more testing under win9x with the NON-deprecated build

- Kernelex must set the compatibilty mode to Windows 98SE to bypass the psapi.dll error
- You need an OLDER SDL.dll


Title: Re: Binaries for 0.8.x test thread
Post by: smcv on July 12, 2011, 09:59:44 am
Hey Sago,
Just to let you know: as a result of <https://bugzilla.icculus.org/show_bug.cgi?id=4962>, ioquake3 now supports two protocols simultaneously: protocol 68 from Q3 >= 1.32c (which OA currently re-labels as protocol 71, to avoid OA clients trying to join Q3 servers and vice versa), and Thilo's new protocol 69 (which fixes some DoS vulnerabilities).

I wouldn't necessarily recommend merging from ioquake3 right now in any case, because it seems Thilo might be making more changes in protocol 69, but presumably you'll want to catch up once the protocol has settled down. In future builds (after merging r2075 or later from ioquake3) you'll need to set PROTOCOL_LEGACY_VERSION to 71, define LEGACY_PROTOCOL in q_shared.h, and set PROTOCOL_VERSION to some new value (perhaps 10069 or something?).

The new protocol does include the client and server's idea of sv_heartbeat in the handshake, as an alternative way to tell you whether you're incompatible, so you might even be able to leave PROTOCOL_VERSION set to 69 and rely on comparing sv_heartbeat. I haven't tried that out yet.

In Debian I plan to continue to use a shared ioquake3 engine to run OA, and set com_legacyprotocol and com_protocol on the command line to match the values you use in your standalone builds. So, I'll avoid uploading a newer ioquake3 to Debian until you've confirmed what values you're going to use!


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on July 12, 2011, 12:07:29 pm
I have read a little about this new protocol and I have always been interrested in it. Especially for OpenArena a better protocol could be very useful. I would not like to include a protocol that is work-in-progress.

The protocol was actually not changed to prevent joining Q3 servers but because it was the only options known at that time that could separate incompatible versions (a big problem for 0.6 and 0.7(.1) servers) and allow them to coexist on the same master server.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on July 12, 2011, 01:39:05 pm
Merging the renderer bits shouldn't be a problem though. In my working copy the only real renderer changes between OA and IOQ3 right now is the preliminary IQM support and the new JPEG library (which I didn't apply since it breaks Windows compiling, for some reason)

I almost feel like I could maintain the renderer/ part of the code project myself and commit it to oax or so, and I wonder if there's a possible way for multiple renderers in one place too (i'm thinking renderer_dx9, renderer_soft, renderer_ogl2)


Title: Re: Binaries for 0.8.x test thread
Post by: smcv on July 16, 2011, 07:54:39 am
I would not like to include a protocol that is work-in-progress.

Sure, I just wanted to warn you that this change was on the way!

separate incompatible versions (a big problem for 0.6 and 0.7(.1) servers) and allow them to coexist on the same master server

The new protocol addresses this by comparing sv_heartbeat (aka HEARTBEAT_FOR_MASTER), as well as the numeric protocol ID. It seems OA currently uses QuakeArena-1 as its heartbeat string (before ioquake3 r1815 it wasn't made very obvious that changing it in standalone games was desirable), and changing it now would probably be a compatibility break, but next time you break content compatibility you could set sv_heartbeat to OpenArena-0.9 or something, and appear as a different game on the master server.


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on July 28, 2011, 08:09:36 am
It should be noted that if you are using a binary from this thread and especially if you are running a *nix variant that you should not use a binary from before 0.8.x-22 as they contain a severe vulnerability. See http://archives.neohapsis.com/archives/fulldisclosure/2011-07/0338.html for details.


Title: Re: Binaries for 0.8.x test thread
Post by: smcv on July 29, 2011, 08:32:51 am
The new protocol addresses this by comparing sv_heartbeat (aka HEARTBEAT_FOR_MASTER), as well as the numeric protocol ID. It seems OA currently uses QuakeArena-1 as its heartbeat string

Following discussion with the author of dpmaster on <https://bugzilla.icculus.org/show_bug.cgi?id=5099>, it seems OA was right all along - QuakeArena-1 is part of the heartbeat protocol and shouldn't change per standalone game. Recent versions discriminate based on com_gamename (formerly cl_gamename) instead, and use the DarkPlaces heartbeat protocol. I've been keeping up with ioquake3 bugs and trying to advocate as much backwards-compatibility as possible, so OA can stay compatible with 0.8.x without having to fork the engine.

Thilo apparently still wants to make some changes to the VoIP code, so it's still not a good time to rebase onto current ioquake3. I'll let you know when the situation changes...


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on July 31, 2011, 11:54:32 pm
Cleaned up my cgame fx changes. Unfortunately this is not a diff/patch file, but it applies to beta 48.

The UI change is just to add a new 3d element for the new missionpack menu


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on November 12, 2011, 12:14:02 pm
Hi guys! Some questions:
Will OpenArena 0.8.8 come with the at-the-moment-latest executables (version 22, of july 2011), or will you create a newer executables set? I don't know what new fixes/features ioquake3 added in these last months. But I can imagine, if there would be something "big", that it would need a good testing before the release! Maybe some of those changes risk to break compatibility? (http://openarena.ws/board/index.php?topic=4243.0)

In any case, remember to compile execuables for Windows, Linux (both 32 and 64 bits) and Mac for the release (someone told in 0.8.5 Mac executable was not updated).


Title: EMERGENCY
Post by: Gig on November 20, 2011, 06:05:58 am
Hi guys! I noticed that the current "new" executable, version 22, DOES NOT WORK WITH MODS (it gets stuck at loading the mod!). Tested under Windows XP (one of the mods I tested is DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/ModCompat/BFG10K_Arena]BFG10K Arena (http://([b)).

New executables are important (e.g. they added something to g_humanplayers, right?)... but this problem is too heavy to be acceptable!


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on November 20, 2011, 06:21:46 am
Tested Openfortress (dated 20081115)

Code:
59 arenas parsed
24 bots parsed
********************
ERROR: Bad UI system trap: 53
********************
forcefully unloading ui vm
RE_Shutdown( 0 )
Hunk_Clear: reset the hunk ok

Tested Q3 Catch the chicken (dated 20010202)

Code:
59 arenas parsed
24 bots parsed
********************
ERROR: Bad UI system trap: 53
********************
forcefully unloading ui vm
RE_Shutdown( 0 )
Hunk_Clear: reset the hunk ok


Something engine-side's doing this. 


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on November 20, 2011, 06:39:25 am
Testing back, I see that version 18 (http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-18.zip) works, while version 20 (http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-20.zip) and later no.
I haven't been able to find a download for version 19 (it's not listed here (http://files.poulsander.com/~poul19/public_files/oa/dev081/)), so I don't know if the problem appeared between 18 and 19 or between 19 and 20.
Guys, I suppose some "diffs" between 18 and 20 are needed... but I'm not able to do it.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on November 20, 2011, 07:40:49 am
cl_ui.c
Code:
#ifndef STANDALONE
case UI_GET_CDKEY:
CLUI_GetCDKey( VMA(1), args[2] );
return 0;

case UI_SET_CDKEY:
CLUI_SetCDKey( VMA(1) );
return 0;
#endif

to

Code:
#ifndef STANDABONE
case UI_GET_CDKEY:
return 0;

case UI_SET_CDKEY:
return 0;
#endif


makes mods work because of the CDKEY UI traps.




(http://openarena.ws/crap/q3ctc.jpg)
NOW GIVE ME ALL YOUR CAKES.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on November 20, 2011, 07:48:07 am
Cake given. :) Now waiting for version 23! :)


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on November 20, 2011, 07:59:02 am
I really had expected that to have been fixed by now. I originally stopped using the STANDALONE define because of this specific problem.

I have not yet released any binaries since 22 because I have huge compile trouble with all the renderer files I have found here.

I think I will push out an engine without the renderer changes so they can be applied there.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on November 20, 2011, 08:00:17 am
i'm guessing it has to do with the jpeg library switch? That was aggravating to deal with when I only wanted to simply test the IQM implementation.

Maybe a 22 + rendering changes could be pushed out at least before we get to 23. Is there a problem sticking to 22?


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on November 21, 2011, 12:14:00 am
Maybe a 22 + rendering changes could be pushed out at least before we get to 23. Is there a problem sticking to 22?
There would be no problems in that. Although I have not yet attempted to apply the renderer changes to that.
I have attempted to start from scratch and copy all files again. But these are without renderer changes:
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-23.tar.bz2
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-23.zip
The renderer is now in its own dll/so-file.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on November 21, 2011, 12:56:04 am
Does it contain the mod fix only, or also something new from ioquake3 in the last months, that needs to be tested?


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on November 21, 2011, 04:35:22 am
Does it contain the mod fix only, or also something new from ioquake3 in the last months, that needs to be tested?
New sound searching method.
qvm-based server side mods on pure servers.
alternative protocol.

-23 is build using a new script so old things like icons should be verified again.

I will post the script and extra files used to genereate it later.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on November 21, 2011, 01:12:27 pm
Which icons should I check?

PS: If you want to update the first post of the thread with the new link, it would be good. :)


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on November 21, 2011, 02:27:30 pm
Also networking does not work...


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on November 21, 2011, 02:37:31 pm
D'oh! I quickly started a version 23 dedicated server, and connected from a client on the same machine (and running version 23 executable, and also using the 0.8.5 executable for client), and it worked. I don't have a second machine to do the tests, now... so probably I can't help much with online tests...


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on November 21, 2011, 03:23:25 pm
Also networking does not work...
The default master server was not "dpmaster.deathmask.net". I did not notice until I tried with a clean config.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on November 23, 2011, 01:37:07 am
Apologies for being late with my 088 engine working folder


It's basically the -22 engine (I think it's 22) with glsl and my various rendering changes applied to it. This is what I used to compile and test.

http://openarena.ws/test/oa088-eng-22-leimod.zip



I should mention 23 has very strange sound bugs - I can hear sometimes clicking in some sound effects.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on November 24, 2011, 03:40:39 pm
Haven't tried sounds with 23 yet. To have a scenery loosely limilar to yours... do you have openal enabled or disabled?
UPDATE: I've just done a test playing a SP match with OpenAL enabled and one with OpenAL disabled, and I have not noticed strange things in sounds. I'm using windows xp.

----------------------------------------

Another thing: do you remember the bug that brightess controls stop working after you switch from fullscreen to windowed mode (tested under windows xp)? I've found a page on ioquake3 bugzilla:
https://bugzilla.icculus.org/show_bug.cgi?id=2785
Its status is "resolved invalid", and the last post there claims it is not a ioquake3 bug, but a SDL bug, linking this SDL bugzilla page:
http://bugzilla.libsdl.org/show_bug.cgi?id=971
its status is "resolved wontfix"... and it seems to talk about linux only...
At a first search, I don't find other similar bugs in SDL bugzilla http://bugzilla.libsdl.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=&content=brightness

Being much more technical than me, do you understand something more than me?

Is someone around here registered on SDL bugzilla, to submit the bug under Windows in an apposite page?


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on November 24, 2011, 05:30:53 pm
It's pretty funny how darkplaces-sdl has brightness control working, keys working, and better mouse input....

Someone should learn from that and fix up ioq3's crappy sdl code. Not surprising they'd rather blame than fix.


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on November 24, 2011, 05:45:11 pm
["Not a coder" disclaimer]

Hmmm... I'm guessing it's pretty hard to port that piece of code into the idTech3 engine, isn't it?


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on November 26, 2011, 03:12:55 am
Fromhell, are you still experiencing those audio problems? I haven't been able to reproduce the problem on my system.


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on November 26, 2011, 01:37:55 pm
Binaries based on -22 with leimod changes copied in. cg_autoswitch default value also changed from "1" to "2" like in -23
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-24.zip
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-24.tar.bz2


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on November 27, 2011, 06:35:16 pm
While compiling the most recent binaries (the ones from Sago's last post) I've got these errors:

Code:
LD build/release-linux-i386/openarena.i386
/usr/bin/ld: cannot find -lvorbisfile
/usr/bin/ld: cannot find -lvorbis
/usr/bin/ld: cannot find -logg
collect2: ld devolvió el estado de salida 1
make[2]: *** [build/release-linux-i386/openarena.i386] Error 1
make[2]: se sale del directorio «/home/luciano/Descargas/openarena-engine-source-0.8.x-24»
make[1]: *** [targets] Error 2
make[1]: se sale del directorio «/home/luciano/Descargas/openarena-engine-source-0.8.x-24»
make: *** [release] Error 2

Code:
LD build/release-linux-i386/openarena.i386
/usr/bin/ld: cannot find -lvorbisfile
/usr/bin/ld: cannot find -lvorbis
/usr/bin/ld: cannot find -logg
collect2: returns exit status 1
make[2]: *** [build/release-linux-i386/openarena.i386] Error 1
make[2]: goes out of dir «/home/luciano/Descargas/openarena-engine-source-0.8.x-24»
make[1]: *** [targets] Error 2
make[1]: goes out of dir «/home/luciano/Descargas/openarena-engine-source-0.8.x-24»
make: *** [release] Error 2

Am I missing some library for these ones?

EDIT: Turns out I was... the libvorbis-dev library. -.-


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on November 27, 2011, 06:47:08 pm
Gonna need one more engine compile to ensure some changes are working:

- Testing the flare junk, archiving lensReflection1, assuring r_flaresDlight works, assuring r_flares 1337 works (alternate fading), removing r_flaresSurfRadii (it never worked, it was supposed to make flares's initial sizes depend on the size of the surface it's spawned from, so big light brushes could have large flares)
- Reverting the DXT5 change in the texture loader since it makes bloom perform like crap
- The GLSL postprocess stuffs Hitchhiker just posted as changed files to this 24 engine build. I'm going to start with that first.
- I'm going to up the max vertices per shader to 2000 or so to get the stencil shadows working (cg_shadows 2) on OA's higher poly models.  Hopefully that regresses nothing. I've had it at an insane value before in 2007, testing self-shadowing on a subsurf'd angelyss


I'll post changed files when i'm finished.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on November 28, 2011, 03:05:05 am
The zip in this post (http://openarena.ws/board/index.php?topic=4314.msg41473#msg41473) + the zip down below = changed files.

Changes:
- Fixed bloom bleed
- Took out DXT5 since it slowed bloom down
- bloom sanity checking if r_texturebits isn't 32
- r_lensReflections1 is archivable, so is 2
- r_flaresurfradii is gone
- enabled #RAVENMDR
- I didn't up the max vertexes since that actually had memory errors. so i left it alone


Title: MAC Binaries?
Post by: Gig on November 29, 2011, 08:08:25 am
Hi guys!
I don't have a MAC, so I can't do any kind of test about it... that being stated...

In the executables zip I find 6 files. Two of them (client and dedicated server) are Windows32, two of them are Linux32 and two of them are Linux64, right?
What about Mac users? It has been reported that DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Bugs#General]0.8.5 release used 0.8.1 Mac executables (http://([b) (not a major problem, of course... but anyway...). Possibly, this time it would be good to update them (I suppose between 0.8.1 and 0.8.8, executables may have gained nice features).

I don't know who compiled the game for Mac at the time of 0.8.1 (files in OpenArena.app\Contents\MacOS folder report "last modified 20/10/2008")... but who is capable of doing it now? Maybe Digitalfoundryl (http://openarena.ws/board/index.php?action=profile;u=7371), that sells the app on the Mac store (http://openarena.ws/board/index.php?topic=4319.0)? Even if I would have preferred asking to someone without commercial intents, if available...


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on December 01, 2011, 01:25:44 pm
25:
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-25.tar.bz2
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-25.zip

What's changed?
25 = 24+"oa24 diff.zip"+"oa24-leimod.zip"+"2 changes by my"

My two changes was to change:
dynamic and uniformLight to vec4_t in tr_shade_calc.c (line 1409 and 1443) to stop some nasty warnings.

@Gig
The Mac binaries was compiled by jackoverfull (http://openarena.ws/board/index.php?action=profile;u=362)


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 01, 2011, 03:56:31 pm
So, I'm going trying to contact him, then.

I see he's from Italy, like me. I hope he still uses the email address shown in his profile (shown as msn address... but I don't use msn, so I will try sending a classic mail to that address).

UPDATE: My mail did not pass... It returned with a #5.4.6 error.   :-[

I PM'd him, too... but I fear he will not see the PM (he was last active in april).

To who could we ask for Mac compiling, then?  ???


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 01, 2011, 05:12:23 pm
Version 25 tried.
Bloom fix has got something strange, it does not work as expected. :(

First, I tried enabling Bloom keeping texture quality to "16 bits" or to "default". In this case, bloom does not get enabled at all.
(Note: Fromhell said here (http://openarena.ws/board/index.php?topic=4356.msg41495#msg41495) that (s)he disabled bloom as a workaround for another bug -semitransparent square in lower left corner- that happened in case of 16 bit textures... but the bug did not happen in case of "default", to me). A console message says WARNING: 'R_InitBloomTextures' no support for 32 bit textures, effect disabled. No support for 32 bit textures? I suppose it should be "no support for 16 bit textures"...

Enabling bloom with 32 bit textures, instead, makes a strange behavior. Instead of the old "bleeding" effect, now there is a "bright" effect on a major part the screen. I don't know how to describe it exactly. See the screenshots attached, or better try it yourself (quite clear in slimefac map).

Recap:
- Why effect disabled also in case of "default" texture quality, instead of 16 bits only? (More: if there is no time for a real fix for the "square" bug, maybe it would better to keep it for now, and fix it later in a more proper way, instead of disabling the effect? I don't know..)
- Message says "32bit" instead of "16 bit"
- If bloom is enabled, there are strange flashes on the screen... Fromhell, could you plase take another look to it? Thank you!

PS: jackoverfull already answered to my PM! He's going to take a look here. Good!  :)


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 01, 2011, 05:18:34 pm
Hi everyone… ;D

Gig just reached me through pms…Yes, it's true I haven't been much active here recently (in the last couple of years, actually!), I can't even remember what went on with OA 085, the last time I built something for OA was 085rc1.

I don't play much these days (not enough time), but I'm more than willing to setup my building machine and try to provide binaries for the new release. How do i proceed? I'll start with 25 and see if those build, but those will not be the final release, right?


Title: Re: Binaries for 0.8.x test thread
Post by: Peter Silie on December 01, 2011, 05:20:56 pm
+1


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 01, 2011, 05:26:18 pm
Recap:
- Why effect disabled also in case of "default" texture quality, instead of 16 bits only? (More: if there is no time for a real fix for the "square" bug, maybe it would better to keep it for now, and fix it later in a more proper way, instead of disabling the effect? I don't know..)
- Message says "32bit" instead of "16 bit"
- If bloom is enabled, there are strange flashes on the screen... Fromhell, could you plase take another look to it? Thank you!


1. because when at default, there's no guarantee we'll have a 32-bit texture for the bloom canvas
2. it's referring to the renderer's lack of 32-bit, not itself
3. weird, i never get them. I use samplesize 512, bloom looks okay there.


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on December 01, 2011, 05:52:34 pm
Gig, have you tried with r_bloom_cascade = 0 and r_bloom_reflections = 0?


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 01, 2011, 05:53:09 pm
Considering 1) and 2)... maybe the user may not understand what happens. Maybe it would be better to keep the "square" bug until a real fix is found... what do you think about it?

About 3).. how can I help debugging it?
First test (as in the screenshots in the previous post), with a config I was using since some days (while testing 088 betas/RC), its settings are:
seta r_bloom_cascade "1"
seta r_bloom_cascade_blur ".4"
seta r_bloom_cascade_intensity "20"
seta r_bloom_cascade_alpha "0.15"
seta r_bloom_cascade_dry "0.8"
seta r_bloom_dry "1"
seta r_bloom_reflection "0"
seta r_bloom_sky_only "0"
seta r_bloom_fast_sample "0"
seta r_bloom_sample_size "128"
seta r_bloom_darken "4"
seta r_bloom_intensity "1.3"
seta r_bloom_diamond_size "8"
seta r_bloom_alpha "0.3"
seta r_bloom "1"

Second test, using a completely new q3config.cfg, then only setting 32 bit textures and bloom on:
seta r_bloom_sky_only "0"
seta r_bloom_reflection "0"
seta r_bloom_dry "1"
seta r_bloom_cascade_dry "0.8"
seta r_bloom_cascade_alpha "0.15"
seta r_bloom_cascade_intensity "20"
seta r_bloom_cascade_blur ".4"
seta r_bloom_cascade "1"
seta r_bloom_fast_sample "0"
seta r_bloom_sample_size "256"
seta r_bloom_darken "4"
seta r_bloom_intensity "1.3"
seta r_bloom_diamond_size "8"
seta r_bloom_alpha "0.3"
seta r_bloom "1"

NOTE: I may be wrong, but I think I never tweaked such advanced bloom variables before, I don't know why some of them differ between the two configs! Maybe 088 betas or newer executables changed some defaults?

With the "second test" configuration, the problem is much less evident (but it still exists)

I attach extracts of console dumps of the two tests (parts about graphic init).

I did a third test, taking the config from the first one and then setting r_bloom_sample_size "512": after the vid_Restart, I got a "WARNING: 'R_InitBloomTextures' too high resolution for light bloom, effect disabled" message.

UPDATE: Setting r_bloom_cascade to 0 (default value is 1), as Neon suggested, seems to fix the problem. What do you think about it?


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 01, 2011, 06:32:39 pm
I've prepared a build enviroment, 0.8.1 builds fine (it was already there, used just to test everything was allright), version 25 doesnt at this time.

I've solved a first problem: in vm_powerpc_asm.c definitions founds in q_shared.h are referenced but that file is not included. However I'm now getting this:


Code:
DED_CC code/zlib/inftrees.c
DED_CC code/zlib/zutil.c
DED_CC code/qcommon/vm_powerpc.c
DED_CC code/qcommon/vm_powerpc_asm.c
DED_CC code/sys/sys_unix.c
DED_CC code/sys/con_tty.c
LD build/release-darwin-ppc/oa_ded.ppc
Undefined symbols:
  "_Sys_StripAppBundle", referenced from:
      _main in sys_main.o
  "_Sys_TempPath", referenced from:
      _Sys_WritePIDFile in sys_main.o
      _main in sys_main.o
      _Sys_Quit in sys_main.o
      _Sys_ParseArgs in sys_main.o
      _Sys_SigHandler in sys_main.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [build/release-darwin-ppc/oa_ded.ppc] Error 1
make[1]: *** [targets] Error 2
make: *** [release] Error 2
MiniServer:openarena-engine-source-0.8.x-25 jack$
That should be one of the very final steps of the build, actually, if I understands this correctly, the build should be already finished and it's a linking problem. Any hint?


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 01, 2011, 07:28:08 pm
I did a third test, taking the config from the first one and then setting r_bloom_sample_size "512": after the vid_Restart, I got a "WARNING: 'R_InitBloomTextures' too high resolution for light bloom, effect disabled" message.


Are you running a Voodoo<5?


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 01, 2011, 07:48:43 pm
it seems sys_osx.m isn't properly built. Also, I see that on the makefile it's referred with an older name (sys_cocoa.m), but fixing that doesn't change a thing.

In previous releases of OA this file didn't exist, os x used sys_unix.c
Also, why the .m extension? Is that really objective-c code? I positive, why? It's the only .m file out there…


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 01, 2011, 11:40:39 pm
I like this engine


So, should I wait for jack to make a mac engine binary or release Windows/Linux 088 patch in the meanwhile?


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 02, 2011, 01:47:01 am
I did a third test, taking the config from the first one and then setting r_bloom_sample_size "512": after the vid_Restart, I got a "WARNING: 'R_InitBloomTextures' too high resolution for light bloom, effect disabled" message.


Are you running a Voodoo<5?

From the dump I attached to the previous post (and that nobody downloaded yet  ;D):
GL_RENDERER: Radeon X1600/X1650 Series

(It's a 512 MB card)

Anyway... I really suggest to wait for the updated Mac executable before releasing 0.8.8.

PS: Have you tried with the default configuration+Bloom? Does the problem happen to you? In that case, is remembers a bit the "bleeding" effect.


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 02, 2011, 02:05:57 am
there will be no mac binary release, unless I manade go build it…or someone else, does, of course.

and right now this doesn't seem likely, given the status of the mac code (i wonder who did these changes and why…are they specific to oa or to ioq3 as well?).

Trying again…
Sys_TempPath is defined (always for os x) both in sys_osx and in sys_unix…in a different way.


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 02, 2011, 02:51:50 am
got around that problem using a modified makefile, based on the latest one from ioq3. Got this now, tough: http://pastebin.com/JyMR28Pi


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 02, 2011, 04:22:17 am
same kind of problem as before: tr_localis not being build.  >:(
Trying to solve this…


Title: Re: Binaries for 0.8.x test thread
Post by: Peter Silie on December 02, 2011, 06:38:17 am
So, should I wait for jack to make a mac engine binary or release Windows/Linux 088 patch in the meanwhile?

Wait till he made it.
After his success, the mac port should be more controlled in the future (jack: will you be here to manage oax changes).


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 02, 2011, 07:07:01 am
I've always been available.

Communication with the rest of the team, tough, has never been too direct, I remember chasing fromhell on msn to get sources to build 0.7.7…
And if 0.8.5 doesn't have mac binaries is probably because i didn't even know it had been released. Nobody contacted me about that and I haven't had time to follow the forum (or, basically, do anything else than follow a very specific, completely unrelated project) since april) to see what was going on.

I do have some spare time in these days, so I'll be trying to build 0.8.8, but the mac specific code isn't exactly ready to build and I'm not exactly a programmer, so I can offer no guarantee.

Anyway, at this point latest svn ioq3 builds, oa 0.8.8 25 doesn't, in a few hours I'll resume working on that, trying to find the reasons and to get it to build.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 02, 2011, 01:17:16 pm
To everyone: could you please try this in your systems?
1) rename your q3config.cfg file, to start OpenArena with a completely new one.
2) Start OpenArena 0.8.8 RC1 with version 25 executables
3) Go to Setup -> System -> Graphics. Enable Bloom and set texture quality to 32 bit, there
4) type /map slimefac
5) Go around the map, in particular where there is much "bloom" effect. Do you see stange things appearing on the edges of the screen?

It resembles the old "bleeding" effect, but more unfocused...

I attached an example screenshot (but seeing it in action is much more evident than in the screenshot!).


PS: If the problem is caused by r_bloom_cascade... maybe its default value should be changed from 1 to 0 for the release? Just guessing...


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on December 02, 2011, 01:35:43 pm
Tested, and yep, it happens with r_bloom_cascade 1.


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 02, 2011, 04:57:53 pm
discovered sdl_glimp doesn't build as well.

i ran a diff with the latest rc of 0.8.5 that was on my hd, it still builds fine, but still can't find what's wrong with 25. As for now I don't have many ideas left.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 02, 2011, 06:42:54 pm
Maybe you could try starting compiling earlier versions (e.g. 16, 18, etc.), searching for the first one you cannot compile and then searching in its diffs (maybe with some help from Sago), to try to understand what it does not like?


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 02, 2011, 11:10:37 pm
just don't diff with 23 since that's a new ioq3 revision without the oa changes necessary. Forget 23 existed.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 03, 2011, 12:43:30 am
That bloom bug oddly only happens in fullscreen mode. It goes away in windowed.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 03, 2011, 02:49:41 am
Just for curiosity, I tested a previous version of the executables, where there was the "old bleeding bug". That bug did not disappear turning off r_bloom_cascade, unlike what happens with the new bug.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 03, 2011, 03:23:23 am
the only other clamping mode I could try is GL_CLAMP which would make it bleed to black


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 03, 2011, 06:33:25 am
Maybe you could try starting compiling earlier versions (e.g. 16, 18, etc.), searching for the first one you cannot compile and then searching in its diffs (maybe with some help from Sago), to try to understand what it does not like?
Right, that's exactly what i'm trying now.

Quote
just don't diff with 23 since that's a new ioq3 revision without the oa changes necessary. Forget 23 existed.
And that's exactly what i last tried yesterday… ;D
In fact 23 gives totally different linking problems…

Seeking for earlier revisions.


How do I proceed to obtain an earlier revision…let's say 20? I'm looking onto the svn but can't find much about 0.8.8 or -dev or whatever…


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 03, 2011, 07:14:44 am
Try here:
http://files.poulsander.com/~poul19/public_files/oa/dev081/
There are various previous packages from Sago.

If what you need isn't there, ask Sago...
I don't know if and where is the svn of the engine.


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 03, 2011, 07:17:31 am
thanks. Trying…


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 03, 2011, 07:20:13 am
Bloom bug update - GL_CLAMP does not fix it, so this is beyond a rushing fix



Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 03, 2011, 05:41:59 pm
The first revision not to build on os x is 15.

Did a diff with 14, here is the result:
Code:
D Makefile                         Different size   14/Makefile
  Makefile.local                   Extra File       15/Makefile.local
D cl_input.c                       Different size   14/code/client/cl_input.c
D cl_main.c                        Different size   14/code/client/cl_main.c
D cl_parse.c                       Different size   14/code/client/cl_parse.c
D cl_scrn.c                        Different size   14/code/client/cl_scrn.c
D client.h                         Different size   14/code/client/client.h
D libmumblelink.c                  Different size   14/code/client/libmumblelink.c
D libmumblelink.h                  Different size   14/code/client/libmumblelink.h
D jinclude.h                       Different size   14/code/jpeg-6b/jinclude.h
D jmorecfg.h                       Different size   14/code/jpeg-6b/jmorecfg.h
D null_client.c                    Different size   14/code/null/null_client.c
D ui_main.c                        Different size   14/code/q3_ui/ui_main.c
D common.c                         Different size   14/code/qcommon/common.c
D cvar.c                           Different size   14/code/qcommon/cvar.c
D files.c                          Different size   14/code/qcommon/files.c
D net_ip.c                         Different size   14/code/qcommon/net_ip.c
D q_platform.h                     Different size   14/code/qcommon/q_platform.h
D qcommon.h                        Different size   14/code/qcommon/qcommon.h
D vm_interpreted.c                 Different size   14/code/qcommon/vm_interpreted.c
D vm_x86_64.c                      Different size   14/code/qcommon/vm_x86_64.c
D vm_x86_64_assembler.c            Different size   14/code/qcommon/vm_x86_64_assembler.c
D sdl_glimp.c                      Different size   14/code/sdl/sdl_glimp.c
D sdl_input.c                      Different size   14/code/sdl/sdl_input.c
D sv_client.c                      Different size   14/code/server/sv_client.c
D sv_main.c                        Different size   14/code/server/sv_main.c
  sys_cocoa.m                      Missing file     14/code/sys/sys_cocoa.m
D sys_local.h                      Different size   14/code/sys/sys_local.h
D sys_main.c                       Different size   14/code/sys/sys_main.c
D sys_unix.c                       Different size   14/code/sys/sys_unix.c
D sys_win32.c                      Different size   14/code/sys/sys_win32.c
  sys_osx.m                        Extra File       15/code/sys/sys_osx.m
D cmdlib.c                         Different size   14/code/tools/asm/cmdlib.c
D ui_main.c                        Different size   14/code/ui/ui_main.c
D ioquake3.nsi.in                  Different size   14/misc/nsis/ioquake3.nsi.in
D Makefile                         Different size   14/misc/nsis/Makefile

sys_cocoa became sys_osx more or less at this point in ioq3, but its contents are totally different. cocoa only contained a function to create a native looking alert, wich doesn't seem to be in the newer codebase (it's onlty to be found in the backup copy of sys_unix), sys_osx contains a bunch os os x specific functions.

sys_unix isn't much different, at the momen't i can't see any obvious possible culprit, i'll investigate further.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 04, 2011, 02:51:52 am
Bloom bug update - GL_CLAMP does not fix it
Who knows why this bug appeared with "bleeding" bug removal.

... and now? What to do?
1) try again to find a fix
2) change default of that "cascade" variable, to have it set to 0 (but what makes that cascade option?)
3) keep it as it is now
4) undo version 25 bloom changes (restoring the old bleeding bug)

What do you think to do?


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 04, 2011, 03:05:22 am
3.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 04, 2011, 07:42:59 am
Why not 2?
What is that "cascade" option supposed to do?


This new bug is better than the old one because it is possible to hide it disabling that option... but is worse than the old bug because it is somehow more visible and because, depending from your advanced bloom settings, it may even affect the whole screen...


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 04, 2011, 11:51:20 am
Finished to examine the diff between 14 and 15.

Differences aren't that extensive, yet it 15 doen't build and I cant see why. >:(


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 04, 2011, 05:36:16 pm
Sago, are you sure you cannot help Fromhell and Jackoverfull with their respective problems (bloom bugs and compiling version 15 and later)?


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 04, 2011, 06:07:28 pm
All sago would need to do is set r_bloom_cascade to default 0 instead of 1 in the renderer/tr_bloom.c file, it's such a trivial change I don't even have to make a diff file for that

though there would need to be a build 26 with working Mac compiling first

I realize how big of a headache this situation is all around.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 05, 2011, 02:15:20 am
But again, what that "cascade" option changes, exactly?


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 05, 2011, 05:07:05 am
This (http://openarena.ws/board/index.php?topic=4223.0)


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 05, 2011, 06:38:30 am
I didn't remember about that thread.  Ehm... ::) Sorry.

Anyway, considering that it seems that "cascade" option isn't from you, but from tcpp, I PMd him to ask him if he can take a look.

Bye!


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 05, 2011, 08:11:32 am
I realize how big of a headache this situation is all around.
Can't say I've made much progress yesterday.
Tried to find what's wrong, but to no solution so far. Will try to import changes from 15 into 14 to see at which point it stops linking, but it will not be easy.


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on December 05, 2011, 02:31:44 pm
Just an idea, jack: have you tried to compile the remaining releases, from 16-25 except 23?


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 05, 2011, 03:32:10 pm
Just an idea, jack: have you tried to compile the remaining releases, from 16-25 except 23?
Tried 18 and 20.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 07, 2011, 01:11:35 am
i've poked lordhavoc to take a look at Mac building build 25, he was able to but left the dedicated server out


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 08, 2011, 05:41:55 pm
Here we go AO 0.8.5 25 for OS X, client and server, universal binary.  :) :)

http://www.jackoverfull.com/tmp/OAMac085r25.zip

Please understand I've worked on this instead of sleeping, thus: basically no testing at all. :RIP:
But it's always fun. ;D

I've included my modified Makefile and the script to build the application package, should be ok to include them in the main sources. I had to modify a bit the mac os x specific parts of the code, I'll track down all the changes and upload them in a second file soon.

It should have the same system requirements of the previous releases: any mac with Mac OS X 10.4.x should be more than enough to run OA. It's possible it will run on 10.3.9 as well, perhaps without music, but I doubt many would care anyway.

I'll probably do a very brief test (just see if it runs and if it's possible to host and join a game between different architectures) on my X64 Macbook Pro and my PPC G3 iMac tomorrow, given I can spare 15 minutes, please feel free to contact me again if additional builds are needed.


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on December 08, 2011, 05:50:21 pm
You're an idol, Jack. Here goes a cake for you. :up:


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 08, 2011, 06:20:39 pm
Thank you, Jack!

Obviously, some little tests would be precious!

I'm sorry tcpp has not visited the forum yet since when I pm'd him few days ago... (in the hope he may fix the cascade bloom bug)... I hope he may get here in time... but I understand there is extremely short time, now...

PS: just for curiosity: what was the problem between 14 and 15?


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 09, 2011, 04:37:08 am
Quote
You're an idol, Jack. Here goes a cake for you. :up:
Thanks. A big slice of that cake goes to lord havoc, of course…he saved me a lot of time.

Thank you, Jack!

Obviously, some little tests would be precious!

Right…


Quote
PS: just for curiosity: what was the problem between 14 and 15?
the ioq3 team started using a bit more of the native os x interface in the client but the makefile had to be updated to tell the linker to search for the frameworks that provided the interface. For some reason that change in the makefile had not been imported in OA.


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 09, 2011, 06:33:17 am
testing now…

the toggleconsole key does toggle the console, but it isn't drawn on screen. i'm not sure if it's a new bug or what. On the other hand if I press ~, which is "cl_consoleKeys" everything looks fine.


OA quits with "illegal instruction" on my G3.  :RIP:
Perhaps the ioq3 team removed g3 support?


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 09, 2011, 06:46:58 am
in fact ioq3 1.36 doesn't work either (but quits a while after that point and with no error at all!), while 1.34 worked fine.

Someone here who can test on other macs? I can only try on my own and on my g3 at this time.



Title: Re: Binaries for 0.8.x test thread
Post by: WingedPanther on December 09, 2011, 08:47:46 am
I've got some access to an Intel MacBook Pro.  I can do some testing on it.


Title: Re: Binaries for 0.8.x test thread
Post by: WingedPanther on December 09, 2011, 09:00:36 am
Just attempted to run.  Was this meant to be a patch, it's failing to find default.cfg and crashing?


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 09, 2011, 09:01:56 am
Just attempted to run.  Was this meant to be a patch, it's failing to find default.cfg and crashing?
odd…have you placed it next to a baseoa folder? I used the 0.8.5 version.


Title: Re: Binaries for 0.8.x test thread
Post by: Tiny on December 09, 2011, 12:50:51 pm
I got somehow a macbook and an iMac, and petersillie told me a mac user was needed for some test, if i can help i'll gladly do it, just tell me what i have to do lol


Title: Re: Binaries for 0.8.x test thread
Post by: WingedPanther on December 09, 2011, 03:52:15 pm
Copying the baseoa folder from my 0.8.5 copy fixed it.  I had the impression there's a touch more jitter on rendering walls, but it worked well for me.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 09, 2011, 04:44:52 pm
Don't forget the 088 patch RC1 for the GLSL files the engine now depends on.

I do want to release it today, but we have another roadblock....... I'm sick!!

However some of my sick day could lead to some time for mac testing.

- Make sure OGG vorbis works
- Make sure CURL works
- Make sure VOIP works


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 09, 2011, 04:54:40 pm
I got somehow a macbook and an iMac, and petersillie told me a mac user was needed for some test, if i can help i'll gladly do it, just tell me what i have to do lol
You just need to download openarena 0.8.1 (http://openarena.ws/download.php?view.2), perhaps apply the 0.8.5 patch (http://openarena.ws/download.php?list.60) (tough, if I understood correctly, isn't really needed in order to test this build), download and open the Mac OS X Binary (http://www.jackoverfull.com/tmp/OAMac085r25.zip), place the application next to the baseoa folder, open it and…well, test it for a while.

Copying the baseoa folder from my 0.8.5 copy fixed it. 
:)

Quote
I had the impression there's a touch more jitter on rendering walls, but it worked well for me.
Perhaps…No idea, haven't had time to play in ages. :RIP:



Quote
- Make sure OGG vorbis works
First (and almost onl) thing I tested. Sounds fine on my macbook pro. Should be ok on ppc, but i don't have the hardware to try at the moment.


Quote
- Make sure CURL works
Is used to download additional maps? How do we test it?


Quote
- Make sure VOIP works
Never tested this on mac…As before, there is a quick way to check?


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 09, 2011, 05:58:30 pm
Testing voip? I suppose setting up voip, connecting from a computer to the other one and then testing by using microphone and speakers.

Voip instructions here:
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Voip
(note: maybe such instructions may need some polishing -e.g. I'm not sure about bandwidth requirements for client and server- if somebody wants to help...)


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 09, 2011, 06:01:39 pm
Don't forget the 088 patch RC1 for the GLSL files the engine now depends on.
Do you mean engine 25 is no more fully compatible with 081/085, but with 088 only? What problems may affect 081//085 users?

Ps: tcpp has not visited the forum yet since 5 december (since just an hour before I wrote him the PM about cascade bloom bug, or similar!). D'oh! D'oh! D'oh!


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 10, 2011, 01:19:17 am
Testing voip? I suppose setting up voip, connecting from a computer to the other one and then testing by using microphone and speakers.

Voip instructions here:
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Voip
(note: maybe such instructions may need some polishing -e.g. I'm not sure about bandwidth requirements for client and server- if somebody wants to help...)
Will see what i can do.


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 10, 2011, 01:54:53 am
tested voip, all works fine. :)

Setted it up, launched 2 instances of OA (I don't have a second OA capable computer available at this time) started and joined a game…I can hear myself speaking.

Now, what about curl?

I'm up early and have more or less 1 hour free… ;D


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 10, 2011, 01:58:55 am
Accessing to my old iBook G4 (now my mother's), the firt mac that ever ran OA, back at the times of 0.5.1, to do some PPC testing… :)


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 10, 2011, 02:38:14 am
OA runs on my G4 (of the second generation, still untested on older G4, wich had a slightly different instruction set) with 10.5 Leopard. Can connect to my MBP without problems.

OpenAl doesn't work there, tough, even if it is installed (probably in an older version), the console says it's rendering the audio in software.
Oddly, I can't even hear myself speaking from the other computer: when I try I get briefly a "connection interrupted" message on the screen of the iBook.


And the console is now displayed properly even using the ingame key to toggle it!  :o


Title: Re: Binaries for 0.8.x test thread
Post by: Tiny on December 10, 2011, 02:54:24 am
Seems i can't load the game, i got an error message telling me that it can't load the default cfg :-X


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 10, 2011, 02:57:57 am
You need to put the application in the same folder of baseoa, otherwise you'll just get this…

(http://img849.imageshack.us/img849/5871/schermata20111210a09560.png)


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 10, 2011, 04:38:11 am
About cascade bloom bug:
tcpp answered to my email...
Quote from: tcpp
Hi.

I'm glad to see my cascaded bloom algorithm was accepted for the next release of
OpenArena, but I'm sorry that I cannot deal with this bug now because I don't have
access to any PC that is usable for the development until March or April.

But I don't think it is good to leave this bug in OA 0.8.8, so could you remove or
disable the cascaded bloom algorithm?

Thanks.


Title: Re: Binaries for 0.8.x test thread
Post by: Tiny on December 10, 2011, 05:33:27 am
You need to put the application in the same folder of baseoa, otherwise you'll just get this…
Lol indeed, my fault, as i read " put it next to the baseoa folder " i didn't put it inside ^^

Edit: tested a bit, and i didn't see anything going wrong, just one thing, when i want to open the console, i gotta press twice the button, same to close it, dunno if that's a bug or not.


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on December 10, 2011, 03:29:57 pm
Don't forget the 088 patch RC1 for the GLSL files the engine now depends on.
Is it not a little dangerous to make the engine depend on a new pack-file without boosting the protocol number?

What if the 0.8.8 patch is unloaded to join a 0.8.1 or 0.8.5 server?
What if the patch is downloaded to an old binary?


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 10, 2011, 04:01:59 pm
You need to put the application in the same folder of baseoa, otherwise you'll just get this…
Lol indeed, my fault, as i read " put it next to the baseoa folder " i didn't put it inside ^^

Edit: tested a bit, and i didn't see anything going wrong,
:)


Quote
just one thing, when i want to open the console, i gotta press twice the button, same to close it, dunno if that's a bug or not.
I must confirm that the console toggles operates oddly…
With my usual keyboard layout I can toggle it typing ~, ingame I can also use <, that was the key i mapped long ago, but once it's open < doesn't close it.
Interestingly, using the USA layout ~doesnt work anymore, yet `, which is on the same phisical key that holds < using the italian layout, always works, even in the menu, as ~ did before. Also, with the USA layout -not using the two altervatives of the italian one - the console sometimes doesn't open fully (it stays only about half out). could depend also on how long I hold the key, perhaps.



Title: Re: Binaries for 0.8.x test thread
Post by: Udi on December 10, 2011, 04:08:12 pm
Also, with the USA layout -not using the two altervatives of the italian one - the console sometimes doesn't open fully (it stays only about half out). could depend also on how long I hold the key, perhaps.

There's a variable for that: cl_consoleHeight determines how much the console comes down, the default value is 0.5 so it only comes down half the screen. If you set it to 1 it will fully open.


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 10, 2011, 04:16:28 pm
Also, with the USA layout -not using the two altervatives of the italian one - the console sometimes doesn't open fully (it stays only about half out). could depend also on how long I hold the key, perhaps.

There's a variable for that: cl_consoleHeight determines how much the console comes down, the default value is 0.5 so it only comes down half the screen. If you set it to 1 it will fully open.
right.

The point is that when I press the key some times it comes down a quarter of the screen, some others half (that's the usual size), apparently random and only with the USA layout.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 10, 2011, 06:36:59 pm
Don't forget the 088 patch RC1 for the GLSL files the engine now depends on.
Is it not a little dangerous to make the engine depend on a new pack-file without boosting the protocol number?

Should've mentioned a protocol change earlier. :/

build 26 would just have that, and r_bloom_cascade default to 0.


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on December 10, 2011, 07:31:26 pm
Wait... GLSL is the only thing which makes the engine to depend on a compatibility break to work? If that's the case, what about not including GLSL by now? You don't want to break compatibility with 0.8.X until 0.9.0, do you?


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 10, 2011, 07:52:24 pm
Wait... GLSL is the only thing which makes the engine to depend on a compatibility break to work? If that's the case, what about not including GLSL by now? You don't want to break compatibility with 0.8.X until 0.9.0, do you?

I thought everyone knew about the GLSL pak file requirement (after all there was testing, right?).... now you don't want GLSL support?

Ugh. If we keep doing these last-minute retractions, then 088 will never be released.

It's too late. We have GLSL integrated. It's easier said than done to UNintegrate it. Not to mention the sheer difficulty of reintegrating all of our changes in later ioq3 revisions in the future......


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on December 10, 2011, 08:07:49 pm
I'm not a programmer, so I was ignorant about GLSL requiring a compatibility break change.


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on December 11, 2011, 03:58:15 am
I was aware of the problem but did not register that the GLSL was used anywhere in pak6-patch088-111119.pk3. I thought is was included for future use.

I did not notice any problems joining a 0.8.1 or 0.8.5 server with -25 binaries. Is it possible that the 0.8.8 patch are only required during loading?

Also I did not notice a problem stating 0.8.8 with old binaries.

I did notice a problem starting 0.8.1 with -25 binaries. But the file will always be present during initial load because it will be distributed whit the engine.

Where can I see something breaking in 0.8.8 without the -25 binary. That is really the case I am most interested in.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 11, 2011, 04:09:32 am
I thought that glsl support was something "more" to be used in future versions of the game (e.g. oa3 style reboot or new mods).

Where is it used in 088? I have not been able to test it also because I don't know enough about it: I have not exactly understood what it is... something similar to cell shading?

And I was not aware it may represent a compatibily problem before reading a post here yesterday...

PS: is it enabled/disabled by a cvar?

PPS: glsl water effect in the video linked here (http://openarena.ws/board/index.php?topic=4314.msg41737#msg41737) looks nice...


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 11, 2011, 06:01:48 am
hi,
the GLSL support should not break compatibility but, maybe I'm missing some info here? If the engine compiles, default value of r_ext_vertex_shader is set to be 0 (off). Any map shader that uses glsl, would have its glsl commands be ignored if they are added with leading escape sequence '//GLSL'.
As far I was able to see any glsl related code in the engine should never execute if detection of glsl capabilities fails at engine start.
If you find there could be a problem with glsl please let me know and I will look into it.
It does seem the glsl support was added a bit too late for the 0.88 to take advantage of it. And, for the proper testing, I imagine I should send few working glsl programs as it should demistify the usage of glsl programs in shaders (I'll start a thread in maps forum to ask for anyone interested in working together to implement glsl stages to the shaders). Sorry for getting off topic ..
For the engine and any eventual problems, please let me know..
Cheers


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 11, 2011, 06:15:18 am
So, the command to enable glsl is "r_ext_vertex_shader 1"? Just tried it, and the game crashes on my machine (windows xp, 088 patch + executables 25):

Quote
----- R_Init -----
SDL using driver "directx"
Initializing OpenGL display
Estimated display aspect: 1.250
...setting mode 4: 800 600
Using 8/8/8 Color bits, 24 depth, 0 stencil display.
Available modes: '720x576 1280x1024 320x240 400x300 512x384 640x480 800x600 1024x768 1152x864 1280x960 720x480 320x200 640x400 1280x800 800x480 1280x768 848x480 1280x720'
GL_RENDERER: Radeon X1600/X1650 Series
Initializing OpenGL extensions
...ignoring GL_EXT_texture_compression_s3tc
...GL_S3_s3tc not found
...using GL_EXT_texture_env_add
...using GL_ARB_multitexture
...using GL_EXT_compiled_vertex_array
...using GL_EXT_texture_filter_anisotropic (max: 16)
...using GL_ARB_vertex_shader

GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: Radeon X1600/X1650 Series
GL_VERSION: 2.1.8545 Release
GL_EXTENSIONS: GL_AMD_performance_monitor GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_map_buffer_range GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_envmap_bumpmap GL_ATI_fragment_shader GL_ATI_meminfo GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texgen_reflection GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_swizzle GL_EXT_vertex_array GL_KTX_buffer_region GL_NV_blend_square GL_NV_texgen_reflection GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_WIN_swap_hint WGL_EXT_swap_control
GL_MAX_TEXTURE_SIZE: 4096
GL_MAX_TEXTURE_UNITS_ARB: 8

PIXELFORMAT: color(24-bits) Z(24-bit) stencil(0-bits)
MODE: 4, 800 x 600 fullscreen hz:N/A
GAMMA: hardware w/ 0 overbright bits
rendering primitives: single glDrawElements
texturemode: GL_LINEAR_MIPMAP_LINEAR
picmip: 0
texture bits: 32
multitexture: enabled
compiled vertex arrays: enabled
texenv add: enabled
compressed textures: disabled
glsl programs: enabled
Initializing Programs
Error:
Fragment shader(s) failed to link,  vertex shader(s) linked.
Fragment Shader not supported by HWWARNING: built-in varying gl_TexCoord [2] has mismatched access semantics between the vertex and fragment shader
WARNING: built-in varying gl_TexCoord [3] has mismatched access semantics between the vertex and fragment shader
WARNING: built-in varying gl_TexCoord [4] has mismatched access semantics between the vertex and fragment shader
WARNING: built-in varying gl_TexCoord [5] has mismatched access semantics between the vertex and fragment shader
WARNING: built-in varying gl_TexCoord [6] has mismatched access semantics between the vertex and fragment shader
WARNING: built-in varying gl_TexCoord [7] has mismatched access semantics between the vertex and fragment shader
ERROR: Varying gl_TexCoord[2] read in fragment shader, but not written to in vertex shader.
ERROR: Varying gl_TexCoord[3] read in fragment shader, but not written to in vertex shader.
ERROR: Varying gl_TexCoord[4] read in fragment shader, but not written to in vertex shader.
ERROR: Varying gl_TexCoord[5] read in fragment shader, but not written to in vertex shader.
ERROR: Varying gl_TexCoord[6] read in fragment shader, but not written to in vertex shader.
ERROR: Varying gl_TexCoord[7] read in fragment shader, but not written to in vertex shader.
 
********************
ERROR: Couldn't link shaders for program generic
********************
RE_Shutdown( 0 )
Hunk_Clear: reset the hunk ok
----- R_Init -----

GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: Radeon X1600/X1650 Series
GL_VERSION: 2.1.8545 Release
GL_EXTENSIONS: GL_AMD_performance_monitor GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_map_buffer_range GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_envmap_bumpmap GL_ATI_fragment_shader GL_ATI_meminfo GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texgen_reflection GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_swizzle GL_EXT_vertex_array GL_KTX_buffer_region GL_NV_blend_square GL_NV_texgen_reflection GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_WIN_swap_hint WGL_EXT_swap_control
GL_MAX_TEXTURE_SIZE: 4096
GL_MAX_TEXTURE_UNITS_ARB: 8

PIXELFORMAT: color(24-bits) Z(24-bit) stencil(0-bits)
MODE: 4, 800 x 600 fullscreen hz:N/A
GAMMA: hardware w/ 0 overbright bits
rendering primitives: single glDrawElements
texturemode: GL_LINEAR_MIPMAP_LINEAR
picmip: 0
texture bits: 32
multitexture: enabled
compiled vertex arrays: enabled
texenv add: enabled
compressed textures: disabled
glsl programs: enabled
Initializing Programs
Error:
Fragment shader(s) failed to link,  vertex shader(s) linked.
Fragment Shader not supported by HWWARNING: built-in varying gl_TexCoord [2] has mismatched access semantics between the vertex and fragment shader
WARNING: built-in varying gl_TexCoord [3] has mismatched access semantics between the vertex and fragment shader
WARNING: built-in varying gl_TexCoord [4] has mismatched access semantics between the vertex and fragment shader
WARNING: built-in varying gl_TexCoord [5] has mismatched access semantics between the vertex and fragment shader
WARNING: built-in varying gl_TexCoord [6] has mismatched access semantics between the vertex and fragment shader
WARNING: built-in varying gl_TexCoord [7] has mismatched access semantics between the vertex and fragment shader
ERROR: Varying gl_TexCoord[2] read in fragment shader, but not written to in vertex shader.
ERROR: Varying gl_TexCoord[3] read in fragment shader, but not written to in vertex shader.
ERROR: Varying gl_TexCoord[4] read in fragment shader, but not written to in vertex shader.
ERROR: Varying gl_TexCoord[5] read in fragment shader, but not written to in vertex shader.
ERROR: Varying gl_TexCoord[6] read in fragment shader, but not written to in vertex shader.
ERROR: Varying gl_TexCoord[7] read in fragment shader, but not written to in vertex shader.
 
----- Client Shutdown (recursive error after: Couldn't link shaders for program generic) -----
RE_Shutdown( 1 )
-----------------------

I've had to edit q3config.cfg to disable it, then.


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 11, 2011, 09:17:48 am
I'll try to understand why this happens .. btw, when you started OA after the crash, did it ask you to start in Safe mode?  there should be (unless my last diff didnt include it) automatic disabling of this cvar if OA fails to start and you start it in safe mode.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 11, 2011, 09:25:55 am
Yes, it asked to me to use safe video settings. But I preferred to manually edit q3config.cfg to disable that single variable instead of resetting all video settings.


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 11, 2011, 09:54:30 am
not much came up searching on the net.. there is this error reported with ATI cards but on Linux.
I might have questions and things for you to try (if you have the time and feel like it).. Should I maybe start a new thread about this not to clog this one?


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on December 11, 2011, 10:17:04 am
Mine stopped working because the glsl-files was missing. Perhaps a check to see if the files are there before enabling glsl will solve the problem.


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 11, 2011, 10:47:29 am
I can add this check. I'm thinking of adding few lines that would disable altogether the glsl feature if one glsl program fails to compile. I've added few lines to tr_shader.c that outputs more info regarding the glsl compilation - hoping this would make debuging easier. I'll make a diff and post it here.
btw, I see in the source that OA outputs more info for developer using 'Printf(PRINT_DEVELOPER,...' - is this output enabled by a cvar? Do you know how this works? might be useful to have this developer info from Gig's machine.




Title: Re: Binaries for 0.8.x test thread
Post by: grey matter on December 11, 2011, 11:48:24 am
I see in the source that OA outputs more info for developer using 'Printf(PRINT_DEVELOPER,...' - is this output enabled by a cvar? Do you know how this works?

Code:
set developer "1"
Either in console or config.


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 11, 2011, 03:10:41 pm
Thanks grey matter!

@Sago007, here attached are the latest source files I have as well as glsl folder with programs (to replace existing one).
 
In this diff I removed the loading of generic programs altogether as I think the error Gig is receiving might be due to linked programs - not sure but is something to test.

@Gig, Once this diff included and binaries available, we should try debugging a bit (i.e. start the game, enable vertexShaders and try loading a postprocessing program - see if that works as it is composed only of a single vertex and single fragment glsl program. one would load this program using r_postprocess cvar - i.e. r_postprocess color1). The error you report is strange as at no point, as far as I can see, does the fragment shader read these TexCoord variables..

Thank you all!


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 11, 2011, 06:37:37 pm
What I can say:
- I don't know if my card supports glsl or not. If not, I suppose the engine should detect it and report an error in console, but not crashing/shutting down the game. What is supposed OA to do in this case? Update: I read in Hitch's previous post that glsl code should be ignored in that case.
- Missing glsl files? But Fromhell said they were inside the 088 patch... and I did the test with 088! Does it mean some files should be outside the pk3 or what? :-\ Is there a list of files needed by glsl?
- I will try to post some debug infos.
- Am I the only one with the game crashing with r_ext_vertex_shader 1? Neon? Others?


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 11, 2011, 06:40:34 pm
Cards that support GLSL are cards that at least support Pixel Shader 2.0 (GeforceFX, Radeon9500)

My game doesn't crash with r_ext_vertex_shader 1 because I have the patch pk3 in there with the glsl files necessary.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 11, 2011, 06:57:02 pm
My game doesn't crash with r_ext_vertex_shader 1 because I have the patch pk3 in there with the glsl files necessary.

Uh? I do have 088 rc1 patch. What else patch pk3 are you talking about?
Anyway, the engine (momentarily) auto-disabling the effect in case it does not find needed files is important, to prevent crashes each time one will connect to a 081 or 085 pure server (where new pk3s would be ignored).


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 12, 2011, 06:03:31 am
Some other tests done. The game crashes after a /vid_restart (or doing something that triggers it, like switching from windowed mode to fullscreen).
If I launch OpenArena, set r_ext_vertex_shader 1 and then load a map, it loads without crashing (although I cannot notice any difference from standard game! E.g. the water seems the old, classic water.). Even if I set "r_postprocess color1" and load another map, it does not crash (although I still cannot notice any difference). It crashes if I do a /vid_restart.

Attaching here a log taken with "/developer 1" enabled. Again, executables version 25, Windows XP, OpenArena 088 RC1. (I had to attach it because it was over the maximum characters limit for a post).

An interesting thing I noticed - but probably totally unrelated with the crash - is that the program cannot find some files that it searches for by using an absolute path instead of relative path.
You can see that my OA installation folder is under X:\OpenArena\OpenArena-0.8.8, and my homepath folder is under c:\documents and settings\user\Dati applicazioni\OpenArena. That's ok.
Instead, those paths appearing as D:\svnthis\oa\... and E:\projects\oa\.... (that appear in some lines about images not found) are absolutely not related with my system! Maybe they refer to Fromhell's or Sago's, or Udi's system? Or well, to the system of whoever is the author of the shaders that search for those images...




Title: Re: Binaries for 0.8.x test thread
Post by: Udi on December 12, 2011, 07:42:39 am
An interesting thing I noticed - but probably totally unrelated with the crash - is that the program cannot find some files that it searches for by using an absolute path instead of relative path.

The md3 files have those, grepping results:

E:\projects
models/misc/telep.md3
models/players/sarge/head.md3
models/weaphits/ring02.md3

D:\svnthis
models/players/gargoyle/head.md3
models/players/gargoyle/head_1.md3
models/players/gargoyle/head_2.md3
models/players/gargoyle/lower_1.md3
models/players/gargoyle/lower_2.md3
models/players/gargoyle/upper.md3
models/players/gargoyle/upper_1.md3
models/players/gargoyle/upper_2.md3
models/players/sarge/head_1.md3
models/players/sarge/head_2.md3

poopypants
models/weaphits/bullet.md3

rocketFlare_001
models/weaphits/boom01.md3

I don't know about modelling, but I guess those warnings can be ignored.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 12, 2011, 08:01:45 am
poopypants
models/weaphits/bullet.md3

rocketFlare_001
models/weaphits/boom01.md3

Shader remapping in cgame makes those two unused

but still.......... poopy pants........... in everyone's logs........ now that's getting crap past the radar :P

I should mention there's a tool on the Darkplaces files folder (http://icculus.org/projects/twilight/darkplaces/files/modeltools20070412.zip) that's intended to alter the strings in MD3 files. That'll be a good start


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 12, 2011, 12:06:22 pm
What I can say:
- I don't know if my card supports glsl or not. If not, I suppose the engine should detect it and report an error in console, but not crashing/shutting down the game. What is supposed OA to do in this case? Update: I read in Hitch's previous post that glsl code should be ignored in that case.
- Missing glsl files? But Fromhell said they were inside the 088 patch... and I did the test with 088! Does it mean some files should be outside the pk3 or what? :-\ Is there a list of files needed by glsl?
hi Gig,
you card does support glsl (there are 4 ARB extensions needed and they are present on your video card). It is possible that there is a call to glsl OpenGL functions even if the glsl support is not present on the video card - I will double check this. I am noobie when it comes to Q3 engine and cant really say much about the ok3 files - from what I understood is that you need to run an un-pure server for OA to look outside pk3 files. And finally, for the list of glsl files, the last diff I've sent will make OA not look for any glsl files at startup time - it will try to load glsl files only if either they are requested by postprocessing program or by a OA shader (by default & at the moment neither use glsl programs - so no files needed).


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 12, 2011, 12:11:21 pm
Anyway, the engine (momentarily) auto-disabling the effect in case it does not find needed files is important, to prevent crashes each time one will connect to a 081 or 085 pure server (where new pk3s would be ignored).

the engine usually displays a message gracefully if it fails to compile the glsl program. For glsl program to be loaded and compiled the map that the server runs needs to request a specific glsl program (and none of 081 or 085 map will not do so).


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 12, 2011, 12:36:49 pm
Some other tests done. The game crashes after a /vid_restart (or doing something that triggers it, like switching from windowed mode to fullscreen).
If I launch OpenArena, set r_ext_vertex_shader 1 and then load a map, it loads without crashing (although I cannot notice any difference from standard game! E.g. the water seems the old, classic water.). Even if I set "r_postprocess color1" and load another map, it does not crash (although I still cannot notice any difference). It crashes if I do a /vid_restart.
Thanks for the verbose log file.
after changing the r_ext_vertex_shader to 1  the glsl will kick in only after you do vid_restart. looking at the log file you've sent it is clear the glsl files are present and loaded - the whole thing fails at compile time. I am trying to compare supported ARB extensions on you video card and mine to fine possibly an extension that is required but not tested for in the engine. Next step would be to test with engine containing my last diff file - that might prove that the problem comes from 'generic' glsl program being composed of two fragment shaders. Anyways, I'm going to double check  all the glsl related calls to make sure they are executed only if a) glsl support exists on the video card and b) all programs compiled without errors or warnings.


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 12, 2011, 12:52:59 pm
p.s. for water, on Hydronex map, to be drawn using glsl program; the OA shader 'textures/liquids/hydrowater' located in liquid_water.shader file in pak0.pk3's 'scripts' folder would need to be modified to include commands that actually tell OA to load glsl program called 'water' and use it when rendering 'textures/liquids/hydrowater' shaded surfaces.
So if I've understood the protocol version and compatibility concerns well, then that would be the actual issue which would break the compatibility with 081 and 085. Please correct me if I'm wrong but as long the 'glsl' programs folder is kept in 088 patch pk3, the 088 should without problems connect to the 081 or 085 servers. The last diff I did, no glsl files are needed to start the engine - so probably the protocol number can now stay the same?


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on December 12, 2011, 02:55:00 pm
-26:
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-26.zip
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-26.tar.bz2

Works on 0.8.5 for me even with r_ext_vertex_shader on.

I forgot r_bloom_cascade default to 0


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 12, 2011, 04:39:04 pm
building…


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 12, 2011, 05:14:30 pm
Here we go: 26 OS X binary… ;)

http://www.jackoverfull.com/tmp/OAMac088r26.zip

I've included all the (3) files that has to be changed in order to build it on OSX, please merge them in the sources. There are just a few OS X or PPC specifics edits, nothing drastic.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 12, 2011, 06:18:03 pm
I will try with version 26 as soon as I can. But I'm extremely busy with real life in these days, and probably (unless I somehow find 10 minutes tuesday morning) will not be able to do the test before thursday evening.

But I haven't understood yet where/what I have to look at to understand if glsl is really working or not... Did you say that no current map contains a glsl effect? Do you have a "glsl test map"?


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 12, 2011, 06:26:20 pm
just try r_postprocess edges
vid_restart
check out edges

also try r_postprocess egafilter


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 13, 2011, 02:56:45 am
Okay. Tested version 26 executables.
OpenArena does not crash anymore with r_ext_vertex_shader 1 and vid_restart. This is good.  :)
But again, tried r_postprocess edges, r_postprocess egafilter, r_postprocess color1... and noticed absolutely nothing.  ???

Attaching "developer 1" condump.


Title: Re: Binaries for 0.8.x test thread
Post by: Udi on December 13, 2011, 07:24:10 am
But again, tried r_postprocess edges, r_postprocess egafilter, r_postprocess color1... and noticed absolutely nothing.  ???

You have to have the latest GLSL folder from Hitchhiker (http://openarena.ws/board/index.php?topic=1933.msg41840#msg41840), download the glsl.zip, rename it to something like z_glsl.pk3, put into your baseoa folder, and it should work (http://ubuntuone.com/7asfZ5QFutpT4WIg4E4ka5).


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 13, 2011, 01:56:55 pm
Gig, if you enter in console just /r_postprocess it will probably say that you're using program 'none'. your log file says that OA cannot locate the 'edges' program. Please try Udi 's suggestion - I'm hoping over here it will compile and work..
Then, I think all the programs I've made are a rough version of how they should be done.. i.e. edges could be done in a better way. 'bloom' should actually be called 'dream' or 'soften' as, quality-wise,  it does not come close to bloom that already exists in OA .. they were made along the way and more as quick demos of what could be done..

then off topic, svn - Revision 945: /experimental/fbo-test .. https://bugzilla.icculus.org/show_bug.cgi?id=3422
Some glsl programs there (to be adapted .. mainly file names) .. seems my postprocessing bit was kind of re-inventing the wheel
(on topic.. some ATI cards related fix there.. maybe be useful to get more info on the error you reported)


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 13, 2011, 05:51:52 pm
I will try adding that zip file, as pk3 (anyway the forum probably accepts pk3 files directly, without the need to rename them to .zip to upload them), to my baseoa. But I don't know exactly when I will be able to do it; I hope within 24h, but maybe 48.

Anyway, that zip file has been downloaded only four times until now... thus many people have not tried it yet...  I thought it was a file directed to Sago or Fromhell, to build the new version...


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 14, 2011, 02:26:32 am
I will not be able to do tests on my system at least until tonight, so for the moment I did a test on another machine. Again Windows XP, but this one with an integrated video system (Windows reports it as a Intel Q35 Express Chipset Family)... I don't know, but it maybe it does not support pixel shader 2.0... IDK.

Dump taken with r_ext_vertex_shader 1, r_postprocess edges, developer 1.

This time, I have placed glsl.zip (renamed as z_glsl.pk3) into my baseoa folder. But I do not see the "edges" effect.

PS:
Gig, if you enter in console just /r_postprocess it will probably say that you're using program 'none'.
Even if it does not work, it does not revert "r_postprocess" to "none"... it remains the one I manually specified (e.g. "edges"), even if I close OA and start it again.


Title: Re: Binaries for 0.8.x test thread
Post by: dbX on December 14, 2011, 09:01:54 am
Intel Q35 Express Chipset Family

It would seem these support only OpenGL 1.4, so you won't be able to use shaders with this graphics card.


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 14, 2011, 02:15:31 pm
Gig, if you enter in console just /r_postprocess it will probably say that you're using program 'none'
Even if it does not work, it does not revert "r_postprocess" to "none"... it remains the one I manually specified (e.g. "edges"), even if I close OA and start it again.

oops.. that is true... the cvar value remains even if the program is not found and thus loaded.. sorry for the bad info :(

the log file says "glsl programs: disabled" .. quick look at the OpenGL extensions supported by the card -> some required extensions are missing on it.

Thank you Gig for all the testing!

I'm busy these days as well and earliest I will be able to look at the source again is next week.. :(


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 14, 2011, 05:23:25 pm
Hi! Tried on my system, with the glsl pack (re-attached here renamed as z_glsl.pk3, but it's the same zip file of Hitch's previous post).
Now, r_postprocess edges WORKS!!!!  :)
r_postprocess egafilter: I don't know what to look at.  ::)
r_postprocess <random string, to test what happens specifying a non-existing glsl program>: nothing happens.  :)
r_postprocess color1: glsl program finds an error (maybe a syntax error) and OA crashes on vid_restart (even if I'm using executables 26).  :RIP: (Log file attached)

Bye!


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 15, 2011, 02:13:34 am
An idea: if would be nice to have the console autocomplete feature to list possible values for "r_postprocess".
Sago, Fromhell... do you think it would be possible?


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 15, 2011, 03:42:45 am
no because that would show a lot of invalid programs

we're trying to get 088 out here, not more featurecreep


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 16, 2011, 04:02:17 am
Okay, then.
Another question (Fromhell please do not get angry with me, I'm simply trying to say an idea to optimize times): considering that Hitchhiker will not be able to work on glsl before next week, and that it is a thing that is important (other than fixing that "color1" program -who knows if other glsl programs are bugged, too?-, making the game not crash if a glsl program fails compiling is important)... the release is then delayed of some more days.... what about using this time to take another look into the bloom bug with 16 bit textures? The workaround used in v25-26 executables (totally disabling bloom unless user forces 32bit textures) is a quite "rude" one...


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 16, 2011, 04:06:50 am
bloom was never intended to be used in 16-bit color because 16bpp doesn't have the appropriate texture format for it. It will never be done. It is unfixable.
besides, on modern hardware (like any HD Radeon or GF8+), you shouldn't even play in 16-bit color because the dithering feature is gone, and it's not faster in 16bpp... and if you HAVE to play in 16bpp, chances are your hardware doesn't even work well with bloom anyway


by the way, i'm not going to wait for the r_postprocess crash fix. I could release 088 before then. I wouldn't even be packing the color1/2 shaders anyway.

I'm already angry with you because I had to hold off 088 longer than I would have wanted. It's possible the schedule slip might end up into NEXT YEAR if this is kept up. ugh.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 16, 2011, 05:19:03 am
I'm sorry for annoying you, I can assure it's not my goal, but it's only a side effect of testing.

Anyway, I entered into GLSL stuff only recently... up to few days ago, I had not even understood what GLSL is (http://openarena.ws/board/index.php?topic=4314.msg40334#msg40334). I had no interest on it until when you placed this new feature into the executables, and someone (maybe Sago) started saying that it could cause compatibilty problems... and then I started doing some tests with it, and discovered it may easily crash the game, a thing that would be better to avoid, IMHO. I don't even know what many of those glsl programs in the patch are supposed to do, or which of them you will include and which not....

PS: I don't think it's a problem to do not have bloom in case of really 16 bit textures; the problem with version 25-26 bloom is that (apart the bugged cascade bloom which is enabled by default), even if 99% people uses 32bit color depth in their OS, and keeping "default" enables 32 bit textures in that case (if I correctly understood), that "default" causes OA to forcedly disable bloom anyway (because you said the engine at that moment does not know what is the system color depth, or something similar...), and the error message shown in console is not clear enough to make people understand they have to force 32bit textures in order to use bloom.


Title: Re: Binaries for 0.8.x test thread
Post by: Peter Silie on December 16, 2011, 10:25:36 am
Don´t be angry with him.
Look: we now even have the mac version up!
It will be a nice x-mas gift this year :D

maybe next release on easter? ;D


Title: Re: Binaries for 0.8.x test thread
Post by: WaspKiller on December 17, 2011, 02:10:02 pm
-26:
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-26.zip
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-26.tar.bz2

Works on 0.8.5 for me even with r_ext_vertex_shader on.

I forgot r_bloom_cascade default to 0


Sago,

Testing this today on my FragFest Server (http://oa.goquake.com/?page_id=1034).  Just noticed that there is no oa_ded.exe file.  However, I assume oa_ded.x86.exe is a drop-in replacement.  I also assume it is safe to go ahead and remove oa_ded.exe.

My question is why the name change?  I know ioq3 has supported 64bit for some time but there is no oa_ded.x64.exe file in the package and I assume there won't be a 64bit version for Windows until OA 3.0.


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on December 17, 2011, 03:39:57 pm
The compile script have always included the architecture in the filename. I usually removed it while packing it. Currently I have a script that automatically creates the package without renaming it.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 18, 2011, 05:47:45 am
-26:
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-26.zip
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-26.tar.bz2
Works on 0.8.5 for me even with r_ext_vertex_shader on.
Maybe I forgot to say that also for me 0.8.5 does not crash with executables version26 and r_ext_vertex_shader 1. And if I set r_postprocess edges, it's okay, obviosly it does not work and a console line says it cannot find the "edges" glsl program. Okay.
It seems the only glsl fix still needed for executables is to intercept the case of errors in glsl programs and stop their execution without crashing the game (still writing something in console, if possible).

Sago, what do you suggest about the 16 bit Bloom thing (http://openarena.ws/board/index.php?topic=1933.msg41885#msg41885)?


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 18, 2011, 06:57:34 pm
I hope to get it out this week. There's a big storm brewing. If it's not out this week then it's not out this year.


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on December 20, 2011, 12:15:42 pm
Sago, what do you suggest about the 16 bit Bloom thing (http://openarena.ws/board/index.php?topic=1933.msg41885#msg41885)?
I always use 32 bit. Considering the memory requirements of bloom I don't see any need for it. Personally I don't like postprocessing effects that affects a large portion of the screen. Personally I think moderation is the key, effects loose meaning if overused. 


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 20, 2011, 12:22:45 pm
Well, the question was not if bloom is nice or useful or not (e.g. I often leave it off, but that's not the point)... the question was about the current behavior that one has to manually force 32 bit textures in order to use bloom, because leaving "default" for that setting now disables bloom and the message shown in console is not clear enough to inform the user of what he is supposed to do to really enable bloom....


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on December 20, 2011, 12:26:52 pm
My answer is still the same.

I don't believe I can speak about a function I don't understand.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 20, 2011, 03:09:40 pm
Okay.... suggestions from someone else, then?

PS: Hitchhiker, are you still there? When do you think you will be able to take a look to the glsl code?


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 21, 2011, 04:07:16 am
still around :)
I am at my bro´s place for next 10 days and he has an ATI card in his comp! So for me its downloading the source and having a look, testing... I am hoping to send some info and a fix by end of week..


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 23, 2011, 09:07:37 am
Okay. While we are waiting for Hitchhiker's new patch...

Jackoverful and other Mac testers, are you happy with the Mac version executables? Is everything ok?

PS: does someone want to say an opinion about the bloom question? Please...
FH, what would be the problem with, at least, making the error message clearer if one tries bloom without forcing 32 bit textures?


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 23, 2011, 09:19:34 am
Jackoverful and other Mac testers, are you happy with the Mac version executables? Is everything ok?
As happy as I can be not playing…Launched it a couple of times, it works, networking works, voip seems ok, but I basically don't have time to play these days.


Title: Re: Binaries for 0.8.x test thread
Post by: Peter Silie on December 23, 2011, 11:35:32 am
Win seems fine, Linux seems fine and Mac also.
So no more changes - make the release imho.


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on December 23, 2011, 12:24:34 pm
Win seems fine, Linux seems fine and Mac also.
So no more changes - make the release imho.
Agreed.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 23, 2011, 05:12:42 pm
yeah i've been waiting for days for a new winlinmac build with the bloom cascade default to 0

I should mention the winter storm missed.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 23, 2011, 06:07:41 pm
Win seems fine, Linux seems fine and Mac also.
So no more changes - make the release imho.

Well, to be precise, there are still the glsl crashing the game (Hitch said he should fix it in these days, but I'm not him so I cannot say the exact date! -he mentioned "the end of the week", so I hope sunday evening we may have the fix-), and the question about bloom that I don't know why nobody posts his opinion (despite it being quite annoying, with the feature auto-disabled unless the user does a simple but non-intuitive tweaking).


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on December 24, 2011, 07:44:10 am
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-27.zip
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-27.tar.bz2

Now includes jackoverfull's Mac-files and r_bloom_cascaded defaults to 0.


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 24, 2011, 08:12:19 am
building…


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 24, 2011, 08:21:12 am
Now includes jackoverfull's Mac-files
not all of them: vm_powerpc_asm.c is still unmodified.

I've upped the modified one with the binary for 26, here: http://www.jackoverfull.com/tmp/OAMac088r26.zip


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on December 24, 2011, 08:25:09 am
vm_powerpc_asm.c is still unmodified.
Oh, I just placed it in the root folder with the two other files.


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 24, 2011, 08:27:19 am
vm_powerpc_asm.c is still unmodified.
Oh, I just placed it in the root folder with the two other files.
Right, didn't notice it…

It should go in code/qcommon, tough.


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 24, 2011, 08:33:41 am
Here we go: http://www.jackoverfull.com/tmp/OAMac088r27.zip

Feel free to unpack it and change the name to OpenArena.app if your going to ship the release with this build (the .app folder should be placed in the same folder containing baseoa, as if it was itself an executable), as long you're doing it on Linux. There shouldn't be problems with windows as well, but I'm not going to bet on that.


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on December 24, 2011, 08:52:24 am
Now this is pressure releasing. :D


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 24, 2011, 09:07:17 am
Hitch, I understand it's Christmas and all of us are very busy with real life... but please be quick with the glsl crash fix... because it seems they do not want to wait longer for 088 release.... Gasp!

Fromhell, what would be the problem with printing a red or yellow "Bloom requires 32 bit quality textures. Effect disabled. Please set r_texturebits 32 before enabling bloom." (or similar) console message when it auto-shutdowns bloom?


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 24, 2011, 09:28:00 am
that fix is simple - not including those crashy glsl files you tested on. Who said they were going to be included in 088? not me. I'd only include the ones with the GPL headers for the basic, Free glsl support.

i'm not changing that bloom message


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 24, 2011, 10:11:10 am
About glsl: but then, what's the purpose of putting in a feature that would do nothing? The problem is not the single glsl program with errors (we can live happy also without it), it's the engine crashing if it cannot complie one of them! If I understood correctly, the alternative to creating glsl programs and using them via r_postprocess variable, is to somehow incorporate them directly inside shaders/maps? In that case, a single future shader/map may crash the game as well (well, maps can already crash the game in other ways, it's true), I suppose. Anyway, do as you think it's the right thing. IMHO, I'd prefer one or two more days and a fix... but it's your choice.

About (not) adding a new error message: is there some reason for your decision about it? I don't realize it. :-\ I can understood things as far as there is some reason explained. In this case, I'm really confused of why it would be so <difficult?/impractical?/fool?> to help users understand how to enable bloom. Of course, I will explain on the wiki what to do, but you know it's not a real solution: probably people will repeatedly ask here on the forum "why does bloom not work anymore?" instead of searching info on the wiki. The reason I focused with asking a "stable" bloom in the last month (ps: sorry for being annoying) it to help new players to have a good impression with the game.


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on December 24, 2011, 10:20:08 am
Now with vm_powerpc_asm.c in the correct place:
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-27b.tar.bz2

No new binaries because none of the released files are powerpc related.


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 24, 2011, 10:39:34 am
hi
ill try to post few modifications by tomorrow.
the errors Gig reported are, as far I can see, due to ATI cards being less forgiving than nVidia when glsl program is made so any future glsl program will have to be tested on different cards before it is placed in public version of OA. So far the errors that caused crashes were due to missing or incorrect glsl programs - not to the implementation of the glsl support. (sure, a better error handling can be done)
0.88 can have the support - it should not interfere with the engine..
Having glsl support in this version of OA should provide a working ground for the next release that will hopefully have models or maps use the feature.
0.88 can also be released as-is as anyone who is going to use glsl programs when creating game contents could get the latest binaries from the svn.



Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 24, 2011, 01:28:35 pm
a quick fix for the crashing is here attached. I changed the level of notification from ERROR to WARNING. Now when a glsl program is in error, a warning is printed to the log and execution continues.
A shading stage that has glsl keywords, that would specify a glsl program that fails compilation is now drawn using standard rendering pipeline. Hope this is OK like this?

edit: please dont use this file just yet.. i've checked different maps after posting and seems the tr_shader.c I've posted is not what I thought..


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 24, 2011, 02:11:37 pm
and execution continues.
Execution of game engine (ignoring/disabling the glsl program that caused the error, in practice using standard rendering) or of the glsl program after the error (continuing execution from the code line below the one that caused the error, with unpredictable results)?


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 24, 2011, 03:43:16 pm
hi,
my above edit was false alert as it seems.. after re-downloading OA and trying with original pk3 files it works well for me..

what happens in engine now is that if the glsl program fails to compile the shader stage is marked as non-glsl and is drawn using standard rendering (same as it was from beginning).
What was causing the crashes was the engine notifying about the glsl compilation error with ERROR command which stops the engine (it is an expected behavior). If a glsl program fails to compile it is not really a stopping issue. So one change I did was to change from ERROR to WARNING - now even if glsl program fails to compile the execution will continue. This is at loading time.
The second change is that the shader parsing will not stop, if glsl program fails, and the engine will be able to finish parsing the shader. So if the shader contains any non-glsl commands they will be parsed and drawing of the shaded surface will happen as if glsl keywords were not there.
A glsl program that fails compilation should never be called. I've added an extra check and the new files are here attached.


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 24, 2011, 09:54:05 pm
^!!!!^!!!!!!!!!!!^!!!!!!!!!!!!!!!!!!!

Yeah, that added and it should be the last engine build for 088 ever now. We won't make the 25th release though, i'll be busy

Merry xmas!!!


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 25, 2011, 03:12:53 am
Merry Christmas to everybody!!!
Yoo-oh-oh! (Santa's laughing) :) :) :)
Best wishes for happy life to everyone!

Fromhell, I don't know if you will include some of those glsl programs in the release, but I'd suggest to include at least one of them (maybe one easily recognizable, like "edges"?), to allow people to test if glsl works with their card.

PS: My friend, sorry for insisting, but I still don't understand the reason for not adding a new warning message in console, for bloom. I'd prefer avoiding people repeatedly reporting "bloom not working" on the forum... don't you think so?

PPS: I haven't checked yet if some of those glsl programs include GPL info and others not. I thought they were written by Hitch himself purposedly for OpenArena... maybe it's not so...

PPPS: Thank you again to everyone who collaborates with the project... and to Hitch, that worked on Christmas night!


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on December 25, 2011, 04:47:26 am
-28 with the Hitchhiker-files:
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-28.zip
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-28.tar.bz2


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 25, 2011, 04:57:43 am
-28 with the Hitchhiker-files:
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-28.zip
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-28.tar.bz2
Building…Now or when I'm back, tomorrow.


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on December 25, 2011, 06:30:15 am
A cake for Sago and another one for Jack were delivered.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 25, 2011, 06:45:16 am
... and one for Hitch (although I will not be able to test his fix today. I'm writing from phone).


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 25, 2011, 09:30:14 am
Writing from the phone as well...

Left a mac building, if all it's fine i'll upload the bin in a few hours.


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 25, 2011, 11:05:58 am
Everything all right. :)

http://www.jackoverfull.com/tmp/OAMac088r28.zip


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 25, 2011, 06:13:09 pm
Good. I hope to do a rapid test with windows binaries next morning... Now going to sleep... Zzzz...


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 26, 2011, 04:33:53 am
 :) :) :) Okay, given a quick try on windows. R_postprocess "color1" does not crash the game anymore, it gives a warning in console (even if it seems it needs a carriage return at the end of that line).

Quote
glsl programs: enabled
Initializing Programs
Error:
Fragment shader failed to compile with the following errors:
ERROR: 0:16: 'char' : undeclared identifier
ERROR: 0:16: 'r' : syntax error parse error
ERROR:  compilation errors.  No code generated.

Couldn't compile fragment shader for program postprocessInitializing Shaders
----- finished R_Init -----
Loading vm file vm/ui.qvm...
it needs a new line before "Initializing Shaders"... But this is not urgent, it can be done also after the 088 release (fixing it before would be "nice", anyway).

UPDATE: I noticed another thing: considering that in future glsl will be included directly in shaders used in maps (instead of r_postprocess)... now the error message does not mention the name of the glsl program in error (you have to set developer 1 and read the line before the error to know the name of the glsl program it was loading -e.g. consider also the case of reading someone else logs, without knowing his r_postprocess value-)... maybe the error may mention the glsl program? Of course, now there are no maps with glsl-integrating shaders, so I don't know at all how the engine would do and what the console would write in case of errors in such shaders.

The only question I still have is that I don't understand the reason for not adding a specific message to tell users to set 32 bit textures before enabling bloom.

UPDATE: Question for Hitchhiker: are those glsl programs in z_glsl.pk3 (http://openarena.ws/board/index.php?topic=1933.msg41868#msg41868) released under GPLv2 or not?


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on December 26, 2011, 01:29:34 pm
The only question I still have is that I don't understand the reason for not adding a specific message to tell users to set 32 bit textures before enabling bloom.
Code freeze. Only major problems will be fixed. I might add a message in the gamecode soon. I might even do it before 0.8.8 is released but I won't backport it into 0.8.8.

Fixing small problems are very problematic because:
1) It results in badly designed solutions
2) It often introduces bigger problems


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 26, 2011, 01:36:25 pm
Are you thinking about a status line message when "mouseovering" on the bloom option in menu? I thought to it, too, but feared it may not get in 088, and thought that, being the bloom behavior more related to engine than gamecode, it best fitted in the engine. Anyway, it's okay also there. The problem is that not having it in 088 neither in engine or gamecode would be not good. :(
Another similar message that would be useful is that the "crosshair shows health" option causes the custom crosshair colors to be ignored.

And probably we may add descriptions to other menu options, to make them clearer to the user... but this is not the right thread for them. If you want to look deeper into this thing, I'm available. :)


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on December 27, 2011, 05:12:31 am
Everything all right. :)

404!


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on December 27, 2011, 05:25:54 am
Sorry about that, misnamed file. Now's working, same link: http://www.jackoverfull.com/tmp/OAMac088r28.zip


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 27, 2011, 08:29:28 am
:) :) :) Okay, given a quick try on windows. R_postprocess "color1" does not crash the game anymore, it gives a warning in console (even if it seems it needs a carriage return at the end of that line).

Quote
glsl programs: enabled
Initializing Programs
Error:
Fragment shader failed to compile with the following errors:
ERROR: 0:16: 'char' : undeclared identifier
ERROR: 0:16: 'r' : syntax error parse error
ERROR:  compilation errors.  No code generated.

Couldn't compile fragment shader for program postprocessInitializing Shaders
----- finished R_Init -----
Loading vm file vm/ui.qvm...
it needs a new line before "Initializing Shaders"... But this is not urgent, it can be done also after the 088 release (fixing it before would be "nice", anyway).

UPDATE: I noticed another thing: considering that in future glsl will be included directly in shaders used in maps (instead of r_postprocess)... now the error message does not mention the name of the glsl program in error (you have to set developer 1 and read the line before the error to know the name of the glsl program it was loading -e.g. consider also the case of reading someone else logs, without knowing his r_postprocess value-)... maybe the error may mention the glsl program? Of course, now there are no maps with glsl-integrating shaders, so I don't know at all how the engine would do and what the console would write in case of errors in such shaders.

The only question I still have is that I don't understand the reason for not adding a specific message to tell users to set 32 bit textures before enabling bloom.

UPDATE: Question for Hitchhiker: are those glsl programs in z_glsl.pk3 (http://openarena.ws/board/index.php?topic=1933.msg41868#msg41868) released under GPLv2 or not?

hi, the color1 program that works on ATI cards is here attached.

for error messages, will add it in near future.

for license for glsl programs, I've often started from a existing snippet of code found on the net and worked with that - dont know if that is no-no is GPL world? None of the programs is a copy-paste solution (except the glsl programs that are no longer used by OA and that come from ZEQ2 lite, that might still be part of the glsl folder). Anything that might be done by me for OA is under GPL license.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on December 27, 2011, 04:56:01 pm
Attached, your file, re-packaged as a working pk3.

I've finally seen what that "color1" does: it's a sort of almost-greyscale, but with some details that are still colored (pink mostly). A nice effect, even if probably not extremely useful...

PS: tested some other effects from the previous file (http://openarena.ws/board/index.php?topic=1933.msg41868#msg41868): "color2" does not compile. "Bump" makes the screen black, and "banner" makes the screen like a plaid (http://en.wikipedia.org/wiki/Full_plaid)... :-\


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on December 28, 2011, 08:23:47 am
:)
bump and banner can be used on objects in the game (again, the shader that defines the textures used to texture an object would need to be modified to use these programs - at the moment no shaders use these) - they are not postprocessing effects.
color2 will not compile as it needs updating - if color1 works on nVidia (I think it should)..
these are just example postprocessing programs.. I dont know how many tests they had so far - to have more input on how usefull they are and if they should be included (I think fromhell said they would not make it to the release version anyways).
The glsl support has just been implemented so, in 0.8.8, it can have only a limited number of useful things it can do. I saw a part of the engine source that defines the in-game menus where gfx options are choosen - eventually, if possible to modify that part, for the next release I could try adding an option there to choose the postprocessing programs by simply clicking.
Thanks for testing!


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on January 08, 2012, 05:03:35 pm
HI, Hitch! I was curious to know if you had the time to fix that error messages (using line feed when needed, specifying the name of the glsl program that caused the error)...

For Fromhell and Sago (I hope to do not trigger an angry answer!)... are you still sure you do not want 0.8.8 to inform users about the relationship between bloom and 32bit textures?


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on January 08, 2012, 05:06:46 pm
I'm curious too: any news about a possible release date?


Title: Re: Binaries for 0.8.x test thread
Post by: fromhell on January 08, 2012, 06:04:29 pm
I wish I could set a concrete date. I think "ASAP" is my only date right now, as i'm waiting for NeonKnight's fixpacks. Then i'd make an RC3 for any last minute reports

The mapper perfectionism is delaying 088 too much!


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on January 08, 2012, 06:15:03 pm
I don't have much to do, anyway.
Just place music and map intro, but 0.8.8 can be released without them, anyway.


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on January 09, 2012, 06:05:15 am
I see, thanks. :)


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on January 09, 2012, 12:22:01 pm
HI, Hitch! I was curious to know if you had the time to fix that error messages (using line feed when needed, specifying the name of the glsl program that caused the error)...


this one has a line break at error line mentioning program that failed compilation.. (modifications: file taken from v28 and added line breaks)


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on January 10, 2012, 05:47:10 am
Thank you. Who knows if Sago will build updated executables with it before 0.8.8...

PS, another curiosity: I noticed a patch you posted on the other thread, on 29 november (http://openarena.ws/board/index.php?topic=4314.msg41513#msg41513), but that has been download 0 times. Was it important? Is it obsolete?


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on January 10, 2012, 05:54:14 am
Gig, this is not a wiki. :D


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on January 10, 2012, 07:21:20 am
Ooops! :) Link markup fixed.


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on January 10, 2012, 01:02:06 pm
Thank you. Who knows if Sago will build updated executables with it before 0.8.8...

PS, another curiosity: I noticed a patch you posted on the other thread, on 29 november (http://openarena.ws/board/index.php?topic=4314.msg41513#msg41513), but that has been download 0 times. Was it important? Is it obsolete?

that was a developer workaround to permit having glsl programs on OS filesystem.. not needed

I don't think the changes I last did (adding a line feed) is something that would need to cause 0.8.8 to be rebuilt -  maybe just include it in the next release?


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on February 07, 2012, 11:05:33 am
For Mac users.... please take a look: http://openarena.ws/board/index.php?topic=4433.msg42915#msg42915


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on February 07, 2012, 02:38:19 pm
I didn't even know that existed… ::)

Please PM me in this occasions or just post in a topic I've taken part in, I may not have time to play or to actively follow the forum but for a quick test i can save half an hour now and then.

Trying in a few minutes…


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on February 09, 2012, 05:02:55 pm
Sorry guys, do you know which is the latest ioquake3 engine version integrated in OA binaries?

Wikia user "r9k" told me DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Talk:Manual/Using_Mods#Notes_for_server_admins]here (http://([b) that ioquake3 added sv_dlrate variable to allow higher downloads speeds for the UDP download (it is also mentioned in updated ioquake3 readme (http://svn.icculus.org/*checkout*/quake3/trunk/README)). He told it is in ioquake3 since r2073, 12.07.2011...
I tried in OA version 28 binaries, and that variable seems to do not exist... does someone know something about this?


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on February 21, 2012, 11:29:49 am
In another thread Sago said that he tried to include that ''sv_dlrate'' system in OpenArena, but he did not succeed. I hope this may happen in future (it would be very useful), but of course I'm not capable to help in this thing.

Talking about binaries, an user reported here:
http://openarena.ws/board/index.php?topic=4446.msg43323#msg43323
crashes with 0.8.8 Mac executables...


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on June 16, 2012, 04:30:57 am
I took the source from https://github.com/undeadzy/openarena_engine discussed in another thread.

http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-30.zip
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-30.tar.bz2

It also includes patch for CVE-2012-3345 (http://seclists.org/oss-sec/2012/q2/511). A local attack affecting Linux and Mac on systems with multiple users. 

It is compiled with out the dynamically loaded renderer. I do want to use the the dynamically loaded renderer but I want to know what files to include in my packing script.


Title: Re: Binaries for 0.8.x test thread
Post by: jackoverfull on June 16, 2012, 04:33:18 am
Do you need a Mac OS X build?


Title: Re: Binaries for 0.8.x test thread
Post by: ostar2 on June 23, 2012, 06:36:14 pm
Is possible open arena will ever use quake 4? ???


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on June 23, 2012, 09:36:14 pm
DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/NOTTODO]No. (http://([b)


Title: Re: Binaries for 0.8.x test thread
Post by: smcv on August 15, 2012, 08:27:47 am
It is compiled with out the dynamically loaded renderer. I do want to use the the dynamically loaded renderer but I want to know what files to include in my packing script.

Unpatched ioquake3 loads renderer_${cl_renderer}_${CPU}.so, where cl_renderer defaults to "opengl1". So as a minimum you need renderer_opengl1_${CPU}.so, or whatever corresponds to the new default for cl_renderer if it's been patched.

Unpatched ioquake3 also has an "opengl1_smp" renderer, which isn't used by default. It corresponds to the old ioquake3-smp executable, which isn't compiled any more if you use dynamically-loaded renderers.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on September 25, 2012, 06:45:05 am
I took the source from https://github.com/undeadzy/openarena_engine discussed in another thread.

http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-bin-0.8.x-30.zip
http://files.poulsander.com/~poul19/public_files/oa/dev081/openarena-engine-source-0.8.x-30.tar.bz2

It also includes patch for CVE-2012-3345 (http://seclists.org/oss-sec/2012/q2/511). A local attack affecting Linux and Mac on systems with multiple users.  

It is compiled with out the dynamically loaded renderer. I do want to use the the dynamically loaded renderer but I want to know what files to include in my packing script.

Maybe I forgot to test this in June (I had many things to do at that time! Not that now I have a lot of time, but...).
What changes should it contain against 0.8.8 binaries (version 28, right?)? What should I test?


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on September 25, 2012, 10:43:00 am
What changes should it contain against 0.8.8 binaries (version 28, right?)? What should I test?
There isn't much new functionality. The new version was mainly released to include the security fix for the local exploit present in 0.8.8.

Because this goes back to use STANDALONE variable it is also a good idea to test that mods load correctly (this was earlier a problem with the STANDALONE variable and the reason OA did not use it until now). I have loaded ReactionQuake and WasternQuake in Linux so the problems appears to be fixed.  

Testing that network compatibility still works is the most important (this has failed before).


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on September 26, 2012, 01:51:22 am
Tried Target Quake Arena and Alternate Fire mods, they work.
Also tried Target Quake from dedicated server mode, connected from a client (from the same computer), and works.
OS: Windows XP.

Someone should try with a "real" dedicated 2 server...


Title: Yawspeed
Post by: Gig on October 01, 2012, 04:14:25 am
A thing I noticed with the new (v30) binaries.

Do you remember about cl_yawspeed and cl_pitchspeed (turning around using keyboard)?
http://openarena.ws/board/index.php?topic=4466.0
They were hard-coded to their default value (140) in official 0.8.5 and 0.8.8 binaries (as some sort of anti-abuse protection). You were able to change them to any value you liked, but the game continued to work as if they were set to 140. It has been pointed out that was a strange behavior, that may confuse users.

In the new test binaries, you are not allowed to change their values anymore. They do not appear as "cheat-protected" (even in devmap mode, you cannot change them), but as "read only". You cannot change them when playing, or when playing demo, or from main menu, or from devmap mode....
The problem is... if you change them form 0.8.8 binaries (e.g. set them to 500), then launch v30 binaries, it keeps the "500" value, uses it, and prevents you from changing it again.
Well, changing their values from old binaries is not the only way to "workaround" the lock... you can change them also simply text-editing your q3config.cfg file, or starting openarena with "openarena.exe +set cl_yawspeed 500".
In other words, the new lock is not good enough yet.
I can imagine that the old kind of lock (unelegant) was done to be not "workaroundable" in any way (unless using unofficial binaries). However, I suppose it should be possible to prevent abuse also using the "elegant" lock in some way (maybe resetting to the default value on program start/match start? Or making the variable as cheat-protected? I don't know...)...

I don't know if you thought about a way to let server admins to decide if their players would be allowed to customize such variables or not (it was one of Corvette's thoughts) or allowing some ranges of freedom... e.g. using "dmflags" or "videoflags" (ehm.. its not "video"... maybe the old name "fairflags" would have been better for that)...

Another thing: strangely enough, if you type /cl_pitchspeed ENTER, it says its current value only, and it doesn't say ", default value is 140"! I don't know the reason of this (maybe because, being a read-only variable, it thinks it may never be changed? Wrong!), but hope it may be fixed and the default value being mentioned.


Title: Re: Binaries for 0.8.x test thread
Post by: grey matter on October 03, 2012, 03:05:08 am
Code: (qcommon/cvar.c)
void Cvar_Register(vmCvar_t *vmCvar, const char *varName, const char *defaultValue, int flags)
{
cvar_t *cv;

// There is code in Cvar_Get to prevent CVAR_ROM cvars being changed by the
// user. In other words CVAR_ARCHIVE and CVAR_ROM are mutually exclusive
// flags. Unfortunately some historical game code (including single player
// baseq3) sets both flags. We unset CVAR_ROM for such cvars.
if ((flags & (CVAR_ARCHIVE | CVAR_ROM)) == (CVAR_ARCHIVE | CVAR_ROM)) {
Com_DPrintf( S_COLOR_YELLOW "WARNING: Unsetting CVAR_ROM cvar '%s', "
"since it is also CVAR_ARCHIVE\n", varName );
flags &= ~CVAR_ROM;
}

In other words, variables that are declared to be read-only AND should be saved/loaded to/from config files are silently made writeable (you'll see the WARNING in console with "set developer 1").
This is a sane approach, since the read-only value is a constant that must be present in the binary anyways, so there's no need to use a config for those at all.


Title: Re: Binaries for 0.8.x test thread
Post by: sago007 on October 03, 2012, 01:22:42 pm
I think the problem is that Cvar_Get does not use the new meaning of CVAR_ROM and therefore reads the value from config anyway like before.

To me it sounds like Cvar_Get should be updated to understand the new CVAR_ROM. I wonder how much that would break in the engine.


Title: Re: Binaries for 0.8.x test thread
Post by: hairball on October 03, 2012, 07:45:06 pm
Should cl_yawspeed and cl_pitchspeed simply be set as CVAR_CHEAT rather than CVAR_ROM?

The #define for CVAR_ROM makes it sound like it is more protective than it really is:

Code:
#define CVAR_ROM                0x0040  // display only, cannot be set by user at all

In practice, a CVAR_ROM without any other flags appears to work as Gig mentioned.  It shouldn't be used for protecting against modifications.  I looked at some of the other uses of CVAR_ROM and it turns up in com_standalone etc.  That makes sense: you want the user to be able to set com_standalone at startup but it's a global setting that should never be able to alter without restarting.  The comment and name CVAR_ROM is a misnomer.

I think using CVAR_CHEAT would be sufficient.  What do you guys think?  This was one of the things I mentioned in the README.md.  It felt wrong with the 0.8.8 code removing the variable entirely and using a value.  I think CVAR_ROM was the wrong choice.  CVAR_CHEAT could be the correct setting.


Title: Re: Binaries for 0.8.x test thread
Post by: Gig on October 03, 2012, 11:44:24 pm
Reading what grey matter wrote, it seems the program would completely disable the "read only" part in that case (making it a standard stored variable, one may guess), but it does not look like exactly like that, because it is still "read only" from inside the game.
Are we sure now it has got both archive and rom attributes? Hairball says, however, that a cvar with the rom attribute only works like that variable now... so also without the archive flag, would it be loaded from q3config.cfg anyway? Or only from OS command line?

As hairball suggests, maybe we may try to make it "cheat protected" instead. In that case, what would happen? Would it be changeable from devmap mode? Would it be automatically restored to its default, when later playing in standard mode?

By the way, I'd like to understand better what are the abuses that caused them to be considered cheating. Someone in the thread I linked in the post above mentioned something like a 180 degree turn or spin? What did he mean exactly? Are we sure it is necessary to completely lock these settings, or maybe we could accept a range of "sane" values (e.g. between 100 and 200  -just an example-... if you set it lower or higher than that, it will be automatically reverted to 140... maybe with an "out of range" or similar warning to the user)?


Title: Re: Binaries for 0.8.x test thread
Post by: hairball on October 21, 2012, 10:34:04 am
Reading what grey matter wrote, it seems the program would completely disable the "read only" part in that case (making it a standard stored variable, one may guess), but it does not look like exactly like that, because it is still "read only" from inside the game.

Based on what grey matter posted, the current value is a mistake and it should be changed.

As hairball suggests, maybe we may try to make it "cheat protected" instead. In that case, what would happen? Would it be changeable from devmap mode? Would it be automatically restored to its default, when later playing in standard mode?

 I have since changed it to CVAR_CHEAT in git and it works as intended in my testing.  It works like any other CVAR_CHEAT in that you can only change it if cheats are enabled.

Code:
code/qcommon/q_shared.h:897:#define CVAR_CHEAT          0x0200  // can not be changed if cheats are disabled


Title: Re: Binaries for 0.8.x test thread
Post by: GrosBedo on March 12, 2013, 04:03:38 pm
Someone should try with a "real" dedicated 2 server...

I have run a few dedicated 2 servers running both vanilla OA, Excessive+ server-side, AfterShock and Defrag since the first release of undeadzy, and everything seems to run smoothly.

I have currently a few servers online that I relaunched since about a month, running the latest undeadzy's release, plus a few new commits from ioquake3 and server-side demos patch:
https://github.com/lrq3000/openarena_engine_serversidedemos/tree/latestwithtell

Everything is fine for now. I'll keep you updated if I notice a problem.


Title: Re: Binaries for 0.8.x test thread
Post by: GrosBedo on March 13, 2013, 02:40:22 pm
About the vars problem, I had the same problem with the sv_demoClients variable I used for my server-sideo demos patch.

What I did to fix that was to forcefully set the value at engine start:
Code:
Cvar_SetValue("sv_democlients", 0);

Also it was set as CVAR_ROM.

Another thing to note: there are hacks for Quake 3 Arena which can set a variable even if it is cheat protected.


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on February 01, 2014, 10:29:50 am
which is the latest version of the source? If I start adding my changes to the oa renderer, can I use the file 'openarena-engine-source-0.8.x-30.tar.bz2' (link here above by sago007) or I need to go through the SVN?
Cheers


Title: Re: Binaries for 0.8.x test thread
Post by: Neon_Knight on February 01, 2014, 10:38:01 am
Well, the latest version of the source, regarding binaries, seems to be 0.8.x-30.


Title: Re: Binaries for 0.8.x test thread
Post by: Hitchhiker on February 05, 2014, 03:45:25 pm
Thanks Neon_Knight!