Let begin the great AGK test ;D
For quite a while now I've found the output of AGK getting worse. Especially on Mac.
Since version AGK Classic 2018-07-12 I've found a big drop in raw FPS output and the introduction of judder. As 99% of the time I develop on my Mac I'd be interested to see what other users experience across various OS's and AGK versions.
I've compiled binaries of 3 different versions of AGK for Windows / Mac and Linux. The versions used were :
AGK Classic 2018-07-12
AGK Classic 2019-06-11
AGK Studio 2019-07-23
For me the best performer ( on Mac at least ) for both constant smoothness and fastest FPS ( with vSync off ) is AGK Classic 2018-07-12.
How to test :
1.. Download the version(s) for the OS's you have.
2.. Watch closely for a minute or two to see which AGK version runs the smoothest without juddering.
3.. After point 2 press S to toggle vSync Off and see which version produces the fastest FPS.
Download Links :
https://www.syntaxbomb.com/files/AGK-FPS-Judder-Windows.zip
https://www.syntaxbomb.com/files/AGK-FPS-Judder-Mac.zip
https://www.syntaxbomb.com/files/AGK-FPS-Judder-Linux.zip
Report :
Let me know the results of which worked best / worst for you + The OS's used and the FPS with vSync off per version.
Compile yourself? :
For those that have AGK Classic / Studio / Different versions - Here's the code if you don't want to download the included binaries - Also attached is the ball.png which goes in the media folder.
//
// FPS drop and juddering since AGK Classic 2018-07-12
//
// press 'S' to toggle vsync on / off to see speed drop after AGK Classic 2018-07-12
// press ESC to quit this exciting thing
//
SetErrorMode( 2 )
SetWindowSize( 1920, 1080, 1 )
SetVirtualResolution( 1920, 1080 )
SetDisplayAspect( 1920.0 / 1080.0 )
SetOrientationAllowed( 0, 0, 1, 1 )
SetRawMouseVisible( 0 )
SetRandomSeed ( GetUnixTime() )
SetVSync( 1 )
SetClearColor( 0, 0, 0 )
SetDefaultMinFilter( 0 )
SetDefaultMagFilter( 0 )
UseNewDefaultFonts( 1 )
Type tBall
x As Float
y As Float
speed As Float
size As Integer
EndType
Local ball As tBall
Local balls As tBall[]
Local tempImage, ballSprite, vSync, FPS
tempImage = LoadImage( "ball.png" )
ballSprite = CreateSprite( tempImage )
vSync = 1
FPS = CreateText( " FPS : " )
SetTextPosition( FPS, 0, 0 )
SetTextSize( FPS, 30 )
For count = 1 To 200
ball.x = Random( 0, 1919 )
ball.y = Random( 0, 1079 )
ball.speed = Random( 1, 6 ) + ( Random( 1, 50 ) / 100.0 )
ball.size = Random( 32, 32 * 4 )
balls.insert( ball )
Next
Repeat
If GetRawKeyPressed( 83 )
vSync = 1 - vSync
If vSync = 0
SetSyncRate( 5000, 0 )
SetVSync( 0 )
Else
SetVSync( vSync )
EndIf
EndIf
For count = 0 To balls.length
SetSpritePosition( ballSprite, balls[ count ].x, balls[ count].y )
SetSpriteSize( ballSprite, balls[ count ].size, balls[ count ].size )
DrawSprite( ballSprite )
Inc balls[ count ].x, balls[ count ].speed
If balls[ count ].x > 1920 Then balls[ count ].x = 1920 - balls[ count ].x - balls[ count ].size
Next
SetTextString( FPS, " FPS : " + Str( ScreenFPS() ) )
DrawText( FPS )
Swap()
Until GetRawKeyPressed( 27 )
I don't get why they would decline to comment on why this is happening. Is it something they can fix but don't want to because of the focus on AGKS? Or have they borked something in the updates that requires significant work to fix which they are not willing to do due to other technicalities?
I've seen you voice your concerns over there Qube and you may as well speak to the wall. It's dissapointing behaviour on their behalf.
Don't get me started on the absolute sham of a release of AGKS with 90% of what they promissed for release missing.
@Qube: exact that post you should post on the TGC site.I don´t know about the reaction of TGC but i think its a really good post to ask why this issues doesn´t repaired.
Tested on my linux box:
AGK Classic 2018-07-12:
2000-2100fps, only a bit of jittering here and there - NOT silky smooth
AGK Classic 2019-06-11:
1920-2000fps, started to jitter pretty much after ~15 seconds (jumping by a dozen pixels)
When I've run it a third time - after running all the others - I had no "jumping jitter" for 1 minute (then I stopped)
AGK Studio 2019-07-23:
1950-2050fps, same "tiny bit of jittering" than with "2018-07-12", NOT silky smooth but similary "neglectable"
Watch the "slow and big" balls - they do not move "smooth" when they are slow (but not the slowest).
Interesting: 2018-07-12 was the only version which has shown "marching pixels" on some balls (depends on the speed). Some of the slower had pixels move (just look "top left" of the balls). I was not able to see that in the over versions. It was less visible after I started the other samples and came back to it.
All of this might have to do with: filtering textures and that they place stuff on "pixel coordinates" (so this "subpixelrendering thing" they try to do). Maybe they changed something there?
If stuff "stutters/jitters" it somehow appears as if the affected ball sprite was squeezed (width of 100px becomes 99px) for a short moment.
@ Jumping Jittering
With "jumping jittering" I mean the effect of a ball moving "to the right" and then a bit back "to the left" as if wrong tweening values were passed - or some rounding errors happened.
You might consider adding "left + right" cursorkey support to globally slowdown/speedup movement speed. this "wobbling" (skewing graphics, jumping positions) is only visible for certain speeds (eyes too slow / not tricked). No need to upload the whole thing, just provide an alternative "bytecode.byc". Binaries are just the runtimes - as you know.
bye
Ron
I tried on Windows (for now)
Version AGK Classic 2018-07-12 worked the best. It ran smooth and was the only one to correctly run at my native Monitor Refresh of 75hz and 2800FPS with vsync off.
Version AGK Classic 2019-06-11 wasn't smooth, ran at an incorrect vsync of 60 and 2400FPS with vsync off.
AGK Studio 2019-07-23 ran the worst, less smooth, ran at an incorrect vsync of 60 and 1600FPS with vsync off.
Interesting results here. On my old system, both classic versions ran smooth at 60 fps. Vsync off and they both jumped between 300-400 fps. Did not notice any jittering in either version.
Studio version ran at about 58 fps and jitter was noticeable. VSync off ran about 180 fps, a huge difference from classic.
Windows 10 Home 64 bit
AMD A8-6410 2.0ghz with AMD Radeon R5 graphics
4 GB Ram
I've posted on the TGC forums so I hope it's seriously looked at and I don't get fanboi fob offs, we'll see.
Studio v1.0 does run the worst for me too but I expect that'll just be brushed away as early Vulkan days. It's clear that there has been a deterioration over both AGK Classic heading into Studio and the longer it goes on the harder it'll be to fix.
Specs
- Windows 10
- 144Hz monitor
- RTX 2070 GPU
AGK Classic 2018-07-12
- VSync On = 143-144 FPS. Hard to notice jitter at this FPS, but FPS tends to be a locked 144 in other games.
- VSync Off = ~2000 FPS.
AGK Classic 2019-06-11
- VSync On = 59.9994 FPS. Incorrect VSync. Looks very jittery
- VSync Off = ~1900 FPS.
AGK Studio 2019-07-23
- VSync On = 59.9994. Exactly like version above.
- VSync Off = ~1100 FPS. "Big" drop in FPS.
@Hezkore:you should post it in the tgc forum.
The vsync limitation issue was corrected some agk versions ago.But it seems its back.
When I see other developers and how they deal with customers, I find it a bit sad at TGC.
Much is ignored and just with Discord you would have the opportunity to actively participate in the development.
I just do not understand.
Maybe its time for an intervention.
We should keep bumping the thread Qube posted to keep it on the first page. Lets prevent it dying out in to the nether pages of that forum. Hopefully they will listen and fix what needs to be fixed.
Quote from: c0d3r9 on July 27, 2019, 22:23:28
@Hezkore:you should post it in the tgc forum.
The vsync limitation issue was corrected some agk versions ago.But it seems its back.
I've never used AGK for any of my projects, and I don't think I ever will.
So this issue doesn't bother me in any way.
Feel free to use my results though and post on the forum.
I'm only posting my results for Qube.
Ok, this couldn't resist. ;-)
I too had noticed a drop in performance and smoothness, but thought was due to my old specs. However I now tested on my new laptop(i7-7700HQ@2.80GHz, 8GB, GTX1050, 512GB SSD, W10H V1903 x64) and made some vids to show the initial results.
AGK2 V2018-07-12:
https://i.imgur.com/5zZISK1.mp4
This was by far the best performer(or appeared to be). Average 60fps.
AGK2 V2019-02-08:
https://i.imgur.com/GOkrE04.mp4
Here it really is getting 'the shakes'. Average 59fps.
AGKS V1.0:
https://i.imgur.com/wywEM4T.mp4
Here fps's went down a lot. Average 30fps.
I've tried different compilation settings: VSync. Full speed, 60fps and turns out disabling 'Event based rendering' gives the most smooth movement, but none of the settings up the fps rate significantly.
The later is on Vulkan so should in theory be the faster one I suppose, while above results seem to imply something different. However, it does appear more smooth.
Now.. without VSync enabled the story changes quite a bit:
AGK2 V2018-07-12:
a smooth 265fps.
AGK2 V2019-02-08:
a smooth 255fps.
AGKS V1.0:
a smooth 350fps.
I do not know how to interpret above results correctly though. Any comments on this?
@ videos
I had recorded some with my phone too - but the 25fps recording of a 60fps animation just has to look jerky. No chance to judge fairly based on these videos.
@ laptop fps
Why does your modern laptop limit at <300fps, shouldn't it be a digit more?
@ vsync
I had visible tearing in all 3 binaries. With hardware vsync (rather than a "I ought to refresh every x.yyyy ms") it should not show tearing - except my nvidia driver (Linux) does not play nicely here.
Yet I assume it happens because of this: my main screen (connected via HDMI) is having a refresh rate of "60.02Hz" while the DVI one a refresh rate of "59.95Hz" (according to the nvidia driver panel). The rendering of the tests here happen at a refresh rate of "59.8xxx - 59.9xxxx". Maybe that results in this tearing (as it does not use a hardware vsync).
bye
Ron
@Derron
Quote@ videos
I had recorded some with my phone too - but the 25fps recording of a 60fps animation just has to look jerky. No chance to judge fairly based on these videos.
Funnily enough the recording doesn't appear to have a visible impact on the jitter or fps at all: it's oddly enough the same with or without recording.
Guess there's some overhead that's reserved for the purpose? I used the Windows in build Game Menu recorder.
Quote@ laptop fps
Why does your modern laptop limit at <300fps, shouldn't it be a digit more?
I'd like to see that indeed. But.. it's not really a gaming laptop. Dunno if this is the reason though.
@Rick Nasher - Cool, thanks for doing that :) - That pretty much echos my finding on MacOS in regards to the judder too.
QuoteI too had noticed a drop in performance and smoothness, but thought was due to my old specs.
Lol, when I first came across it 8+ months ago I thought it was my Mac and was about to reload from fresh but out of curiosity I tried an early version of AGK and that ran just fine.
QuoteI do not know how to interpret above results correctly though. Any comments on this?
A GTX 1050 is no slouch and not really much behind my Radeon 580 Pro. I wonder if *drum roll* Vulkan has kicked in with AGK Studio for the raw FPS and that's why it out performs OpenGL of AGK Classic?
Although I find your results very low as when I boot into Windows 10 I get over a 1000+ FPS. Go Mac \o/ :P
Quote@ vsync
I had visible tearing in all 3 binaries. With hardware vsync (rather than a "I ought to refresh every x.yyyy ms") it should not show tearing - except my nvidia driver (Linux) does not play nicely here.
Yet I assume it happens because of this: my main screen (connected via HDMI) is having a refresh rate of "60.02Hz" while the DVI one a refresh rate of "59.95Hz" (according to the nvidia driver panel). The rendering of the tests here happen at a refresh rate of "59.8xxx - 59.9xxxx". Maybe that results in this tearing (as it does not use a hardware vsync).
Do my games that you've played have tearing too?. It's just that all those have delta timing for 60FPS whereas the example code / binaries for this test are just pure sync with no timing so should lock to your monitors refresh.
Gah, this is all getting complex :))
1. the select option for code does not work with firefox
2. I guarantee that the slowdown is because they have left debug on in vulkan
All three binaries run at 60fps for me
Try running with the VulkanDebugPlayer9.exe from the vulkan thread (https://forum.thegamecreators.com/thread/224730#msg2646292)
Quote1. the select option for code does not work with firefox
Stupid Firefox ;D
Quote2. I guarantee that the slowdown is because they have left debug on in vulkan
Nope, it's present in AGK Classic after version 2018-07-12 too. Along with frame rate stutter. It's also present in both FPS drop and stutter with AGK Studio on MacOS which doesn't even have the Vulkan engine enabled.
QuoteAll three binaries run at 60fps for me
Did they all have smooth scrolling when watched for a few minutes?, any frame jumping?. What was the FPS performance like when you switched off vSync ( press S but ignore scroll smoothness )?
QuoteTry running with the VulkanDebugPlayer9.exe from the vulkan thread
It's not a Vulkan issue. The issue crept almost a year ago with AGK Classic along with the knackered IDE on MacOS.
QuoteDid they all have smooth scrolling when watched for a few minutes?, any frame jumping?. What was the FPS performance like when you switched off vSync ( press S but ignore scroll smoothness )?
They all scrolled smoothly. There was stutter with the very slow objects (in all versions) but i think that's the nature of using floats to move something at a very slow rate
Vsync off was
07-12 1200
06-11 1200
07-23 1100-1200
So everything worked pretty spot on for you which is very odd and confusing, lol.
QuoteThere was stutter with the very slow objects (in all versions) but i think that's the nature of using floats to move something at a very slow rate
Sub-pixel rendering should be fine so perhaps something else is going on here as it's silky smooth for me.
QuoteSub-pixel rendering should be fine so perhaps something else is going on here as it's silky smooth for me.
As reported by Derron
QuoteWatch the "slow and big" balls - they do not move "smooth" when they are slow (but not the slowest).
I think there is a mac/windows issue for sure.
One thing i just cannot understand is why Rick only got 30fps, so i think there is definitely something going on.
I didn't know hat vulkan wouldn't be available for mac. Is is that something for later on?
Quote from: blinkok on July 30, 2019, 05:56:01
QuoteWatch the "slow and big" balls - they do not move "smooth" when they are slow (but not the slowest).
I think there is a mac/windows issue for sure.
I tested this on Linux.
Quote from: Qube on July 29, 2019, 23:29:32
Do my games that you've played have tearing too?. It's just that all those have delta timing for 60FPS whereas the example code / binaries for this test are just pure sync with no timing so should lock to your monitors refresh.
Cannot remember any tearing - but the games were no "horizontal scroller" ones where tearing would be visible so easily ("space ship torn apart").
Nonetheless I temporarily disabled my second screen - and the tearing was gone (while the "59.xxx" value stayed. So I will have to port your sample code to NG to check it with some other renderers (especially SDL). I think it is an issue with Linux + Nvidia-driver + engines (here AGK) to wait for/accept/receive the wrong vsync-signal.
This of course must not have to do with the "stuttering" others see.
I assume it most probably happens to certain object speeds - too fast objects "smear" along the screen (for your eyes) so the movement is too fast to recognize jitters. Too slow objects just have so low jitters that it should not be visible too - here the visual problem is the "throbbing" or "pumping" of the textures based on the way AGK does subpixel rendering (monitor position is fixed but texture is tried to be on int positions too).
If you have "slow-to-mid" speeded balls then you can see jittering - the movement is not steady. When you calculate your delta this is happening in the "physics" stage (when calculations are done) and until the "render" stage happens, some microseconds more or less are gone (not-steady) so the calculated movement must not necessarily fit exactly to what is to render in that very moment.
Ok... have had a look at your code and you do not use delta-timing at all (which is obvious once you remove "vsync" and the balls just move in lightingspeed). This very very much explains why it can jitter: time between the renders is not guaranteed to be stable - and so the movement isn't guaranteed to be stable too. You might add a "start/stop" key which you can press once your system "has settled" and it then stores low,avg,max fps (as the one in that agk-thread suggested). The difference between min and max is what makes your jitter.
You then just have to find out WHY there is a difference as a hardware vsync should take care of this already (the "start" after a vsync happened is always at the same time difference to the "last vsync" so the handling of all your balls happens at this "fixed" rate).
bye
Ron
Great analysis Derron, AGK should take you on as a contractor ;)
This is a port of your code to NG + some deltaTime stuff. Tried to do stuff in the very same order than you (so render balls before moving them and so on).
I get more jitter wit hthe "gl2sdlgraphics" from NG than with the "classic" one (no shaders). Yet both begin to jitter in a later stage.
I also get screen tearing with both renderers so I assume it is an issue with the driver / settings / dual screen setup.
SuperStrict
Framework Brl.StandardIO
Import SDL.SDLTimer
Import SDL.d3d9sdlmax2d
Import SDL.gl2sdlmax2d
Import SDL.glsdlmax2d
Import Brl.PNGLoader
Import Brl.Random
global vsync:int = True
global useDeltaTime:int = False
global screenW:int = 1920 'DesktopWidth()
global screenH:int = 1080 'DesktopHeight()
global renderer:int = 0
global rendererString:string
Select renderer
Case 0
SetGraphicsDriver GLMax2DDriver()
rendererString = "GLMax2DDriver"
Case 1
SetGraphicsDriver GL2Max2DDriver()
rendererString = "GL2Max2DDriver"
?win32
Case 2
SetGraphicsDriver D3D9SDLMax2DDriver()
rendererString = "D3D9SDLMax2DDriver"
?
End Select
Graphics(screenW, screenH, 32)
'SetVirtualResolution(screenW, screenH)
HideMouse()
Type TBall
Field x:Float
Field y:Float
Field speed:Float
Field size:int
End Type
Global balls:TBall[200]
Global ballImage:TImage = LoadImage( "media/ball.png", DYNAMICIMAGE)
For Local count:int = 1 To 200
balls[count] = new TBall
balls[count].x = Rand( 0, 1919 )
balls[count].y = Rand( 0, 1079 )
balls[count].speed = Rand( 1, 6 ) + ( Rand( 1, 50 ) / 100.0 )
balls[count].size = Rand( 32, 32 * 4 )
Next
'fps handling
Global lastTime:int = Millisecs()
Global timeGone:int
Global timesRendered:int
Global loopBeginTime:int
Global fpsMin:int = -1, fpsMax:int = -1, fpsCurrent:int
Global deltaTime:Float
Repeat
timeGone :+ Millisecs() - lastTime
deltaTime = (Millisecs() - lastTime) / 1000.0
lastTime = Millisecs()
if timeGone > 1000
'scale if more than 1000ms are gone...
fpsCurrent = timesRendered * (timeGone/1000.0)
if fpsMin = -1 or fpsMin > fpsCurrent then fpsMin = fpsCurrent
if fpsMax = -1 or fpsMax < fpsCurrent then fpsMax = fpsCurrent
timeGone = 0
timesRendered = 0
endif
if KeyHit(KEY_S) then vsync = 1 - vsync
if KeyHit(KEY_D) then useDeltaTime = 1 - useDeltaTime
cls
For Local count:int = 0 To balls.length
SetScale(balls[count].size /32.0, balls[count].size /32.0)
'draw at OLD position
DrawImage(ballImage, balls[count].x, balls[count].y)
SetScale(1, 1)
'move to NEW position
if useDeltaTime
'speed is given in "per 60", so we need to multiply * 60
balls[count].x :+ balls[count].speed * deltaTime * 60
else
balls[count].x :+ balls[count].speed
endif
If balls[count].x > 1920 Then balls[count].x = 1920 - balls[count].x - balls[count].size
Next
DrawText("vsync: " + vsync, 10, 10)
DrawText("FPS: " + fpsCurrent + " ("+fpsMin +" - " + fpsMax+")", 10, 30)
DrawText("delta: " + useDeltaTime + " ("+string(deltaTime)[..6]+"ms)", 10, 50)
flip vsync
timesRendered :+ 1
Until AppTerminate() or KeyHit(KEY_ESCAPE)
PS: With GLMax2D I reach 3200 fps (compared to the 2000 of AGK) and with GL2Max2D (very basic shader-based rendering) I reach 2400. Maybe it is the "tier 1" kicking in?
bye
Ron
Quote
I also get screen tearing with both renderers so I assume it is an issue with the driver / settings / dual screen setup.
Yep, like I said I don't get tearing on my (non dual screen) Linux System.
https://www.syntaxbomb.com/index.php/topic,5872.msg28206/topicseen.html#new
Quote
PS: With GLMax2D I reach 3200 fps (compared to the 2000 of AGK) and with GL2Max2D (very basic shader-based rendering) I reach 2400. Maybe it is the "tier 1" kicking in?
I get 2800 FPS for the quickest build of AGK and AGK is not compiled to machine code, but to bytecode and then interpreted.
Sorry for offtopic:
nvidia-settings --assign CurrentMetaMode="$(nvidia-settings -q CurrentMetaMode -t|tr '\n' ' '|sed -e 's/.*:: \(.*\)/\1\n/g' -e 's/}/, ForceCompositionPipeline = On}/g')" > /dev/null
And the tearing was gone ... will have to put it into a startup file ;-)
bye
Ron
Cool. Glad you got it fixed.
I have to smile a little bit.
I saw Ricks screenrecords and i remember that i have that shaking sprites since i use AGK.
Nobody have an solution for that and this problem have many other engines too?
VSync helps a lot but not in all cases.
Freesync could be a good solution to drop such issues.
Stuttering after a short "warmup" ;) every x seconds.Its definitely a sync problem.(that what i read some month ago of many many websites/forums etc.)
I test it all atm on my non-vulkan laptop so the framedrop is opengl related.I will test how many fps are possible if the update allows change between opengl and vulkan.
You'll never get 100% constant uninterrupted 2D silky smooth scrolling on modern OS's as there is so much junk going on in the background that it's bound to skip a beat from time to time.
All I know is that AGK Classic 2018-07-12 was the most constant at being smooth across all OS's ( and the fastest with vSync off ). In my games I use vSync on + delta time movement with a target frame rate of 60FPS. It's worked overall really well but after noticing in later versions of AGK it getting worse and now the new AGK Studio being the worst I'm amazed no-one else has said anything.
Perhaps the serious game makers in AGK are make 3D games or don't really aim for silky smooth 2D games. If I was happy with 30FPS or less for 2D then I'd be happy in jerky jerk jerk land but I'm old and anal about smooth scrolling for 2D games :P
QuoteAll I know is that AGK Classic 2018-07-12 was the most constant at being smooth across all OS's ( and the fastest with vSync off ). In my games I use vSync on + delta time movement with a target frame rate of 60FPS. It's worked overall really well but after noticing in later versions of AGK it getting worse and now the new AGK Studio being the worst I'm amazed no-one else has said anything.
Yes it seems that you´re right.
And i haven´t compared the different version because i have always vsync on.
QuotePerhaps the serious game makers in AGK are make 3D games or don't really aim for silky smooth 2D games. If I was happy with 30FPS or less for 2D then I'd be happy in jerky jerk jerk land but I'm old and anal about smooth scrolling for 2D games :P
Thats so true... ;D
Quote from: Derron on July 30, 2019, 09:02:40
This is a port of your code to NG + some deltaTime stuff. Tried to do stuff in the very same order than you (so render balls before moving them and so on).
Cool, tried this on MacOS with BlitzMax NG and it ran every well indeed with only the very occasional judder too. As this nigh on matches how AGK 2018-07-02 works for me it further just clarifies that something has gone wrong in later version of AGK.
Quote
but I'm old and anal about smooth scrolling for 2D games :P
Standards shouldn't be dropped, with the power of modern systems they should be very capable of smoooooth scrolling easily.
lol, you would of thought so with the shear grunt of GPU's these days but it's seems constant silky smooth scrolling still holds king with a C64 :P
Miracles a side I'm actually amazed that I got BlitzMax NG to compile and run on my Mac with zero fuss :o - in the past it either didn't work or every example I tried just went error nuts.
So who do I pay for a Metal renderer? :P
Quote
lol, you would of thought so with the shear grunt of GPU's these days but it's seems constant silky smooth scrolling still holds king with a C64 :P
Either have silky smooth scrolling, or don't bother - it really spoils any scroller type game. Crap game, but the silky smooth scroller title must go to Shadow of the Beast on the Amiga, with soo many parallax scrolling layers too!
If the renderer was just another layer on top of "brl.graphics" or "brl.max2d" then our beloved user col (github.com/davecamp) created some cool stuff (srs.mod - dx11 driver, initial steps with "vulkan" and some shader works). Also considerations were made to create a new renderer-pipeline with "bgfx" as basement (handles all the different renderers then).
Googling a bit ... I land in a thread of a very suspicious forum... called ... uhm wait a second ..."SyntaxB()*mb":
https://www.syntaxbomb.com/index.php?topic=4691.0
@ mac
Brucey is a proud Mac owner so it is more or less "natural" for NG to run on Mac (except you updated your OS X and Brucey didn't do yet ;-)).
Even without Vulkan, Metal, ... NG is always nice to play around a bit here and there. Be prepared to have more to do when creating cross-platform binaries ("no runtime + script" language).
bye
Ron
QuoteCrap game, but the silky smooth scroller title must go to Shadow of the Beast on the Amiga, with soo many parallax scrolling layers too!
Yup, now that was a technical marvel for it's day that really pushed the Amiga hardware. As said, shame the game itself was utter crap though.
QuoteEven without Vulkan, Metal, ... NG is always nice to play around a bit here and there. Be prepared to have more to do when creating cross-platform binaries ("no runtime + script" language).
I'd not get back into Blitz as sooner or later OpenGL will stop on MacOS and that'd be a complete waste of time reinvested. Most if not all game creation studios already have ( or moving to ) the death of OpenGL on MacOS. It may be years away before they remove it fully but as it's on the cards I wouldn't be happy using something that I know is end of life on a platform.
Think Brucey is aware of the "EOL" for OpenGL on Mac - hence the interest in "bgfx":
https://github.com/bkaradzic/bgfx
But that would mean to have to write a new render-pipeline on top of it - and if feasible then of course compatible to the current "immediate mode" max2d-implementation (+ shaders so we could reach out for GaborD to see some "made in BMX NG videos" ;-)). Maybe Col settled finally after moving and finds some time to jump in (after he made render2texture work with NG's brl-drivers instead of just the sdl.mod ones).
(Feel free to rip our derailing-posts out of this thread into a new one).
bye
Ron
QuoteThink Brucey is aware of the "EOL" for OpenGL on Mac - hence the interest in "bgfx":
That would definitely extend the life of Max should it ever become fully working with all the needed bits and pieces :)
Quote(Feel free to rip our derailing-posts out of this thread into a new one).
I think this thread has run it's course already so no real need to clean up. Besides thread derailment is kinda our thing over here ;D
Out of curiosity: why did you install NG? Just to see "does it even work" ?
@ postcount
Pay attention, y2k bug incoming to your post count.
bye
Ron
QuoteOut of curiosity: why did you install NG? Just to see "does it even work" ?
I wanted to revisit some of my very very old BlitzMax stuff and the official BRL release of Max just hates me. Luckily the latest version of NG was a breeze to get working on my Mac so it'll stay installed :)
QuotePay attention, y2k bug incoming to your post count.
Cool, I'm gonna hit the 2000 club soon. I'll give myself a beer for reaching that milestone.
2000 posts ;D
Quote from: Qube on July 30, 2019, 22:45:26
2000 posts ;D
Landmark event. Perhaps that could be the theme of the next competition? The year 2000. Throw it out there and see what people come up with :)
Yes, I know. I de-railed the thread even more. My bad :P
In the year 2000 nothing important happened - a pizza delivery boy has fallen into a time capsule, my computer continued to work ... and a bit later the loveletter mail virus created a billions of damage.
Maybe a "year 2000"-compo would just lead to some fireworks demos :)
bye
Ron
Base the games on stories out of 2000AD, was Dan Dare one of them.......?
The Y2K bug happened. The Earth is flat. Iron Man didn't really die.
Quote from: 3DzForMe on July 31, 2019, 10:40:20
Base the games on stories out of 2000AD, was Dan Dare one of them.......?
Now there's an idea. Although the licence holders would probably go nuts even if the games were free.
Dan Dare was in Eagle comic, man. Blasphemy !!!!!
Quote from: Amon. on July 31, 2019, 15:28:08
The Y2K bug happened. The Earth is flat. Iron Man didn't really die.
You know that the BD release for Avengers is yet to come - so NO SPOILERS.
bye
Ron
Quote. Dan Dare was in Eagle comic, man. Blasphemy !!!!!
That'll explain why I couldn't find him in the 2000AD Wiki ;)
That Xaby guy over on the TGC forums in Qubes thread is doctoring his results because there's no way his precious has anything wrong with it.
Update: I just recently updated my graphics drivers to the latest. Performance is much better. Not just in AGK, everything runs better.
The three examples run mostly the same. 2018 AGK runs an even 60 FPS, the 2019 and studio both show 59.998... No juttering in any of them.
QuoteDan Dare was in Eagle comic
Blimey!, not heard Dan Dare and Eagle comics mentioned in a loooong time :P
QuoteThat Xaby guy over on the TGC forums in Qubes thread is doctoring his results because there's no way his precious has anything wrong with it.
I guess there would be some who'd not find a difference but luckily and hopefully enough have posted to show there is an issue within all the other noise. Guess we'll just wait and see what happens next.
QuoteThe three examples run mostly the same. 2018 AGK runs an even 60 FPS, the 2019 and studio both show 59.998... No juttering in any of them.
Did you watch each one for a few minutes? Also did you turn vsync off ( press "S" ) and see what the raw FPS was like across the versions?, thanks.
No change after several minutes. Sync off gives me about 350-400 fps. Slightly better than my old drivers. Don't get that huge frame drop with studio like I did with the old drivers.
Already have the latest driver(NVIDIA's 431.60), installed it prior to testing. So it's not gonna change my results I'm afraid.
my last post on the tgc forum
Holy cow...
Today i tested on my Ryzen rig.(Ryzen 5 2400G APU Vega 11)
AGK Classic 2018-07-12
around 500 fps opengl
AGK Classic 2019-06-11
around 500 fps opengl
AGK Studio 2019-07-23
around 990 fps vulkan
And all three builds, no stuttering, tearing...nothing.Independend if vsync on or off.
Very mysterious, but it seems Studio is vulkan optimised.
New version is out. Gonna test in a bit to see if the results are the same. They added the option of being able to pick renderer which is cool
No difference on Mac but I expected that as the Vulkan renderer is not on Mac yet and RickV has said that Paul hasn't looked into the issue yet but will soon.
QuoteThey added the option of being able to pick renderer which is cool
They did, which will be handy for those that need to keep to OpenGL due to shaders and incompatibilities. The only thing I found odd was how it's implemented :
#renderer "Basic"
#renderer "Advanced"
#renderer "Prefer Best"
The first will always use OpenGL, the second will always use Vulkan, the third will try and use Vulkan but drop back to OpenGL if required. Note that the non-Windows platforms are still using the old renderer code so they will ignore this directive and always use OpenGL.
Not sure if there are more commands to come but I would of thought the easier way would of been :
#renderer "OpenGL" // Forces OpenGL as the renderer
#renderer "Vulkan" // Tries to set Vulkan as the renderer but if it can't then fall back to OpenGL
Plus a command : RendererInUse()
Then use the command to know which customer shaders / renderer specific stuff you need to use.
*EDIT * - It would also allow to add more renders in future if needed like #renderer "Metal"
That would be too logical Qube ;D
I can't resist downloading though...
ok now that is an improvement over the last AGK Studio (but not AGK 2018 frame rates).
Running Qube's Ball Demo on Windows 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.
#renderer "Basic"
#renderer "Advanced"
#renderer "Prefer Best"
Does it work for languages too?
The first will always use English, the second will always use German, the third will try and use German but drop back to English if required.
I understand the approach of not stating exactly WHAT is used that way you can always replace the underlaying renderers. But this is not a "user/client option" but a one for the developers. Seems I need to ...*shrug*.
bye
Ron
I updated to that 2019.08.1 Classic AGK whatsits face, I cannot see any difference on anything me, to be fair though, I'm just farting about and not looking, but, I've had post-jollybob blues, and doing the update it has made me implement some collapsible tiles on my Dizzy thing, so there's a bonus really! :D
Dabz
Hmm.. confusing.
Tried latest Studio: Now with vSync on getting a mere 28-30fps, without it, it runs at 280-360fps. Appears lot less stabilized, constantly varying.
QuoteI updated to that 2019.08.1 Classic AGK whatsits face, I cannot see any difference on anything me, to be fair though, I'm just farting about and not looking
Well you're a bag of useless if you're not even watching :P
Quoteand doing the update it has made me implement some collapsible tiles on my Dizzy thing, so there's a bonus really!
OK, ya forgiven, keep at it ;D
QuoteHmm.. confusing.
Tried latest Studio: Now with vSync on getting a mere 28-30fps, without it, it runs at 280-360fps. Appears lot less stabilized, constantly varying.
AGK hates your PC :P - Have you tried the shiny new #renderer commands to see if the "fix all" Vulkan does something magic?
Quote
Tried latest Studio: Now with vSync on getting a mere 28-30fps, without it, it runs at 280-360fps. Appears lot less stabilized, constantly varying.
Hmm AGK/AGK Studio does seem to have become inconsistant across machines, which is a concern. Rick said he'd speak to Paul about Qube's thread over there.
@Rick N.: what a machine do you have? I have more fps on my lowend laptop.
This
is interesting. Looked back in the thread and saw Rick Nasher's specs
QuoteHowever I now tested on my new laptop(i7-7700HQ@2.80GHz, 8GB, GTX1050, 512GB SSD, W10H V1903 x64)
Which is far better than mine.
QuoteWindows 10 Home 64 bit v1803
AMD A8-6410 2.0ghz with AMD Radeon R5 graphics
4 GB Ram
512 GB SSD
Yet, he is getting worse performance than I am. Apparently worse than c0d3r9 as well.
taking a look at Qube's sample code, I noticed that he uses DrawSprite() and DrawText(). Using DrawSprite is like using DrawPixmap in BMax, very slow. I rewrote Qube's example to eliminate DrawSprite() and now it runs twice as fast with 2019.6.11 (the only version I have installed on my laptop right now). I also slowed down the update for FPS, so it is easier to read.
//
// FPS drop and juddering since AGK Classic 2018-07-12
//
// press 'S' to toggle vsync on / off to see speed drop after AGK Classic 2018-07-12
// press ESC to quit this exciting thing
//
SetErrorMode( 2 )
SetWindowSize( 1920, 1080, 1 )
SetVirtualResolution( 1920, 1080 )
SetDisplayAspect( 1920.0 / 1080.0 )
SetOrientationAllowed( 0, 0, 1, 1 )
SetRawMouseVisible( 0 )
SetRandomSeed ( GetUnixTime() )
SetVSync( 1 )
SetClearColor( 0, 0, 0 )
SetDefaultMinFilter( 0 )
SetDefaultMagFilter( 0 )
UseNewDefaultFonts( 1 )
Type tBall
x As Float
y As Float
speed As Float
size As Integer
EndType
Local ball As tBall
Local balls As tBall[]
Local tempImage, ballSprite, vSync, FPS
ballImage = LoadImage( "ball.png" )
vSync = 1
CreateText(1, " FPS : " )
SetTextPosition( 1, 0, 0 )
SetTextSize( 1, 30 )
For count = 1 To 200
ball.x = Random( 0, 1919 )
ball.y = Random( 0, 1079 )
ball.speed = Random( 1, 6 ) + ( Random( 1, 50 ) / 100.0 )
ball.size = Random( 32, 32 * 4 )
balls.insert( ball )
CreateSprite(count,ballImage)
SetSpriteSize(count,ball.size,ball.size)
Next
frametime as float
framesPerSecond as float
MaxFPS as float
Repeat
frametime = frametime + GetFrameTime()
If GetRawKeyPressed( 83 )
vSync = 1 - vSync
If vSync = 0
SetSyncRate( 5000, 0 )
SetVSync( 0 )
Else
SetVSync( vSync )
EndIf
EndIf
For count = 0 To balls.length
SetSpritePosition( count+1, balls[ count ].x, balls[ count].y )
Inc balls[ count ].x, balls[ count ].speed
If balls[ count ].x > 1920 Then balls[ count ].x = 1920 - balls[ count ].x - balls[ count ].size
Next
framesPerSecond = ScreenFPS()
if framesPerSecond > MaxFPS
MaxFPS = framesPerSecond
endif
if frametime >= 0.5
frametime = 0.0
SetTextString( 1, " FPS : " + str(MaxFPS ) )
MaxFPS = 0
endif
//DrawText( FPS )
sync()
Until GetRawKeyPressed( 27 )
This might also explain why Rick Nasher gets worse performance. Possibly his drivers are not optimized for pushing images over the bus continuously. @Rick, maybe give this version a try, see if performance improves.
Runs about the same speed here (although sometimes 1800, rather than the 1700 before) however reading the FPS value is a lot easier than it was. Either way the FPS varies by quite a margin, rather than a constant rate (sometimes around 1400 FPS).
Its very mysterious.
On my laptop all three builds runs near the same speed(around 380fps, lower than i used qubes code) but all three have stuttering/flickering and tearing with vsync on.(with vsync off its to fast ;) =
On my Ryzen now both AGKC builds runs a little bit faster like before.Around 525fps.
The studio build the same like before.(vulkan)
But on my Ryzen no stuttering/flickering and tearing.
Now i test the new commands and try opengl on my ryzen.....
Okay thats crap....380-400fps! Remember, AGKC could to it with more then 500fps.
Opengl with ryzen is the same speed like on my lowend laptop.Aaand stuttering as well.
Its indeed a big opengl issue.
For those of you who are getting incorrect sync rates (i.e. 60 fps on a 75hz monitor) or getting a lot of tearing with vSync on, try making a couple of changes to Qube's code and see what happens. First, after line 14, put SetSyncRate(0,0). Put it after SetRandomSeed ( GetUnixTime() )
but before SetVSync( 1 )
Then, around line 55, remove the SetSyncRate(5000,0) line.
Now compile and run the code. See if you get the proper fps and if the tearing is eliminated.
@ c0d3r9
If you have BlitzMax NG installed, you could try my NG port to check if it is an AGK, OpenGL or DirectX issue.
bye
Ron
@Derron: The problem of flickering/stuttering have many other engines/frameworks too, it seems its a combination of opengl/synchronization to display issue.
I don´t know right.I saw that behaviour not only with AGK and on different machines.
Except DX, but i think dx uses(most in past) vsync as a standard and so some ugly things never happen.
The FPS issue is clearly a AGK Studio opengl problem.
@TomToad: Of course it makes not really a difference.Except you have a machine that can run faster then 5000fps
And for speed SetSyncrate(0,1) is better.
Btw. But right, the code is shorter and no need to set the syncrate twice.
I am aware of the "stuttering". It was more about the "raw fps" for the very same "test game logic". BlitzMax' Max2D uses immediate rendering (though there is some bufferedGLmax batching stuff). Maybe AGK does something not every computer likes - some shader processing, a borked up cache (refilled everytime) or something similar.
For the ones interested in something more:
https://gpuopen.com/archive/gpu-perfstudio/
https://github.com/baldurk/renderdoc
or as suggested by a fellow forum member:
https://apitrace.github.io ("easy" but not for vulkan)
bye
Ron
QuoteUsing DrawSprite is like using DrawPixmap in BMax, very slow.
No it's not :P
That was my understanding too, I thought it was the same as only making particular sprites visible (drawn) rather than hiding lots of sprites. If not then that's rather stupid.
Quote
Its indeed a big opengl issue.
No it's not! AGK has been running on Opengl from day one, but getting slower and slower - and more jittery.
Paul has responded to your thread Qube. Maybe ask him about DrawSprite too.
I mean its a opengl issue in AGK.
I think that was clear ;)
No you're blaiming Opengl and saying the Vulkan version is faster. The 2018 version of AGK was FAR FAR faster, by 1000FPS faster on my system. You really can't have this kind of wild changes in frame rates across systems on AGK. They really need to get this sorted.
No, i say the opengl renderer in AGKS is much slower then the vulkan renderer and the other both AGKC versions.
So its on the opengl side.Whatever Paul does inside AGKC/S.
I will wait if he can fix it.He should fix it.
Yes but you're missing the whole point!!
Yes on the latest AGK Studio the Vulkan version is faster than the Opengl version BUT the standard opengl version of AGK was far far faster. The AGK guys have gone backwards regards frame rates and smoothness with the Studio version! BUT again, that the frame rate varies wildly means no consistancy now from system to system. If you have a commercial game I wouldn't recommend it at all. They dropped the ball here.
QuoteYes on the latest AGK Studio the Vulkan version is faster than the Opengl version BUT the standard opengl version of AGK was far far faster. The AGK guys have gone backwards regards frame rates and smoothness with the Studio version!
Thats exactly what i said some posts ago.
Before i test AGKS on my ryzen i only used my non-vulkan laptop and i have the same results.
AGKC was better in july 2018...i know...
..okay..so, whats the conclusion now..what to rant about, i need to get ready ;D
They'll come up with something. I know it. :P
If help is needed: Why is the Vulkan Engine rendering everything even that which is offscreen? It's really lagging my game. OpenGL though has no probs with this.
There seems to be a bug with the way SetSyncRate() and SetVSync() works, or at least the documentation is wrong. This doesn't affect performance per se, but can explain why some have frame rates that don't match the monitor refresh rate and why there may be tearing with vSync on.
According to the docs, when SetVSync is set to 0, then the frame rate will match what is used for SetSyncRate. When SetVSync is set to 1, then SetSyncRate is overridden and the refresh rate matches the vertical blank of the monitor.
With 7-12-2018, it seems to work that way. If I set the sync rate to 75 and vSync to 0, the frame rate is ~75 fps. If I set the vSync to 1, then the frame rate drops to 60 (my monitor's refresh rate). If I set the sync rate to 30, then I get 30fps and 60fps respectively. However, if I set vSync to 1, then back to 0 while the program is running, it will go full speed instead of the value set in SetSyncRate. Apparently, the sync rate isn't just overridden, but completely disabled and must be reset when you set vSync from 1 to 0.
Now it seems that 6-11-2019 and studio behave differently. If I set the sync rate to 75 and vSync to 0, then it runs at 75fps. Set vSync to 1 then it goes to 60fps. However, when I go back to 0 within the program, it goes back to 75, which makes it seem that the sync rate is actually being overridden and not just disabled. A plus for later versions of AGK, but the real problem comes when I set the sync rate to 30. When I set vSync to 1, the fps remains at 30! It is not being overridden. In order to match the monitor's refresh, I need to manually set the sync rate to 0. So if you have a monitor with a 75Hz refresh rate, but the app has a sync rate of 60 (which is default if no sync rate is set), then you will get tearing as the app's rate is not matching your monitor.
It seems that SetSyncRate sets the maximum fps and only is disabled when the monitor rate is lower or matches the sync rate.
Ok guys this calls for some more testing..
After trying TomToad's code it now gives me with vSync a ~30fps and without vSync, lows of 341 and peaks of 369fps.
(And indeed much easier to read). ;) Some improvement, but still doesn't really explain things adequately.
Just now did a quick test(short on time) on my ancient homebuild PC of 2007, which has an AMD Athlon x64, 4GB and was recently upgraded with a GTX1030 GPU. "Now let me tell you what I already know."
(https://media.giphy.com/media/W5XkUh1xkioCs/giphy.gif)
Speeds are 60fps with and 470fps without vSync, so that's incredibly much faster in comparison I think,
as apposed to my 2019 Asus laptop with an i7 4cores, 2threads per core, 8GB and Intel HD and NVIDIA GTX 1050 GPU laptop.
And actually both OpenGL AGK C versions run slower(60 to 360fps ) than the Studio version.
Will need to test more precisely when I have more time. Will also test on my old laptop of the same age.
LMAO @RickNasher
That film was too good.
Paul replied to Qubes thread with fixes in a new Windows player. He said all concerns in the thread are fixed for next update.
Indeed. :)
Let's see what they come up with.
It seems Paul listens more than Mark Sibly ever did: https://forum.thegamecreators.com/thread/224808?page=2
I've read what Paul said about DrawSprite() but on Mac I can not make Sync() quicker at all :P
Perhaps the difference will be more evident in Vulkan? - Guess I'll have to do some tests in Windows, bah!
Same here on PC, it just seems to effect *some* systems.
If "DrawSprite()" really is an "immediate" command then the benefit should be very noticeable in demos like Qube's (drawing only one asset a hundred of times, no other assets "inbetween").
So what should differ is the amount of "draw calls" (can they be "read/printed" in AGK?). If draw call limit is not the FPS limiter then maybe fill rate, destroyed textures (need to reupload stuff after each immediate draw call).
Like said - maybe one should analyze a render frame with apitrace, renderdoc, ... they should show how the image is created (vertex buffers, single "draw commands", ...).
PS: I wonder why nobody blamed of that vsync() bug "Paul" just found after... how many months/years? Sometimes it seems the main functions are still possible causes of sleepless nights ;-)
bye
Ron
QuoteIf "DrawSprite()" really is an "immediate" command then the benefit should be very noticeable in demos like Qube's (drawing only one asset a hundred of times, no other assets "inbetween").
I guess some systems just handle it better. I've tried 1000's of sprites at once and can't make Sync() faster than DrawSprite() / Swap() on Mac. I suspect with Vulkan it will show up more but I'm not sure if I want to go down the route of hiding / cloning sprites so I think for now I'll just force OpenGL rendering and be happy that the main vSync() bug will be fixed in the next version of Studio along with some tweaks for DrawSprite().
QuotePS: I wonder why nobody blamed of that vsync() bug "Paul" just found after... how many months/years? Sometimes it seems the main functions are still possible causes of sleepless nights ;-)
I'm just glad that issues have been found and fixed / will be fixed. In the end it was worth compiling nine exe's across three OS's to gain a better picture of what was going on.
At least now Paul should make some benchmark/function test before he release a new version ;)
Quote
At least now Paul should make some benchmark/function test before he release a new version ;)
lol yes a very good idea, and a common sense approach. :D
I suspected screen refresh rate / resolution might have something to do with it so did a quick test.
On an external mon, with vSync on still gives same 30fps, while without goes well into the 500's.
Now the external mon has a lower res of 1360x768, so I lowered the resolution on the inbuild screen from 1920x1080 to that one and same thing there; 30fps with +500's without. However I also noticed both tries were having considerable flicker on some individual items, which I never had seen before. Switching back resolutions didn't resolve.
Then when I messed about with the IDE refresh settings, such as Event based rendering (disabled cuts fps to a crawl!) and in Windows Settings>System>Display>Scale & layout 100%(changes size of text, apps and other items) then suddenly the flicker was gone!
Weird stuff.