- April 8, 2012 at 1:30 am #30820
Please instruct on how to compile for the SGX 535 or 543 with PVUniSCoEditor. I can get 1.6 to open, but I have no idea where to put the SGX compilation files, in order to achieve anything but a crash, upon character entry. This is for OS X. (“MacOS” won’t even exist soon so I suggest updating the name.)
Jessy 2012-04-08 01:34:05April 10, 2012 at 9:32 am #35705
If you bring up the Preferences dialog (Edit > Preferences) and then switch to the Compiler Settings tab, you can select which compiler to use and also the location for temporary files (this must be a user-writeable location).
However, we have never seen PVRUniSCoEditor crash because an incorrect path has been specified. Which version of OSX are you running and where abouts do you have the SDK extracted?
Also thanks for the information regarding the name change. We are aware of this and will most probably take action when Mountain Lion is officially released.April 10, 2012 at 11:44 am #35706
Thanks for the info.Arron wrote:If you bring up the Preferences dialog (Edit > Preferences) and then switch to the Compiler Settings tab, you can select which compiler to use and also the location for temporary files (this must be a user-writeable location).
With version 1.5, I’ve have this, working okay for several months:
GLSL ES Compiler: /Applications/PVRUniSCo/OGLES/PVRUniSCo_SGX53x
Location for temporary files: .Arron wrote:However, we have never seen PVRUniSCoEditor crash because an incorrect path has been specified. Which version of OSX are you running and where abouts do you have the SDK extracted?
I’m on 10.7.3 and don’t have an SDK installed, just PVRUniSCoEditor. I tried version 1.6. Location for temporary files remained the same (the default), but I tried to use the new files for the SGX 535 and 543, linked above, instead of the one I have for the 535. Putting either of them in the location above results in a crash, when any text is entered.
By the way, what’s a “UniSCo”? :-)Jessy2012-04-10 11:46:45April 16, 2012 at 4:42 pm #35707
Martin KrausMemberArron wrote:However, we have never seen PVRUniSCoEditor crash because an incorrect path has been specified. Which version of OSX are you running and where abouts do you have the SDK extracted?
I’ve the same problem with PVRUniSCoEditor crashing when I try to compile shaders. I’m on MacOS X 10.6.8 and installed the SDK to /Users/martin_kraus_germany/Projects/SDKPackage_OGLES2 .
I can use PVRUniSCo and PVRShaman without problems; thus, I strongly suppose it is a problem with the PVRUniSCoEditor executable.
Since I used PVRShaman for the first time today I have a few comments:
It might make sense to have the semantics more compatible with the uniforms of the OpenGL compatibility profile, see Section 7.4 of: http://www.opengl.org/registry/doc/GLSLangSpec.4.10.6.clean.pdf . For example, the type of the inverse transposed matrices should be mat4 (not mat3) and there should be transposed matrices (e.g. WORLDVIEWT). I assume including additional uniforms is not a big deal but it would help developers a lot if they can rely on the same standard uniforms. (By the way, the reason for using the uniforms of the OpenGL compatibility profile is NOT that the OpenGL compatibility profile was important (it obviously isn’t for OpenGL ES); however, several game engines (at least Unity and Blender) support the same uniforms as in the compatibility profile, which makes them a de-facto standard and it makes it possible to use the same GLSL shader on multiple platforms without having to worry about setting uniforms.)
It would be really cool if PVRShaman could use cmd+s, cmd+c, cmd+v, etc. on Macs instead of ctrl+s, ctrl+c, ctrl+v, etc. I’ve pressed the wrong key combinations dozens of times today.
A menu point for saving the POD file would be really nice. In particular because the save button is often grayed out even if I have changed the POD file (e.g. after adding a new material). I’ve lost several changes because I started to rely on the dialog box asking to save the file when closing it but sometimes that didn’t appear and my changes were just lost.
When I use (in this order)
#define gl_ModelViewMatrix glt_ModelViewMatrix
uniform mat4 glt_ModelViewMatrix;
in the GLSL code and the semantics
UNIFORM glt_ModelViewMatrix WORLDVIEW
I get a warning:
warning: Variable glt_ModelViewMatrix has type of ‘gl_ModelViewMatrix’ which differs from semantic WORLDVIEW of type ‘mat4’ /…/unity_texture.pfx
The solution is to switch the lines in the GLSL code, i.e.:
uniform mat4 glt_ModelViewMatrix;
#define gl_ModelViewMatrix glt_ModelViewMatrix
It appears that the warning is based on an incorrect parsing of the preprocessor directive.
Finally, concerning the fact that the old version of PVRUniSCoEditor wasn’t broken, it would be cool if you could also offer old versions of all SDKs such that developers can download the working versions if something breaks in a new version.
Martin Kraus2012-04-16 16:45:44April 18, 2012 at 3:10 pm #35708
Jessy: Thanks for the extra info. We can reproduce the problem so we will look in to fixing this issue ASAP and get a new version on the website in the next few days. I’ll reply to the post when it’s ready to go. I’ve filed this as BRN36872.
PS. I believe UniSCo stands for ‘Unified Shader Compiler’.
Thanks for the feedback regarding PVRShaman. We are always looking to improve and add to the list of semantics for Shaman so I’ll make a note of your suggestions and we will look in to adding them in the next release.
Regarding the incorrect OSX shortcut keys – we are revising the GUI for our applications and this should be resolved in the coming release.
The toolbar icon for Save is context specific depending on which tab you have open (Scene or Editor). So if you are currently viewing the editor and the file doesn’t have changes (but the POD does), the save icon will be greyed out. However, closing the application should warn you that the POD has unsaved changes?
You’re indeed correct in that the warning is based on parsing the shader however there appears to be an issue when taking the preprocessor in to consideration. I’ll mark this as a bug.
EDIT: Filed as BRN36873.
We don’t normally provide older SDKs on the website because this could be confusing to users but we can supply older builds on a per-user basis if requested.
Regards.April 18, 2012 at 3:38 pm #35709
Thanks for you answer!Arron wrote:The toolbar icon for Save is context specific depending on which tab you have open (Scene or Editor). So if you are currently viewing the editor and the file doesn’t have changes (but the POD does), the save icon will be greyed out.
Ok, I didn’t expect this. My short answer is: “Don’t mode me in!”
My longer answer: this is a bad user design because
a) the effects editor has its one save button (thus why duplicate that functionality?)
b) the main save button would be the only button that depends on which tab is open (as far as I can tell)
c) the main save button is placed in proximity to the hierarchy of the POD file, thus, it makes sense to always associate it with the POD file
d) if I manipulate the POD hierarchy (e.g. by adding a material), I should be able to save this change by clicking the save button (whatever tab I have open)
Thus, I would suggest to avoid that dependency.Quote:However, closing the application should warn you that the POD has unsaved changes?
It usually does but as far as I remember it didn’t in a few cases. If it happens again, I’ll try to reproduce the circumstances and let you know.April 19, 2012 at 11:25 am #35710
A fixed version of PVRUniSCoEditor is now available for download in the ‘Utilities’ section of the website.
Martin: Thanks for the feedback. As I mentioned in a previous post we are currently reviewing and redesigning the GUI for our utilities so your feedback will definitely be taken in to account during the review :).
If you can reproduce the issue of failing to save the POD when the application is closed please let us know and we’ll mark it as a bug.
Arron.April 19, 2012 at 2:13 pm #35711Arron wrote:A fixed version of PVRUniSCoEditor is now available for download in the ‘Utilities’ section of the website.
Thanks! The topic of this title is proven inaccurate. I’m doing exactly what I did with the previous version, but now the shaders actually compile.Jessy2012-04-19 14:13:36