What Do You Need Help With? V6

[Fatfatfatty]

[QUOTE=Tamschi;41733865]It's a bit problematic with value-type vectors, as operators can't use ref parameters (which is really stupid in my opinion, unless they are inlined in which case the "value call" would be faster once the copy is optimized out).

[editline]6th August 2013[/editline]

That would mean that after dt has passed the acceleration is different from the changed positions though. Or is that irrelevant here?

[editline]6th August 2013[/editline]

dt must be very small to get enough accuracy, if the elapsed game time is too large you should instead repeatedly evaluate a smaller one.[/QUOTE]

ElapsedGameTime.MilliSeconds is regularly at 16 milliseconds

[ZeekyHBomb]

[QUOTE=Tamschi;41733865]That would mean that after dt has passed the acceleration is different from the changed positions though. Or is that irrelevant here?[/QUOTE]

[quote=http://gafferongames.com/game-physics/integration-basics/]it calls the acceleration function to calculate the acceleration for the current state at the time t+dt[/quote]
The state passed in is the state at t + dt, if I understand that correctly.

[QUOTE]dt must be very small to get enough accuracy, if the elapsed game time is too large you should instead repeatedly evaluate a smaller one.[/QUOTE]

Also make sure that the size of the forces are correct in regard of your world size. Try smaller k and b in acceleration().

[thf]

[QUOTE=Fatfatfatty;41733859]Oooh, it was just a fancier word for something I already knew :v[/QUOTE]

You will probably find that for very many things in programming.

[Fatfatfatty]

[QUOTE=ZeekyHBomb;41734005]The state passed in is the state at t + dt, if I understand that correctly.

Also make sure that the size of the forces are correct in regard of your world size. Try smaller k and b in acceleration().[/QUOTE]

I keep lowering my k and b, but even at billionths of a billionth it still accelerates off screen faster than i can blink and then just goes to NaN

[ZeekyHBomb]

[QUOTE=Fatfatfatty;41733934]ElapsedGameTime.MilliSeconds is regularly at 16 milliseconds[/QUOTE]

Wait, so are you passing in 16 or 0.016? It should really be the latter.

[editline]6th August 2013[/editline]

Also I guess the initial position should be more or less close to 0.

[thf]

While coding my game, I realised that I while I want to use modern OpenGL as much as possible, I also want to support things like laptop video chips. I am not sure if I have to drop down to decrepated OpenGL or something to get good support. I also don't know about GLSL versions and which one I should use. Is there some good place where I can read which versions that most laptops (and desktop video cards of course) support?

[Tamschi]

[QUOTE=thf;41734583]While coding my game, I realised that I while I want to use modern OpenGL as much as possible, I also want to support things like laptop video chips. I am not sure if I have to drop down to decrepated OpenGL or something to get good support. I also don't know about GLSL versions and which one I should use. Is there some good place where I can read which versions that most laptops (and desktop video cards of course) support?[/QUOTE]

With GLSL 1.2 you'll have support for most crappy integrated Intel laptop graphics, deprecated functions aren't necessary for anything realistically in use for playing games today.

[thf]

[QUOTE=Tamschi;41734612]With GLSL 1.2 you'll have support for most crappy integrated Intel laptop graphics, deprecated functions aren't necessary for anything realistically in use for playing games today.[/QUOTE]

So I can use the same client code (CPU code) and just switch shader versions and it'll work? Coming from GLSL 3.3, are there any substantial changes to my shaders that you think I need to make? I'll read more into details later but I'm really interested in a summary.

[Tamschi]

[QUOTE=thf;41734625]So I can use the same client code (CPU code) and just switch shader versions and it'll work? Coming from GLSL 3.3, is there any substantial changes to my shaders that you think I need to make? I'll read more into details later but I'm really interested in a summary.[/QUOTE]

Provided that you don't use any features unavailable on that particular hardware, yes.

Use [URL="http://www.realtech-vr.com/glview/index.html"]GLview[/URL] to check available extensions, there also seems to be a database feature that list extensions available on different hardware.

[thf]

[QUOTE=Tamschi;41734687]Provided that you don't use any features unavailable on that particular hardware, yes.

Use [URL="http://www.realtech-vr.com/glview/index.html"]GLview[/URL] to check available extensions, there also seems to be a database feature that list extensions available on different hardware.[/QUOTE]

I'm not sure if I actually use extensions. Does GLEW load extensions?

edit: Alright, I found out it does.

[Fatfatfatty]

Okay, my code works a little bit better, but the accelration function is complete haywire, it will just make my stuff go back to (0,0) and fly back and forth

[WTF Nuke]

[QUOTE=ZeekyHBomb;41731573]This is correct.
Just std::move it again when initializing the member in Model, because rvalue-references themselves are lvalues, which means for them to become rvalues again you need to move them.[/QUOTE]

Ok, so you mean like this?
[cpp]Model::Model(std::vector<std::pair<std::string, int> > && m)
materials(std::move(m)){
}[/cpp]

Another quick question, I'm trying to make the file loader more manageable, and to do this I've decided from using a vector of floats to a vector of arrays of floats.
[cpp]vector<float> vertices;
//to
vector<std::array<float, 3> > vertices;[/cpp]
The reason is because this implies association, as there is association between three values. However, what I want to know is if there is much of a performance hit (which really matters with bigger files), how to use std::copy with something like this, and how to construct the arrays quickly using emplace_back or push_back (I can't use vertices.emplace_back(x,y,z)). I could use a struct instead then, and if so, is there a performance hit there either?

[ZeekyHBomb]

[QUOTE=Fatfatfatty;41736066]Okay, my code works a little bit better, but the accelration function is complete haywire, it will just make my stuff go back to (0,0) and fly back and forth[/QUOTE]

Yes, that is the springy force of the example code in the article. You need to put in your own acceleration function to what you desire.

[QUOTE=WTF Nuke;41736181]Ok, so you mean like this?
[cpp]Model::Model(std::vector<std::pair<std::string, int> > && m)
materials(std::move(m)){
}[/cpp][/QUOTE]

You're missing a colon before materials, but otherwise yes, like that. Also, in C++11 you can do std::vector<std::pair<std::string, int>> without a space between the closing angle brackets.
That type looks like something you'd want to typedef, too.

[QUOTE]Another quick question, I'm trying to make the file loader more manageable, and to do this I've decided from using a vector of floats to a vector of arrays of floats.
[cpp]vector<float> vertices;
//to
vector<std::array<float, 3> > vertices;[/cpp]
The reason is because this implies association, as there is association between three values. However, what I want to know is if there is much of a performance hit (which really matters with bigger files), how to use std::copy with something like this, and how to construct the arrays quickly using emplace_back or push_back (I can't use vertices.emplace_back(x,y,z)). I could use a struct instead then, and if so, is there a performance hit there either?[/QUOTE]
Either of the three version should perform the same, although I don't know if the compiler is smart enough to still vectorize it properly (provided any of your code can make use of auto-vectorization).
You could just benchmark loading some huge models and compare. If you do, please post your findings, I'd be interested.

You can do vertices.emplace_back({x, y, z}) with std::array (look up initializer lists/std::initializer_list) and when providing the proper overload for your struct constructor (although then you could also do emplace_back(x, y, z)...).
When you go with the struct, you should make sure it fulfills POD criteria. I'm unsure if a weaker criteria suffices in order to still retain the same span of optimizations for the compiler.

[Richy13]

[QUOTE=ZeekyHBomb;41725077]Sure
[cpp]#ifdef MY_NEW
void* operator new (const std::size_t size)
{
void *const p = std::malloc(sizeof(MemoryChunk) + size);
//stuff
}
#endif

void* operator new (const std::size_t size, const int param)
{
#ifdef MY_NEW
//do param stuff
#else
static_cast<void>(param);
#endif
return new(size);
}[/cpp]

Just tested it, works fine for me. Seperate new.cpp containing overloaded new and delete and main.cpp just containing main() and a call to new and delete.
Make sure you are indeed building with that file.

Sorry, I meant curly brackets.[/QUOTE]

Is there any need for the

static_cast<void>(param);

Also when I do

return new(size);

I am getting intellisense saying: IntelliSense: expected a type specifier, this is what I was getting when I overwrote new[] which is why I took it out

[editline]6th August 2013[/editline]

Oh, and how do I actually use the new "new" with the debug parameter?

[ZeekyHBomb]

The cast is to stop the compiler from emitting a warning about an unused parameter. It won't actually emit any actual instructions.

The IntelliSense parser might catch something wrong. Try maybe ::new.
As long as the compiler compiles it you should be fine. Maybe you can wrap it around some preprocessor #ifs to stop it complaining.

You do new(newParam) Type(ctorParam);.

[Fatfatfatty]

I dont even know how a custom acceleration function is supposed to look like :p

[thf]

[QUOTE=Fatfatfatty;41736672]I dont even know how a custom acceleration function is supposed to look like :p[/QUOTE]

Just wondering, is this orbit static? (as in, it will never be affected by anything else than the thing it is spinning around)
If so, you could do a simpler analytic solution instead of a numerical one.

[Richy13]

[QUOTE=ZeekyHBomb;41736640]The cast is to stop the compiler from emitting a warning about an unused parameter. It won't actually emit any actual instructions.

The IntelliSense parser might catch something wrong. Try maybe ::new.
As long as the compiler compiles it you should be fine. Maybe you can wrap it around some preprocessor #ifs to stop it complaining.

You do new(newParam) Type(ctorParam);.[/QUOTE]

Well when compiling, I get error C2059: syntax error : ';'
for all 3 calls, I did try ::new but nothing

[WTF Nuke]

[QUOTE=ZeekyHBomb;41736334]Yes, that is the springy force of the example code in the article. You need to put in your own acceleration function to what you desire.

You're missing a colon before materials, but otherwise yes, like that. Also, in C++11 you can do std::vector<std::pair<std::string, int>> without a space between the closing angle brackets.
That type looks like something you'd want to typedef, too.

Either of the three version should perform the same, although I don't know if the compiler is smart enough to still vectorize it properly (provided any of your code can make use of auto-vectorization).
You could just benchmark loading some huge models and compare. If you do, please post your findings, I'd be interested.

You can do vertices.emplace_back({x, y, z}) with std::array (look up initializer lists/std::initializer_list) and when providing the proper overload for your struct constructor (although then you could also do emplace_back(x, y, z)...).
When you go with the struct, you should make sure it fulfills POD criteria. I'm unsure if a weaker criteria suffices in order to still retain the same span of optimizations for the compiler.[/QUOTE]

I tried the array solution, however I am unable to use an initializer list (as I am using VC, and they aren't supported for vectors last time I checked). I made a struct to hold the data, however it is not a POD struct because I had to provide a constructor, because for some reason I cannot emplace back without one. Loading crytek_sponza took roughly the same time with structs as without, so not a perfomance hit.

[Fatfatfatty]

[QUOTE=thf;41736692]Just wondering, is this orbit static? (as in, it will never be affected by anything else than the thing it is spinning around)
If so, you could do a simpler analytic solution instead of a numerical one.[/QUOTE]

No, it will not be static, it will be dynamic.

[ZeekyHBomb]

[QUOTE=Richy19;41736705]Well when compiling, I get error C2059: syntax error : ';'
for all 3 calls, I did try ::new but nothing[/QUOTE]

Ah sorry, return operator new(size);.

[editline]6th August 2013[/editline]

[QUOTE=Fatfatfatty;41736798]No, it will not be static, it will be dynamic.[/QUOTE]

Well, for one thing you can do your gravity calculation there.
And if you choose your previous velocity as the velocity for the initial state, I guess it would yet again fly in circles.

[Fatfatfatty]

Hmm, i toyed around for a bit and achieved this.

[img]https://dl.dropboxusercontent.com/u/45707598/better.png[/img]

Hmm, this sure isn't what i wanted, but it is an improvment

physicsStateDerivative evaluate(physicsState initial, float t, float dt, physicsStateDerivative d)
        {
            
            physicsState state;
            state.Pos = initial.Pos + d.DX * dt;


            state.V = initial.V + d.DV*dt;

            physicsStateDerivative output;
            output.DX = state.V;

            output.DV = acceleration(d, t+dt);
            return output;
        }

        Vector2 acceleration(physicsStateDerivative state, float t)
        {
            const float k = 10f;
            const float b = 1f;
            return -k * state.DX- b * state.DV;
        }

        void integrate(physicsState state, float t, float dt)
        {
            dt /= 1000;
         physicsStateDerivative a = evaluate(state, t, 0.0f, derivativeState);
         physicsStateDerivative b = evaluate(state, t, dt*0.5f, a);
         physicsStateDerivative c = evaluate(state, t, dt*0.5f, b);
         physicsStateDerivative d = evaluate(state, t, dt, c);

         Vector2 dxdt = 1.0f/6.0f * (a.DX + 2.0f*(b.DX + c.DX) + d.DX);
         Vector2 dvdt = 1.0f / 6.0f * (a.DX + 2.0f * (b.DV + c.DV) + d.DV);

         currentState.Pos = state.Pos + dxdt * dt;
         currentState.V = state.V + dvdt * dt;
        }

and for adding force and gravity

public void Addforce(Vector2 direction)
        {
            derivativeState.DV += direction / mass;
        }

        public void AddGravity(Vector2 direction)
        {
            derivativeState.DV += direction;
        }

[Richy13]

[QUOTE=ZeekyHBomb;41736885]Ah sorry, return operator new(size);.[/QUOTE]

That did it :D thanks!

Weird that I dont have to define that in delete...
BTW, is it possible to do the same with delete? ie: pass a parameter in to it and if so would it be used like:
delete(param) classPointer;

also would the syntax be
[cpp]
void operator delete (void *const p, const int param)
{
//do stuff with param
delete(p);
}
[/cpp]

[editline]6th August 2013[/editline]

Uh, new problem, I tried doing the param thing to new[] via:
[cpp]
void* operator new[] (const std::size_t size, const int param)
{
#ifdef DEBUG
//do param stuff
#else
static_cast<void>(param);// get rid of unused variable warning
#endif
return operator new(size);
}
[/cpp]

But it seems new[](int) exists already:
Error 1 error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in msvcprtd.lib(newaop_s.obj)
Error 2 error LNK1169: one or more multiply defined symbols found

[editline]6th August 2013[/editline]

And the error seems to have vanished by its self

[Fatfatfatty]

I really dont know what makes my universe mine, what sets it apart from others, all I know is that physics is bullshit. :<

This has been one of the most difficult things I have ever done in programming, and it even beats my no-tutorial collision physics. This has so much maths I just dont understand.

[ZeekyHBomb]

[QUOTE=Fatfatfatty;41736960]Hmm, i toyed around for a bit and achieved this.

[img]https://dl.dropboxusercontent.com/u/45707598/better.png[/img]

Hmm, this sure isn't what i wanted, but it is an improvment

//code

[/QUOTE]

Now you're just applying the gravitational force in the "zeroth" step. You should do it in the first through forth step. Do it via the acceleration-function.
Here's what the functions do, which you should know if you read the article:
evaluate: does an Euler integration from an estimate derivative to calculate a state at t + dt on which it does a derivation
accelerate: calculates acceleration in a given state at a given time-point (used in evaluate to for the velocity derivative)
integrate: does four derivation estimates (using evaluate), averages them and uses the result to calculate the new state (also via Euler integration, but with a more sophisticated derivation guess than plain Euler)

[QUOTE=Richy19;41736981]That did it :D thanks!

Weird that I dont have to define that in delete...
BTW, is it possible to do the same with delete? ie: pass a parameter in to it and if so would it be used like:
delete(param) classPointer;

also would the syntax be
[cpp]
void operator delete (void *const p, const int param)
{
//do stuff with param
delete(p);
}
[/cpp][/QUOTE]

I don't believe you can do that.
If you're doing something like tracking allocations of different sub-systems you can write the param as passed to new into the MemoryChunk-header.

[QUOTE]Uh, new problem, I tried doing the param thing to new[] via:
[cpp]
void* operator new[] (const std::size_t size, const int param)
{
#ifdef DEBUG
//do param stuff
#else
static_cast<void>(param);// get rid of unused variable warning
#endif
return operator new(size);
}
[/cpp]

But it seems new[](int) exists already:
Error 1 error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in msvcprtd.lib(newaop_s.obj)
Error 2 error LNK1169: one or more multiply defined symbols found[/QUOTE]

Not sure, works for me on both g++ and clang++ with libstdc++ and clang++ and libc++.
In case you get it working, you might want to call operator new[] depending on what you're doing there.

[editline]6th August 2013[/editline]

[QUOTE=Fatfatfatty;41737321]I really dont know what makes my universe mine, what sets it apart from others, all I know is that physics is bullshit. :<

This has been one of the most difficult things I have ever done in programming, and it even beats my no-tutorial collision physics. This has so much maths I just dont understand.[/QUOTE]

Maybe you should just drop RK4. If you have no idea what your code does, you're gonna have a bad time maintaining and adapting it. Which you probably already experienced ;)

[Fatfatfatty]

I read the article again and again and again, i just cant comprehend it. But I need to, I cant create my game unless I do, this is depressing and annoying.

I know what my code does, but I dont know how to apply it into the acceleration function, it was like this before

gravity was additive to force

outside forces which werent gravity were additive and divided by mass

that's how gravity and force work.

[ZeekyHBomb]

You can use an existing physics library.

If you want to do it on your own you'd be well off acquiring some basic physics, linear algebra and as it seems analysis knowledge.
Maybe you can find some book on that. You don't need to be a mathematician or a physicist, but if you want to write code for physical simulation you're going to need some of that.

I don't have an in-depth understanding of RK4, but combining my knowledge from school, that article that was linked about RK4 and the Wikipedia page I seem (!) to have a grasp on the over-all structure and what the article says I should understand.

[MayorBee]

[QUOTE=ZeekyHBomb;41732985]Works for me. Make sure Component is actually a polymorphic type (i.e. has virtual functions).[/QUOTE]
That was the problem. Thanks a bunch for all the help, I'll definitely look into your suggestions.

[stringy]

Just learned about c++11 suffix return types and it seems a lot more logical that the old form, because the return type naturally comes after the function interface (I would never ask what a function returns before I ask its name and parameters). There are the added benefits of being able to refer to function parameters and their types directly in the return type, and so I want to just use this format exclusively; is this overkill? I know compatibility with various compilers might be an issue, but I'm using c++11 features everywhere else, and I think GCC/Clang supports auto everywhere anyway, so why not?

The way I see it, "auto" becomes an odd symbol for declaring a function ( just like "= 0" is an odd way for declaring a method pure virtual), and I can use the nicer "-> return_type" syntax everywhere, so:

int bar();
//becomes
auto bar() -> int;

Player getPlayer(int index);
//becomes
auto getPlayer(int index) -> Player;

Do you see any obvious pitfalls? The only difference I see is an increase in length, but this is only really important for the most trivial interfaces, and in any other the gains in readibility (a distinct seperation between interface and return type) is worth the marginal increase in length, in my opinion.

In a similar vein is there any reason not to use "auto" in local contexts for temporary variables?

int index = getIndex();
doSomething(index);
doSomethingElse(index);

seems no more informative than

auto index = getIndex();
doSomething(index);
doSomethingElse(index);

and it has the added bonus that if this is used consistently you can easily change the type of the index by just updating a few interfaces, rather than all local code which references it.

[ZeekyHBomb]

Compiler compatibility should not be an issue.
The rest is mostly subjective. The most imported thing is to stay consistent.
Remember that auto only resolves to "basic types" though, no references or cv-qualifiers.