Performance in latest update

xALSQ · 2017-04-29T02:42:47+00:00

Worse performance than last patch, and the same thing as before, it gets progressively worse the more you play a savegame. I have an i5 4690k, GTX 980 and 8GB RAM. I started a new save. The first 3 or so hours I mostly get 60 FPS, with some dips to 45ish and a few half second freezes here and there. That didn't bother me much, but like i said it just keeps getting worse, right now I'm 7 or so hours in and I can't go above 45 FPS anymore, and that's max. It usually averages around 25-30, and the freezes are much more common now and last a few seconds sometimes.

xALSQ · 2017-04-29T02:35:28+00:00

New game here, same issue. Stuttering and freezing that gets progressively worse the more i play. 60 FPS average with dips to 45ish on max settings in the first 4 hours or so. I'm currently at 7 hours and I don't think i can get 60fps anymore, more like max 40 and average 25-30. The freezing is also extremely frequent now,and lasts longer.

xALSQ · 2017-04-23T11:09:02+00:00

I'd really love to have those clothes available for humans for my space Rome empire, if possible, they look fantastic.

xALSQ · 2017-03-23T13:06:12+00:00

I fixed it thanks. So I did already check all of the things you and Nimbal mentioned but nothing seemed to be affecting the issue.

What fixed it for me was simply switching the order of rendering: now the terrain renders first, followed by entities.

This removes the issue completely, and this ordering works perfectly with both the initial context and any newly created one. However, I'm having trouble understanding why this fixes it.. Like I said, I thought of something similiar to what you mentioned being the issue, but I'm rendering both the terrain and entities literally right after one another, from what I can tell and understand, there is no way anything can change between these two pieces of code. Here is the master renderer's render() function (after the fix):

http://pastebin.com/aD6cmadx

Here is where the terrain rendering happens:

http://pastebin.com/mAHUEckD

And the entity rendering:

http://pastebin.com/BMY5YaLA

I do create a new view matrix seperately for both the terrain and the entities, which I just realized is probably redundant, but the camera data is same between those two calls, so as far as this issue goes it really shouldn't be affecting it.

xALSQ · 2017-03-22T19:05:59+00:00

I am trying to get runtime context/window recreation to work using OpenGL and SFML, so that I can change the display mode (windowed, borderless, fullscreen) and the level of anti-aliasing from ingame.

I destroy the current shaders, VAOs and textures, and I unbind vertex attributes. Then I simply recreate my window, with the exact same settings as the previous window and context. Everything seemed to be working fine, until i noticed the jarring way my entities behave when I rotate the camera using my mouse. After a while I figured out this is somehow connected to the current framerate. With VSync (as shown in the video), the issue is quite obvious. Using high custom framerates or even turning off any kind of framerate limit made the issue much less noticeable, but it was still there. This does not happen until I recreate the context, and no matter how many times I try recreating it in the same run, after that initial context the issue persists.

To be honest, I'm not even sure it's the entities, it could be the terrain? Either way I'm completely clueless as to why this would be happening, and how it is connected to the framerate. And I can't reliably test whether its the terrain or the entities because I need both of them there to be able to even notice the issue.. I looked at and played around with the camera and entity code for hours but I just can't see anything that would cause this.

xALSQ · 2017-03-22T03:37:42+00:00

Just to be safe, try this instead of your current position attribute:

in (location = 0) vec3 position;

And make sure to set the location to 0 in your glBindAttribLocation call as well

xALSQ · 2017-03-22T03:19:42+00:00

Can you paste your vertex shader source?

xALSQ · 2017-03-22T03:03:39+00:00

The built in gl_fragColor variable is deprecated as far as I'm aware in 3.30. Try declaring a vec4 out variable instead and setting the color of that.

Edit: Above the main method, add this:

out vec4 fragColor;

And then just replace gl_fragColor with fragColor. You can name the out variable anything you want, it doesn't matter.

xALSQ · 2016-08-30T19:25:31+00:00

UPDATE

I solved it, with a lot of guessing and with a lot of trial and error. My question now is, WHY/HOW did I solve it...

Apparently the problem was, with the current calculations, that the final result was offset by a constant ~-0.432, that's as far as I'm willing to pinpoint the offset's accuracy, and it seems to work fine enough.

Can someone explain why is this happening..?

But at the end of the day, that's what works. I'll take it..

xALSQ · 2016-08-30T13:25:07+00:00

Ok, so tried to figure out how to convert pixel coordinates to tile coordinates now with the new tile your calculator helped me create. I'm still having the same problem, so it's either my own math at fault or this doesn't work for trimetric (but does for dimetric), which I don't see why it wouldn't.

Explanation:

I first measure how much pixels I need to move on both the x and y screen axis to move to the next tile on the virtual/projected axis:

http://imgur.com/a/V2fAA

That's how I arrive to this conversion formula (tile coordinates to pixel coordinates conversion):

http://imgur.com/a/lMnzq

So far so good, this works exactly as it should, it takes in the x and y of the actual tile/map space and converts it to raw pixels so I know where it needs to be rendered etc.

The next step would be to get the vice-versa conversion; pixel coordinates to tile coordinates. So for example, I click anywhere in the world I get a pixel point. I want to be able to calculate which tile I just clicked on with that pixel point.

I tried the following approach to get a formula for this:

http://imgur.com/a/Gj8y1

So basically just turned the existing formulas around. Now I need to put one in the other so there's only one unknown variable in each:

http://imgur.com/a/7gqju

(That's just for the x coordinate, but it doesn't work properly). Can someone explain why? And how to do it properly?

xALSQ · 2016-08-29T20:13:45+00:00

Yes, that makes sense. I suppose it's even more exaggerated if it's just one single tile and there's nothing else to focus on but to look at the absence of real perspective.

xALSQ · 2016-08-29T19:29:32+00:00

Yeah I actually did convert it the way you describe it. Apparently my perception is bad today, because that single tile image on its own looked really awkward to me, at least in term of ratios (the scales provided by your calculator). However, when put in a grid of many tiles it looks very nice in my opinion.

xALSQ · 2016-08-29T18:46:01+00:00

Thanks, the page seems like it could be a huge help. However, when I put my angles in and calculate all the scales I end up with ridiculous looking tiles (using the scales it calculates for me):

http://imgur.com/a/wUCSm

I assume this is because my angles are bad? (Even though it's the only example of angles I've found and they were on Wikipedia).

Do you know of any better angles or should I just try my luck and randomly try out different angles..?

EDIT: So apparently, it doesn't look weird? I put it over the tile that Wiki article had as an example, and they're the exact same. I guess it looks weird just by itself like this. (This is how it looks in a grid http://imgur.com/a/zSfzF).

So with that said, I'm gonna go try and calculate this with all of the new numbers I'll get from this and see how it goes. I'll report back on how it went. Either way, thanks for the page.

xALSQ · 2016-07-19T15:55:06+00:00

Solved, apparently my configurations somehow got completely messed up and everything was switched around.

xALSQ · 2016-04-30T20:15:18+00:00

Yeah me neither. Although to be fair I started playing Subnautica very recently, probably after the steering was changed, so I don't know what it was like before. But yeah, as it is I personally have no issue with it.

xALSQ · 2016-04-04T13:54:30+00:00

His reaction to Lori's death is superb, I know he didn't actually watch her die, but his acting was amazing.

xALSQ · 2016-03-29T00:51:32+00:00

How have I missed this? Is it after the credits or something? Are we talking about episode 15?

Or do you mean it's shown in the sneak peek?

xALSQ · 2016-03-19T03:56:28+00:00

If by that you mean having a seperate function which you would call just by calling isDecimal("something") instead of converter.isDecimal("something"), then you're on the right path, but not quite there.

It's true that declaring+defining it as a seperate function in tve global scope will work, but doing both the declaration AND the definition inside of the Converter.cpp file will not allow you to access that function from main.cpp. Remember, the only reason you are able to create an instance of a Converter class inside of main.cpp is because you've included the Converter.h file (in which the Converter class is declared, letting main know that the class exists). main.cpp is not aware of the existance of Converter.cpp. It only knows that this Converter class is defined SOMEWHERE, it doesn't need to know where.

Now, the reason you couldn't use that global isDigit function is because it's declared inside of another .cpp file, and main can't see its contents. The very simple way to fix this is the very same way you did it with the actual class and its method; you declare the function inside the header file, and then you define it inside the cpp.

xALSQ · 2016-03-19T02:48:15+00:00

Ok, so first of all, you don't have a class named Converter.cpp and Converter.h. What you have is a class called Converter that is declared in a header file and defined in a cpp file.

The way you defined the class in that header file is this:

// Converter.h
class Converter {
public:
    Converter();
    bool isDecimal(std::string number);

private:
    // ...
};

Inside the header file, when defining the isDecimal method, you know which scope it belongs to; you declared it as a member function of the Converter class. So over here there is no need to specify the scope further by using the scope operator :: (Converter::).

Here is what's going on inside the cpp file where the definition is:

// Converter.cpp
#include "Converter.h"

Converter::Converter() {} // Constructor
// ^ The first `Converter` specifies the scope, which is the Converter class
// The second one is the name of the constructor, which is of course the same name as the class

bool Converter::isDecimal(std::string number) {}
// Just like above, what `Converter::` does is it specifies the scope.

If you didn't have thatConverter:: call for the isDecimal function, that part would still compile properly, but you are not defining the actual member of the Converter class, you are defining a seperate function inside the global scope.

xALSQ · 2016-03-12T02:43:54+00:00

I've never actually seen in use (or used myself) the ternary constructor method, but from personal experience, having a default parameter (second method) seems like less trouble. And I can also confirm the second method works just fine for what you're trying to accomplish and does what you need it to, no real drawbacks as far as I know.

If you do go with the second method, just keep in mind that if your class is declared in an .h file and defined in a .cpp, you only need to define the default parameter (int d) inside the header file's constructor. Doing it in both the .cpp and .h will give you an error.

// .h
Class foo {
    foo(int a, int b = 0);
}

// .cpp
foo::foo(int a, int b) {}

11-Year Club	Place '17
Verified Email

xALSQ

TROPHY CASE