What Do You Need Help With? V6

[NoRegard]

This is not really a programming question, but when you install a driver for a device, does it matter what version of the device you have?
Let's say you have version A, but you install both the driver for version A and B - won't it still work, since you have driver A? Can drivers 'override' each other?

[mastersrp]

[QUOTE=Tommyx50;46730452]i++ is in theory slower than ++i.

However, it's an incredibly small difference due to pipelining, and the compiler will [I]usually[/I] optimize it out anyways. The reason is because [b]on the CPU level, doing i++ requires a copy - the code needs to be evaluated with the original value, then have 1 added to it afterwards, whereas with ++i the compiler can immediately add 1 to the value.[/b]
...
So, essentially - if you can use either, always use ++i.[/QUOTE]

Any references on this? I've never stumbled upon something like that before, except on small reddit threads with no sources or explanations of what and how.
I'm genuinly curious about how this really works because it sounds utterly strange and weird for that to actually be a thing.

[Z_guy]

[QUOTE=mastersrp;46734578]Any references on this? I've never stumbled upon something like that before, except on small reddit threads with no sources or explanations of what and how.
I'm genuinly curious about how this really works because it sounds utterly strange and weird for that to actually be a thing.[/QUOTE]

i++ returns the old value. This means that it needs to make a copy of the old value before changing it, and then return the copy.
[cpp]
int i = 0;
int j = i++;
// i == 1
// j == 0
[/cpp]

++i returns the new value, so it doesn't need to make any copies.
[cpp]
int i = 0;
int j = ++i;
// i == 1
// j == 1
[/cpp]

When the return value isn't used the compiler should change an i++ to ++i.
For an int the difference is negligible anyway, but it could be significant for more complex types.

[Catse]

snip

[Fredo]

[QUOTE=mastersrp;46734578]Any references on this? I've never stumbled upon something like that before, except on small reddit threads with no sources or explanations of what and how.
I'm genuinly curious about how this really works because it sounds utterly strange and weird for that to actually be a thing.[/QUOTE]

To add to what other people have said, you have to think about how objects implement the increment operators

struct A {
    //Pre-increment
    A& operator++() {
        //"increment" object
        return *this;
    };

    //Post-increment (the int is just to give a different signature)
    //Note that this can't return a reference
    A operator++(int) {
        A copy(*this); //Make a copy
        ++(*this);     //Increment this object
        return copy;   //Return the old value
    }
    ...
};

For some A a, calling ++a will call the pre-increment ++ operator, which only does the increment. Calling a++ calls the post-increment one, which makes a copy and then does the pre-increment anyway.

For primitive types there is no difference between ++i and i++ in terms of performance.

[~ZOMG]

In C++, for an infinite loop, should one use while(1) or for(;;)?

[mastersrp]

[QUOTE=~ZOMG;46741485]In C++, for an infinite loop, should one use while(1) or for(;;)?[/QUOTE]

If they do the same (and they do), just use whatever you feel is most useful.

And before anyone says that the while(1) creates a constant in the assembly code that may not be needed; i doubt it is going to actually be a problem, and in many cases i would probably expect the parser in the compiler to optimize that away.

[Tommyx50]

[QUOTE=~ZOMG;46741485]In C++, for an infinite loop, should one use while(1) or for(;;)?[/QUOTE]

Well, the compiler is almost definitely going to optimize out the while() check and the constant, so either works. I will mention, however, that with for(;;) you can do this:

#define EVER ;;

for(EVER) {
    // ...
}

Take from that what you will! :downs:

[proboardslol]

[QUOTE=~ZOMG;46741485]In C++, for an infinite loop, should one use while(1) or for(;;)?[/QUOTE]

yes

[Dienes]

[QUOTE=mastersrp;46734578]Any references on this? I've never stumbled upon something like that before, except on small reddit threads with no sources or explanations of what and how.
I'm genuinly curious about how this really works because it sounds utterly strange and weird for that to actually be a thing.[/QUOTE]

For some real references, check [URL="http://www.amazon.com/dp/0321113586"]"C++ Coding Standards" by Herb Sutter and Andrei Alexandrescu[/URL] and also [URL="http://www.amazon.com/dp/020163371X"]"More Effective C++" by Scott Meyers[/URL]. Both books confirm the danger of an additional temporary object when using post-fix.

[proboardslol]

or if you wanna troll

loop:

//code

goto loop;

[Fatfatfatty]

I have the most peculiar thing going on with my code. A function call that does not happen despite being defined and all.

I put out a few breakpoints to test my code to see if it wasn't reaching the function call at all. but it very well did trigger at the function call. But the break points INSIDE the function did not hit. And the program seems to continue to run smoothly, except the functions are never called

PhysicsManager.h

#pragma once
#ifndef PHYSMANAGER_H
#define PHYSMANAGER_H

#include <vector>
#include "PHYS_Collider.h"
#include "SFML\Graphics.hpp"

using namespace sf;

class PhysicsManager
{
public:
	PhysicsManager();
	//~PhysicsManager();

	void Update(float DT);

	void DebugDraw(Window * window);
	void AddCollider(PHYS_Collider * collider);

private:
	std::vector<PHYS_Collider *> colliders;
	Vector2f gravity;
	float drag;
};

#endif

PhysicsManager.cpp

#include "PhysicsManager.h"
#include "PHYS_Collider.h"
#include <vector>

using namespace sf;

PhysicsManager::PhysicsManager()
{
	drag = 0.95;
	gravity = Vector2f(0, 9.2);
}

void PhysicsManager::Update(float DT)
{
	for(int i = colliders.size()-1; i >= 0; i--)
	{
		if(colliders.at(i)->ToDelete())
		{
			delete colliders.at(i);
			colliders.erase(colliders.begin() + i);
		}
	}
	
	for(int i = 0; i < colliders.size(); i++)
	{
		colliders.at(i)->Update(DT, gravity, drag); //THIS IS WHERE THE STRANGE STUFF IS GOING ON!!!!!
	}

	for(int i = 0; i < colliders.size(); i++)
	{
		for(int j = 0; j < colliders.size(); j++)
		{
			colliders.at(i)->Intersects(colliders.at(j)); //check intersections
		}
	}
}

void PhysicsManager::AddCollider(PHYS_Collider * collider)
{
	colliders.push_back(collider);
}

PhYS_Collider.h

#pragma once
#ifndef PHYS_COLLIDER_H
#define PHYS_COLLIDER_H



#include <vector>


#include "SFML\Graphics.hpp"
class ENT_Entity;
using namespace sf;

class PHYS_Collider
{
public:
	
	//~PHYS_Collider();
	virtual bool Intersects(PHYS_Collider * collider) = 0;
	virtual void Update(float DT, Vector2f gravity, float drag);
	void AddForce(Vector2f forceVector);
	bool IsIntersecting();
	ENT_Entity* getOwner(){return owner;}
	void DeleteMe();
	bool ToDelete();
	std::vector<PHYS_Collider *> colliders;
	Vector2f getPosition(){return position;}
private:
	
protected:
	Vector2f position, force;
	bool intersects;
	bool deleteme;
	ENT_Entity* owner;

};

#endif

phys_collider.cpp

#include "PHYS_Collider.h"
#include "SFML\Graphics.hpp"
using namespace sf;

void PHYS_Collider::AddForce(Vector2f force)
{
	this->force += force;
}

bool PHYS_Collider::IsIntersecting()
{
	return intersects;
}

void PHYS_Collider::DeleteMe()
{
	deleteme = true;
}

bool PHYS_Collider::ToDelete()
{
	return deleteme;
}

void PHYS_Collider::Update(float dt, Vector2f gravity, float drag) //THIS IS WHERE IT IS NOT CALLING
{
	force += gravity;
	force *= drag;
	position += force;
}

[Tommyx50]

[QUOTE=Fatfatfatty;46741851]I have the most peculiar thing going on with my code. A function call that does not happen despite being defined and all.

I put out a few breakpoints to test my code to see if it wasn't reaching the function call at all. but it very well did trigger at the function call. But the break points INSIDE the function did not hit. And the program seems to continue to run smoothly, except the functions are never called
[/QUOTE]

In PHYS_Collider.h, you have:

virtual void Update(float DT, Vector2f gravity, float drag);

In PHYS_Collider.cpp, you have:

void PHYS_Collider::Update(float dt, Vector2f gravity, float drag) //THIS IS WHERE IT IS NOT CALLING

In one, it's dt - in the other, it's DT. This means the compilers looks at it, and thinks "these are 2 different functions!" - meaning that when you call it, it's trying to use an undefined function.

EDIT:

Apparently I'm wrong - sorry!

[NoRegard]

What C++ (or C#) game development library would you recommend? So far I've been looking at SFML, but the tutorials I found for it spent like 3 hours explaining how to make splash screens.

[mastersrp]

[QUOTE=Tommyx50;46742211]In PHYS_Collider.h, you have:

virtual void Update(float DT, Vector2f gravity, float drag);

In PHYS_Collider.cpp, you have:

void PHYS_Collider::Update(float dt, Vector2f gravity, float drag) //THIS IS WHERE IT IS NOT CALLING

In one, it's dt - in the other, it's DT. This means the compilers looks at it, and thinks "these are 2 different functions!" - meaning that when you call it, it's trying to use an undefined function.[/QUOTE]

Is that actually a thing? Does the C++ compilers really give a shit what the names of the parameters are? I know in C, you can prototype without even naming the variables, as long as it is properly defined with variable names.

[Fredo]

The names of the parameters don't matter. Only the types and number of arguments affect the signature of the function. If the function wasn't defined the code wouldn't compile. In addition in C++ (and maybe later versions of C) you can even exclude the name of a parameter when you define the function (not just in the declaration) if you aren't using it.

As for what's going on, is colliders empty? I'm not sure where you put your breakpoints but if they were outside of the for loop then maybe it never called the function.

[CRASHFORT]

It doesn't.

MSVC Nov 2013 CTP

class Base
{
public:
    virtual void Example(float whatever, int hello) = 0;
};

class Other : public Base
{
public:
    virtual void Example(float hello, int whatever) override
    {
        std::cout << "Other" << std::endl;
    }
};

int wmain(int argc, const wchar_t* argv[])
{
    Other other;
    other.Example(10.0f, 20);
}

I'm sure this is very clearly documented in the standard. It doesn't make any sense that it wouldn't work.

[proboardslol]

Managing entities in a game with something like SFML, where an individual NPC has a sprite image, an X and Y vector, and other variables (maybe dialogue data or inventory), what is the best way to update those entities? I was told that an array which holds all this data is a bad way to do it. Would a linked list of all entities work? something like

struct entity{
    NPC npcData;  //some NPC class
    struct entity* next;
} currentNPC

//...

while (currentNPC != 0){
    currentNPC->npcData().update();
    currentNPC = currentNPC->next;
}

For arguments sake, let's say this is C++. Ignoring any syntax errors, would that be a good way to update everything without having to worry about null array elements?

[Tommyx50]

[QUOTE=proboardslol;46747155]Managing entities in a game with something like SFML, where an individual NPC has a sprite image, an X and Y vector, and other variables (maybe dialogue data or inventory), what is the best way to update those entities? I was told that an array which holds all this data is a bad way to do it. Would a linked list of all entities work? something like

struct entity{
    NPC npcData;  //some NPC class
    struct entity* next;
} currentNPC

//...

while (currentNPC != 0){
    currentNPC->npcData().update();
    currentNPC = currentNPC->next;
}

For arguments sake, let's say this is C++. Ignoring any syntax errors, would that be a good way to update everything without having to worry about null array elements?[/QUOTE]

A linked list is probably the worst way, since you need to hold a lot of boilerplate data, you are constantly jumping around in memory (meaning the cpu cache becomes far less effective), and there's no way to arbitrarily access the data of an entity - you can only move forwards or backwards from whatever entity you are currently looking at.

An array of structs is possibly one of the better ways. You can just loop through it, updating through each entity as you go along, and it'll be laid out fairly nicely in memory.

If you're really crazed about performance, you'll want to use data-orientated design a struct of arrays, but the gains may not be much depending on how many NPCs you are planning on having and how much data they store each.

[Darwin226]

[QUOTE=Tommyx50;46748162]A linked list is probably the worst way, since you need to hold a lot of boilerplate data, you are constantly jumping around in memory (meaning the cpu cache becomes far less effective), and there's no way to arbitrarily access the data of an entity - you can only move forwards or backwards from whatever entity you are currently looking at.

An array of structs is possibly one of the better ways. You can just loop through it, updating through each entity as you go along, and it'll be laid out fairly nicely in memory.

If you're really crazed about performance, you'll want to use data-orientated design a struct of arrays, but the gains may not be much depending on how many NPCs you are planning on having and how much data they store each.[/QUOTE]

Do you ever need random access to an entity by it's index? If you need a specific entity, you probably have a pointer to it.

[Dienes]

[QUOTE=Fatfatfatty;46741851]I have the most peculiar thing going on with my code. A function call that does not happen despite being defined and all.

I put out a few breakpoints to test my code to see if it wasn't reaching the function call at all. but it very well did trigger at the function call. But the break points INSIDE the function did not hit. And the program seems to continue to run smoothly, except the functions are never called[/QUOTE]

When you say "never called", does that mean that even the effects of the function are not occuring? Or only that the debugger fails to step into the function? Are you compiling with any optimizations?

[Fatfatfatty]

[QUOTE=Dienes;46748793]When you say "never called", does that mean that even the effects of the function are not occuring? Or only that the debugger fails to step into the function? Are you compiling with any optimizations?[/QUOTE]

I found the issue and it works now.

[proboardslol]

[QUOTE=Tommyx50;46748162]A linked list is probably the worst way, since you need to hold a lot of boilerplate data, you are constantly jumping around in memory (meaning the cpu cache becomes far less effective), and there's no way to arbitrarily access the data of an entity - you can only move forwards or backwards from whatever entity you are currently looking at.

An array of structs is possibly one of the better ways. You can just loop through it, updating through each entity as you go along, and it'll be laid out fairly nicely in memory.

If you're really crazed about performance, you'll want to use data-orientated design a struct of arrays, but the gains may not be much depending on how many NPCs you are planning on having and how much data they store each.[/QUOTE]

It's funny cause someone told me almost the opposite; that an array is the worst way to do it

[Darwin226]

[QUOTE=proboardslol;46749481]It's funny cause someone told me almost the opposite; that an array is the worst way to do it[/QUOTE]

The problem is that "worst" doesn't mean anything. If you don't plan to do any insertions, then why not use an array? If you do, maybe it's in a way that it's still worth it. Maybe you can allocate enough memory before hand.
There's a ton of factors so just do it one way, separate the interface from the implementation and then swap it out later if you get in trouble.

[Tommyx50]

[QUOTE=Darwin226;46748490]Do you ever need random access to an entity by it's index? If you need a specific entity, you probably have a pointer to it.[/QUOTE]

No, most of the time you are moving forwards through the array 1 element at a time - this seems to give a strong case for linked lists. However, linked lists are all over the place in memory. The very nature of them implies jumping back and forth in memory, which means that cache misses are very likely, meaning you need to load from RAM (which is slow). The only reason you'd use a linked list would be if you had a relatively small number of entities, but a very inconsistent number at any one time, due to the ease of adding onto the list. However, even situations like this can often be done better by pooling.

[QUOTE=proboardslol;46749481]It's funny cause someone told me almost the opposite; that an array is the worst way to do it[/QUOTE]

Depends on what you are doing. Linked lists tend to have a very limited set of situations where they are actually good.

[Darwin226]

[QUOTE=Tommyx50;46750256]No, most of the time you are moving forwards through the array 1 element at a time - this seems to give a strong case for linked lists. However, linked lists are all over the place in memory. The very nature of them implies jumping back and forth in memory, which means that cache misses are very likely, meaning you need to load from RAM (which is slow). The only reason you'd use a linked list would be if you had a relatively small number of entities, but a very inconsistent number at any one time, due to the ease of adding onto the list. However, even situations like this can often be done better by pooling.
[/QUOTE]

If entities interact in any ways you can be sure there's going to be jumping around in memory.
You would probably get a speedup with operations like drawing but that's done by the GPU anyways so you're not gaining much.
I can appreciate that there are situations where you should worry about cache misses but I've yet to see a benchmark where there's significant overhead in iterating through the entities.
Also, RAM isn't slow. Slower than a CPU cache, sure. Maybe even by an order of magnitude. Still not slow.

[Tommyx50]

[QUOTE=Darwin226;46750946]If entities interact in any ways you can be sure there's going to be jumping around in memory.
You would probably get a speedup with operations like drawing but that's done by the GPU anyways so you're not gaining much.
I can appreciate that there are situations where you should worry about cache misses but I've yet to see a benchmark where there's significant overhead in iterating through the entities.
Also, RAM isn't slow. Slower than a CPU cache, sure. Maybe even by an order of magnitude. Still not slow.[/QUOTE]

RAM is terribly slow, when it matters. It's "fast" compared to a hard disk, but typically you are going to be limited by the time to access RAM moreso than the time to do your CPU calculations.

Not only does a link list give large memory overhead (typically 4 to 16 bytes per entity, depending on the bit-ness of the processor and whether it's doubly-linked or not), but it also means that you frequently get cache misses. This is an incredibly slowdown!

"If entities interact in any ways you can be sure there's going to be jumping around in memory."

Jumping around in memory is inevitable, yes. The goal is to avoid it as much as possible - there's a reason that CPUs have a cache. Using linear arrays helps greatly.

[cartman300]

And i thought i was overoptimizing.

[Tommyx50]

This isn't a case of over-optimization. It's just competent engine design. When not only is your program slower, but also harder to debug and memory-hogging, you are doing something wrong!

[Darwin226]

[QUOTE=Tommyx50;46752330]RAM is terribly slow, when it matters. It's "fast" compared to a hard disk, but typically you are going to be limited by the time to access RAM moreso than the time to do your CPU calculations.

Not only does a link list give large memory overhead (typically 4 to 16 bytes per entity, depending on the bit-ness of the processor and whether it's doubly-linked or not), but it also means that you frequently get cache misses. This is an incredibly slowdown!

"If entities interact in any ways you can be sure there's going to be jumping around in memory."

Jumping around in memory is inevitable, yes. The goal is to avoid it as much as possible - there's a reason that CPUs have a cache. Using linear arrays helps greatly.[/QUOTE]

Let's see. 4 bytes per entity. So that's like 4 extra megabytes per MILLION entities. Hardly a space bottleneck.
Secondly, if you're iterating over your entities and they need to interact by jumping around in memory, you're gonna get cache misses anyways. I'm having a hard time imagining a scenario where you literally only need to read sequential data about each of those EXCEPT to render them.

[editline]19th December 2014[/editline]

CPUs have a cache because elementary operations on collections benefit from them greatly (summing up numbers and things like that). Anything you do with an entity will be too complex to utilize the sequential access.