|
Title: OpenArena 0.8.8 source Post by: sago007 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. Title: Re: OpenArena 0.8.8 source Post by: grey matter on February 20, 2012, 11:16:30 AM Thank's a bunch!
When will these be mentioned on openarena.ws? Title: Re: OpenArena 0.8.8 source Post by: sago007 on February 20, 2012, 11:18:21 AM Thank's a bunch! No problemWhen will these be mentioned on openarena.ws? Hopefully Title: Re: OpenArena 0.8.8 source Post by: SooKee on February 20, 2012, 01:18:18 PM Ah fantastic! That's great, thank you :)
Title: Re: OpenArena 0.8.8 source Post by: GrosBedo on February 20, 2012, 05:04:53 PM Thank's a lot Sago :)
Title: Re: OpenArena 0.8.8 source Post by: fromhell on February 20, 2012, 05:24:02 PM http://openarena.ws/page.php?14
Any info I need to add? Maybe compiling instructions? Title: Re: OpenArena 0.8.8 source Post by: Gig on February 20, 2012, 05:45:33 PM http://openarena.ws/page.php?14 Good. I suppose it should be listed here (http://openarena.ws/download.php). And the "SVN" word may be a link to the SVN itself.Any info I need to add? Maybe compiling instructions? Title: Re: OpenArena 0.8.8 source Post by: hairball 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: Hi Sago,Engine source: http://files.poulsander.com/~poul19/public_files/oa/dev088/openarena-engine-source-0.8.8.tar.bz2 -28 from the binary thread. 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. Title: Re: OpenArena 0.8.8 source Post by: GrosBedo 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 (http://openarena.ws/board/index.php?topic=1933.msg43327#msg43327), 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? Title: Re: OpenArena 0.8.8 source Post by: hairball 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 :) 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
Title: Re: OpenArena 0.8.8 source Post by: Gig 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 (http://([b)) 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. About GLSL, maybe you should ask Hitchhiker (http://openarena.ws/board/index.php?action=profile;u=3740). PS: there is at least a little fix (http://openarena.ws/board/index.php?topic=1933.msg42372#msg42372) 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-.Can we change OpenArena to not require that change as well? 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 (http://openarena.ws/board/index.php?action=profile;u=362).PS: your work sounds promising. :) Title: Re: OpenArena 0.8.8 source Post by: sago007 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.
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. Title: Re: OpenArena 0.8.8 source Post by: Gig on March 06, 2012, 12:04:56 PM Just for curiosity, what are those two?
Title: Re: OpenArena 0.8.8 source Post by: sago007 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. Title: Re: OpenArena 0.8.8 source Post by: GrosBedo 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. Title: Re: OpenArena 0.8.8 source Post by: sago007 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).Title: Re: OpenArena 0.8.8 source Post by: hairball 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 (http://([b)) may be nice... or at least to inform the user that those variables are read-only!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. About GLSL, maybe you should ask Hitchhiker (http://openarena.ws/board/index.php?action=profile;u=3740). PS: there is at least a little fix (http://openarena.ws/board/index.php?topic=1933.msg42372#msg42372) 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-.Can we change OpenArena to not require that change as well? 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..Code: @@ -712,7 +729,7 @@ 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 (http://openarena.ws/board/index.php?action=profile;u=362).Title: Re: OpenArena 0.8.8 source Post by: hairball 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?Title: Re: OpenArena 0.8.8 source Post by: hairball 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).Title: Re: OpenArena 0.8.8 source Post by: grey matter 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. Title: Re: OpenArena 0.8.8 source Post by: hairball 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.Title: Re: OpenArena 0.8.8 source Post by: Gig 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? ???
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)... Title: Re: OpenArena 0.8.8 source Post by: hairball 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. Title: Re: OpenArena 0.8.8 source Post by: GrosBedo 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. Title: Re: OpenArena 0.8.8 source Post by: hairball on March 07, 2012, 07:05:12 AM The 3 changes are: Thanks! I merged it.- 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. 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.Title: Re: OpenArena 0.8.8 source Post by: GrosBedo on March 07, 2012, 07:35:38 AM Thank's to you! Your work is really great!
About the config, I'm stupid, I didn't even think of testing without lol. Tested, indeed it's in my config, with a raw config there's nothing abnormal on the menu. Title: Re: OpenArena 0.8.8 source Post by: Hitchhiker on March 09, 2012, 11:53:03 AM Quote q_shared.c has a GLSL change to load those files. renderer_opengl2 doesn't need that change. About GLSL, maybe you should ask Hitchhiker (http://openarena.ws/board/index.php?action=profile;u=3740). PS: there is at least a little fix (http://openarena.ws/board/index.php?topic=1933.msg42372#msg42372) 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-.Can we change OpenArena to not require that change as well? Hi y'all, sorry for the late answer. q_shared.c - that one has the glsl mentioned in order to capture the glsl related shader script keywords while making the same keywords invisible to the older builds of the engine. This was added to make shader scripts, that contain glsl keywords, usable on the older versions of the engine. The glsl shader script keywords were agreed to be prefixed with '//GLSL' chars which effectively makes anything that follows the '//' chars a comment and, this way, older versions ignore the glsl keywords and new versions can still access them). I see no other way of implementing this functionality. :( @hairball thanks for posting! Your post made me look deeper in the ioquake3 patches and yes, it seems there are more than one version of the renderer in preparation. Do you know how many renderers (and maybe a link to them or just some names) are there that are in a stable/promising stage? My concern here is that if any kind of pluggable renderer is going to be implemented in ioquake3 then the above (shader scripts and containing glsl keywords) should be an issue and standardized. I.e. the way a glsl program is specified from within the shader script (use always the same keyword for specifying vertex and same word for shader part of the glsl program, etc). This as the shader scripts will always be the same no matter which renderer is used. Cheers Title: Re: OpenArena 0.8.8 source Post by: hairball on March 09, 2012, 08:53:56 PM q_shared.c - that one has the glsl mentioned in order to capture the glsl related shader script keywords while making the same keywords invisible to the older builds of the engine. I haven't read through the large patch, but the opengl2 renderer supports GLSL so they have to have a way to load the shader scripts. Maybe he doesn't need to care about backward compatibility? I'm not that familiar with the renderer. My interest is more in the client/server part.This was added to make shader scripts, that contain glsl keywords, usable on the older versions of the engine. The glsl shader script keywords were agreed to be prefixed with '//GLSL' chars which effectively makes anything that follows the '//' chars a comment and, this way, older versions ignore the glsl keywords and new versions can still access them). I see no other way of implementing this functionality. :( @hairball I'm not sure how many will ever be in ioquake3 itself. The opengl2 renderer has been in development since 2010 or so in the form of a bug report! It's on rev 28 in a bug report... having 28 revisions of a patch in a bug report that's from 2009 just screams DVCS. They don't appear to be making any progress toward converting away from SVN. *shrug*thanks for posting! Your post made me look deeper in the ioquake3 patches and yes, it seems there are more than one version of the renderer in preparation. Do you know how many renderers (and maybe a link to them or just some names) are there that are in a stable/promising stage? As far as renderers, I haven't heard of too many. The big one is James Canete's opengl2 which has VBO, GLSL, etc. 27 from UrT did a GLSL renderer as well but I think James' is more comprehensive since it's been in development for so long. OA has another renderer which I call renderer_oa. Xreal has one of the most comprehensive amount of changes of course but the license probably prohibits it from being integrated into ioquake3. It could be compiled and loaded locally if someone pulls out the changes. I have a special purpose null renderer + sqlite log that I use to extract out QVM messages. There was a post on the wiki about the idea of a modular renderer a long time ago but it didn't really make progress from what I saw until Canete's patch. I think Canete's is the best example of a modular renderer since he is targeting it. Title: Re: OpenArena 0.8.8 source Post by: fromhell on March 09, 2012, 09:01:24 PM I haven't read through the large patch, but the opengl2 renderer supports GLSL so they have to have a way to load the shader scripts. Maybe he doesn't need to care about backward compatibility? I'm not that familiar with the renderer. My interest is more in the client/server part. I'm a bit toward both ways On one hand I want to play OA on a PowerVR PCX2. Targeting this lowly budget 1997 video card in an asset reboot (OA3) would mean an overall low-end range compatibility and faster framerates (the card has no glArrayElement and blending beyond alpha, RGBA4 and RGB5 are the only texture formats you can use). Remember that Q3A never ever ran properly on this card, and Q3A itself had a lot of room for improvement (too many unused textures loaded, and a big lack of atlasing and LODs that didn't go low enough) A lot of PCX2's blending shortcomings can be solved by having additional shader files to load over where PCX2 has trouble with, but with a .simple extension instead (similar to STVEF). GL_ZERO shaders would become GL_ONE shaders with rgbGen const '0 0 0' for example, on marks, to get it to show properly on pcx2. I know what you're asking. "WHO USES PCX2 IN 2012?!!" No one, to be honest, but I believe that as a technical artist targeting the PCX2 would also hit a lot of old slow and modern slow video chipsets, especially anything on OpenGL ES. and maybe consoles (Pipe dream warning: Dreamcast / N64 / PS2 / GC / Wii OA?) and possibly - pave the way for a fast software renderer. On the other hand I want to play OA with nice normal maps, spec, and per-pixel lighting on a AMD RadeonHD, like the mainstream audience does. Title: Re: OpenArena 0.8.8 source Post by: Hitchhiker on March 10, 2012, 01:40:41 AM On the other hand I want to play OA with nice normal maps, spec, and per-pixel lighting on a AMD RadeonHD, like the mainstream audience does. I do too and i see modular renderer as a really good idea as it will provide a way for different computer configurations to get the best out of their graphic cards. But I don't see anything good in having different ways of loading glsl programs to the engine as, if you are creating a map, you would have to crate a shader script for each renderer in a single shader and that might not be possible to do. So should I abandon making changes to the renderer and the one of James Canete's is used in OA? James Canete's renderer certainly contains much much more improvements than anything I have done so far. Title: Re: OpenArena 0.8.8 source Post by: fromhell on March 10, 2012, 04:44:29 AM I haven't used/checked his. OA would still need to apply changes because we have those flare additions/bloom/spec/envmap etc
Title: Re: OpenArena 0.8.8 source Post by: hairball on March 10, 2012, 08:05:59 AM I haven't used/checked his. OA would still need to apply changes because we have those flare additions/bloom/spec/envmap etc His patch applies cleanly to r2224.Edit: The branch is now public here: https://github.com/undeadzy/openarena_engine with the name 'opengl2_renderer'. Note that this doesn't work at runtime yet. :) The VBO patch doesn't compile cleanly with RAVENMD4. When you start it up, it complains about duplicate GLSL functions. I added a comment to the ioquake3 bug report where v28 of this patch lives: https://bugzilla.icculus.org/show_bug.cgi?id=4358 Title: Re: OpenArena 0.8.8 source Post by: Gig on March 11, 2012, 05:49:06 AM If Sago reads this...
Is there a reason for r_aviMotionJpegQuality hard-coded to 50 (changing it does not change che output file), while its default is reported to be 90? Title: Re: OpenArena 0.8.8 source Post by: Hitchhiker on March 12, 2012, 02:19:28 PM @hairball,
thanks for setting up the git repo and for posting on the ioquake3 page. I've just downloaded the opengl2_renderer, had a quick look at it and it seems the unification of two different glsl supports might prove to be a bigger task than I originally thought. The main issue I can see is that (as things are now, between the two renderers) the shader scripts use different keywords and glsl programs have a different set of uniform variables to use. This as far I can see, short of having two different sets of shader scripts and glsl programs in the pk3 files, could not work. Then, I could try changing the existing OA's renderer (glsl related part) to correspond to the one James has done but that would mean re-implementing almost everything he's already done on his end. And I don't have the needed know-how to do that. :( Since his renderer provides for so much more functionality and speed improvements I believe easiest would be to simply use his rendering code. So when James finds the time to look into your post on ioquake3 page, if he asks about OA glsl bit and what to do with it, I believe safe to leave it out (@all, your comments please?) - it will be much easier that way for him to implementing the OA's non-glsl improvements of the renderer (if he has interest to do so ofc.). As for the applying his patch to the 088.. If I am understanding this correctly? You've taken the renderer code from the 088 and applied James' patch to it? If so, in OA 088 and James' renderer there is a cvar called r_postprocess and I am not sure how the two have mixed when the patch was applied? I'm looking at https://github.com/undeadzy/openarena_engine/blob/opengl2_renderer/code/renderergl2/tr_init.c and https://github.com/undeadzy/openarena_engine/blob/opengl2_renderer/code/renderer_oa/tr_init.c (I'm probably going all wrong about this?) :) Maybe just for a test, and not wanting to waste any of your time, do you know if it would be possible to merge OA 085 with James' patch (oa085 didnt have any glsl support)? @fromhell, do you know if RAVENMD4 could be disabled and still have the models, entities & world displayed in OA? If so, maybe a test could be setup to permit better evaluation of the opengl2 renderer? Title: Re: OpenArena 0.8.8 source Post by: hairball on March 12, 2012, 04:54:55 PM As for the applying his patch to the 088.. If I am understanding this correctly? You've taken the renderer code from the 088 and applied James' patch to it? Nope. What I did was pull the OA 0.8.8 renderer changes out and put them into code/renderer_oa. I then integrated James' renderer into code/renderergl2. Both of them have very simple modifications so I can reuse parts of code/renderer that don't change. However, code/renderer_oa and code/renderergl2 are completely independent. You can use either one with the cl_renderer cvar.We will need a third renderer, maybe called renderer_oagl2, that combines James' renderer with the OA changes like bloom and all the stuff fromhell mentioned. I think the first step is to get James' renderer working without any OA renderer changes. Then copy his renderergl2 code into the new renderer and start applying the OA changes. I looked through the bugzilla archive and there's one more renderer but it appears to be stagnant since 6 months ago. It sounded like it had some bugs. I asked for clarification if it is still in development. If not, I think there would be 4 renderers in OA: vanilla q3, old OA, opengl2 (James'), and OA opengl2 (james' + OA modifications). Then at that point after a while you could remove the old OA if you want. There's not much penalty to keeping it around though since all of the renderers are independent. Fromhell mentioned in another thread a DX and software renderer so maybe there will be 6 in OA. :) Maybe just for a test, and not wanting to waste any of your time, do you know if it would be possible to merge OA 085 with James' patch (oa085 didnt have any glsl support)? What if I take pak6-patch088.pk3 and remove the glsl/ files? Would that be a good test? The glsl parts aren't required, are they?Title: Re: OpenArena 0.8.8 source Post by: hairball on March 14, 2012, 07:00:39 PM Hitchhiker: He replied:
http://icculus.org/pipermail/quake3-bugzilla/2012-March/002511.html tl;dr he would want a single renderer with OA and Reaction changes rather than forking it. He won't be able to look at it for a while since he is adding other features. Title: Re: OpenArena 0.8.8 source Post by: GrosBedo on March 14, 2012, 07:18:41 PM @hairball: <offtopic>What is the Reaction codebase?</offtopic>
Title: Re: OpenArena 0.8.8 source Post by: fromhell on March 14, 2012, 08:05:30 PM He's referring to the changes the Reaction mod requires. It's an excellent Q3 mod that's a tribute to Action Quake2.
Title: Re: OpenArena 0.8.8 source Post by: Gig on March 15, 2012, 01:49:04 AM (DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/ModCompat/Reaction
Title: Re: OpenArena 0.8.8 source Post by: GrosBedo on March 15, 2012, 05:26:06 AM Oh nice! I didn't know this mod was still maintained!
Title: Re: OpenArena 0.8.8 source Post by: Hitchhiker on March 15, 2012, 12:58:54 PM Hitchhiker: He replied: http://icculus.org/pipermail/quake3-bugzilla/2012-March/002511.html tl;dr he would want a single renderer with OA and Reaction changes rather than forking it. He won't be able to look at it for a while since he is adding other features. thanks for the link hairball! it is definitely good news. :) looking forward to seeing James' renderer in action! Title: Re: OpenArena 0.8.8 source Post by: sago007 on March 19, 2012, 12:08:54 PM If Sago reads this... I don't know any reason. It might have been a patch or an unsuccessful merge. The value might have been changed from 90 to 50 in a patch named OORefFlare but the cvar was unknown to me before this thread.Is there a reason for r_aviMotionJpegQuality hard-coded to 50 (changing it does not change che output file), while its default is reported to be 90? Title: Re: OpenArena 0.8.8 source Post by: Gig on March 19, 2012, 03:53:13 PM In this case, maybe we may find some info in ioquake3 sites?
EDIT: May this help you someway? http://icculus.org/pipermail/quake3-commits/2011-February/001810.html (quesiton: I see there also "r_screenshotJpegQuality" exists... is that hard-locked, too? I haven't tried it yet.) PS: Googling for r_avimotionjpegquality OORefFlare does not show results... PPS: Do you think you may try to remove the lock, so we may make some tries with different values? Title: Re: OpenArena 0.8.8 source Post by: GrosBedo on March 23, 2012, 12:55:12 PM In the checking for sanitization of clientCommands there may be a possible memory access crash: in sv_client.c SV_ExecuteClientCommand():
Code: if(strcmp(Cmd_Argv(0), "say") && strcmp(Cmd_Argv(0), "say_team") ) The strcmp should be replaced by a Q_stricmp or Q_strncmp to avoid potential crashing when clientCommand string length is below 3 characters. Title: Re: OpenArena 0.8.8 source Post by: sago007 on March 23, 2012, 01:22:30 PM In the checking for sanitization of clientCommands there may be a possible memory access crash: in sv_client.c SV_ExecuteClientCommand(): I cannot spot that potential memory access crash. Cmd_Argv () is designed so it always returns a pointer to valid memory to ensure that sting operations are always safe. Code: if(strcmp(Cmd_Argv(0), "say") && strcmp(Cmd_Argv(0), "say_team") ) The strcmp should be replaced by a Q_stricmp or Q_strncmp to avoid potential crashing when clientCommand string length is below 3 characters. Q_stricmp should be used over strcmp because it is a Quake function and it does not have undefined behavior if one of the arguments are null. Title: Re: OpenArena 0.8.8 source Post by: hairball on April 13, 2012, 09:15:26 PM I added a branch for gimhael's VBO renderer. He said that the backend is optimized better than Canete's. It doesn't work with MD4 either. He says he is targeting tremulous and backporting changes to ioquake3.
The sdl_glimp.c has a number of changes. This renderer may be worth looking into as well. Title: Re: OpenArena 0.8.8 source Post by: Hitchhiker on April 17, 2012, 04:37:38 PM Thanks hairball!
just for info, for what is worth, I've uncommented the RAVEN_MD4 define and compiled OA. Did not notice anything missing in regards to models, maps, ... not really sure if MD4 is or is planned to be used with OA? Title: Re: OpenArena 0.8.8 source Post by: fromhell on April 17, 2012, 04:56:25 PM i'd happily use MDR if a Blender exporter existed (and supporting its internal LOD feature as well). There is huge space / memory gains with MDR.
right now the only pipeline to MDR is through IQM through Noesis. Title: Re: OpenArena 0.8.8 source Post by: sago007 on June 16, 2012, 03:57:31 AM In the past week I found some time to look at the repository. I am happy to see that all the icons have been replaced now meaning everything just works. It is a really great job. I have a few things that perhaps could make it even better:
I understand using Makefile.local to overrule variables in Makefile to make it easier to port and I think it is great. But perhaps there should be a Makefile.local.local so that the next person can do the same if I for instance only need the dedicated server. I notice that cl_renderer by default will be set to renderer_openarena_* and then fallback to renderer_opengl1_* if it is missing. Perhaps the default and fallback renderer should be the same. Cross-compile did not work for me. I am not really sure about why. I could overrule it by setting CC and WINDRES environment variables to the correct value but I guess it should work without it. I have attached a patch for what I believe to be the problem. Title: Re: OpenArena 0.8.8 source Post by: Hitchhiker on June 25, 2012, 11:50:27 AM https://bugzilla.icculus.org/show_bug.cgi?id=4358 Some updates. But not OA related. Title: Re: OpenArena 0.8.8 source Post by: SooKee on May 20, 2014, 02:18:30 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. Does anyone else have an issue compiling the game logic (oa-0.8.8.tar.bz2) with GCC 4.8? I get no errors compiling on one machine running GCC 4.7.2 but it won't compile the qvm on another machine running GCC 4.8.2. Here are the errors: Code: make[2]: `build/release-linux-x86_64/baseq3/cgamex86_64.so' is up to date. This is from a vanilla download - no changes. Code: gcc --version Title: Re: OpenArena 0.8.8 source Post by: sago007 on May 20, 2014, 04:56:13 AM LCC that is used to compile the qvm is broken in GCC 4.82. This is caused by a non-standard implementation of memmove i LCC. The program does an "undef memmove" and replaces it with a non-standard version. It is fixed in later versions.
Title: Re: OpenArena 0.8.8 source Post by: Neon_Knight on May 20, 2014, 11:31:58 AM Here's another... I'm using https://github.com/OpenArena/engine.git.
Code: make[2]: se ingresa al directorio «/home/neonknight/dev/oaengine/engine» Title: Re: OpenArena 0.8.8 source Post by: sago007 on May 20, 2014, 11:47:59 AM https://github.com/OpenArena/engine.git now has the memmove fix in branch "oa-0.8.8" too. It compiles with gcc-4.8.2.
If cloning is too advanced then I have also packed a ball: http://files.poulsander.com/~poul19/public_files/oa/dev088/oa-0.8.8-1.tar.bz2 I have no problems compiling the engine. Although I had to do: Code: git checkout 6eaf168ab717b340ccf0b626cd31b5687d9664f1 The engine also requires libgl1-mesa-dev, libsdl1.2-dev, libvorbis-dev, libfreetype6-dev and libxmp-dev. The last one is a rather new library. It exists in Ubuntu 14.04 but not in previous versions. It is in Debian testing (jessie) too. Travis fails to build it because travis does not have libxmp. @Neon_Knight: Your output suggests that you are missing libsdl1.2-dev Title: Re: OpenArena 0.8.8 source Post by: Neon_Knight on May 20, 2014, 02:06:23 PM Indeed that was. I also installed the remaining packages you've mentioned. However, it still doesn't compile; now I have this problem:
Code: REF_CC build/release-linux-x86/renderer_oa/glsl/anime_fp.c Any ideas? Title: Re: OpenArena 0.8.8 source Post by: fromhell on May 20, 2014, 02:09:21 PM That's unusual. There shouldn't be any .c files at all in the glsl/ folder - just .glsl files. It compiles fine for me :S
This compiling of GLSL shaders was only just recently brought in the latest commit and is something that's trying to mimic renderergl2's compiling of GLSL files as string objects to be referenced in tr_init.c as const char pointers, which doesn't work yet. Title: Re: OpenArena 0.8.8 source Post by: sago007 on May 20, 2014, 02:21:22 PM I have the same problem as Neon_Knight. That is why I had to checkout an earlier version.
I believe it is caused by the addition to the Makefile: Code: +Q3ROASTRINGOBJ = \ Code: +$(B)/renderer_oa/glsl/%.o: $(B)/renderer_oa/glsl/%.c Title: Re: OpenArena 0.8.8 source Post by: sago007 on May 20, 2014, 03:07:45 PM I created a version that I could get to compile:
https://github.com/sago007/engine I just compiled and launched the game. Appears to work ok. I removed Q3ROASTRINGOBJ and related. I could not see any problems related to that. Failed to trigger travis, so I do not know if my changes to get Travis to compile without xmp works. Title: Re: OpenArena 0.8.8 source Post by: fromhell on May 20, 2014, 06:41:16 PM I also tried to do make a USE_FALLBACK_GLSL var for the makefile to disable that but I failed that too, so I didn't commit that.
I still don't get why it doesn't work, I copied RGL2's process as closely as I could.... :/ |