Jump to content

Gijs-Jan

Development Team
  • Content count

    296
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Gijs-Jan


  1. On 3/22/2021 at 5:36 PM, maxm222 said:

    Yeah, sure, I knew all that, of course, no big whoop, I didn't have a cow, man, I didn't think the empire would fall.

    It just that [blushes], since I hadn't seen it again, I thought it was fixed in the last iteration and that someone might not know that it had snuck back in.  I guess I just forgot: "don't sweat the little stuff."  Gotta go back and work the steps.

    :)

    If you come across this issue again, can you upload the GC auto save & the save on strategy that was made prior to going to the crash site?


  2. Hi,

    We haven't looked at the visuals of shooting in GC for quite a bit and because a lot of new assets got introduced need to give it another pass - so likely this is a temporary change.

    Having said that, it would really help us fix the issue if you could provide some details on the specific issues you have with it.
    Is it mechanical (Do you feel they miss more, hit more, etc) or visual (it looks bad)?

    What specifically felt or looked bad and do you maybe have screenshots or recordings of it? (or maybe a save game?)

    What was the last version you played prior to this version?


  3. On 10/8/2019 at 12:23 PM, Solver said:

    Alright. I can say that simply 

    
    python -m json.tool save.json > save-pretty.json

    works well on saves to get them into a readable format (quadrupling the file size!) for some quick edits. If those prove difficult to load, I should be able to get it back into the ugly format with another Python one-liner.

    Yeah, and given the file-size problem we have already (until I get to the optimization), you can understand why I really didn't want to have it pretty-print by default! :')


  4. 29 minutes ago, Solver said:

    I'm on Linux, and vim can deal with the save files, but it doesn't make that very convenient.

    If you're not going to pretty-print, why not just compress the whole thing? With data like what you have, a quick compression is sure to yield at least a 90% ratio. Yes, you could say it's not then human-editable save files, but frankly I would say the current ones aren't anyway. When you need a special editor or plugins to open the file properly, it means at least some level of tech skill is necessary, and in that case you might as well ask the users to decompress the file first.

    If I change a save file so it's prettified, should I expect the game to load it properly still?

    It's simply a matter of time and manpower but definitely planned - it's just not a priority at the moment. 
    You are right in the quick win w.r.t. compression, although we need to do that on part of the file so we can support the Save/Load elements' partial loading. There's a bunch of other optimizations planned as well to do with aliasing the common patterns, etc.

    I assumed Windows because I didn't think that on Linux you would have issue pretty-print formatting it efficiently. 
    It might be that the Save/Load Element will give issue as it's only partially loading files and scanning for (extremely simple) terminator patterns, but the underlying load system has no issue with formatted JSON.


  5. 23 hours ago, Solver said:

    One small request for the tech team. Would it be possible to change the JSON serialization for saved games to a pretty-printed format with linebreaks? Currently it's just one ginormous line, which means that many editors have trouble working with the file, and it's also harder to manually edit stuff due to it not being pretty-printed.

    The problem is that the file is already gigantic (relatively speaking) and pretty printing increases the size even more given how / what we serialize. 
    (The pretty print doesn't really concern itself with speed either. For the size we've got an optimization pass planned)
     
    If you're Windows based I suggest taking a look at Notepad++ with a JSON formatting plugin which works well even with very large files. (https://github.com/sunjw/jstoolnpphttps://sourceforge.net/projects/jsminnpp/ or https://sourceforge.net/projects/nppjsonviewer/)


  6. Most of the current high-CPU usage (when everything is "idling") is coming from the dynamic batching that Unity is doing as most meshes haven't been statically batched. Given that we're in a destructible environment that's rather hard to do and we want to wait until late in development where we better know which usecases we can easily batch, and which ones we cannot.

    Having said that - High CPU temperature is mostly because the machine is simply using what's asked from it.
    I can "optimize" the game (to give more FPS), but I'll always ask the hardware to give it's fullest potential.
    In a game you tend not to want to leave performance on the table... 

    A framelimiter does mitigate this if FPS is high enough for you and I'll add it as a task for the settings screen for Chris to review.


  7. 1 hour ago, Alienkiller said:

    I and the others don´t have that problem.

    Seems only yours. Check for Virus, newest drivers, upgraded Windows etc. If there is no Virus / Hack you can go to the next step.

    After that try a repair from Steam. If it finds nothing (wrong or missing file normaly) make a normal or new game. Sometimes your saves are damaged.

    If that won´t work (and Step 1 finds nothing too) then you have to delete the Game completley [and all saves etc.] that there is nothing and I mean absolutely nothing is left.

    Then make a completely clean and fresh install. That´s all what you can do.

     

     

    While I appreciate trying to help in the issue, the problem is most definitely in the code and is an issue we should fix.
    To be clear, doing the above will not fix the issue and I do not recommend it for this issue. :-)


  8. The error is popping up in the interaction between logic and animation - a pretty notorious (in it's instability) section of Unity's API. 
    That specific code is not multi-threaded (90% of our core logic is single-threaded, only the FOW calculations run off-thread and they are isolated).
    We have been able to replicate the issue once or twice (in the past two years) on build, every time adding new logging and getting a new piece of the puzzle.

    If there is anything unique about your setup I suspect it might be in how you issue orders.


  9. Thanks for trying out the build on Linux!

    I suspect issues, if any, are mostly in Ground Combat with regards to shaders.
    Feel free to report any issues in either this thread, so we can collate them, or through the F12 bug report but make sure to mention you run on Linux for custom bug reports.

    Having said that officially we won't support a Linux build at this moment. Unofficially I'll keep an eye on this thread and those reports.
     


  10. 1 minute ago, Chris said:

    It's under My Documents >> My Games.

    There's definitely a crash in the game that occurs if you complete a project and there's another project in the queue after it; if that's the cause of the bug for you then don't worry - pretty sure we'll hotfix that one tomorrow!

    Aw man, I already lost so much sleep the past few weeks :'-(

    Kidding, we're glued to the issue tracker at the moment and patching what we can!

    • Like 1

  11. There are a lot of different things contributing to this issue, and it also depends on what type of rendering setup you are using (forward/deferred, lightmapped / realtime etc).

    One of the big underlying causes is that Unity doesn't really deal well with dynamic environments where there are a lot of non-static GO's.
    This in particular starts to break down when certain rendering paths don't properly support batching. The end result is that the CPU spends a lot of time creating dynamic batches that are straight up ignored and cause individual render calls in parts of the render pipeline (stalling the GPU).

    The solution we've tried inhouse is to manually combine meshes and objects for those parts of the level that are indestructible after the scene loads, which already gives a mighty speed boost and solves both above issues.

    The other issue is that Unity simply doesn't like runtime combining of scenes with lightmaps, which is making completely randomized maps quite a pain to implement.

    I want to assure everyone that we know the issue, and we've been testing solutions to this throughout development and I'm confident that we can get orders of magnitudes of improvement in FPS.
    We simply haven't implemented those solutions as they would slow down the work being done on nailing down the level design workflow.

    • Like 2
    • Thanks 1

  12. 3 hours ago, drages said:

    If devs add the option, why not.. pathfinding and attack code should be there. The game should able to calculate more then one tile units, able to target it as one.. it can attack to other things too.. AND we need to able to add totally new enemies with the models and animations, which is the hardest part for a modder..

    Lot of assumptions there!
    Adding in multi-tile pathfinding will definitely require a bit of extra code. I'm not saying it's impossible, but it'll definitely require some work.
    This is mostly because Chris wants to avoid the various issues that multi-tile units introduce.


  13. @Skitso

    To be honest, I'd refrain from blaming anything on your end before I really start on the optimizations!
    And when I do and you still have issue, and you have the time, we can probably take a look at what specifically it is on your machine that might be bottlenecking it. :-)

    • Thanks 1

  14. 1 hour ago, raidsoft said:

    Would be great if you could separate the graphics settings to be adjusted manually and separately in the final game instead of only presets. Being stuck with the unity presets is extremely restricting in terms of tweaking settings to increase performance for individual cases. Not everyone values settings the same either so just giving people the option to tweak it if they want would be great, or at least have the option to tweak it in an .ini file if making UI assets for it would use too much time.

    It's definitely planned.

     

    9 hours ago, Skitso said:

    @Chris

    A quick test: Camera on top of the building left from the starting position so that the roof is removed.

    Fantastic - 29fps

    Beautiful - 34fps

    Good - 37fps

    Simple - 44fps

    Fast - 68fps

    Fastest - 68fps

    As you can see, even with my relatively powerful gaming rig, the only playable (60 lock with vsync) settings are the 2 lowest.

     

    Hmm, interesting. I wouldn't expect such a hard drop-off, especially with your hardware (I've got a 1070 here as well).
    And you're right in that the Simple to Fast is the point where all dynamic lights get shut off. 
    Suspect it's the shadow handling then, which is also tied to the lightmaps.

    Earlier you mentioned that there wasn't any AA btw; the whole reason we're still using forward rendering at the moment is for AA, and it should be enabled upper tiers.


  15. Yeah, this is definitely due to the lighting setup in that case (per pixel lights is too high on the Fantastic setting).
    It won't be an issue in the main game.

    It should be fixed once we sort out the lightmap issues, or alternatively something more drastic to fix it.
    (There are issues with the lightmapping in the rendering path we're using in Unity, which was used because it supports hardware AA)

    The transparancy effect is a side effect of how Unity deals with it, and we'll probably need to write a different shader for it.


  16. The FPS drops I've not seen on similar hardware. Have you been able to tie it to specific cases?
    (Units walking, or shooting destructible terrain, etc)

    As for the performance:

    There are a tonne of optimizations we've simply disabled because they just consume development time while things are up in the air.
    There are "minor" ones such as logging and debug code that cause most of the "stutter" currently in game.
    There are "major" ones such as mesh merging, lightmapping (for those knowledgeable, a bit more problematic in our setup) and optimizations on the materials, or even rewriting shaders such that they're not just plug-and-play shaders.
    The mesh merging alone, although mostly benefiting lower-end hardware, bumped FPS about 3x-5x (from 60ish to 300ish).

    And then there are the cases where some code is still doing way more than it should be doing, because we're experimenting with certain mechanics.

    You can expect a lot of improvement in speed as we continue development the coming few months because a lot we haven't been able to do as we were still changing, well, almost everything.

    I'll bring up performance in the morning meeting tomorrow and see if we might be able to put out a comparison build now that the pressure of the Kickstarter is partially behind us.

    • Like 1
×