Continued shader discussion

[Rick]

So as to not derail the Master Servers thread..

 

Is it really necessary to have it give out a warning when a #### or *** comment is used? I mean it seems kind of pointless to have what looks to be a detriment included, which isn't a detriment in regular JAMP. If possible, you guys should include a 'custom map' friendly version of OpenJK once a stable 1.0 version is out for download to go along with it. And we're not even talking a few easily editable maps, over 60% of the maps in my base folder have an issue with working with OpenJK. Some will miss blades of grass, some will have a missing texture-looking skybox, some will be full of missing textures and so on and so forth, so it doesn't look like an issue that can be fixed by editing the maps unless there's someone willing to go through the entirety of the maps in the files section on jkhub.. It seems like an issue that can easily be fixed with OpenJK by just using JAMP-type acceptance of these type of comments in the shader file.

 

Unless it literally makes it impossible to include these comments in an 'open sourced' version of the JAMP exe like OpenJK is.

[Futuza]

If you want to write a parser to deal with #### comments no one is stopping you, the problem is it is actually a lot of work due to the way parsing is currently implemented just in order to get shaders that are non standard to work.  You could always just edit the problem shaders in the maps that don't work to use proper comments.  Probably could do all the maps you have with a nice script to remove ###'s.

 

I agree it'd be nice, but the problem is mappers who used #### were not doing it correctly and its too much work to get it to work.  Most of the maps I know about that did this incorrectly, have corrected versions (for example Atlantica) that their creators re-released.  Unless you find someone willing to do it - I don't think it is going to happen.

 

Look at that ensiform likes you!

Edited January 8, 2015 by Darth Futuza

[Rick]

So basically it's a case of the open sourced version of JAMP simply not being able to run the #### comments, and there being no known way to set it back up to how it is in JAMP?

[Xycaleth]

The fact that vanilla JKA supported # comments was a bug rather than being by design. But I agree that OpenJK should try to keep 100% compatibility with the original where it can. If nobody else is going to look at it, I'll see about actually adding the functionality in properly, but issue a warning in the console to say that your shader is potentially problematic. This probably won't be for the first release though.

[ensiform]

Technically it is a detriment because while it appears on the surface to do no harm it is allocating extra shaders(*2 for the hash) for potentially being there.  Every time it hits one of those in your shader files.
 
The warnings are were not put in place to protect against these types of incorrect shaders, they just happen to fall under the same category.  There are a few types of shader syntax bugs that can cause the rest of the shader chain to literally break which is what this is there for.  And why we really shouldn't revert totally back to archaic basic parsing with no syntax checking at all.
 
The fact that it now displays the warning now shouldn't be that hard for someone to fix the shader files.  Its not like you have to recompile each map.
 

So basically it's a case of the open sourced version of JAMP simply not being able to run the #### comments, and there being no known way to set it back up to how it is in JAMP?

No that isn't hard just see above in this post as to why choosing not to for now.

[Xycaleth]

We could add support for # comments but issue a warning when it's encountered. This way you don't over-allocate and the shader remains compatible.

 

At the end of the day, the final result is all the players see. He/she doesn't know or care about how it's done, or even if it was intentional. Rejecting shaders with # comments would be a break in compatibility which you push for a lot in other areas of the code, so I don't see any reason to break compatibility here.

[ensiform]

But I still refuse to allow it on a global scale in all of COM_Parse.

[Xycaleth]

That's fine. We can write specific code for shaders only.

[ensiform]

How's this?  Seems to work by not skipping the file anymore.

 

http://slexy.org/view/s20xus2djt

 

I need a map that for sure was still affected that isn't ord mantell rp to know for sure.

[Xycaleth]

Looks good to me except you only need to match one # at the start of the line, not two.

[ensiform]

Yea but then you can end up with # randomly being skipped, at least in COM_Compress, no?

[Futuza]

 

How's this?  Seems to work by not skipping the file anymore.

 

http://slexy.org/view/s20xus2djt

 

I need a map that for sure was still affected that isn't ord mantell rp to know for sure.

 

Looks good to me.  (Assuming Xycaleth's concern will be okay).  The only thing I'd add is maybe change the warning description a bit so people are less likely to be confused by why they're getting an error warning.  eg:

ri->Printf( PRINT_WARNING, "WARNING: Depreciated # style shader comment \"%s\" on line %d in file %s.  Please correct to use c++ style comment syntax.\n", shaderName, shaderLine, filename );

Looks good to me except you only need to match one # at the start of the line, not two.

Lol...does this non-standard comment style even have any specifications?  Python style #'s?  Or...two required?  What are most of the broken map shaders using?

[ensiform]

Pretty sure they just keep reusing someones old shader that has ########## in it, from Scziio or from cantina_mo.shader etc.

 

Would rather leave it there, it says line ignored now as well.  Scare people to pushing the map devs to fix it would be best. 

######################
////// Starport //////
######################

[Futuza]

Pretty sure they just keep reusing someones old shader that has ########## in it, from Scziio or from cantina_mo.shader etc.

 

Would rather leave it there, it says line ignored now as well.  Scare people to pushing the map devs to fix it would be best. 

I can appreciate the attitude (since these shader copiers should learn), but a lot of the old mappers aren't going to fix them since they've left JKA.  :/

[eezstreet]

# shouldn't be allowed because COM_Parse uses C-like syntax. Wouldn't really make sense to support it.

[Futuza]

# shouldn't be allowed because COM_Parse uses C-like syntax. Wouldn't really make sense to support it.

But then it breaks a lot of people's old shaders that work with vanilla jka and they complain that openjk isn't backwards compatible.

[ensiform]

They don't work in vanilla they just appear to do nothing, cluttering shader text.  Which of course the users don't understand but ._.

[Futuza]

They don't work in vanilla they just appear to do nothing, cluttering shader text.  Which of course the users don't understand but ._.

Such is the life of a software developer.

[ensiform]

Vanilla never actually treated it as a comment, ever.

[eezstreet]

If I remember correctly, # actually makes the load times WORSE

[ensiform]

If it did, it would be insignificant with todays computers.  No FUD please.

[Rick]

I'm not asking you guys on editing your mod specifically to fit me. It's your mod and it's up to you on how you want to make it, but all I'm saying is that if there's a patch of some sort for this issue that you'll find yourself with a lot more players who use custom maps that will use your mod. Why? Because from my point of view, I'd rather stick with base JAMP until I'm required to use OpenJK if it means having to go through the 20/30+ maps in my base folder and editing each and every one of their shader files. Let's not even bring up the models/skins who use this as well. Like I said, you're the mod's developers and it's your choice on what to do with your mod, and I think it's great for people who want to play on the standard basejka maps but if you want to expand you're gonna need backwards compatibility, otherwise you're expecting people to re-edit all of their maps as well as have future map makers not repeat the same mistake, which is pretty hard to do considering they've been doing it for the past 12 years since JKA's been out.

[Archangel35757]

 

 

How's this? Seems to work by not skipping the file anymore.

 

http://slexy.org/view/s20xus2djt

 

I need a map that for sure was still affected that isn't ord mantell rp to know for sure.

Looks good to me. (Assuming Xycaleth's concern will be okay). The only thing I'd add is maybe change the warning description a bit so people are less likely to be confused by why they're getting an error warning. eg:

ri->Printf( PRINT_WARNING, "WARNING: Depreciated # style shader comment \"%s\" on line %d in file %s.  Please correct to use c++ style comment syntax.\n", shaderName, shaderLine, filename );

Lol...does this non-standard comment style even have any specifications? Python style #'s? Or...two required? What are most of the broken map shaders using?

In the warning note it should be "Deprecated" and NOT "Depreciated"

[ensiform]

Rick, its primarily not a mod.  Please stop calling it one.

 

You personally wouldn't have to.  In fact 1 pk3 with all the shader fixes could actually fix all of them.

 

I would hardly call this lacking of backwards compatibility.  Sure some _shaders_ are broken but the maps actually work, the game works.

 

Regardless.  Measures will be taken to allow your broken map shaders and skin/model shaders.

[Futuza]

^^Wait he can?  How?

 

 

In the warning note it should be "Deprecated" and NOT "Depreciated"

Great.  Trying to depreciate me are you?