gameboy Posted November 18, 2015 Share Posted November 18, 2015 Very good function to achieve, I ask you what time to complete it? We want to test it as soon as possible. Link to comment Share on other sites More sharing options...
nikagra Posted November 18, 2015 Author Share Posted November 18, 2015 #elif and #include support is quite easy to implement. #elif should be very similar to #if, to implement #include one should add contents of included file and recursively run preprocessor on it (maybe limit maximum number of include levels to prevent circular dependencies). This two should take up to 3-4 days of workExpressions in #define is a non-trivial feature. It's hard to estimate it at this point 1 Link to comment Share on other sites More sharing options...
gameboy Posted November 19, 2015 Share Posted November 19, 2015 Hello, nikagra. You encounter difficulties, I think the game development team will help you. My friend wraitii he might be able to help you in this. Link to comment Share on other sites More sharing options...
gameboy Posted November 19, 2015 Share Posted November 19, 2015 (edited) I think we'll be able to experience your masterpiece by the end of this month. Come on, man. Edited November 19, 2015 by gameboy Link to comment Share on other sites More sharing options...
nikagra Posted November 19, 2015 Author Share Posted November 19, 2015 I knew I can count on you Link to comment Share on other sites More sharing options...
gameboy Posted November 22, 2015 Share Posted November 22, 2015 I think you must have made new progress, is it, my friend? Link to comment Share on other sites More sharing options...
nikagra Posted November 22, 2015 Author Share Posted November 22, 2015 (edited) Initial implementation of #include directive is ready.This is only initial implementation. I'm also not sure if it works in every case (probably not) and it still has some limitations, e.g. changes in included files are not tracked by file system. Preprocessor is designed to operate on single string buffer, if we want to include another file we have to overcome this limitation. I've chosen to create deep copies of included macros and attach them and preprocessed include file to main (current processing shader) file.You can test this changes with Skirmish map type Acropolis Bay (2). I've prepared some testing shaders. Check header.glsl and edge_detection.vsWhat do you think?preprocessor_include_initial_impl.zip Edited November 22, 2015 by nikagra Link to comment Share on other sites More sharing options...
nikagra Posted November 22, 2015 Author Share Posted November 22, 2015 In my opinion we should adapt FXAA at least as an option for low end PCs. I would rather use FXAA than NoAA. When we prepare SMAA we can add it as second option or remove FXAA 1 Link to comment Share on other sites More sharing options...
Lion.Kanzen Posted November 22, 2015 Share Posted November 22, 2015 I highly recommend use our trac to upload, submit patches, changes.http://trac.wildfiregames.com/ Link to comment Share on other sites More sharing options...
gameboy Posted November 23, 2015 Share Posted November 23, 2015 nikagra，my friend! Your patch is very good, this is a great attempt, I personally think that SMAA will bring us better graphics, you do not have to worry about our computer configuration, and now the configuration of the computer has fully supported the processing of advanced graphics, so SMAA as the first option is a better choice. Thank you I think you'll do better, my friend. Come on, please keep trying to do better. Link to comment Share on other sites More sharing options...
nikagra Posted November 23, 2015 Author Share Posted November 23, 2015 (edited) I highly recommend use our trac to upload, submit patches, changes.http://trac.wildfiregames.com/I've created task for thisBy the way, could you please explain why such custom preprocessor is used? According to The OpenGL® Shading Language (1.10.59) spec, all directives are supported by built-in preprocessor (no #include support for to obvious reasons). I've checked Ogre3D ssource, there is no clear explanation here also Edited November 23, 2015 by nikagra 1 Link to comment Share on other sites More sharing options...
niektb Posted November 23, 2015 Share Posted November 23, 2015 Better ask on IRC, I think that gives you a higher chance of getting a useful answer. Link to comment Share on other sites More sharing options...
Stan` Posted November 23, 2015 Share Posted November 23, 2015 One comment about the patch style itself, we use tabs not spaces About the submission to trac, you can submit diffs directly we have a viewer for it.I can't really see the difference between with and without the patch, so it might be more subtle than I expected.WithWithout Link to comment Share on other sites More sharing options...
nikagra Posted November 23, 2015 Author Share Posted November 23, 2015 (edited) I can't really see the difference between with and without the patch, so it might be more subtle than I expected.Patch only adds partial support for #include directive. It's too early for SMAA yet Edited November 23, 2015 by nikagra Link to comment Share on other sites More sharing options...
Stan` Posted November 23, 2015 Share Posted November 23, 2015 Oh right my bad 1 Link to comment Share on other sites More sharing options...
gameboy Posted November 24, 2015 Share Posted November 24, 2015 (edited) My friend, nikagra. What I know is that the GLSL version of the 0AD game is OPENGL2.0, and the development team is developing OPENGL4.0+Here is a patch you can refer to it, perhaps to help you.http://trac.wildfiregames.com/ticket/3641You can also go directly to the chat channel to go directly to Yves to discuss this matter, he is now developing the work to support OPENGL4.0+. He can help you.http://webchat.quakenet.org/?channels=0ad Edited November 24, 2015 by gameboy Link to comment Share on other sites More sharing options...
niektb Posted November 24, 2015 Share Posted November 24, 2015 Actually, Philip isn't doing anything with a new render. 1 Link to comment Share on other sites More sharing options...
gameboy Posted November 24, 2015 Share Posted November 24, 2015 Actually,PHILPS is working on the job, but you don't know it Link to comment Share on other sites More sharing options...
wraitii Posted November 24, 2015 Share Posted November 24, 2015 No, it's Yves that is working on upgrading the renderer to use OpenGL 4. However, we plan to still maintain an OpenGL 2 rendering system in parallel. 1 Link to comment Share on other sites More sharing options...
gameboy Posted November 24, 2015 Share Posted November 24, 2015 We will see it at Christmas time (OPENGL4.0+), my friend? Link to comment Share on other sites More sharing options...
niektb Posted November 24, 2015 Share Posted November 24, 2015 No 1 Link to comment Share on other sites More sharing options...
gameboy Posted November 24, 2015 Share Posted November 24, 2015 Maybe it's time to wait until January 2016, and I guess right? Link to comment Share on other sites More sharing options...
niektb Posted November 24, 2015 Share Posted November 24, 2015 Wait till January 2017, before asking again. But I think we're going offtopic. Better stick to the SMAA topic (in case you can help nikagra with his technical questions ofc, else stop posting in this topic). 3 Link to comment Share on other sites More sharing options...
gameboy Posted November 24, 2015 Share Posted November 24, 2015 Okay, that's a long wait. Let's continue to help our new friends. Link to comment Share on other sites More sharing options...
wraitii Posted November 30, 2015 Share Posted November 30, 2015 Hey Mikita, I review your patch on Trac. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now