3D TileEditor

[iWasAdam]

Here's the final code in operation:

At and angle, zoom, screen size. The mouse is now properly tracked in 3d/2d.
The cyan outline will track exactly in 3d the 2d mouse position. and will also update dynamically if the view is changed.

I know it's not that interesting to look at, but the code was challenging to work out

[iWasAdam]

tiny addendum to this. Compiled for windows and now fully compatible with 60fps!!!!

[Derron]

With 60fps or with windows? If with 60fps your timing code would need an overhaul :p

Hope you do not loose yourself in details but finish and release a game - best testbed to see if things work on all computers :-p

bye
Ron

[iWasAdam]

A stable 60fps is my global aim for both MacOS and Windows - now achieved   
I have 2 Macs and 2 Windows machines to test on. All have very different cpu and graphics cards.

60fps is stable in debug mode. In release mode there can be a general 30% speed increase.

As for detail vs game. The last time I went for game before detail, it was a complete disaster. This time I am making sure all the system level stuff is completed and working perfectly cross-platform.

[Derron]

So 60 fps is kind of "max" stable on your machines? Or are the 30%+ in release mode measured without fps-limitation? In my game I have <60fps in some screens when doing debug builds as so many stuff is done there (GC kicks in I think). On other screens I have some hundred FPS more.


bye
Ron

[iWasAdam]

No, I set my internal timers for 60fps and lock the main loop to that. Actual fps will fluctuate +- 2 in normal operation. if it begins to drop then I know I am stressing the gpu and need to look at my render systems.
30% gives me some flexibility that retail will always be 60fps.

sound emulation is running at 120x per second

I lock to 60 across all systems so that whatever machine/OS it runs on, the end experience remains the same.

[RemiD]

personally, i limit at 30fps, but the game should be playable at as low as 15fps... SO the turns moves animations speeds must be automatically adjusted depending on the fps...

if it begins to drop then I know I am stressing the gpu and need to look at my render systems.

just consider that the computer your game will be played on not necessarily has the same hardware / os than yours (so it may have less fps)

[Derron]

Some devices have other refresh rates...so if you play it on 144Hz displays...it would flicker/delay here and there?

What happens to 59Hz TFT Screens...hickups?

Bye
Ron

[iWasAdam]

yep. I've got some pretty low hardware here to test on. 7yr old laptop and very bad surface 3 for testing. everything rock solid at 60fps

it would flicker/delay here and there?

Nah. All solid with no flicker

Here's the first show with the old cardrogue characters being used showing alpha in operation:


Here's the previous engine with the same models and graphics being used. Notice the FPS !!!!!


The new engine is doing thing very differently and now fully supports true particles, light mapping and shadow systems with a rock solid 60fps.

The key issue with the last renderer was it failed on windows completely and had very bad performance on lower systems (which I had not caught in time)

It's taken a long time to get to this point with learning all the 3d and then getting it right!

I think it should also be said that the first version (although it looked fine), there was no title system as such. Everything was hard coded. The new tile system is what I envisaged it should have been - flexible and extendable.

[Derron]

You know you received a PM regarding tile systems a bit time ago? ;-) Maybe you find the time to write a bit about it after the compo.


@ flickering
I am talking about the slight delay happening when hardcoding for 60 fps - or using a delay calculating with 60 fps. If you have a 59 Hz display it will expose a slight slight hickup each ~1 second.

This is why some people lock it to the refresh rate (flip 0 vs flip 1) and use tweening for their internal refresh rate (60hz, 30 physics updates/s: real data, tweened data, real data, tweened data).


What FPS would you get without any limitations (no delay, no vsync) this should be > 60 on your old hardware. On your newer hardware you would surely reach 300, or way more.
If you already only receive 65 fps or so - then you will see lower FPS once you add the game logic. In TVTower I experienced the AI doing 20ms-work-per-AI-tick things in certain situations (analyzing and optimizing the upcoming programme schedule). With 60 FPS you only have 16ms for: rendering _and_ updating if you do it in one single thread. In my case this means I would only render 59 fps or so (it only misses this single one, as afterwards the task is done and the AI was only using 1-2 ms). I had to split that AI task to do "a little bit here and there" each tick - so the task now takes 10 (AI-)ticks instead of 1 - but the framerate wont drop that much in that very very rare occuring situation.

Similar things could happen in your games - which is why I wanted to make you aware.


PS: What resolution is the game running in? I assume FHD will use a bit more render time, did you check that out already?


bye
Ron

[iWasAdam]

You know you received a PM regarding tile systems a bit time ago

I did? That one must have slipped through the radar. If you want me to go into the tile concepts - no problem

The fps system is run on timers, so there is always a slight variation. All the animation systems are time based so there are no issues regarding this.

I cant say about an unlocked fps speeds as the whole system was coded from the ground up based on a particular render approach. so it's not a simple task to just 'turn it off'. I did a quick test (resetting the timer interval from 60 to 120), and it all felt twice as fast! Although the FPS counter still reported 60 - the counter is internal code so maybe is doing something else as well? But interesting to note.

Again with AI and other 'tasks', I hand tweak to get maximum performance where needed. One thing I've found is that stuff like AI doesn't need to be run each 'frame'. So a number of 'tasks' run at different times to even everything out.

Resolution is the great one - Although not tested on mega displays (2000-5000 res) - I test run both windowed and fullscreen (fullscreen is running at the monitor resolution 1920x1200). In fullscreen there is a slight speed up as windowed mode has lots more resources being used.
General resolution I am using as 1397x852 as this is the window size that best fits my dev. But again I do test multi-resolutions and it remains rock solid at 60fps

a quick test between cpu use in debug and retail with the exact same scene is: Debug 29%, Retail 9.9%

[Derron]

animation/movement should be done on an _different_ timer base (or custom "Timer" thing).
split updates (logic, movement,...) apart from rendering.

Rendering is just drawing the current state of the world (current might mean "last calculated + some simulated/tweened" coordinates).

At the end movement / "the world" should also work with a 1 fps-setup - it just would look very "stop motion"-alike.


What happens if the computer got a slowdown (anti-virus jumping in, OS doing a sudden update in "background" - eg. my Windows 10 notebook has 90% CPU utilization everytime it installs some windows updates) ? Does a slow down mean, the world is moving "slower" too? Just think of the games benefitting from pressing the "Turbo-Button" on your old x86-DX processors.
All the input handling should be done on the physics update - or if possible even less often (depends on your setup - dunno if Monkey2 does polling each time, as keystate polling costs a bit CPU - which is why Brucey added a DisableAutoPolling()-thingy on BlitzMax, after he profiled my game and some slowdowns).

So instead of
entity.x = x + dx
DrawImg(entity.img, entity.x, entity.y)

you split things into update() and render()

Code: BlitzMax

1. 'update():
2. '====
3. 'deltatime would with vsync be around 0.016
4. 'dx is no longer based on your 16ms frametime, but a "pixels per second" value
5. entity.x = x + dx * deltatime
6. entity.y = y + dy * deltatime
7. '... add further collision checks etc.
8.  
9.  
10. 'render():
11. '====
12. DrawImg(entity.img, entity.x, entity.y)
13.  
14.  
15. 'enhanced render():
16. '====
17. local tweenX:int = entity.x + timeSinceLastRender/frameTime * entity.dx
18. local tweenY:int = entity.y + timeSinceLastRender/frameTime * entity.dy
19. '... add additional checks for not "overlapping" with other entities
20. 'which are normally detected in your update call
21. DrawImg(entity.img, entity.x + tweenX, entity.y + tweenY)
22.  

@ AI
Yes, I run the AI on every "ingame minute" and on every "real time second" (the AI gets informed about onSecond, onGameMinute - and for both about onTick). So I have a TWorldTime-Class doing all the ingame-time thingies for me, and a "TTime"-class doing the realtime stuff.

so for ingame-day-night-cycles you would use TWorldTime, but for physics you would use TTime (or even better your DeltaTimer-stuff).



@ high-res
good to read. Just wanted to avoid you testing on 640x480 and wondering why a FHD then isn't 60fps+.

[iWasAdam]

Code: [Select]

Method OnUpdate60()
_gameFrame += 1
_gameTime = Millisecs()

RequestRender()

CheckMovement()

storm.Update()
physics.Update()

ProcessKeyboard()
End method

There my base render code. _gameTime is where all the timing stuff comes from and it is time based not frame based.

[Derron]

Side question: So you always render before updating - so you render the "last state" not the current one? Means it is a delay of 16ms between "what you see" and "what happens" ?

If you changed it to "OnUpdate120" - it only can move faster, if "physics.Update()" (and others) are assuming a constant deltatime (time since last call to itself) somewhere. Maybe you move "x + dx" with "dx" being a value not affected by the real deltatime/"time since last call".

Just imagine you have it hardcoded "x = x + 1". Of course it would move faster if you call this 120 instead of 60 times a second. This is why deltatime comes in handy. You base your dx on a "pixels per second" base. So if you had a 60 updates/second value before, eg. 0.5 - to move 30 pixels per second, you now use the one you _planned_ with your value. In our case here this means the value becomes "30.0" (30px/second).
If you still want to stay with your constant 60 updates per second, you would move this way: "x = x + 30.0 * 1/60.0". And as it now becomes framerate independend you would use "x = x + 30.0 * deltaTime". So if you have a render frame function needing a bit longer this time, this will get compensated accordingly (it eg moves with 30.0 * 0.030 instead of 30.0 * 0.0166).

Dunno if you knew this already, so excuse if you did. Just want to help if that is possible.


bye
Ron

[iWasAdam]

No problem. I was using delta time prior. But now I'm locking to 60fps it's not an issue. I can easily modify if needed in the future