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 / AppGameKit Studio v1.0 - slowest performance of all AppGameKits and judders the most too?

Author
Message
Qube_
9
Years of Service
User Offline
Joined: 21st Oct 2014
Location: Omnipresent
Posted: 6th Aug 2019 20:09 Edited at: 6th Aug 2019 20:09
Link
Tested the latest version of Studio on Windows 10 and with Vulkan enabled and vSync on it's all nice and smooth with no juddering, which is good news.

If I turn vSync off then full screen I only get 220FPS and windowed mode I get 700FPS. Full screen is over a 1000FPS less than Classic 2018-07-12. Could be rubbish Vulkan drivers but I wouldn't expect to have that huge difference. All very interesting.
Back to top
Profile PM Email Website
maddin
4
Years of Service
User Offline
Joined: 1st Jun 2019
Location:
Posted: 6th Aug 2019 21:04
Link
This only happens to own projects, the example projects have been altered already for export, the correct info is already stored in AppGameKit file.
After fiddling around with options, runasadmin etc. I found the solution for this problem:
When you configure the export settings and press export button these settings are NOT saved in AppGameKit file. Also when you close the export window and do "file - save" the APK settings won't be saved.
BUT if you do "close project" the export settings will be saved as expected in AppGameKit file and the next time export is OK.

off topic: I don't think it's a good idea to allow an IDE to open more than once... What do you think?
Back to top
Profile PM
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 7th Aug 2019 18:46 Edited at: 7th Aug 2019 20:22
Link
So it looks like there are several things going on here.

1) The VSync bug causing stuttering and incorrect VSync FPS (fixed in Studio on Windows and the next version of AGK2)
2) The Studio OpenGL renderer has a bug that causes sprite rendering to be much slower than AGK2 when using Render() or Sync() (fixed in the next version of Studio)
3) The Studio Vulkan renderer also suffers from the same bug as (2) causing sprite rendering with Render() or Sync() to be slower than it should, but to a much lesser extent since Vulkan loves draw calls (fixed in the next version of Studio)
4) The Studio OpenGL renderer is slower than AGK2 when using DrawSprite(), I've improved this for the next version of Studio but it is still not as good as AGK2. I suspect this is because the old AGK2 renderer passed vertex data directly in the draw call for sprites, whereas the new renderer uses vertex buffers for everything, since Vulkan only supports vertex buffers and that dictated the design. I may be able to re-implement the old OpenGL draw mode for small sprites, but it could take some time so I can't make any promises. However in the meantime I recommend using Render() or Sync() to draw your sprites as that way AppGameKit can batch them into a single vertex buffer and a single draw call, which will make faster in all cases (once the fix for bug (2) above is released)

I couldn't notice any differences between AGKC 2018-07-12 and AGKC 2019-06-11 except the odd differences on Mac that I mentioned above.

Edit: I've attached a new Studio player for Windows with the above fixes which should improve batched sprite rendering with some improvement in DrawSprite() rendering

Attachments

Login to view attachments
Back to top
Profile PM Email
Qube_
9
Years of Service
User Offline
Joined: 21st Oct 2014
Location: Omnipresent
Posted: 8th Aug 2019 00:51
Link
@Paul, thanks for the update... The way I usually make a game is to have a texture atlas with all my sprites and use DrawSprite() with Swap(). Are you saying that doing it that way is now slower in Studio because Vulkan works differently?
Back to top
Profile PM Email Website
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 8th Aug 2019 01:00
Link
In almost all cases DrawSprite will be slower, even in the old AGK2, since every call to DrawSprite creates a separate draw call, whereas letting AppGameKit draw them batches them into as few draw calls as possible. It just happens to be that DrawSprite is even slower in the new OpenGL renderer.
Back to top
Profile PM Email
Stephen Elliott
6
Years of Service
User Offline
Joined: 31st Jul 2017
Location:
Posted: 8th Aug 2019 08:39 Edited at: 8th Aug 2019 08:53
Link
Thanks for the update Paul. Interesting to hear that DrawSprite is the slower way to show sprites on-screen. So what is the alternative, hide lots of sprites until they are required? Why can't DrawSprite simply act as a flag that says this sprite is to be shown and all other sprites are hidden by default? That way AppGameKit can process the drawing internally in an optimized way?
Back to top
Profile PM
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 8th Aug 2019 10:27
Link
I create a sprite when it needs to be on screen and delete it when I'm finished with it. This method works fine for me and I can have hundreds of sprites for buttons, hp meters, explosion effects, text backgrounds etc. In fact, I generally think of sprites as the least of my worries when it comes to performance. Sound and 3d cause my performance headaches.
http://www.getgameleads.co.uk
http://www.verticalsync.co.uk
Back to top
Profile PM Email Website
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 8th Aug 2019 14:38
Link
Quote: "So what is the alternative, hide lots of sprites until they are required?"

For best performance, yes. I still have an idea to add a command that allows you to assign sprites to a group, then you can show and hide the group all at once.

Quote: "Why can't DrawSprite simply act as a flag that says this sprite is to be shown and all other sprites are hidden by default?"

DrawSprite tells AppGameKit that the sprite must be drawn to the screen or render image at that moment in time. It may be possible for AppGameKit to queue up the draws until something changes which forces the draws to complete, like changing render image, but it would require a lot of changes to the way AppGameKit handles DrawSprite, so may take a while to implement.
Back to top
Profile PM Email
Increase
7
Years of Service
User Offline
Joined: 21st Feb 2017
Location:
Posted: 8th Aug 2019 18:00
Link
there is setspritegroup()
Worldwide optimal state system - ISBN 9783748157748
Weltweit optimales Staatssystem - ISBN 9783748159476
Back to top
Profile PM Website
Qube_
9
Years of Service
User Offline
Joined: 21st Oct 2014
Location: Omnipresent
Posted: 9th Aug 2019 03:37
Link
Quote: "DrawSprite tells AppGameKit that the sprite must be drawn to the screen or render image at that moment in time. It may be possible for AppGameKit to queue up the draws until something changes which forces the draws to complete, like changing render image, but it would require a lot of changes to the way AppGameKit handles DrawSprite, so may take a while to implement."

Could you not keep the old way and add a new draw command which queues up the draws until swap() is called?
Back to top
Profile PM Email Website
tiresius
21
Years of Service
User Offline
Joined: 13th Nov 2002
Location: MA USA
Posted: 9th Aug 2019 04:30
Link
Maybe a StartSpriteBatch and EndSpriteBatch type functions to reduce the draw calls. I've seen in other libraries ....
Funcygames.com
Back to top
Profile PM Email
Stephen Elliott
6
Years of Service
User Offline
Joined: 31st Jul 2017
Location:
Posted: 9th Aug 2019 13:38
Link
Thanks for clarifying Paul.
Back to top
Profile PM
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 18th Aug 2019 12:41 Edited at: 18th Aug 2019 12:43
Link
@Paul Johnston

Did some experimenting..

Experiment I:
1. In NVIDIA Control panel, I've set my default driver to NVIDIA (my system has an Intel HD too, but no difference in regards to fps though).
2. Using the default NVIDIA setting for vSync - "Use the 3D application setting".
3. Ran Qube's speed test (Studio version).

Results:
With AppGameKit vSync on: 30fps (max)
With AppGameKit vSync off: ~350fps.



Experiment II:
1. In NVIDIA Control panel, I've changed vSync to "On".
3. Ran Qube's speed test again.

Results:
With AppGameKit vSync on: still getting the low 30fps, so no change at all from the default setting.
With AppGameKit vSync off (thus forcing the vSync on the NVIDIA settings): 60fps. This was way up in the 350's when using the default "Use the 3D application setting", so a significant drop!

*Makes me think it really doesn't do what it should.



Experiment III:
1. In NVIDIA Control panel, I'v now set vSync to "Off".
2. Ran Qube's speed test again.

Results:
With AppGameKit vSync on: 60fps.
With AppGameKit vSync off: ~350fps.

Now this is more what I'd expected to get when using the default NVIDIA vSync-setting "Use the 3D application setting".
Looks a bit like miscommunication (between driver<>AGK<>OS?) to me. Or.. something changed in the way this used to work in the past or I never understood the way it was working in the first place or my machine is behaving crazy.



Dunno how it works behind the scene's ,but this is a bit weird I think and might be pointing to the needle in the haystack.
Back to top
Profile PM Email Website
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 24th Aug 2019 09:21
Link
Bump> Did anybody take notice of this?
Back to top
Profile PM Email Website
Stephen Elliott
6
Years of Service
User Offline
Joined: 31st Jul 2017
Location:
Posted: 24th Aug 2019 16:14
Link
Maybe wait for Paul's update before doing any more tests?
Back to top
Profile PM
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 24th Aug 2019 18:14
Link
Will do. But kinda worried Paul /TGC didn't see above findings for perhaps they could be key to the problem.
Back to top
Profile PM Email Website
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 29th Aug 2019 18:12
Link
Quote: "Did some experimenting"

Is this using the version I posted above with the VSync fixes? VSync is bugged in the current release version so I'm not surprised it changed between 30 and 60 fps. If the VSync frame is just ever so slightly late to hit the 60fps window it gets delayed to the next VSync which means half the frame rate.

Quote: "I received a mail in which one could comment on what one would like for AGKS V2, My first thought: Is this a joke?"

I agree with you, that is a very badly worded statement, it should have said what would you like to see in the next update.
Back to top
Profile PM Email
Amon
9
Years of Service
User Offline
Joined: 30th May 2014
Location: Shropshire, United Kingdom
Posted: 29th Aug 2019 18:43
Link
Hi, Paul. When can we expect the next update that fixes this?
Win 10 Pro - AMD RYZEN 7 Octacore 3.8ghz - 32GB DDR4 - RTX 2070 8GB
Back to top
Profile PM Email Website
Rick Nasher
6
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 31st Aug 2019 17:45 Edited at: 1st Sep 2019 23:29
Link
@Paul Johnston
Ahah, that explains a lot. Indeed, it's also with that one you posted. Strangely, didn't hear from anybody else about this, well at least not the way I described the issue.

Thanks for the explanation, hope you'll manage to fix it.

[EDIT1: Perhaps it's only on my system? I'll try on 2 other machines and report back]
[EDIT2: Tried on my old laptop(also NVIDIA, but from 2007): there it didn't get passed 30fps under any circumstance. Will need to get to my PC and try there also.]
Back to top
Profile PM Email Website
Stephen Elliott
6
Years of Service
User Offline
Joined: 31st Jul 2017
Location:
Posted: 2nd Sep 2019 11:05 Edited at: 2nd Sep 2019 11:06
Link
...
Back to top
Profile PM
Conjured Entertainment
AGK Developer
18
Years of Service
User Offline
Joined: 12th Sep 2005
Location: Nirvana
Posted: 2nd Sep 2019 12:34
Link
Quote: "Hi, Paul. When can we expect the next update that fixes this? "

As soon as he finishes it; would be my bet.

Thanks for all of your hard work Paul in your quest to make AppGameKit better.

A few bugs are expected in any new release, and tracking them down can be a time consuming task, as well as the fixes once found.
Hope you get it sorted out soon, so wishing you the best of luck on your Vulkan endeavor.


Coding things my way since 1981 -- Currently using AppGameKit V2 Tier 1
Back to top
Profile PM Website
Zigi
14
Years of Service
User Offline
Joined: 5th Jul 2009
Location:
Posted: 11th Sep 2019 20:45
Link
Quote: "I've attached a new Studio player for Windows..."

Hi @Paul
Is this fix coming to Linux at all?
I have similar problem on Linux too.
I did want to continue one of my old projects in Studio, figured it could be fun using the level editor this time but then I have noticed lot of stutter it was not smooth on my dev PC. Then I was not sure if this stutter was there in the old Classic version too because it is barely noticeable on my desktop so I fired up my tablet with the old Classic version installed from about a year ago and it did run really smooth and nice on my tablet, much better than the Studio version on my PC.
Then checked the Studio version on the same tablet and it was unplayable, it was not just a little stutter, it was rock hard lag. The Studio version is unplayable. Same code, same project on the same device but the difference is huge
But even if the device is not supported any more, I do experience some stutter even on my desktop PC running Linux. The game is very simple, nothing complicated but the experience is not smooth.
Using the latest proprietary drivers on my PC.

Thanks.

Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-04-19 09:02:49
Your offset time is: 2024-04-19 09:02:49