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
Stephen Elliott
2
Years of Service
User Offline
Joined: 31st Jul 2017
Location:
Posted: 5th Aug 2019 19:29 Edited at: 5th Aug 2019 20:49
"Once that's done I'll remind him to review this and other threads." - thanks Rick.

Installed today's Studio Version, and that is an improvement over the last AppGameKit Studio (but not AppGameKit 2018 frame rates). Good work.

Running Qube's Ball Demo on Windows and it now runs smoothly, and also runs at the correct Monitor Refresh of 75hz on my system at 1600/1700 FPS with Vulkan and 1000/1100 with OpenGL..
DavidAGK
5
Years of Service
User Offline
Joined: 1st Jan 2014
Location:
Posted: 5th Aug 2019 21:18
To me, performance and elimination of all stuttering is absolutely essential and should be a key focus. There should be standard benchmarking tests that TGC use on each release to ensure at the very worst it’s not getting slower and ideally getting faster. A basic language that performs super fast is what AppGameKit should be all about IMO.

Using Tier 1 AppGameKit V2
Started coding with AMOS (Thanks Francois Lionet)
Qube_
4
Years of Service
User Offline
Joined: 21st Oct 2014
Location:
Posted: 5th Aug 2019 23:37
Quote: "To me, performance and elimination of all stuttering is absolutely essential and should be a key focus. There should be standard benchmarking tests that TGC use on each release to ensure at the very worst it’s not getting slower and ideally getting faster. A basic language that performs super fast is what AppGameKit should be all about IMO."

I agree and something crept in with the later versions of AppGameKit Classic which on a lot of systems increased stutter whilst running with vSync on and also reduced raw FPS with vSync off.

Great news that early reports on the latest version of Studio with Vulkan enabled appear to be promising
DavidAGK
5
Years of Service
User Offline
Joined: 1st Jan 2014
Location:
Posted: 6th Aug 2019 07:10
Yes, any performance benefits brought by Vulkan are definitely welcome!

I’d love to see TGC squeeze more speed out of Tier 1 code/logic. I recall someone saying Tier 2 was the same speed for graphics but about 20 times faster at executing code. So would be great to see some movement on that front. The faster the code executes the more you can do so it’d be nice to see that on the Studio roadmap.
Using Tier 1 AppGameKit V2
Started coding with AMOS (Thanks Francois Lionet)
DavidAGK
5
Years of Service
User Offline
Joined: 1st Jan 2014
Location:
Posted: 6th Aug 2019 08:53
Just tried my 2D platform game with the new AppGameKit Studio release and Vulkan - I get a much higher frame rate (when vsync is turned off) under AGK2 (and therefore Open GL) than I do under AppGameKit Studio with Vulkan :S Ugh! Also more stuttering and shearing. AGKStudio also appears slower using OpenGL than AGK2.... With VSync turned on Vulkan performs nicely but I like to see the unclamped FPS to keep an eye on performance.

I'll have to have a closer look at some stage but currently it looks like I'd have to release my game under AGK2.
Using Tier 1 AppGameKit V2
Started coding with AMOS (Thanks Francois Lionet)
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 6th Aug 2019 14:19
Today i make some tests and it seems that opengl is a big problem.
I.e. i try qubes code and like i posted before vulkan is very fast.
But if i choose the opengl mode with studio on my ryzen system, it have near the same speed like my lowend laptop.
Both AGKC builds from 2018/2019 runs around 515 fps.
I i use #renderer "Basic" it drops in AGKS to 380fps.And full of stuttering/tearing.
It seems opengl is a big problem.
The only thing that seems to work correct is vulkan.Opengl goes down in speed in the last year.
Laptop: Win10@64bit - i3 2x2Ghz - 8GB Ram - 1TB HDD
Desktop: Win10@64bit - AMD Ryzen 5 2400G - MSI B450 Tomahawk - 8GB Ram - 240GB SSD
Paul Johnston
TGC Developer
16
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 6th Aug 2019 16:52
There was a bug with SetVSync(1) that would still limit the FPS to the previous value passed to SetSyncRate, which could cause occasional stuttering. I fixed this in the Windows player in AppGameKit Studio and I've fixed it for the next version of AGK2 for all the desktop platforms. You can work around it by calling SetSyncRate(0,0) before calling SetVSync(1). It seems VSync on Mac doesn't actually do anything, at least on my machine, and the previous frame rate limiting was purely due to this bug.

I tried your example projects on my Mac and the 2018-07-12 version fluctuated randomly between 100 and 200 fps, making it jump around a lot. The 2019-06-11 and the Studio 2019-07-23 versions both performed the same and remained around 160fps, there was a little bit of jumping but it was much better than the 2018-07-12 version. So I don't know what's going on there. I'll see what happens when I implement Vulkan on Mac and see if it reveals anything.
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 6th Aug 2019 17:25 Edited at: 6th Aug 2019 17:29
I know that behaviour but i set SetSyncRate(0,1) for better speed.
In short for the FPS issue
Ryzen 5 2400G
AGKC 2018-07-12 around 525 FPS opengl
AGKC 2019-06-11 around 510 FPS opengl
AGKS 2019-08-05 around 380 FPS opengl - around 990 FPS vulkan

On my laptop AGKS have around 380 FPS with opengl too!
The other values you can find here in the thread.

The occasional stuttering is a problem i have since i buyed AGK.Don´t know if it is an AppGameKit, opengl or syncing -> display problem.
About that problem i wrote in past here but i found not really a solution, or any words from the devs here
Laptop: Win10@64bit - i3 2x2Ghz - 8GB Ram - 1TB HDD
Desktop: Win10@64bit - AMD Ryzen 5 2400G - MSI B450 Tomahawk - 8GB Ram - 240GB SSD
Stephen Elliott
2
Years of Service
User Offline
Joined: 31st Jul 2017
Location:
Posted: 6th Aug 2019 19:06 Edited at: 6th Aug 2019 19:54
"To me, performance and elimination of all stuttering is absolutely essential and should be a key focus. There should be standard benchmarking tests that TGC use on each release to ensure at the very worst it’s not getting slower and ideally getting faster."

Well said!!

"Today i make some tests and it seems that opengl is a big problem."

NO it's clearly not Opengl, because way before Vulkan (and the Studio version) was introduced Qube's 2018 AppGameKit demo out performs EVERY VERSION of AppGameKit by a large margin and does not have stutter(run the exe's). DavidAGK (and others) have said the same. These guys have actually written full games, rather than tinkering with small programs. There's clearly been a hiccup introduced which has unsettled the previous rock solid smooth frame rates.

After Paul's update (on my system) the smoothness has returned, but it's 1000FPS slower than the 2018 version of Basic AppGameKit with Vulkan and even slower with Studio Opengl!! Something is very wrong.
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 6th Aug 2019 20:02 Edited at: 6th Aug 2019 20:03
I mean that it is an opengl related problem in AGK.Whatever inside.
The slowdown is in Studio if i use opengl and not vulkan.
So its on the opengl(implementing side - whatever how paul does it) side.
I thought it was clear what i mean.
Laptop: Win10@64bit - i3 2x2Ghz - 8GB Ram - 1TB HDD
Desktop: Win10@64bit - AMD Ryzen 5 2400G - MSI B450 Tomahawk - 8GB Ram - 240GB SSD
Stephen Elliott
2
Years of Service
User Offline
Joined: 31st Jul 2017
Location:
Posted: 6th Aug 2019 20:08 Edited at: 6th Aug 2019 20:08
I think you really should read Qube's very first post properly. Ignore Studio for a second, AppGameKit has become significantly slower and more jittery on some systems.
Qube_
4
Years of Service
User Offline
Joined: 21st Oct 2014
Location:
Posted: 6th Aug 2019 20:09 Edited at: 6th Aug 2019 20:09
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.
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 6th Aug 2019 20:18
Quote: "I think you really should read Qube's very first post properly. Ignore Studio for a second, AppGameKit has become significantly slower and more jittery on some systems."

I know that. And i have post my results.
I only have test it now on my Ryzen and see the differences.
And that the opengl renderer are slow like on my lowend laptop.

I think its clear what i mean.
And i think benchmarking should be possible before any release.

@Qube_: i was really surprised too
Laptop: Win10@64bit - i3 2x2Ghz - 8GB Ram - 1TB HDD
Desktop: Win10@64bit - AMD Ryzen 5 2400G - MSI B450 Tomahawk - 8GB Ram - 240GB SSD
maddin
User Offline
Joined: 1st Jun 2019
Location:
Posted: 6th Aug 2019 21:04
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?
Paul Johnston
TGC Developer
16
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
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
Qube_
4
Years of Service
User Offline
Joined: 21st Oct 2014
Location:
Posted: 8th Aug 2019 00:51
@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?
Paul Johnston
TGC Developer
16
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 8th Aug 2019 01:00
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.
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 8th Aug 2019 07:03
I use DrawSprite almost too.
@Rick: wich way is the best for AppGameKit? -> example?
Laptop: Win10@64bit - i3 2x2Ghz - 8GB Ram - 1TB HDD
Desktop: Win10@64bit - AMD Ryzen 5 2400G - MSI B450 Tomahawk - 8GB Ram - 240GB SSD
Stephen Elliott
2
Years of Service
User Offline
Joined: 31st Jul 2017
Location:
Posted: 8th Aug 2019 08:39 Edited at: 8th Aug 2019 08:53
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?
CJB
Valued Member
15
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 8th Aug 2019 10:27
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.
Paul Johnston
TGC Developer
16
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 8th Aug 2019 14:38
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.
Increase
2
Years of Service
User Offline
Joined: 21st Feb 2017
Location:
Posted: 8th Aug 2019 18:00
there is setspritegroup()
Worldwide optimal state system - ISBN 9783748157748
Weltweit optimales Staatssystem - ISBN 9783748159476
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 8th Aug 2019 19:20
Thats for collisions
Laptop: Win10@64bit - i3 2x2Ghz - 8GB Ram - 1TB HDD
Desktop: Win10@64bit - AMD Ryzen 5 2400G - MSI B450 Tomahawk - 8GB Ram - 240GB SSD
Qube_
4
Years of Service
User Offline
Joined: 21st Oct 2014
Location:
Posted: 9th Aug 2019 03:37
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?
tiresius
16
Years of Service
User Offline
Joined: 13th Nov 2002
Location: MA USA
Posted: 9th Aug 2019 04:30
Maybe a StartSpriteBatch and EndSpriteBatch type functions to reduce the draw calls. I've seen in other libraries ....
Stephen Elliott
2
Years of Service
User Offline
Joined: 31st Jul 2017
Location:
Posted: 9th Aug 2019 13:38
Thanks for clarifying Paul.
Rick Nasher
2
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 18th Aug 2019 12:41 Edited at: 18th Aug 2019 12:43
@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.
Rick Nasher
2
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 24th Aug 2019 09:21
Bump> Did anybody take notice of this?
Stephen Elliott
2
Years of Service
User Offline
Joined: 31st Jul 2017
Location:
Posted: 24th Aug 2019 16:14
Maybe wait for Paul's update before doing any more tests?
Rick Nasher
2
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 24th Aug 2019 18:14
Will do. But kinda worried Paul /TGC didn't see above findings for perhaps they could be key to the problem.
c0d3r9
1
Years of Service
User Offline
Joined: 2nd Oct 2017
Location:
Posted: 24th Aug 2019 22:23 Edited at: 24th Aug 2019 22:31
I hope Paul is reading it all.
And besides, I hope there is a big update indeed, because I think it's not so nice that Paul will not announce any information about what's going on.
Other developers are doing that as well and I do not understand what the problem is to write 1 to 2 lines in the forum.

A few days ago I received a mail in which one could comment on what one would like for AGKS V2.
My first thought: Is this a joke?

There are errors in AGKC which are known for a long time.
These were partly not fixed with AGKS.
And then one asks us for wishes for AGKS V2!
And sorry, but the communication is really bad. If I had known that the release would be that way, I might have bought AGKS later.
If anything.
Sorry but I had to get rid of it now.
Laptop: Win10@64bit - i3 2x2Ghz - 8GB Ram - 1TB HDD
Desktop: Win10@64bit - AMD Ryzen 5 2400G - MSI B450 Tomahawk - 8GB Ram - 240GB SSD

Login to post a reply

Server time is: 2019-08-26 04:52:37
Your offset time is: 2019-08-26 04:52:37