we need o wait.... the V1.14 update....

Of course when making a game, you need all the fps you can get, as you KNOW it will drop as you start adding logic and graphics. The more you get to work with the better your game. Having it almost hitting 60 fps out the gate is of course a clear indication you are not going to be anywhere near by the time you are finished. I always try to get any game I make at 60 fps, but in GG, to date that has been all but impossible. We still need some serious speed upgrades imo. The more bells and whistles that get added are only going to slow things more. The recent lua downgrade has not been particularly helpful either.

I'm a big supporter of Game Guru and love it in the main, but it's lack of speed is one thing we can all agree on. It needs to be better! Watching the fps drop like a stone because you happen to have placed more than a couple of objects in it gets kind of old.

Me too. Got a lot invested in its eventual success.



Absolutely agreed. And certainly should not get worse with post processing switched off. More than pleased that new effects are added for those 'high settings' but need to keep the base performance at least as is and when possible keep improving too. Hopefully this frame drop is something that can be found, if it's the lua engine changes it might be better to go back to the original config (as it might benefit the most people).

I agree ...what I meant was



As in it would never drop below 60fps ...Which is very unlikely I know

The more FPS you have the more often the Lua scripts will be run, if every script starts off with a check on player distance from the entity then that is a lot of wasted processing . Generally the player position is changing at at such a slow rate that checking ten or twenty times a second is sufficient. Similarly the AI doesn't need to run at 240 FPS! 20 would be fine there too.

In my scripts I use a scheduler that keeps track of real time and enables scripts to be run at a defined rate.

In GG the Vsynch doesn't just mean that screen updates are capped at 60Hz (intended to avoid tearing on standard monitors) it means that everything is capped, including Lua. I can understand why this is the case, it simplifies the whole game loop and means that the engine will operate in a far more consistent fashion but it does mean that on extremely powerful systems they are going to be idle most of the time.

Human eyesight cannot differentiate between an image updated 60 times per second and one updated at 300 times per second (a complete waste as monitors themselves general top out at 200Hz!) , in fact for standard video production 25 FPS is normally deemed sufficient, the highest Hollywood has played with is 64 FPS (Used first in the Hobbit I believe) and audiences did not react positively to it (those that reported seeing difference said it looked 'duller').

From what I gather GG does not support multiple cores, it is 32 bit, and doesn't support fancy new GPUs (DX9 only) . This means it is limited in its ability to leverage all that lovely hardware in your kick-arse gaming rig, also being a general purpose game creation tool rather than an actual fixed purpose game it cannot take advantage of any of the usual 'cheats' that would be used, the game engine doesn't know nor can it be programmed to know what the game designer needs from it so has to do everything in a standard predictable way and allow the game designer access to configurable values with which to tailor the performance .

From my personal experience with GG the performance is pretty much what I would expect from a general purpose (purportedly "easy") game creator, my biggest beef with it is the time it takes to actually load a level, even small levels. Maybe if small levels could be loaded really quickly then people would make smaller levels with much better performance characteristics! One of the things I really like is how quickly I can change my game and retest it, if you've every tried U4 for example you'd know how painful it can be to have to 'Rebuild the lighting' on even small levels just because you added a pebble.

I used to work for Kodak Motion Picture Imaging (back when film companies used nothing but actual film for their cameras), and I agree with this, back then the sweet spot for film speeds was just short of 1 frame per second per frame size, so the standard 35mm film used would have a sweet spot of 32 to 34 fps (it wasn't actually calculated on the film size, it just worked out that way until you got up to a certain size so we used it as a short cut to get a "close enough" figure). That figure is generally still valid for 4:1 or letterbox video now, but hd and widescreen video is quite a bit higher because of the aspect ratio.

But, unfortunately people expect certain minimums with games now days, and one of those things is a minimum of 60fps, so that's what we need to aim for with our end products.

The eye has evolved some neat tricks to keep you alive, the central part of the eye which is where you are focusing you attention is very insensitive to movement but highly sensitive to colour details, the edges of the eye are the opposite, i.e. almost no colour vision but highly sensitive to movement. This way whilst you are busy trying to pick that nice juice apple if a leopard moves in the edge of your FOV you are instantly aware of it and can run to apple pick another day.

What this means in practice is that we are very sensitive to movement at the edges of the monitor screen so with large monitors any flicker present can be very irritating. The closer you sit to the screen the worse the phenomenon. When CRTs were all the rage very wide screens needed to have a higher refresh rate in order to avoid driving the people using them round the bend (the vast majority of people wouldn't even notice btw, as a population we have really crap visual apparatus but around 1 in ten people would notice). Modern LCD and LED screens work differently, the image is maintained for much longer and the flicker effect is far less noticeable. Also very expensive monitors now have frame buffers in them and they update at two or even 4 times the rate at which the image is coming in from the computer or Blu-Ray player or whatever.

My main monitor is not only huge but contains the fancy new active synch stuff which in conjunction with my top of the range GFX card means that the synch rate is synchronised, so no tearing ever. What this basically means is that no matter what FPS the computer pumps out the screen image is rock solid, unless the frame rate drops below about 40 FPS (at which point lagging at the edges of the display becomes noticeable) the image always looks the same.

Now I must admit my eyes are a tad old and weary so a younger me may notice a difference at say <50 FPS but the point is that driving the display much higher is pointless unless it is for manhood measuring purposes.

Well, yes to a point. For instance having a script check a timer value is still having to check a timer value, not really that much faster than a distance check. Not forgetting you probably need that distance check anyway at some point. Of course if you write one huge main script that controls when others are run that would probably be a different matter. Even then you will probably have to have many scripts attached to objects, all of which will be running regardless. I've used timers to try to get code to check less often many times in GG and other programming languages to squeeze a bit more speed. It nearly always has a cost down the line, with inconsistent bugs cropping up now and again. not always, but some things you have to update in sync with everything else. My Occlusion script is a good example of this sort of thing, which I released free quite some time ago. Just before the actual occlusion came in and so made a little less useful. I got some great speed from reducing the tree update frequency, but ran into some odd issues along the way.

GG does use multi cores to a limited degree. Pretty certain the Hobbit was filmed at 48 fps also Games are a bit different when it comes to fps. You can't treat it in the same way. You have control in a game, the reaction time to your input is critical, making 120FPS much more responsive than 60 FPS. Now, I'm not interested in 120 fps with my rig obviously, but people with one that supports it tend to expect it. Your eye might not notice, but the combination of your eye and hands will. 24 fps is the normal for film but run a game at that and you can really tell it is running badly.

All that said, I would be happy with 60 fps Steady with no drop, would be great. Faster loading times would be great also. As you say we could make smaller sections with good effect without having ridiculous waits in between. I'm not sure what can be done in this area though. I think GG already keeps any same entity between levels so it doesn't have to reload them. With more memory you could cache all the objects on the initial load in a stand-alone, rather than load them each level which would be way faster, but not really an option I imagine.

The way my scheduler works is to quickly check how much time has passed since the last time it was run (a few adds and sabtracts per frame) and if less than the passed in or default value the script can be aborted.

For example my scrolling map script updates every 50 ms which is all that is needed for a smooth map update.

I have an update planned for it which will initialise each entity using it with a random start point so that all scripts don't trigger on the same frame, that way the processing can be spread out more evenly. If a level started to creak a bit I can simply change the 50ms value to 100 ms, the map would be less smooth but overall it wouldn't matter that much, in fact it could add to the realism as things in the real world don't update instantly, handheld GPS units for example.

The other thing the scheduler does is keep a track of the current FPS, this can then be used in scripts to work out how far something needs to move in order to look realistic, I use this trick in my classic radar script to make the sweep take 4 seconds (which is the actual sweep rate in real radar systems btw) regardless of frame rate.

(this script is available over on the scripts forum btw)

how do I opt out of this update?

I want my GG kept at 1.13 as 1.131 is unusable for me, if I'm lucky enough to actually make the map-editor load I get 8-12 fps and 4-6 with SOA (to be fair tho there's a lot in this map), something is going very very wrong and I'm in the middle of a map if my progress is stumped again I'm quitting game dev and moving to the woods to whittle spoons!

I'm going to update, clean, scan and defrag my PC and try the beta again but I would like to know how to block this update coz if steam updates it in this state then I can no longer use it



I'd be happy for 60fps, and its true the eye does not see much above 60fps unless your superman, you guys that get 300fps must have some beastly machines, on a empty map with no terrain I get max 130 and 57 (avg) with terrain ...... would love to resize the map so its not sucking up over half my fps before I've added a single model.

We need to wait the NEXT update.... i HOPE it's NOT going to take MONTHS before the new release...

@PartTimeCoder-to opt out of the beta, open up steam, select gameguru [publicpreview]-right mouse click ->properties->betas->[drop down box]-> select NONE-opt out of all betas

I agree that something has changed, on an empty map with bloom off I get >300 FPS, turn on bloom slider and it drops to around 100, on a completely empty map that shouldn't happen I wouldn't have thought. I'll have more of a play tomorrow.

If you opt out of the betas, does it revert to the previous version though? I wish that, like before (Reloaded), all the beta releases showed up in your TGC account, then you could pick and choose which one you want to use. In UE4, an engine update can break a game, but at least with that you can keep as many versions of the engine as you desire. (provided you have the space for them all, of course!)

Pretty sure it does, had to do it myself before and all reverted back to last official release.

I hope they take as much time as needed.

Yes Opting out of the beta will revert to the last live build.

Righto, here is the results of my experimentation:

Release version on gaming beast (AMD Nano + skylake i5):

Start up and hit rocket, completely empty map, defaults settings: 220 FPS, Bloom slider 0: >300 FPS. (actually hovering around 400 mark)
Load The Big Escape level, hit rocket, press E: 67 FPS Metrics panel 'shaders' indicator @ 37.
Move forward until point where first audio triggers (lots of shadow at this point): 75 FPS Metrics panel 'controls' indicator not even registering.

Reload Beta
Start up and hit rocket same as before: 140 FPS! Bloom slider 0: > 300 FPS same as before
Load The Big Escape level, hit rocket, press E: 65 FPS Metrics panel 'shaders; @35 (pretty much same as before)
Move forward to first audio point: 35 FPS!! Metrics 'controls' indicator @ 40 ( please do not use profanity even abbreviated )
On my POS laptop (ASUS something-or-other with Intel integrated GFX):
Pre-Beta on TBE level : 12 FPS (all sliders minimised 29 FPS)
Beta on TBE level : 8 FPS (all sliders minimised 29 FPS)

So Houston we have a problem. I don't think it is the shaders alone and I doubt it has anything to do with Lua as in all cases the Metrics for AI was the same for pre-beta and beta tests.

Hopefully the above might help Lee track down what is going on, might be helpful if someone who isn't having any reduction in FPS could chime in, maybe identify whether this is related to a particular OS or GFX chipset? (I'm running Windows 10 btw), any Nvidia chipset owners like to chime in with their figures doing the above tests?

yea I reverted back to v1.13 by opting out of the beta but I want to opt out of ALL updates till I have finished this game, I'm happy with the way GG is for now and I could do without it getting broken by steam pushing out the update when its out of beta

any issues with future versions I'm happy to deal with at a later date I just want a stable environment for the short term to get this game done, my PSU gave up a while ago and fried my HDD so I lost everything I had not backed up and pretty much had to start from scratch and I really do not want any more delays



that's exactly what I am trying to prevent, once its built I will tackle a new version

can not load the beta, i need a code -.-

Okay im in the beta and got FPS drops as well. I didnt changed anything in the scene.

Here an Image WITHOUT the Update (FPS)


and here is one WITH the Update (FPS)


Greetings

Copy your gameguru folder to a different location, then run it directly from the exe in that folder, you won't get any more updates, you won't however be able to download any store items. But if you really want you can use the steam copy to download them and copy them across.

Another problem is WHY when you make for ex 2levels, in your first level you reach the winzone, and goes to the level two.
WHY THE LOADING IS SO SLOOOOOOOOW!!!!!!!!!!!!!!
EVENT with 2 empty SMALLS levels, LOADING TIME IS KILLING US, (and we are in 2016....)

@Belidos, thanks I did not think we could do that with steam apps, its a perfect solution.

Excellent idea!



Whining like a six year old will get you nowhere. Buy a faster computer. Better yet, just leave.

@ imothep85

Ok a chance to try a couple of models and this slow level loading test your talking about .. Two level jumps and exit 26 seconds.
For me its fine .. What specs are you running ?

This is my computer
http://www.notebookcheck.net/Review-Asus-A95VM-YZ030V-K95V-Notebook.76775.0.html

When i load levels (from one level to another) in RAGE, the game its fast!!!
when i load levels (from one level to another) inGameGuru, it's SLOW!!!
with RAGE i get 15/20s of loading between levels Indoor/Outdoor

As Laptops go that's pretty respectable and I would expect pretty good speeds ...
Comparing with a game loading levels isn't really a very good comparison ... Battlefront take me a good couple of minutes to load levels for example compared to Gameguru..

put a 2 level map together with stock assets and post the fpm files here if you like ... we could try your map to see what speeds we are getting loading the levels compared to you ...

Hi all im getting an issue if i use the beta, both musicinzone and soundloopinfinate stop working, if i roll back they start working but then i get the getterrian height error because im using Gtox's Wyvern's, is there any way i can add that 1 file manually to test if thats the conflicting file? EDIT: Thanks Lee but think i have it sorted now (and sry this should have been in the bugs section)

Thanks everyone for the feedback and answers to some of the questions. I have added my answers below as I wrote them as I read them:

@imothep85 : I have decided on a new approach to FBX and make use of AssImp which has much better FBX import features that mine. Will be in V1.14

@reliquia : I may have left VSYNC=1 in the SETUP.INI, if you change it back to zero your FPS rate will be restored

@TazMan & Belidos & Mariokiki & Kalle801 : While the current public version is out (V1.13) can you make a standalone of your 106 fps level and also create a standalone with the new public preview and send me both. I can then do a side by side comparison and let you know what might have changed. Thanks.

@Dev911 : You can bounce between the current public release and the public preview from your Steam settings, but remember to make backups before and after just in case.

@PartTimeCoder : If you like (and if others agree), I can leave V1.13 as an option in your Steam beta choices, allowing everyone else to move to V1.131. It does look like I will be adding a 'non-SAO' post process path for V1.14 so you can rejoin the world of faster frame rates then. Sound good?

@Kalle801 : The BETA is for internal use. The preview you want is the Public Preview version which does not require a code

@imothep85 : What is the loading time for your standalone executables between two almost empty levels, I am curious!

@Honkeyboy : Your issue "musicinzone and soundloopinfinate stop working". Can you send me an FPM with a level that references them. And also include the 'soundloopinfinate.lua' which I do not have and I can check against the latest version, thanks!

Given this feedback, do you feel the V1.131 should be put on hold for a few more days while we address the above? It would mean delaying the V1.14 and the EBE release while we work to reproduce all of the above and ensure we're mostly happy before proceeding. I do plan to lock in the current V1.13 as it's own build so those who don't want to upgrade to V1.131 do not have to. For now, I have postponed the plan to go live tonight until we bounce these issues about a while. Thoughts welcome!

I agree with "Bod".

Actually this may be a good practice .....
Always leave the earlier version available so users could step back a version if they have show stopper situations

I agree with synchromesh. but also would like to see any issue of now to be fix. the main reason for this update was to take time out to fix bugs I need this update to work right and don't mind waiting on the EBE. being to EBE is not going to enhance any of the game play mechanics or add much to our game and it just enhance on how we can develop a game or make a level faster or easier really don't care to wait on. I never hard time making levels in guru. it's the bugs that is stopping me.

I agree, might be a good practice to have two builds available all the time, so if something goes wrong for some people but works fine for others then they don't have to wait too long for a fix.

As to the standalone thing, I won't be able to do that until the weekend, but i'll send it off then.

Mod hat off ...I have to agree here also ... Despite the missing features users want right away ...What GameGuru can do it does very well .. But with unpredictable bugs and niggles a lot of the time ... So many little things not quite finished

Is the SAO the visual improvement Lee demoed the other week? How do you turn it on/off?

Hi all,

I reverted GG at its previous version 1.13 and I've got a strange visual problem now...

Take a look at the picture attached. Strangely, only the player stick is not blurred.



I'll go buy a pair of glasses !!!

I usually don't need my glasses to look at a computer monitor, but I guess I need them now! Weird!

@ Mariokiki. Looks like depth of field is on with the the blurry pic? Are the settings normal? Perhaps a verify is in order...

@lord julian. Enable bloom and SAO is also enabled.

Keeping an old version available would be a good idea for people working on something they don't want to break. Certainly better than manually copying folders in Steam

Fixed it for ya ... Now it all looks the same

THANKS Lee.

Do you mean http://www.assimp.org/ for xbf import?

Actually the loading time between two levels dpend on how much objects you have in your scene, for example the level azylum takes around 30s to load, others take a little bit less, but in general its around 25/30s

I would llike to know if for the loading screen its possible to have animated backgrounds instead of a static image???

Thanks for the feedback on the reply to the feedback I think I will take some time today to see if I can restore some speed for V1.131 by creating a fast path for the post process shader and also use an optimized LUA module, so expect a new public preview soon (you will know it as it won't have the B8 designation). The problem with bug fixes and functionality tweaks is that the development of them could effectively go on for months, and I am assuming most users would like regular updates to GameGuru. V1.131 would be a version which contains X many fixes and tweaks, and V1.14 would also contains X many fixes, and so on. Providing we don't break existing functionality, I am happy to stagger fix releases so everyone gets a little bit of what they want via a sequence of regular updates.

@lordjulian : There is a new slider in the Visual settings panel which has SAO in the title, slide it to zero to switch off SAO.

@Mariokiki : When you revert, it is highly likely Steam will not automatically restore files to their previous state. My recommendation for reverters is to backup your files before you revert anything, then select the V1.13 build, then do a full Steam verify on your installation. The visual issue you see is likelt caused by new engine and old shaders, or old shaders and new engine.

@imothep85 : Yes the ASSIMP website is correct, and we already use this technology to great effect with AppGameKit, and users seem to like the freedom it brings. I think 30 seconds for loading a new level is fair, but I am curious how long you feel it should typically take to load and process?

I have a few test cases for the speed test so thanks for that, and once I get it tuned to run as fast as the V1.13 build, I will release an update to the preview and let you know here first.

Using ASSIMP tech is a good idea.

I also want the 2 options available.

3com

what I said about bug fixes I only meant towards things that are broken or don't work properly. just want to make that clear. speed is not much of an issue and everyone pc is different in this case. that will be an on going project for guru and will never be solve anytime soon. because for every graphic feature that will be added it will take from the performance one or another. wasting time to fix that will be the inevitable. I personally just run a bank level with all slider off using f11 to test the [performance to see is there a real change to every update. as far the new feature goes it will always take slow down or drop the frame rates. turn all the sliders on and shader on highest, well you know. but this why I don't care for or use these graphic features and don't want to see no more added no time soon. graphic are not everything and guru has a long way to go to get what everyone is looking for eye candy. I accept guru graphics as is. also seeing Wolf new game says it all.

25 to 30 seconds to load between levels is very reasonable in a single player game and nothing to worry about, I've played games from AAA publishers that had up to three minutes between levels. Heck when I was younger you could wait for up to half an hour for a level to load with the old cassette tape media :p

I have now uploaded a new PUBLICPREVIEW build which increases the speed of your levels if you dial SAO down to zero. You can keep bloom, motion blue and DOF as before with no speed consequences as in V1.13. You will still see a small FPS reduction that I had thought was the unoptimized flag for the LUA module, but it must instead relate to some other functionality that has been added in V1.131. Hopefully this version is now fast enough for V1.131 public release and we can continue beta testing the new issues that have been reported during the V1.14 development. Any show stopper, please email me directly at lee@thegamecreators.com. Thanks!

My Steam update seems to be stuck at 90%.

Same here.
Server overloaded?

Edit: It say "update in queue"

3com

which one is it i have 3 to choose from ?

Getting connection timeout error.

@ Tarkus1971
I just have none, v1.13, and public preview.

Do you end successfuly update process?

I keep in 90% ....

3com

I grabbed it a little earlier, so I can only think the server is busier than normal.