Pages: [1]
  Print  
Author Topic: Nightly Windows engine builds  (Read 31891 times)
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« on: July 17, 2016, 06:34:14 AM »

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

There are nothing offending in my posts.
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3775


Trickster God.


« Reply #1 on: July 17, 2016, 09:31:18 AM »

This is great news, Sago, thank you!
Logged


"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
Want to contribute? Read this.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #2 on: July 17, 2016, 05:33:29 PM »

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)
« Last Edit: July 17, 2016, 05:37:41 PM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3775


Trickster God.


« Reply #3 on: July 17, 2016, 08:30:19 PM »

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


"Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
Want to contribute? Read this.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #4 on: July 17, 2016, 10:13:28 PM »

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
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #5 on: July 28, 2016, 03:33:06 AM »

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

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #6 on: July 30, 2016, 03:42:50 AM »

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

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #7 on: August 20, 2016, 04:04:17 PM »

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

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #8 on: September 01, 2016, 01:27:37 AM »

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?
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #9 on: September 01, 2016, 02:34:21 AM »

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

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #10 on: September 01, 2016, 02:59:10 AM »

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...
« Last Edit: September 01, 2016, 03:06:57 AM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #11 on: November 03, 2017, 03:28:07 PM »

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?
« Last Edit: November 03, 2017, 04:15:10 PM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #12 on: November 04, 2017, 06:04:55 AM »

Thinking again about it, another problem for 64bit binaries could be third party DLLs (e.g. openal)...
« Last Edit: November 05, 2017, 04:15:42 PM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
sago007
Posts a lot
*

Cakes 62
Posts: 1664


Open Arena Developer


WWW
« Reply #13 on: November 04, 2017, 06:34:57 AM »

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

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #14 on: November 04, 2017, 10:02:57 AM »

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.
« Last Edit: November 04, 2017, 12:05:16 PM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #15 on: November 04, 2017, 05:49:23 PM »

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.)
« Last Edit: November 04, 2017, 05:56:13 PM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Pages: [1]
  Print  
 
Jump to: