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 / The First Public Vulkan Test

Author
Message
LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 12th Jul 2019 15:57 Edited at: 12th Jul 2019 20:37
Hi All,

While Rick is away, I have been given the honor of asking all AppGameKit Studio pre-order users to try out our new Vulkan renderer. You will know it works when everything looks exactly the same The idea is that you can move your projects from OpenGL to Vulkan without ever worrying that it will visually change your app or game in any way. I have attached a debug version of the Windows Player, which will detect if you have Vulkan hardware and use it, or if you don't have Vulkan, it will revert to using standard OpenGL to maintain backwards compatibility. Here are the steps you can try:

1. Unzip the attached
2. Run the VulkanPlayerDebug.exe executable
3. Launch AppGameKit Studio Alpha\Beta and load an example program (2D or 3D)
4. press the BROADCAST icon (to the right of the RUN button)
5. The VulkanPlayerDebug player window will now show your app loading and running
6. If you have Vulkan hardware, the app running is powered by a brand new Vulkan renderer (no small feat!)

We are looking for bugs at this stage, specifically any visual differences you notice from running examples on your system, or even your own projects you may be working on. There are some missing features, which you can ignore for the moment, including terrain rendering, getimage and makememblockfromimage will not work and video playback is untested. If anything else does not work for you, please do post here to let us know. We want a solid first release and your help will be much appreciated in getting us over the line with a version that hits the ground running. Many thanks and happy app and game making!
Hogging the awesome since 1999

Attachments

Login to view attachments
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 12th Jul 2019 17:03 Edited at: 12th Jul 2019 17:05
Encountered issues so far:

- Depth render images don't seem to work properly, so shader based shadow systems do not render correctly (I've sent an e-mail with an updated 'NormalEnvironmentMapping' project to test with both rendering modes to illustrate).

- Odd UV behavior illustrated in managing more than one texture index on an object using a shader. I've also included a sample project in my e-mail to show this issue.

- Rendering performance of text/sprites/2D elements to a render image seems extremely slow compared to the OpenGL version. The framerate can drop by as much as 90% in comparison, depending on quantity.

- Antialiasing does not appear to work at all when enabled.

- Object loading appears to be extremely slow. A sample test of loading a few objects (X format) took 58 seconds in the Vulkan player while it took 16 seconds in the OpenGL player. The problem expands the more objects that are loaded.

- Received an: 'Error:vkCreateBuffer error:-1000011001 in main.agc at line 144644' message for an unknown reason at a line with the commands 'Render2DFront:SetRenderToScreen'.

- Received other errors in different projects: 'Error:vkCreateBuffer error:-1000011001 in main.agc at line X' messages for unknown reasons at lines with commands like 'Render():SetRenderToScreen()'. As these errors occur at screen/render/renderimage commands, I can't really determine what the cause might be or what other command(s) might be involved. They also seem to happen intermittently, the game/project runs for a while, sometimes up to 10 seconds or more, then this crash occurs.

- Received an 'Error:vkQueueSubmit error:-4 in main.agc at line 102888' message possibly due to a nearby CreateMemblockFromImage command.


I haven't been able to test much else yet due to errors/crashes encountered and the missing 'CreateMemblockFromImage' command which many of my projects depend on. I'll be ready to proceed with more as possible though as the opportunity becomes available.
Bored of the Rings
User Banned
Posted: 12th Jul 2019 17:28
got an error when running theVulkanPlayerDebug.exe program, but assuming because my PC graphics cards doesn't support Vulkan, but thought I'd post anyway.

Professional Programmer, languages: SAS, C++, SQL, PL-SQL, DBPro, Purebasic, JavaScript, others

Attachments

Login to view attachments
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 12th Jul 2019 18:05 Edited at: 15th Jul 2019 17:28
Thanks for giving it a test, I've attached a new version that should fix a few errors.

Quote: "Depth render images don't seem to work properly"

This is probably because the Vulkan renderer is using an inverted depth buffer, so values of 1.0 are near the camera whilst values of 0.0 are further away. It does this because using an inverted floating point depth buffer solves almost all depth fighting issues when drawing large depth ranges. I'll add a new command so you can tell if the renderer is using an inverted depth buffer or not. If you can make use of the AppGameKit shadow routines then this will be handled automatically.

Whilst testing this I also noticed your shader "normalspecrpbrs" has the varyings in a different order between the VS and PS files, this will cause a problem for our Vulkan renderer as it currently needs varyings to be in the same order in both shaders. It's possible we may be able to work around it in future but for now it is easier to make sure they match.

Quote: "Odd UV behavior illustrated in managing more than one texture index on an object using a shader"

This also appears to be a shader varying issue, "fadetopbottomwarp" has the varyings in a different order in the VS and PS files, fixing this seems to make it run as expected.

Quote: "Rendering performance of text/sprites/2D elements to a render image seems extremely slow compared to the OpenGL version"

This is a debug version to catch any bugs. The release version will perform better but may crash the GPU driver if it still has serious bugs.

Quote: "Antialiasing does not appear to work at all when enabled"

On my todo list

Quote: "Object loading appears to be extremely slow"

This is due to the debug version

Quote: "Received an: 'Error:vkCreateBuffer error:-1000011001"

Please try the attached version and see if that fixes it

Edit: Newer version attached in a later post

Attachments

Login to view attachments
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 12th Jul 2019 18:14
Quote: "got an error when running theVulkanPlayerDebug.exe program, but assuming because my PC graphics cards doesn't support Vulkan"

Yeah it looks like your machine doesn't support Vulkan, it's possible a driver update is available for your card. But in any case it should have fallen back gracefully to OpenGL2 so that is technically a bug. The VulkanDebugPlayer3 version attached above should fix this and tell you it has dropped back to OpenGL2
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 12th Jul 2019 18:53 Edited at: 12th Jul 2019 19:03
Quote: "This is probably because the Vulkan renderer is using an inverted depth buffer, so values of 1.0 are near the camera whilst values of 0.0 are further away. It does this because using an inverted floating point depth buffer solves almost all depth fighting issues when drawing large depth ranges. I'll add a new command so you can tell if the renderer is using an inverted depth buffer or not. If you can make use of the AppGameKit shadow routines then this will be handled automatically."


Ok, good to know. Can the Vulkan renderer can be made to auto invert or do whatever is needed for consistent behavior? That would allow developers a better integration with both the Vulkan and OpenGL renderers automatically without trying to manually detect and invert to do whatever would otherwise be required in code and/or shaders (likely providing a more consistent codebase and shaders).

Quote: " Whilst testing this I also noticed your shader "normalspecrpbrs" has the varyings in a different order between the VS and PS files, this will cause a problem for our Vulkan renderer as it currently needs varyings to be in the same order in both shaders. It's possible we may be able to work around it in future but for now it is easier to make sure they match."


Confirmed on the required sequencing of varying values in shaders, which also explains other strange shader behaviors in other tests. For example, the water shader in the AppGameKit Shader Pack. Seems it's pretty common that varying values are not in the same sequential order in many shaders.

Understood on performance being related to the debug version.

Quote: "Please try the attached version and see if that fixes it"


Still encountering frequent 'Error:vkCreateBuffer error:-1000011001' errors that prevent further testing.
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 12th Jul 2019 19:53
Quote: "Can the Vulkan renderer can be made to auto invert or do whatever is needed for consistent behavior?"

In order to get the benefit of solving the depth fighting issue the depth buffer has to remain inverted throughout the life of the app. This is because floating point depth buffers have lots of precision near 0.0 and less near 1.0, so we put 0.0 at the far plane to gain more precision out there. So if you read an inverted depth image in a shader it will always have 1.0 near the camera and 0.0 at the far plane. You could pass in a shader uniform value that adjusts any calculations based on inverted/non-inverted buffers, or use a separate shader specifically for inverted buffers and choose it based on the current renderer state. The state of the depth buffer (inverted or non-inverted) will not change for the life of the app, so checking once would be enough to make any necessary changes to the app's shaders.

Quote: "Still encountering frequent 'Error:vkCreateBuffer error:-1000011001' errors"

I didn't get that error in the examples you sent me, can you send me one that replicates that error?
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 12th Jul 2019 20:27 Edited at: 12th Jul 2019 20:29
Quote: " So if you read an inverted depth image in a shader it will always have 1.0 near the camera and 0.0 at the far plane. You could pass in a shader uniform value that adjusts any calculations based on inverted/non-inverted buffers, or use a separate shader specifically for inverted buffers and choose it based on the current renderer state. The state of the depth buffer (inverted or non-inverted) will not change for the life of the app, so checking once would be enough to make any necessary changes to the app's shaders."


Ok, I guess I'll need to try and explore how to do that further. I've tried inverting (1.0 - depth) the value in the shader and tried some other ideas without success. There is either binary 'all' shadowing or no shadowing. The depth render image also seems to render in red tones only, so that may be another factor I need to account for that is causing my attempts to fail. Seems to break all shader based AppGameKit shadow systems for now.

Quote: "I didn't get that error in the examples you sent me, can you send me one that replicates that error?"


Certainly, sample project sent.
Qube_
9
Years of Service
User Offline
Joined: 21st Oct 2014
Location: Omnipresent
Posted: 12th Jul 2019 22:52
Any news on when a Mac test version is to be available?
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 13th Jul 2019 01:30 Edited at: 13th Jul 2019 01:34
Tested with a game i was making.
Good news is it seems to render everything perfectly.
Bad news is there seemed to be a significant drop in FPS (Sometimes as low as 23)
I'll email you the project so you can have a look

Attachments

Login to view attachments
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 13th Jul 2019 18:00 Edited at: 13th Jul 2019 18:00

Attachments

Login to view attachments
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 14th Jul 2019 01:26 Edited at: 15th Jul 2019 17:27
Quote: "Any news on when a Mac test version is to be available?"

Not yet, sorry

Quote: "Bad news is there seemed to be a significant drop in FPS"

Yeah that's expected with the debug version, however I did manage to fix your screen scrolling issue, try the attached version.

Quote: "I don't know what the error means but I'm sure it means something to you."

Yeah I think I know what caused that, it should be fixed in the attached version.

Edit: Newer version attached in a later post

Attachments

Login to view attachments
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 15th Jul 2019 01:19
Quote: "GetImage() not supported under vulcan"


If CopyImage() is not supported at the moment is there any recommended way to copy a portion of the screen?
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 15th Jul 2019 03:24 Edited at: 15th Jul 2019 03:25

Attachments

Login to view attachments
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 15th Jul 2019 17:27 Edited at: 16th Jul 2019 16:45
Quote: "If CopyImage() is not supported at the moment is there any recommended way to copy a portion of the screen?"

Currently the only way would be to render directly to an image using SetRenderToImage, but it can't be read back to the CPU yet if you want access to the pixel data.

Quote: "Clear colour doesn't seem to register and i get weird shadow stripes across one of the shapes"

The shadow problem was caused by an incorrect sampling of the shadow image, it should be fixed in the attached version. Note it also includes additional shadow smoothing modes (3 and 4) that use 16 samples instead of 4 which you may prefer. The attached version should also fix the clear color issue.

Edit: newer version attached in a later post

Attachments

Login to view attachments
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 15th Jul 2019 18:14
SetTextDefaultFont is also changing the Print font.
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 15th Jul 2019 22:33 Edited at: 15th Jul 2019 22:41
Ghegheghe: Nice touch blink0k. Great to see it's of some use.
These days was just thinking about picking it up again.


I'm sorry to say though that there are *still* shadow issue's present with the version 7. It shows some serious pixel noise:

It's worst right after launch into the default shadow mode 2. Then it somehow get's less when switched just one time between modes, using the F7 key, which toggles between modes 1, 2 and 3.

Currently on an Asus i7, 8GB laptop with an NVIDIA GTX1050 GPU.
Feel free to try using the included source:
http://www.mediafire.com/file/nspbswj2w5yvzx9/U3D13P_FW_V7.1.rar/file
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 16th Jul 2019 01:34 Edited at: 16th Jul 2019 01:38
Quote: "The attached version should also fix the clear color issue."

I've tried that on a couple of apps and it either crashes or just locks up (See attached project)

Rick : I have learned an immense amount from that app mate. Thank you very much!

Attachments

Login to view attachments
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 16th Jul 2019 16:44
Quote: "I'm sorry to say though that there are *still* shadow issue's present with the version 7. It shows some serious pixel noise"

That looks like an issue with the shadow bias, try a larger value and see if that helps (default is 0.001)

Quote: "I've tried that on a couple of apps and it either crashes or just locks up (See attached project)"

The kart project was causing an assert in the 3D physics, which is ignored by the release version, I've attached a debug version that also ignores it since it is handled gracefully.

This version also fixes a few other bugs with shaders containing texture2DLod commands, VSync on Nvidia GPUs, and particles not blending correctly.

Attachments

Login to view attachments
Niijel2
19
Years of Service
User Offline
Joined: 13th Sep 2004
Location:
Posted: 16th Jul 2019 22:31
Ran agk shader demo - got:-

Compiling E:/programs/Steam/steamapps/common/App Game Kit 2/DLC/Shader Pack/Collection/main.agc
Broadcasting: E:/programs/Steam/steamapps/common/App Game Kit 2/DLC/Shader Pack/Collection/
Compilation finished successfully.
Error:Getting image data is not yet supported in Vulkan in main.agc at line 128
Error:Error: Getting image data is not yet supported in Vulkan in main.agc at line 128 in main.agc at line 128
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 16th Jul 2019 22:56
@Paul:
Quote: "That looks like an issue with the shadow bias, try a larger value and see if that helps (default is 0.001)"

Many thanks Paul. Unbelievable that after looking at my code I see bugs I completely overlooked. Just goes to show that looking back at old code after a break really can make a difference. Have some great new idea's too.

Love the new shadow smoothing modes! Those will come in handy.


@blink0k:
Quote: "Rick : I have learned an immense amount from that app mate. Thank you very much!"

Glad to be of help. It goes the other way round too; learned from your code.

I really have to pick things up ghegheghe.

Niijel2
19
Years of Service
User Offline
Joined: 13th Sep 2004
Location:
Posted: 17th Jul 2019 08:29
I get the following error in latest vulkan test its not present in std debug, line 95 is sync command. It seems to run fine otherwise.
scene consists of 6 simple physics objects a camera and no shadows.
Compiling E:/programs/AgkStudio/testimports/main.agc
Broadcasting: E:/programs/AgkStudio/testimports/
Compilation finished successfully.
Warningresent: Swap chain is out of date in main.agc at line 95
=PRoF=
21
Years of Service
User Offline
Joined: 17th Mar 2003
Location: Milton Keynes, UK
Posted: 17th Jul 2019 18:19
I tried one of my games with the Vulkan Debug Player 9, and it seemed to display fine



I did notice that on the full screen fades (a full screen sprite which changes alpha values to fade) it slowed down a lot, but I expect that's because of the debug version.
janbo
15
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 20th Jul 2019 01:19
Am I late to the party ?
I tested my shader pack and they all work except of those who make use of the depth buffer which are quite a bit
But that's just due to the fact that Vulkan now has inverted depth values. Easy fix if there is a way to check if we are in Vulkan or OpenGL renderer.
Also Is the Depth buffer smaller now ? cause we store the red channel only ? and do we have a downward pointing Y axis internally now ?
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 21st Jul 2019 20:18
I'm having trouble getting my sprite shader to work with VulkanDebugPlayer9. I'm getting an error message along the lines of vec 4 colorVarying or UVVarying does not exist in the vertex shader... I'm not using a vertex shader as it is a sprite shader so not sure what's going on. Has anyone managed to get a sprite shader working?
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 22nd Jul 2019 16:10
I've attached the latest player that should fix a few bugs and now supports GetImage and other image manipulation commands.

Quote: "Swap chain is out of date in main.agc at line 95"

That's fine, it is just saying that the window resized and it needed to update the swap chain to match.

Quote: "Easy fix if there is a way to check if we are in Vulkan or OpenGL renderer"

There will be three new commands you can use to query the current renderer
int IsInvertedDepth() returns 0 on OpenGL and 1 on Vulkan
int GetClipSpaceMode() returns 0 if the clip space is -1 to 1 (OpenGL) or 1 if the clip space is 0 to 1 (Vulkan) this is needed for custom projection matrix creation
int IsTopLeftOrigin() returns 0 on OpenGL and 1 on Vulkan, normally shouldn't need to know as its effects are hidden by AppGameKit by using the agk_invert uniform

Quote: "Also Is the Depth buffer smaller now ? cause we store the red channel only ?"

In OpenGL it just copied the single channel data into all 4 channels, so you had the same value 4 times. Vulkan didn't do this by default so only the red channel contained the data. The version I've attached now copies OpenGL and copies the same value to all 4 channels.

Quote: "I'm getting an error message along the lines of vec 4 colorVarying or UVVarying does not exist in the vertex shader"

The default sprite shader is as follows


The varyings in the vertex and pixel shader must match exactly, case, spacing, everything. Order of varyings used to matter in previous Vulkan players but is no longer required.

Attachments

Login to view attachments
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 23rd Jul 2019 11:46
Great! I've got the sprite shader working (thanks Paul!)... Now, shadows appear messed up in VulkanDebugPlayer12. Example screenshot:

Attachments

Login to view attachments
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 23rd Jul 2019 15:11
Quote: "Will be there some new pixel manipulating commands inside?"

Nothing new at the moment

Quote: "Now, shadows appear messed up in VulkanDebugPlayer12"

Are you using the AppGameKit shadow commands or your own shadow shader? If you are using your own shadow shader then you need to account for depth inversion and clip space differences when creating your shadow projection matrices
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 23rd Jul 2019 21:27
Quote: "Are you using the AppGameKit shadow commands or your own shadow shader?"

I'm using the built in shadows (mode 3).
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 24th Jul 2019 22:32 Edited at: 24th Jul 2019 22:34
Is it possible to force AppGameKit Studio to use OpenGL instead of Vulkan (until the shadows problem is fixed, I can't use it) ?

Re shadows issue: With just one 3d model casting shadows, it all looks fine. As soon as I add more models, all hell breaks loose and I get bits of shadow flying about all over the place... if that helps diagnose the problem.
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 24th Jul 2019 23:05
I'd need to see the project, or a small example that replicates the problem. Does the shadow example that comes with AppGameKit work?
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 25th Jul 2019 00:54 Edited at: 26th Jul 2019 13:35
I'm not at desk right now, but the zombies are all cloned objects... Maybe that's got something to do with it.

I had a look at the shadows example project and it looks fine so I'll have a go at putting a little project together later to test whether it is just an issue with cloned objects.

I tried to get the shadow example project to fail in the same way... even using the same models from my project and using clones etc.... and it's all working fine!

I'll have a go at pinpointing the problem tomorrow. Too hot to do anything right now.

...

I'm not sure yet, but It looks like as soon as any of my zombie's spawn, all the shadows are being built from my sprite image data rather than from a projection of the 3d model!?!? I don't know what's going on yet, but I'll figure it out and let you know what's borken when I do...

@Paul: Definitely a bug as far as I can tell. I have stripped my project right back to bare minimum to highlight the issue and sent you the project files via email. Screenshots below. Thanks.


Attachments

Login to view attachments
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 27th Jul 2019 18:08 Edited at: 27th Jul 2019 19:47
Hi Paul. I somehow managed to "fix" my shadows issue. If you load the zombie model before loading the soldier, then it all works fine so something is definitely broken. It shouldn't matter which order you load the models. I hope it's an easy fix!

edit: Nope... I tried moving the zombie load before the soldier in my proper Zombie RPG project, and sadly it didn't fix the shadows issue so for now I'm going back to AGK2 / Classic.
janbo
15
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 29th Jul 2019 15:16
Screen Culling not working
I'm rendering a 181K poly object which runs at stable 118 FPS looking straight at it.
Now I look into the void and GetPolygonsDrawn() shows me zero, but its still running at the exact 118 FPS.
It's a simple demo with nothing running in the main loop except the camera controller routine.
Doing the same in AppGameKit Classic results in higher FPS as soon as I look away.
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 30th Jul 2019 01:42
Do you get the same result with classic?
janbo
15
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 30th Jul 2019 14:27
As statet above:
janbo wrote: "Doing the same in AppGameKit Classic results in higher FPS as soon as I look away."

I don't get the same result...it gets faster.
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 7th Aug 2019 03:42
Quote: "Screen Culling not working
I'm rendering a 181K poly object which runs at stable 118 FPS looking straight at it.
Now I look into the void and GetPolygonsDrawn() shows me zero, but its still running at the exact 118 FPS.
It's a simple demo with nothing running in the main loop except the camera controller routine.
Doing the same in AppGameKit Classic results in higher FPS as soon as I look away."


Have you reported that on GitHub? That would be a significant performance bottleneck that could account for variations some users have reported between the OGL and Vulkan render paths.

Login to post a reply

Server time is: 2024-03-29 08:13:08
Your offset time is: 2024-03-29 08:13:08