Pages: [1] 2 3
  Print  
Author Topic: OpenArena 0.8.8 source  (Read 50677 times)
sago007
Posts a lot
*

Cakes 62
Posts: 1652


Open Arena Developer


WWW
« on: February 20, 2012, 11:10:36 am »

There has been a lot of small adjustments up to the release but now that OpenArena 0.8.8 has been released the source is final too:

Game logic source: http://files.poulsander.com/~poul19/public_files/oa/dev088/oa-0.8.8.tar.bz2
Taken from OAX branch oa-0.8.8 r295

Engine source: http://files.poulsander.com/~poul19/public_files/oa/dev088/openarena-engine-source-0.8.8.tar.bz2
-28 from the binary thread.
Logged

There are nothing offending in my posts.
grey matter
Member


Cakes 8
Posts: 381

>9k


« Reply #1 on: February 20, 2012, 11:16:30 am »

Thank's a bunch!
When will these be mentioned on openarena.ws?
Logged

This space is for rent.
sago007
Posts a lot
*

Cakes 62
Posts: 1652


Open Arena Developer


WWW
« Reply #2 on: February 20, 2012, 11:18:21 am »

Thank's a bunch!
No problem
When will these be mentioned on openarena.ws?
Hopefully
Logged

There are nothing offending in my posts.
SooKee
Nub


Cakes 5
Posts: 37



« Reply #3 on: February 20, 2012, 01:18:18 pm »

Ah fantastic! That's great, thank you Smiley
Logged

- SooKee QuakeNet: #openarenahelp
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #4 on: February 20, 2012, 05:04:53 pm »

Thank's a lot Sago Smiley
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 31
Posts: 14481



WWW
« Reply #5 on: February 20, 2012, 05:24:02 pm »

http://openarena.ws/page.php?14

Any info I need to add? Maybe compiling instructions?
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 48
Posts: 4281


WWW
« Reply #6 on: February 20, 2012, 05:45:33 pm »

http://openarena.ws/page.php?14

Any info I need to add? Maybe compiling instructions?
Good. I suppose it should be listed here. And the "SVN" word may be a link to the SVN itself.
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.
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #7 on: March 05, 2012, 10:01:23 pm »

There has been a lot of small adjustments up to the release but now that OpenArena 0.8.8 has been released the source is final too:

Engine source: http://files.poulsander.com/~poul19/public_files/oa/dev088/openarena-engine-source-0.8.8.tar.bz2
-28 from the binary thread.
Hi Sago,

I started the process of moving this to the latest ioquake3.  I think there are a number of changes that would make it easier to sync with upstream.  With the new modular renderer, all of these renderer changes could be thrown into a new renderer so they don't conflict with upstream's.  You could then use other renderers when they are available (like Useless' opengl2 with VBO, GLSL, etc).  The cl_renderer cvar lets you choose a renderer at runtime rather than having one compiled into the binary.  Useless created a separate directory for his renderer and I think you could follow his example.  A lot of the makefile and standalone changes either don't have to be done or are easier now.

I'd like to throw this up on github.  ioquake3 doesn't have a git mirror (*sadface*) but I'm maintaining one in github.  I have a bunch of minor ioquake3 projects that I sync against the latest ioquake3 without any problems.  I think moving the code to github or gitorious or whatever would make your job a lot easier.
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #8 on: March 06, 2012, 04:26:06 am »

@hairball: that's great news! And since you're maintaining a github mirror of ioquake3, once OA 0.8.8 is merged with ioquake3, it would be almost automatic to keep up with the latest ioquake3 revision!

For infos, here is the merged OA 0.8.5 with ioquake3 by hairball:
https://github.com/undeadzy/undeadzy_openarena#readme

And its ioquake3 mirror:
https://github.com/undeadzy/ioquake3_mirror

Now, as you pointed out, this is only for the engine, as the OA gamecode is a lot more different from the original ioquake3. But at least having an up-to-date engine would fix a lot of issues and security concerns, and would also allow to benefit from the very latest functionnalities such as the sv_dlrate, and would spare a lot of maintenance time in the future.

Hairball, that's great that you are trying to merge the latest OA engine with ioquake3. How much time do you think will you have to spend to merge OA 0.8.8 to ioquake3? Also, are you doing it all over again or are you porting the changes by diffing 0.8.5->0.8.8 and then applying to your OA 0.8.5 merge?



@sago007: about the OA gamecode, since you know better than anyone else the changes that have been made, do you think that using the same process described by hairball (see the readme of the OA 0.8.5 in the link above), would it be possible to also sync the OA gamecode with the latest ioquake3?
Logged
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #9 on: March 06, 2012, 07:18:41 am »

@hairball: that's great news! And since you're maintaining a github mirror of ioquake3, once OA 0.8.8 is merged with ioquake3, it would be almost automatic to keep up with the latest ioquake3 revision!
Yeah Smiley  I would say my UrT client is more representative of what a project looks like when it keeps in sync with ioquake3.  There are a number of UrT changes but they are easy to keep in sync.  I looked at my OA 0.8.5 client and I took some liberties back then.  I'm doing all of the changes this time for OA 0.8.8.

Quote from: GrosBedo
Now, as you pointed out, this is only for the engine, as the OA gamecode is a lot more different from the original ioquake3.
I think it would be the same process for the game code.  My impression is that part changes less than the rest of ioquake3 anyway.  I think you could have both parts in git and keep in sync.  I have never tried to build the game code for OA so I don't know how far it is from the latest.

Quote from: GrosBedo
Hairball, that's great that you are trying to merge the latest OA engine with ioquake3. How much time do you think will you have to spend to merge OA 0.8.8 to ioquake3? Also, are you doing it all over again or are you porting the changes by diffing 0.8.5->0.8.8 and then applying to your OA 0.8.5 merge?
I think a few days.  I made almost all of the changes last night.  I'm going to test it today if I have time.  I moved all of the renderer changes to renderer_oa so the client builds renderer_opengl1_*.so and renderer_openarena1_*.so.  I did a full merge with 0.8.8 and didn't use any of my 0.8.5 work.

Here is my list of concerns after moving 0.8.8 to the latest ioquake3
  • I did not remove cl_yawspeed and cl_pitchspeed.  We need a better way to force the value rather than hardcoding 140 all over the place.
  • Upstream already supports ogg.  Do we need to change anything?  I didn't make any changes related to ogg and instead used USE_CODEC_VORBIS=1 in Makefile.local
  • q_shared.c has a GLSL change to load those files.  renderer_opengl2 doesn't need that change.
       Can we change OpenArena to not require that change as well?
  • For vm_powerpc_asm.c, is q_shared.h really needed?  Why isn't upstream using that change?
  • tr_shade.c - didn't comment out the shader variable.  I think the logic changed upstream because GL_Cull now uses shader->cullType.
  • tr_init.c - Did not hardcode 50 instead of r_aviMotionJpegQuality.  This is similar to yaw/pitch.  We need to find the proper way to handle this.
  • sv_client.c allows for say and say_team to bypass Cmd_Args_Sanitize.  Is this really a good idea?  Is it safe?
  • Handling the Makefile/Makefile.local in a much different manner.  It is very clean now.  Make sure it still aligns with old Makefile's goals.
  • Need to update the mac scripts for the installer to reference OpenArena.  I don't have a mac so I can't test this.
Logged
Gig
In the year 3000
***

Cakes 48
Posts: 4281


WWW
« Reply #10 on: March 06, 2012, 07:34:56 am »

I did not remove cl_yawspeed and cl_pitchspeed.  We need a better way to force the value rather than hardcoding 140 all over the place.
Well, I suppose a way to allow a certain degree of flexibility, or a way for servers to disable the lock (like with DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Videoflags]Videoflags) may be nice... or at least to inform the user that those variables are read-only!
Quote
q_shared.c has a GLSL change to load those files.  renderer_opengl2 doesn't need that change.
   Can we change OpenArena to not require that change as well?
About GLSL, maybe you should ask Hitchhiker. PS: there is at least a little fix that Hight did about GLSL debugging, that has not yet been incorporated into new OA executables -at the moment, we are at version 28 executables-.
Quote
tr_init.c - Did not hardcode 50 instead of r_aviMotionJpegQuality.  This is similar to yaw/pitch.  We need to find the proper way to handle this.
Do you mean that at the moment, r_avimoteionjpegquality variable is ignored by OA executables, and "50" is always used instead? I haven't tried to change it yet... but I cannot imagine the reason for a such lock..
Quote
Need to update the mac scripts for the installer to reference OpenArena.  I don't have a mac so I can't test this.
For Mac stuff, ask Jackoverfull.



PS: your work sounds promising.  Smiley
« Last Edit: March 06, 2012, 03:40:15 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: 1652


Open Arena Developer


WWW
« Reply #11 on: March 06, 2012, 11:32:41 am »

There is a lot of points that I know little about. But there are two that I know about.
  • Upstream already supports ogg.  Do we need to change anything?  I didn't make any changes related to ogg and instead used USE_CODEC_VORBIS=1 in Makefile.local
  • sv_client.c allows for say and say_team to bypass Cmd_Args_Sanitize.  Is this really a good idea?  Is it safe?
cross-make-mingw.sh does not work out-of-the-box on mingw32 in Ubuntu if just USE_CODEC_VORBIS=1 is used. I included libraries and referenced them directly in the Makefile like ioquake3 does with SDL.

Cmd_args_sanitize is bypassed to allow "/say ;-)". There was quite a bit of complaints then 0.8.0 disabled ";" unless written like "/say ";-)"". At the time of disabling that I believed that no mads allowed one to enter commands in "say". But while writing this I remembered that the KK-Admin system in OA allows just that.
Cmd_args_sanitize was created to protect mods from a potential callvote-bug. The big problem here was that the code heavily encouraged the coder to enable the bug.


@sago007: about the OA gamecode, since you know better than anyone else the changes that have been made, do you think that using the same process described by hairball (see the readme of the OA 0.8.5 in the link above), would it be possible to also sync the OA gamecode with the latest ioquake3?
It would be very hard. There are only two larger changes to the gamecode in ioquake3 that I know about and they fork in completly different direction compared to OpenArena.
Logged

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

Cakes 48
Posts: 4281


WWW
« Reply #12 on: March 06, 2012, 12:04:56 pm »

Just for curiosity, what are those two?
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: 1652


Open Arena Developer


WWW
« Reply #13 on: March 06, 2012, 12:19:44 pm »

Just for curiosity, what are those two?
Ok, there is really only one, but it is VERY big. It is called "ioquake3 revision 2116". It conflicts heavily with Elimination.

All other changes are minor in comparison.
Logged

There are nothing offending in my posts.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #14 on: March 06, 2012, 12:59:17 pm »

What is conflicting with r2116?

Anyway, even if the gamecode is not synced, OA should still benefit from the synced engine binaries, the OA gamecode can be considered as a mod after all.
Logged
sago007
Posts a lot
*

Cakes 62
Posts: 1652


Open Arena Developer


WWW
« Reply #15 on: March 06, 2012, 01:38:20 pm »

What is conflicting with r2116?
Almost everything. The big change was to the respawn procedure because the original vq3 code made it very difficult to have spectators and real players on the same team. Of course that particular code was also heavily modified in the original Elimination mod because spectators and real players needed to be on the same team.

Most ioqauke3 enhancements to the gamecode are to make modmaking easier but that often means touching code that all mods including OAX have already touched.

Anyway, even if the gamecode is not synced, OA should still benefit from the synced engine binaries.
I synced it for as long as I was able. As said earlier in another thread the current version of OA is last synced to 1910 after that the patches broke (I believe one patch needed to modify a struct that no longer existed).
Logged

There are nothing offending in my posts.
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #16 on: March 06, 2012, 03:15:08 pm »

I did not remove cl_yawspeed and cl_pitchspeed.  We need a better way to force the value rather than hardcoding 140 all over the place.
Well, I suppose a way to allow to allow a certain degree of flexibility, or a way for servers to disable the lock (like with DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Videoflags]Videoflags) may be nice... or at least to inform the user that those variables are read-only!
cl_yawspeed is replaced with 140 in the actual code.

I looked at the cvar values.  Is there any reason why we can't simply use CVAR_ROM for those?  It seems cleaner than removing all references to cl_yawspeed and using a constant value.

q_shared.c has a GLSL change to load those files.  renderer_opengl2 doesn't need that change.
   Can we change OpenArena to not require that change as well?
About GLSL, maybe you should ask Hitchhiker. PS: there is at least a little fix that Hight did about GLSL debugging, that has not yet been incorporated into new OA executables -at the moment, we are at version 28 executables-.
renderer_opengl2 is using GLSL and I don't believe he is touching q_shared.c.  It's easier to maintain the changes if we avoid touching areas like that.

I'm using some of the other ideas from James like a tr_extensions.c instead of modifying sdl_glimp.c.

tr_init.c - Did not hardcode 50 instead of r_aviMotionJpegQuality.  This is similar to yaw/pitch.  We need to find the proper way to handle this.
Do you mean that at the moment, r_avimoteionjpegquality variable is ignored by OA executables, and "50" is always used instead? I haven't tried to change it yet... but I cannot imagine the reason for a such lock..
Correct.  The diff looks like this (yaw/pitch is the same but with 140):

Code:
@@ -712,7 +729,7 @@

    if( cmd->motionJpeg )
    {
-       frameSize = SaveJPGToBuffer( cmd->encodeBuffer, r_aviMotionJpegQuality->integer,
+       frameSize = SaveJPGToBuffer( cmd->encodeBuffer, 50,
                cmd->width, cmd->height, cmd->captureBuffer );
        ri.CL_WriteAVIVideoFrame( cmd->encodeBuffer, frameSize );
    }

The default is 90 so I don't know why it is being locked to 50.  Should this be a CVAR_ROM too, or simply a default value?

Need to update the mac scripts for the installer to reference OpenArena.  I don't have a mac so I can't test this.
For Mac stuff, ask Jackoverfull.
Thanks!
Logged
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #17 on: March 06, 2012, 03:21:57 pm »

cross-make-mingw.sh does not work out-of-the-box on mingw32 in Ubuntu if just USE_CODEC_VORBIS=1 is used. I included libraries and referenced them directly in the Makefile like ioquake3 does with SDL.
Ok, I'll try it out and see if it's still needed.

Cmd_args_sanitize was created to protect mods from a potential callvote-bug. The big problem here was that the code heavily encouraged the coder to enable the bug.
So are we better off with or without the checks for say/say_team?
Logged
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #18 on: March 06, 2012, 03:24:08 pm »

Anyway, even if the gamecode is not synced, OA should still benefit from the synced engine binaries.
I synced it for as long as I was able. As said earlier in another thread the current version of OA is last synced to 1910 after that the patches broke (I believe one patch needed to modify a struct that no longer existed).
Sago: Are you talking about the engine or gamecode having problems after r1910?  I don't recall running into problems with missing structs in the engine.
Logged
grey matter
Member


Cakes 8
Posts: 381

>9k


« Reply #19 on: March 06, 2012, 03:24:24 pm »

Cmd_args_sanitize was created to protect mods from a potential callvote-bug. The big problem here was that the code heavily encouraged the coder to enable the bug.
So are we better off with or without the checks for say/say_team?

Assuming that the callvote vulnerability was the only one in the gamecode, we should not even need the check in the engine. But better safe than sorry and filter everything except for /say, /say_team. What about /tell by the way?
The only thing I dislike about this selective filtering is gamecode semantics creeping into the engine.

What about a list for the OA specific engine changes, each with a separate diff and explaination? This'd make it easier to apply them years later or in other forks.
Logged

This space is for rent.
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #20 on: March 06, 2012, 03:46:59 pm »

What about a list for the OA specific engine changes, each with a separate diff and explaination? This'd make it easier to apply them years later or in other forks.
IMHO it's better to maintain it in a DVCS like git so people can submit patches and maintain external branches easier.  Maintaining a large series of patches is no fun.
Logged
Gig
In the year 3000
***

Cakes 48
Posts: 4281


WWW
« Reply #21 on: March 06, 2012, 05:11:02 pm »

About r_aviMotionJpegQuality, it seems true that changing its value has no effect, at least in 0.8.8 (output file has got the same size if I set it to 1 or to 90!). Sago, do you know why this has been done, and starting from which version? About version... r_aviMotionJpegQuality seems to do not exist at all in 0.8.1 and 0.8.5 executables?  Huh

Another importing a new ioquake3 feature that went wrong?

The ability of setting the avi quality may be useful (e.g. to avoid the need of using the huge "uncompressed" format if one needs an high quality video)...
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.
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #22 on: March 07, 2012, 12:13:45 am »

I tried it out tonight and it seems fine.  I didn't notice a difference between the 0.8.8 release client and this client with r2224.

Here is the new project.  I uploaded all of my changes.

https://github.com/undeadzy/openarena_engine

I put instructions in the README.md if you want to view the diff between ioquake3 r2224 and this code in git.
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #23 on: March 07, 2012, 06:24:58 am »

Great news! Nice work!

Anyway I think that there may be a few more things to port in the makefile, it should be checked by sago. I already ported some files and changes of the makefile to make the compilation work on Windows:

https://github.com/lrq3000/openarena_engine/commit/c2c316102f40dec74a23d195204fb70c2be6b608

The 3 changes are:
- CC and WINDRES have changed in the last releases of MinGW, now it's simply gcc.exe and windres.exe (but I left the conditionnal check to accept older releases as well, in fact if it can't find the other binaries it falls back to gcc.exe and windres.exe)
- copied the vorbis and ogg lib files
- added a conditional branching in the makefile for Windows (else vorbis can't be compiled)

I did a pull request on your repository.

Also, I think that we should copy the old make-macosx-ub.sh (the new one is the basic ioquake3 standard script, but apart from the vars nothing differs).

----

So I compiled successfully and tried it on different online servers, seems to work ok. I also tried on my own server, with basemod and with ExcessivePlus, works OK.

Anyway there's a small weird graph now showing on the bottom of the menu when I'm launching the client (see attachment), which seems to show the network connections made. This seems to be a new feature, and maybe it's due to my weird config. Also, this graph only shows up in the menu, not in-game.
Logged
hairball
Half-Nub


Cakes 2
Posts: 52


« Reply #24 on: March 07, 2012, 07:05:12 am »

The 3 changes are:
- CC and WINDRES have changed in the last releases of MinGW, now it's simply gcc.exe and windres.exe (but I left the conditionnal check to accept older releases as well, in fact if it can't find the other binaries it falls back to gcc.exe and windres.exe)
- copied the vorbis and ogg lib files
- added a conditional branching in the makefile for Windows (else vorbis can't be compiled)

I did a pull request on your repository.
Thanks!  I merged it.

Anyway there's a small weird graph now showing on the bottom of the menu when I'm launching the client (see attachment), which seems to show the network connections made. This seems to be a new feature, and maybe it's due to my weird config. Also, this graph only shows up in the menu, not in-game.
I see what you mean in the screenshot.  I do not see that graph on my side in Linux.  Have you tried a new config to see if it goes away?  I did not add any features to the client/server.
Logged
Pages: [1] 2 3
  Print  
 
Jump to: