next »

[oahda]

Remember that (at least if enums create global consonants like in C++ which they seem to do here too seeing as you're using them without anything in front of them when calling comp.set()) you'll effectively be taking those names up for D-pads alone.

I think it's better practice to put the name of the enum itself into the constants as well (not necessary in something like Java where enums are scopes and you have to write DPad.UP but necessary in C++ where they are not), like DPAD_UP and so on. It also causes less confusion, because it's not very obvious that a constant simply named UP should belong to an enum called DPad.

Similarly if you add keyboard constants you might want to put KEY_UP or K_UP or something in there and so on.

You might have another enum for directions for something else, where you might want to have DIR_UP (set to 270° if we assume 0° means left, for example).

And on.

[Cheesegrater]

enums create global consonants like in C++

If you're using C++11 and want scoped enums, declare them like so:

Code:

enum class DPad {
    UP,
    DOWN,
    LEFT,
    RIGHT
};

Then use them like DPad::UP, etc.

If you're not using C++11, just create them inside a placeholder class, struct, or namespace.

[oahda]

Gee, I'd forgotten about that. And apparently I can enable it for AngelScript too using a flag. I think I'll do that. Got few enough enums and uses of them that it shouldn't take too long to update them. Thanks!

Either way, Photon evidently wasn't using C++ so it might still not be an option in their language (is it C#?).

[Sik]

I can't believe how nobody pointed out that Photon was using semicolons instead of commas to separate the elements in the enum.

[Photon]

I can't believe how nobody pointed out that Photon was using semicolons instead of commas to separate the elements in the enum.

Actually, I'm using Haxe and that's the way Haxe does it. 

Some good points though. Thanks! I haven't really experimented much yet with Haxe enums but I intend to.

[Sik]

OK nevermind then (honestly it looked like C/C++ enums, which use comma instead).

[oahda]

I can't believe how nobody pointed out that Photon was using semicolons instead of commas to separate the elements in the enum.

Which is why I was guessing it wasn't C++ at all.

[indie11]

Is it impossible to get smooth camera follow in unity?

I just have a simple cube, no rigidbody but still the camera there is some stutter(using the default smooth follow script)

[oahda]

Can I somehow (without using templates myself) take an initialiser list with mixed types as an argument to a function (by doing something like perhaps std::initialiser_list<> tho I know that particular method doesn't work or I wouldn't be asking), just like member initialisation lists? It'd save me some extra functions jumping around each other, I think.

[Cheesegrater]

If I understand your question correctly, your other option is to use a variadic function: http://en.cppreference.com/w/cpp/utility/variadic

They never make for very pretty code, though.

Why not templates, though? Variadic templates would at least be type safe.

[oahda]

Yeah, that's icky.

Seems I mistakenly mistook initialiser lists and member initialisation for the same thing.

No matter tho. I think I figured out a clean enough way to do it with variadic templates after all. I was just mixing up some stuff in my head. I'll finish the code tomorrow. Took a walk and now I'm super tired.

[oahda]

Extreme simplification of my setup and problem:

Code:

typedef void (*Callback)(const std::string &);

class Class { Class(Callback f) { f("test"); } };

void func(const Class &c);

func({[](const std::string &s) { printf("%s\n", s.c_str()); }});

Candidate function not viable: cannot convert initializer list argument to 'const Class'

Doesn't work without the initialiser list either and replacing the function pointer typedef with an std::function typedef doesn't work (I can't use an std::function anyway because I have overloads with const/non-const versions of otherwise the same function signature and std::function can't handle that because it's trying to be smart and parse them the same way, causing an ambiguity when calling one of those function overloads).

(all of this is in reality templated but that shouldn't make a difference)

Why isn't it calling the constructor of Class that takes a Callback when I pass a lambda with the correct signature? It does work if I put Class in front of the initialiser list, so it's really weird (and I don't want to have to do that, because, again, this is templated and names might get pretty long).

My functions taking, say, a Vector<float> which has a constructor taking three floats have no trouble taking {0.0f, 1.0f, 0.0f} as their argument without me putting the class name in front, so why is this complaining?

And no, I can't just pass a function directly to func. This is a little more complex than that. I just stripped it down to be as easy as possible to grasp. So I don't want suggestions of completely different solutions, but on how to solve this for the needs I have expressed.

[oahda]

Oh, well, using auto and return type deduction I actually don't really have to type things twice anyway. This works:

Code:

t.get<Player>().listen
 (
    *t.m_monologue,
    "action",
    Callbacks<bool, const Component>{[](auto)
     {
        return Examinable::withinRange();
     }},
    100
 );

That's clean enough, I guess. But if somebody knows, I'd still like to know.

EDIT:
Welp, my less elegant solution was to let the constructor just take a template type instead of the specific function signature; of course now I can put anything in there, but as the constructor then moves on to initialise its member with that value, the compiler will say no if it's not the correct type of function anyway, plus the user is never supposed to initialise this type of object directly anyway, but will always create them by passing lambdas to some function (which now works even without initialiser list braces around it — exactly the way I wanted it!), and the signature of that function will ask for the correct signature and not for template type "T" so it's fine.

Now it looks like this:

Code:

t.get<Player>().listen
 (
    *t.m_monologue,
    "action",
    [](auto) { return Examinable::withinRange(); },
    100
 );

I don't even have to specify the parameters (not using them in this particular case anyway) or the return type. :D

[lithander]

If you got a grid of N cells and you use a path finding algorithm on it like A* or Dijkstra what's the upper bound on the size of the open list? E.g. what is the maximum number of cells that can possibly be in the open list at any given time?

[BorisTheBrave]

That is a good question. The worst case for Dijkstra I can think of has O(n * 2^n) cells, and requires an open set of O(2^n) cells. A* could presumably be even worse if you cheated on which heuristic you used.

[ProgramGamer]

Quick game maker question: does game maker have a "vector" object (separate from the vectorial functions) which you can use or do you have to make your own?

[Eendhoorn]

Now this is one weird ass issue I'm having. I'm running into problems with the stack when trying to create a floodfill function on my tilegrid. I'm pushing all the "filled" tiles to an array because I want to use them later on.
I never did any low level programming with the stack, but I can imagine this is pretty heavy when calling it recursively.

Now weird thing is, I had a debug function "setTile( tileX, tileY, 1 )" which sets some uv coords for a tile. When this line is included, it doesn't cause a stack-overflow somehow. Is this somehow releasing the stack? FloodFillTile() is the function I'm calling btw.

Code:

public List<Tile> FloodFill (int tileX, int tileY)
	{
		List<Tile> tiles = new List<Tile>();
		Tile startTile = getTile( tileX, tileY );
		tiles.Add( startTile );

		doFloodFill( startTile.ID, tileX, tileY, ref tiles );
		Build();

		return tiles;
	}

	private void doFloodFill( int ID, int tileX, int tileY, ref List<Tile> tiles, bool useTileType = false )
	{
		Tile tile = getTile( tileX, tileY );

		if( tile == null || tile.ID != ID ) 
			return;

		tiles.Add( getTile( tileX, tileY ) );
		setTile( tileX, tileY, 1 ); //somehow this prevents a stackoverflow

		doFloodFill( ID, tileX - 1, tileY, ref tiles );
		doFloodFill( ID, tileX + 1, tileY, ref tiles );
		doFloodFill( ID, tileX, tileY -1, ref tiles );
		doFloodFill( ID, tileX, tileY + 1, ref tiles );
	}
	
	public List<Tile> FloodFillTile (int tileX, int tileY, int tileID, bool solid = true, bool autoTile = true, bool useTileType = false)
	{
		//if( getTile( tileX, tileY ).ID == tileID ) return;

		List<Tile> tiles = FloodFill( tileX, tileY );
		Debug.Log("floodfilled tiles: " + tiles.Count );

		for( int i = 0; i < tiles.Count; i++)
		{
			setTile( tiles[i].xIndex, tiles[i].yIndex, tileID, false );
			setCollider( tiles[i].xIndex, tiles[i].yIndex, solid );
		}
		Build();
		return tiles;

		return null;
	}

[Dacke]

That is a good question. The worst case for Dijkstra I can think of has O(n * 2^n) cells, and requires an open set of O(2^n) cells. A* could presumably be even worse if you cheated on which heuristic you used.

Wait.. you have N nodes in the graph, but more than N open nodes? How did you reach those numbers?

[lithander]

I'm pretty sure in a square grid with N cells each having only 4 connections to the respective neighbours there are never more then 2*Sqrt(N) cells in the open list. But... that's just a guesstimate and not math!

[Dacke]

But the open set consists of the cells (nodes) and not the vertices (connections). So you can't have more open nodes than you have nodes in total. So with N cells you can't have more than N open cells, that doesn't make sense. Right?