GrosBedo
Member
Cakes 20
Posts: 710
|
|
« Reply #25 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.
|
|
|
Logged
|
|
|
|
Hitchhiker
Member
Cakes 11
Posts: 181
|
|
« Reply #26 on: March 09, 2012, 11:53:03 AM » |
|
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-.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
|
|
|
Logged
|
|
|
|
hairball
Half-Nub
Cakes 2
Posts: 52
|
|
« Reply #27 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. 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. 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. @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? 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* 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.
|
|
|
Logged
|
|
|
|
fromhell
|
|
« Reply #28 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.
|
|
« Last Edit: March 09, 2012, 10:43:11 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
|
|
|
Hitchhiker
Member
Cakes 11
Posts: 181
|
|
« Reply #29 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.
|
|
|
Logged
|
|
|
|
fromhell
|
|
« Reply #30 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
|
|
|
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
|
|
|
hairball
Half-Nub
Cakes 2
Posts: 52
|
|
« Reply #31 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_enginewith 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
|
|
« Last Edit: March 10, 2012, 01:46:15 PM by hairball »
|
Logged
|
|
|
|
Gig
In the year 3000
Cakes 45
Posts: 4394
|
|
« Reply #32 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?
|
|
|
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.
|
|
|
Hitchhiker
Member
Cakes 11
Posts: 181
|
|
« Reply #33 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?
|
|
|
Logged
|
|
|
|
hairball
Half-Nub
Cakes 2
Posts: 52
|
|
« Reply #34 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?
|
|
|
Logged
|
|
|
|
|
GrosBedo
Member
Cakes 20
Posts: 710
|
|
« Reply #36 on: March 14, 2012, 07:18:41 PM » |
|
@hairball: <offtopic>What is the Reaction codebase?</offtopic>
|
|
|
Logged
|
|
|
|
fromhell
|
|
« Reply #37 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.
|
|
|
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
|
|
« Reply #38 on: March 15, 2012, 01:49:04 AM » |
|
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/ModCompat/Reaction
|
|
|
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.
|
|
|
GrosBedo
Member
Cakes 20
Posts: 710
|
|
« Reply #39 on: March 15, 2012, 05:26:06 AM » |
|
Oh nice! I didn't know this mod was still maintained!
|
|
|
Logged
|
|
|
|
Hitchhiker
Member
Cakes 11
Posts: 181
|
|
« Reply #40 on: March 15, 2012, 12:58:54 PM » |
|
thanks for the link hairball! it is definitely good news. looking forward to seeing James' renderer in action!
|
|
|
Logged
|
|
|
|
sago007
Posts a lot
Cakes 62
Posts: 1664
Open Arena Developer
|
|
« Reply #41 on: March 19, 2012, 12:08:54 PM » |
|
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?
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.
|
|
|
Logged
|
There are nothing offending in my posts.
|
|
|
Gig
In the year 3000
Cakes 45
Posts: 4394
|
|
« Reply #42 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?
|
|
« Last Edit: March 19, 2012, 05:10:18 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.
|
|
|
GrosBedo
Member
Cakes 20
Posts: 710
|
|
« Reply #43 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(): if(strcmp(Cmd_Argv(0), "say") && strcmp(Cmd_Argv(0), "say_team") ) Cmd_Args_Sanitize(); //remove \n, \r and ; from string. We don't do that for say-commands because it makes people mad (understandebly) VM_Call( gvm, GAME_CLIENT_COMMAND, cl - svs.clients );
The strcmp should be replaced by a Q_stricmp or Q_strncmp to avoid potential crashing when clientCommand string length is below 3 characters.
|
|
|
Logged
|
|
|
|
sago007
Posts a lot
Cakes 62
Posts: 1664
Open Arena Developer
|
|
« Reply #44 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(): if(strcmp(Cmd_Argv(0), "say") && strcmp(Cmd_Argv(0), "say_team") ) Cmd_Args_Sanitize(); //remove \n, \r and ; from string. We don't do that for say-commands because it makes people mad (understandebly) VM_Call( gvm, GAME_CLIENT_COMMAND, cl - svs.clients );
The strcmp should be replaced by a Q_stricmp or Q_strncmp to avoid potential crashing when clientCommand string length is below 3 characters. 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. 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.
|
|
|
Logged
|
There are nothing offending in my posts.
|
|
|
hairball
Half-Nub
Cakes 2
Posts: 52
|
|
« Reply #45 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.
|
|
|
Logged
|
|
|
|
Hitchhiker
Member
Cakes 11
Posts: 181
|
|
« Reply #46 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?
|
|
|
Logged
|
|
|
|
fromhell
|
|
« Reply #47 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.
|
|
|
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
|
|
|
sago007
Posts a lot
Cakes 62
Posts: 1664
Open Arena Developer
|
|
« Reply #48 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.
|
|
|
Logged
|
There are nothing offending in my posts.
|
|
|
Hitchhiker
Member
Cakes 11
Posts: 181
|
|
« Reply #49 on: June 25, 2012, 11:50:27 AM » |
|
Some updates. But not OA related.
|
|
|
Logged
|
|
|
|
|