I finished adapting my classic BlitzMax game to NG and it works great in Windows in both Windowed and Full screen modes and also in both architectures (x86 and x64).
In OSX it works good in Windowed mode but works way too fast in Full screen mode, it seems as (I may be mistaken) it skips a lot of frames so it performs like crazy!!
Anyone can help?!
Quote from: sphinx on July 05, 2019, 00:45:34
I finished adapting my classic BlitzMax game to NG and it works great in Windows in both Windowed and Full screen modes and also in both architectures (x86 and x64).
In OSX it works good in Windowed mode but works way too fast in Full screen mode, it seems as (I may be mistaken) it skips a lot of frames so it performs like crazy!!
Anyone can help?!
Are you using a deltatimer? You need a way to have a capacity on your framerate... Seems your frames are uncapped.
You should never rely on frames anyways to regulate game speed.
For example!
If you're using VSync to limit your FPS; you'd maybe get 60 FPS on most monitors.
But I'd have 144 FPS with my monitor, which means the game would be over twice as fast for me.
There are also lots of ways to force VSync off anyways.
You'll want delta time things, or use a fixed update rate, and let the game render at any FPS.
Thanks for your replies.
I will check delta timer.
I have other problem with OSX!
Inside the game ONLY, the mouse is moving the opposite directions!!!!
Any clue?!
You should maybe isolate the issue in a separate example and post it as an issue on the NG GitHub.
https://github.com/bmx-ng/brl.mod/issues/79
And this already links to:
https://www.syntaxbomb.com/index.php/topic,4951.msg21354.html#msg21354
Brucey suggested to move to SDL.mod on Mac (GL2SDL or GLSDLGraphics).
bye
Ron
Quote from: Derron on July 05, 2019, 09:43:59
https://github.com/bmx-ng/brl.mod/issues/79
And this already links to:
https://www.syntaxbomb.com/index.php/topic,4951.msg21354.html#msg21354
Brucey suggested to move to SDL.mod on Mac (GL2SDL or GLSDLGraphics).
bye
Ron
I did confirm it on the link you posted above!
And Brucey kindly informed me to move to SDL mod.
I did a delta time on my own and it works great now on OSX Windowed and Full screen:
Graphics 800, 600, 32
' ################### DELTA TIME #############################
Global FPS:Int
Global DelayTime:Int
Local Counter:Int
Local mSec:Float
While FPS < 60 '25 is the minimum acceptable FPS for my game but upto 60 FPS is great
Cls
Counter = Counter + 1
If mSec < MilliSecs()
FPS = Counter
mSec = MilliSecs() + 1000
Counter = 0
End If
DrawText FPS, -100, -100 'for some reasons fake/unrealistic FPS is returned if Cls, DrawTex and Flip are missing!!!
Flip
Wend
'16.6 is 1000ms / 60 FPS
DebugLog FPS
If FPS > 60 Then 'No delay time is required if FPS is already lower than 60 frames per second
DelayTime = Int((16.6 - (1000 / FPS)))
End If
DebugLog "Delaytime: " + DelayTime
' ###########################################################
I only needed to call 'Delay DelayTime' just after Flip command of my Main Game Loop.
Well, it works great for me but I do appreciate if anyone give me his 2 cents!
Just had a quick glance but...
Isn't your code crunching in 60 renders as fast as possible and then waiting the rest (delay...) until the second is gone?
This will lead to
stop...go go go...stop
effects.
Assume one plays with a 180hz screen refresh rate.
You render your 60 flips in 0.33 seconds.
Then you delay for 0.67 seconds to fill the second.
This means for 0.67 seconds the very same screen is displayed (no movement etc).
...
Deltatiming has to do with the movement of stuff.
X = X + speed * deltaTime
So if deltatime was a whole second (1.0) then the complete speed value would be added.
Means speed (or other values) are to define as "per second".
Deltatimes are the times of the update intervals.
Normally one would even have Tweening for render interpolation... Delta for the updates (so mostly constant) and tweening for renders (which can be varying when under heavy gpu load).
To keep it easy...just use deltatiming for now and have your loop
Repeat
UpdateWorld()
RenderWorld()
Until exitApp or AppTerminate()
Bye
Ron
I haven't looked at the code (annoying on mobile), but it doesn't have to work like that Derron. (maybe his code does though)
But if you keep a steady "delay" between updates; you will end up with a smooth update rate.
And then just keep rendering VSynced.
But of course, all methods has its up and downsides.
What I personally don't like about delta timing values like movements and such is that if the user has a very large "lag spike" the value will end up very large.
And then the object might jump so far that it goes across the entire screen, messing up some triggers or collision along the way.
You can work around that, of course, but I feel like it's a lot of work... compared to something like a locked update rate.
Quote
What I personally don't like about delta timing values like movements and such is that if the user has a very large "lag spike" the value will end up very large.
Dude, that's why you never allow large spikes! You set a smallish maximum value of frame change and catch-up over several frames - not one.
And fixing a frame-rate doesn't work well (not smooth) with the multiple monitor refresh rates, like 60, 75, 144 and such.
Guys here have set a fixed 60fps update and it's not smooth on my 75hz monitor. Delta time and it would be smooth.
Quote
Just had a quick glance but...
Isn't your code crunching in 60 renders as fast as possible and then waiting the rest (delay...) until the second is gone?
This will lead to
stop...go go go...stop
effects.
Assume one plays with a 180hz screen refresh rate.
You render your 60 flips in 0.33 seconds.
Then you delay for 0.67 seconds to fill the second.
This means for 0.67 seconds the very same screen is displayed (no movement etc).
...
You maybe right but that does not happen with my game on 4 different machines (varying specs)
Quote
Deltatiming has to do with the movement of stuff.
X = X + speed * deltaTime
Believe it or not but that's exactly what I am trying to avoid with my game!!
Far from the headache of reviewing and adding delta timing to all update methods of the game, it will ruin some of the game working!!
I do not know how to explain it but it doesn't worth it for me :(
Anyway, thanks for your reply. I do appreciate it.
Quote from: Derron on July 05, 2019, 09:43:59
https://github.com/bmx-ng/brl.mod/issues/79
And this already links to:
https://www.syntaxbomb.com/index.php/topic,4951.msg21354.html#msg21354
Brucey suggested to move to SDL.mod on Mac (GL2SDL or GLSDLGraphics).
bye
Ron
I did a work around for this :
Local YMouse:Int
While Not KeyHit(KEY_ESCAPE)
?MacOS
YMouse= ScreenHeight - MouseY()
?Not MacOS
YMouse = MouseY()
.
.
.
Wend
Quote from: Steve Elliott on July 05, 2019, 17:42:58
Quote
What I personally don't like about delta timing values like movements and such is that if the user has a very large "lag spike" the value will end up very large.
Dude, that's why you never allow large spikes! You set a smallish maximum value of frame change and catch-up over several frames - not one.
And fixing a frame-rate doesn't work well (not smooth) with the multiple monitor refresh rates, like 60, 75, 144 and such.
Guys here have set a fixed 60fps update and it's not smooth on my 75hz monitor. Delta time and it would be smooth.
Not to mention with a delta-timer, you can easily make your game "process" at normal speed even if the game trips up and runs under target framerate. (frameskip) Deltatimers help keep everything in sync harmony.
In my deltatimer, i have variable game speed, so that i can have slow motion and speed up as well as Framerate monitoring. My DT allows me to run at any designed FPS on any HZ monitor nicely.
Never program without a deltatimer. Even in my software, i cap with a deltatimer. All my software runs at 8fps unless it's a game.
Without a deltatimer, you're basically running as many loops as possible on your machine everytime. Wasted resources.
Quote from: Yellownakji on July 05, 2019, 18:02:53
Quote from: Steve Elliott on July 05, 2019, 17:42:58
Quote
What I personally don't like about delta timing values like movements and such is that if the user has a very large "lag spike" the value will end up very large.
Dude, that's why you never allow large spikes! You set a smallish maximum value of frame change and catch-up over several frames - not one.
And fixing a frame-rate doesn't work well (not smooth) with the multiple monitor refresh rates, like 60, 75, 144 and such.
Guys here have set a fixed 60fps update and it's not smooth on my 75hz monitor. Delta time and it would be smooth.
Not to mention with a delta-timer, you can easily make your game "process" at normal speed even if the game trips up and runs under target framerate. (frameskip) Deltatimers help keep everything in sync harmony.
In my deltatimer, i have variable game speed, so that i can have slow motion and speed up as well as Framerate monitoring. My DT allows me to run at any designed FPS on any HZ monitor nicely.
Never program without a deltatimer. Even in my software, i cap with a deltatimer. All my software runs at 8fps unless it's a game.
Without a deltatimer, you're basically running as many loops as possible on your machine everytime. Wasted resources.
Indeed, having the option to make a slow motion or fast forward of your game is a cool feature.
Quote from: Hezkore on July 05, 2019, 16:36:27
I haven't looked at the code (annoying on mobile), but it doesn't have to work like that Derron. (maybe his code does though)
But if you keep a steady "delay" between updates; you will end up with a smooth update rate.
And then just keep rendering VSynced.
So how do you handle "/setmaxfps 30" or whatever might be feasable on older computers? Also there are machines with "vsync" not working properly - so do not rely on that (which is why some people used "TTimer"-intervals).
Also it is clear that "it doesn't have to work like that" - I just wrote about what the poster had as "code in use".
Also of importance with this kind of coupled and vsync-linked logic/render approach is ...
Quote from: Hezkore on July 05, 2019, 16:36:27
What I personally don't like about delta timing values like movements and such is that if the user has a very large "lag spike" the value will end up very large.
And then the object might jump so far that it goes across the entire screen, messing up some triggers or collision along the way.
You can work around that, of course, but I feel like it's a lot of work... compared to something like a locked update rate.
This is why you split updating from rendering ...
You could update your physics 200 times a second to solve your "paper thin wall VS bullet" problem.
Or you just check more closely (move the bullet not "one step per update" but "10 micro-steps per update"). That way you won't miss such stuff.
Of course this is only useful if that entity has a "can colllide"-flag - without you can skip the additional cpu workload.
Quote from: sphinx on July 05, 2019, 17:57:08
Quote
Deltatiming has to do with the movement of stuff.
X = X + speed * deltaTime
Believe it or not but that's exactly what I am trying to avoid with my game!!
Far from the headache of reviewing and adding delta timing to all update methods of the game, it will ruin some of the game working!!
I do not know how to explain it but it doesn't worth it for me :(
Try to explain, delta-timing can NOT ruin some of your game logic - except you did it wrong (eg did not split logic from drawing/rendering).
Also in most cases (moving objects) you will have a "Type" having a "Move()" or "Update()" method - add your delta-timer-logic there once and all extending types will inherit from it. There is no reason to "avoid" it.
Only reason not to use delta-timing is on specified hardware - if you programmed for some old computer or arcade machine (where you eg lock to interrupts).
bye
Ron
I think you misunderstand.
I'm not saying you should rely on VSync, I'm saying the opposite really. (that was the issue to begin with)
I'm saying you can update the game at a steady rate and keep rendering VSynced or unlocked.
You'll generally want to use VSync though, cause there's no need to render more frames than your screen can render anyways.
And you can use a fixed update rate (separate from rendering) and still get very smooth gameplay.
Keep in mind that games like Battlefield and a lot of other games run at 30 updates per second.
But they update things related to the rendering and positioning as the scene is rendered.
Giving you a fixed update rate with smooth positioning and animations which will work on any monitor HZ.
I have 30 "logic updates" and 60 renders per second too. And if vsync is enabled, these 60fps become "refresh rate"fps.
Sorry for having misunderstood you regarding vsync.
So back to "why split update/render":
- allows to have flexible "render rates"
- allows to have (more or less) constant "logic updates"
- allows to define speeds/velocity in "per second" rather than "per hertz"
- allows for slow-downs or "speed-ups"
- allows to run without even rendering something pretty easily
bye
Ron
True words.
Listen to this man. ^
Hi.. Im just testing something..