OpenArena Message Boards

There are now nightly Windows build available here: http://files.poulsander.com/~poul19/public_files/oa/dev088/engine_windows_nightly/

As of now (2016-07-17) they are without xmp-support as I have not been able to link it successfully yet and it is not part of MXE.

The build is performed using this Docker image: https://hub.docker.com/r/sago007/docker_mxe_openarena_engine_builder/

The build use MXE (http://mxe.cc/) for building the binary. You may ask: Why MXE?
The reason is that building a maintainable Windows compile environment would be a waste of my time then one already exists. Unfortunately the current Makefile does assume that it has to do all the work and therefore partly gets in the way.
In the old days I compiled vorbis etc and placed the binary into the repository but now someone have already compiled vorbis and the like. No reason to do the same thing twice.

What about a Linux build?
On Linux it is easy to compile it yourself (no Windows compile hell). Just remember to check that the branch you are interested in actually compiles: https://travis-ci.org/OpenArena/engine/branches

This is great news, Sago, thank you!

I should really get those shaders in renderer_oa/glsl built into the code to make these nightlies even more practical for 088 use somehow, especially brightness_fp/vp since that solves the "TO DARK" issue (which is really more of a linux problem but still)

I have already discovered the first bug, just by opening the game from the opengl1 and software executables:

Not a bug. opengl1 is outdated. software isn't even software rendered yet and should be completely disregarded, and building .opengl1.exe and .software.exe should really be disabled as they'll only serve to confuse

Excuse me, which one is the executable I should consider "good" in that package (http://files.poulsander.com/~poul19/public_files/oa/dev088/engine_windows_nightly/openarena_engine_windows_2016-07-09_aea5478119e3e6e27107587ab3089c250194353d.zip), then?

To me:
- OpenArena.x86.exe (which from Fromhell's words seems the "right" one) shows the logo "compressed" (as in NK's second screenshot)
- OpenArena_opengl1.x86.exe (which from Fromhell's words is "outdated") shows the logo "correctly" (as in NK's first screenshot)
- OpenArena_software.x86.exe (which from Fromhell's words seems "unfinished") shows the logo "compressed" (as in NK's second screenshot).

Sorry for insisting, but we have to know which is the binaries version we have to test.

And if it is openarena.x86.exe, as problable, then those binaries have actally got some kind of problem with the shader/model of the title screen.

A fix for the above concerns is committed, a nighlty build should be available shortly

Tested version 2016-08-20.
It looks like the problem has been fixed, thank you!

However, I'm not able to get r_slowness (the feature to simulate how the map would work on older hardware) working...
I have r_slowness_cpu 300, r_slowness_gpu 96 (but I tried also with lower values), but setting r_slowness 1 does not seem to have any effect. Am I missing something?

It should be 4.  Yes, 4. Also, this only works on Windows at the moment, since it spams a win32 sleep function.

Okay, it works now. Thank you.

PS: I can guess values from 1 to 3 were for differents methods you tried to achieve it, and which did not work...

Sago, do you plan to make also 64bit executables?

From the littIe I know about the topic, 64bit binaries run faster than 32 bit ones (due to having more registers available and assuming SSE2 optimizations at least), at the cost of using more RAM (due to having to store "longer" addresses).
However, I imagine the amount of RAM used by OpenArena shouldn't be excessive for todays PCs. The only thing that comes in my mind which may be a problem could MAYBE be some built-in ram usage limits (e.g. some memory allocation cvars default values)? What do you think?

Thinking again about it, another problem for 64bit binaries could be third party DLLs (e.g. openal)...

I did not originally believe that a 64 bit executable Windows version was worth it. Even if the 64 bit version is slightly faster there are no 64 bit system that would not be able to run the 32 bit version at full speed. My main concern was people not understanding the different binaries and not understanding why the 64-bit exe did not run on a 32-bit machine.

Supporting an architecture can take a lot of resources. Compiling a 32-bit Linux version of OpenArena today is not that simple.
Since adapting the MXE build environment, I am no longer too concerned about the effort needed to maintain a 64-bit Windows build environment. MXE does provide all the libraries that are currently used.

An annoying thing is libxmp. I have not gotten it to work yet in the MXE Windows 32-bit build and I consider it a higher priority than a 64-bit build. Creating a 64-bit build will likely make it harder to get libxmp to work, so I would prefer to get libxmp working first.

libxmp might not be the last library added to OpenArena and adding new libraries gets exponentially harder with each architecture supported.

IIRC, I read somewhere (I don't recall where) that a 32bit software runs about 2% slower under 64bit Windows than under a native 32bit Windows, due to the overhead caused by the WindowsOnWindows layer. 2% isn't much. And also, that a 64 bit program can run about 20% faster, due to the the architecture optimizations. I do not know about Linux.

Comparing to a few years ago, I suppose nowadays people are more friendly with 64bit programs (starting from Windows 7, 64bit OS is the norm and 32bit OS the exception), and it will be even more when OA3 will be released.

Still, if that gives headaches to support and maintain, it may not be worth it.

I know Fromhell is trying ways to make the game run faster... but however I think that her efforts mostly aim to older systems which do not support 64 bit, so it doesn't actually matter for this.

64-bit's much touted improvements will still be bottlenecked by the VM, the sound backend (including OpenAL), and the renderer module (not having skinned/vertex shaded model animation, especially for MDRs). It's not an automatic instant modernizer and as a 64-bit windows user for at least a decade now, I can't imagine any benefit from this and you can't always trust GCC to shoehorn in SSE2 or newer extensions in automatically in the most efficient ways or those percentages (2% slower 40% faster sounds like a fud article)


(FYI I do still use GCC 4.7.2 to compile binaries. It's the last version to not regress the 486/Pentium platform, important because the emulator I use to profile assets only emulates a Pentium MMX at best.)