Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Studio Chat / Shader missing some attributes

Author
Message
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 27th Jul 2019 17:30
So the beta worked ok, but the final release won't run at all.

Shaders fail to compile saying "agk_time" and "vec3 position" are no longer valid.

Time I can live without....position I used across multiple shaders.
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 27th Jul 2019 18:23
'Position' as an attribute or varying? There are currently some structural limitations in the shader compiler that requires varyings to line up exactly sequentially between the vertex shader and the fragment/pixel shader. I'm using 'position' as a label as an attribute with no problems. If you can post an example of a shader that isn't compiling for you, it may help determine what is happening.
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 29th Jul 2019 12:32
As an attribute.

It used to be passed in via AppGameKit I believe, but now it's not. I'm not sure if posvarying or pos would work instead......I assume there must still be an attribute passed in to set the vertex positions.

It's very frustrating....even the beta didnt work under opengl, and it was supposed to be the same. Image allocation seemed broken, and global lighting didnt work the same.
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 29th Jul 2019 18:55
I'm using it and it is working ok, so there must be some difference. Is the error message maybe something slightly different?

Are you using the 'position' label in both the vertex and fragment shader in some way? Do you have the shader handy that you could post for analysis? Or a sample project using it that can show the error?
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 29th Jul 2019 19:08
No, it's only used in the vertex shader, it's used for varying purposes from moving grass to the ocean.

There's no easy version I can post I don;t think....I used about ten custom shaders and it's not until the main sync that it errors, so I'm not even sure which one is giving the error right now.

I'll try identifying it and will post again....
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 29th Jul 2019 19:15 Edited at: 29th Jul 2019 19:18
Ah, I found the error with your tip....my ocean shader uses POSITION as an attribute in the VS, and as a varying in the PS.....seems to be the issue.

I've now changed the PS to an attribute, and it fails to compile. If I disable the ocean shader, it runs and loads now.

EDIT: but actually nothing works - the landscape doesn't render at all. Neither of these isssues were in the beta, so I assume it's the vulkan engine that's the issue....but from what I've seen, there no apparent benefit anyway? Memory impact seems bigger and no framerate benefit?
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 29th Jul 2019 19:21
Hmmmm...so a simple scene that runs at 60-70fps in classic, now hitting 20fps in Studio....and that's without the landscape even rendering!!!
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 29th Jul 2019 19:27
So here's the same simple scene, in Classic and Studio.......Classic 2.5 times faster....and Studio isn;t even rendering the landscape for some reason.

Attachments

Login to view attachments
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 29th Jul 2019 19:33
Yes, the new shader compiler is a little pickier and more aware of variable conflicts and sequencing. Best to keep things split when needed as standard practice, then pass a value over to a new/different label if it needs to be used in both. Keep varyings for shared values and make sure they are exactly sequential. Things may change in the future, but these are important steps for now.

There can be a number of reasons for the other issues, any one of which may only be guesswork without sample code. But Vulkan also doesn't necessarily always mean global performance improvement, a number of factors come in to play. There is also a potential issue with how the Vulkan engine is currently rendering that someone else reported which could be having an additional impact (improper screen clipping). And there is likely still some tuning/tweaking left to do.

Login to post a reply

Server time is: 2024-02-26 19:57:44
Your offset time is: 2024-02-26 19:57:44