SyntaxBomb - Indie Coders

As for sounds you've got to go with screams and splatters.   

Quote from: Steve Elliott on March 15, 2021, 18:47:31
As for sounds you've got to go with screams and splatters.   

Agreed. I have a decent library - just hope I have enough squelchy/fleshy sounds 

Too much Rugby on this weekend and old firm today but managed a few things. 

Splash screen.

http://www.steviegoodwin.plus.com/images/Untitled/WG22.png

Started working on more lab defences. These things will cut you to ribbons.

http://www.steviegoodwin.plus.com/images/Untitled/WG23.png

Looking good Stevie!

(Grammar police on http://www.steviegoodwin.plus.com/images/Untitled/WG22.png , "it's" should be "its"  )

Quote from: therevills on March 23, 2021, 08:59:52
Looking good Stevie!

(Grammar police on http://www.steviegoodwin.plus.com/images/Untitled/WG22.png , "it's" should be "its"  )

Cheers, now sorted. 

It's been a while since last update.

I've spent most of this time rewriting the code     For some reason everything was originally designed to run at 30fps. It just worked better for the animations and was easier to tell what was happening etc..  Physics values were found by trial and error. The plan was always to have a fixed physics timestep at 60fps BUT it turns out that jump height, distance and even collisions were all fecked at this higher frame rate.  I managed to fix it all using various formula to first determine gravity required to reach a certain distance/height over a certain time and also the vertical velocity required at that gravity to jump to that height. It now pretty much plays the same but I was close to giving up.

Note to those who say just use variable physics timestep using deltatime rather than a fixed timestep - it does not work and is too eratic to be predictable. The game runs at 200fps on my shite setup so should be smooth for all at 60fps.

In other news I've finished the editor so can now design, load, edit and save any level very quickly.  It was much easier than I thought it would be.

Here the latest finished level. Its a bit of a bastard but it can be done so probably one of the later stages.

http://www.steviegoodwin.plus.com/images/Untitled/WG24.png

Yep I'm with you Steve on fixing FPS to a known value then basing everything from that.
60 FPS is the general standard to aim for. I know people want x and y and a, but the actual refresh is usually dealt with by the is so it should all just work 

lol on modern systems it's a minefield.   

But using non-delta systems (instead fixing a FPS update) means that you're not updating in-sync with the refresh rate (because everybody has a different refresh rate on their monitors).  Running Steve's games on anything but a 60hz refresh rate monitor results in a 'slight judder'.  He solved that particular problem by offering a 75hz mode in the menu (and adjusting movement amounts accordingly).  It works, but you have to give a refresh rate for all monitors to cover all bases - like 60, 75, 120 and 144.  A small number currently, but the user then has to bother with selecting the correct value.  Not a bad solution though.

In 3D games I feel it's not so noticable and with a 3D physics type game then a constant update time would seem more appropriate.  But with silky smooth 2D scrolling or movement then delta-time has always worked better for me.  Plus the fact if you're updating at 60FPS and somebody is running your game at 200FPS, then the people with fast computers are not getting the extra smoothness - because the update is fixed.  Like I said, it's a minefield.

I'm looking forward to playing this.

Quote from: Steve Elliott on March 28, 2021, 20:49:35
lol on modern systems it's a minefield.   

But using non-delta systems (instead fixing a FPS update) means that you're not updating in-sync with the refresh rate (because everybody has a different refresh rate on their monitors).  Running Steve's games on anything but a 60hz refresh rate monitor results in a 'slight judder'.  He solved that particular problem by offering a 75hz mode in the menu (and adjusting movement amounts accordingly).  It works, but you have to give a refresh rate for all monitors to cover all bases - like 60, 75, 120 and 144.  A small number currently, but the user then has to bother with selecting the correct value.  Not a bad solution though.

In 3D games I feel it's not so noticable and with a 3D physics type game then a constant update time would seem more appropriate.  But with silky smooth 2D scrolling or movement then delta-time has always worked better for me.  Plus the fact if you're updating at 60FPS and somebody is running your game at 200FPS, then the people with fast computers are not getting the extra smoothness - because the update is fixed.  Like I said, it's a minefield.

I can't guarantee the same results if I allowed 60,75,120 and 144hz refresh due to floating point inaccuracy using Euler (semi implicit integration). I can probably detect the refresh without the need to select it but I cannot test the results other than 60fps. This is totally different to the likes of Gunstar because the physics there did not have to be spot on and wouldn't be a game breaker.  I'm sticking with 60fps for now and might add something nearer deadline.

I recently read about Super meat boy being broken at high refresh rates, falling through platforms and not being able to make certain jumps, so its a problem for the pros too it seems.

That doesn't sound quite right. You would imagine that at high frame rates the step would be very small. In wich case i would imagine the problem might be detecting the same collision twice or the code to bounce something off a surface would actually leave the object in contact with the surface
I know people who would check the distance travelled and if it was larger than the smallest element in the game then it would step trough the distance traveled to ensure that bodies did not fall through objects.

Quote from: blinkok on March 28, 2021, 22:39:17
That doesn't sound quite right. You would imagine that at high frame rates the step would be very small. In wich case i would imagine the problem might be detecting the same collision twice or the code to bounce something off a surface would actually leave the object in contact with the surface
I know people who would check the distance travelled and if it was larger than the smallest element in the game then it would step trough the distance traveled to ensure that bodies did not fall through objects.

Thats what I do. The most I check for x movement is 1 pixel a frame and y is 3 pixels (terminal velocity). I agree and have no idea what caused the issue for SMB other than reading about it.

Looking really great Stevie

For 2D games I keep it as super simple as possible. I have a target FPS ( usually set to 60fps ), all movement and timer variables are floats. I then have the worlds most basic delta time routine of deltaTime = GetFrameTime() * targetFrameRate which I just use like Inc x, 1 * deltaTime. Incredibly basic stuff but why complicate the issue.

I find it works very well at 60hz, 100hz, 120hz and 144hz. I could faff about with interpolation, averaging and prediction etc etc but I've not had any issues running my 2D games at smooth 60hz.

Quote
For 2D games I keep it as super simple as possible.

This is my AGK Delta Time code:


// init delta time

Type Delta

prev_time   As Float
time_frame  As Float
update_time As Float
req_fps     As Float
dt          As Float
prev_dt     As Float
min         As Float
max         As Float

EndType

Global delta As Delta
ResetTimer()

delta.req_fps      = 60.0
delta.update_time  = 1000.0 / delta.req_fps
delta.min          = 0.005
delta.max          = 5.0
delta.prev_time    = Timer()
delta.time_frame   = 1.0 / delta.update_time
delta.dt           = 1.0 / delta.update_time
delta.prev_dt      = 1.0 / delta.update_time

// delta time function

Function get_delta()

delta.time_frame = ( Timer() - delta.prev_time ) * 1000.0
delta.prev_time  = Timer()

delta.prev_dt    = delta.dt
delta.dt         = delta.time_frame / delta.update_time

// limit increase from frame to frame

If( delta.dt > (delta.prev_dt * 2.0) )

delta.dt = delta.prev_dt * 2.0

ElseIf( delta.dt < (delta.prev_dt / 2.0) )

delta.dt = delta.prev_dt / 2.0

Endif

// keep frameskip sensible and avoid delta becoming too small

if( delta.dt > delta.max )

delta.dt = delta.max

Elseif( delta.dt < delta.min )

delta.dt = delta.min

Endif

EndFunction delta.dt



// update with delta eg)

Function update_enemy( dt As Float )

        enemy.speed = 2.0
enemy.x = enemy.x + ( enemy.speed * dt )

...

Endfunction


// main loop

dt As Float

Repeat
dt = get_delta()

        update_enemy( dt )

Until game_mode = QUIT


Nice and neat but how does it work with a physics integrator? Like I said, i can't use a variable dt/timestep as it will impact your ability to make certain jumps etc.