Is there a way to get Mouse Click coordinates in SFML?

Because App.GetInput().GetMouseX/Y is coordinates in general, not click coordinates.

Use the MouseButtonPressed event - it contains coordinates.

when I try to pass Event.MouseButtonEvent.X into a function it just gives me a "invalid use of struct" error

Ok guys, not a programming question, but more of a game design question.

I'm trying to make a 2D multiplayer speluking (cave exploring/mining game) game where players can modify the terrain.

Now, if I have only one "layer" within the game, that would be pretty easy. I could just have all of the terrain be 'tiles' that players can mine away leading to basically very linear areas (which is boring).

However, that is not what I want to do -- I want the players to be able to mine or add terrain tiles such that they can modify the foreground or the background terrain to create different terraces on which they can walk.

The problem I have with this is programmatically figuring out where the terrain collisions will be.

It's probably easier to show a picture...



Let's say that you start with the flat terrain on the bottom. Eventually you want to come along and build a small hill and then I dunno.. put a windmill on top. You place four rows of dirt tiles to create a second level that you can stand on while still being able to walk along the bottom level.

On the left side where I have steps, I want there to be collisions such that the player can't be standing on the step and then walk right and fall off the step -- instead he runs into the dirt wall and has to either jump up and to the right, or move left and down. On the other hand, on the far right side, I want the player to be able to walk through without colliding.

Basically, I'm just having a hard time even imagining an algorithm or game mechanic that would allow players to do that without allowing them to create stupid terrain traps that are impossible to get around or lead to other players getting stuck. I'll try to explain better in the future :)

nevermind, figured this one out

Fuuuck, I really hate naming shit.

public int CantThinkOfName(double d)
{
    if (d < .5)
        return -1;
    else if (d > .5)
        return 1;
    return 0;
}

public int CantThinkOfName(double d)
{
return ( d < .5 ) ? ( -1 ) : ( d > .5 ) ? ( 1 ) : 0;
}

n__n

That's disgusting.

But it's short and uh... I dunno?

It's short and way less readable.

Normally I'm an advocate of using shortcuts in code, but in this case, the code with the series of if's was so much more readable than yours

Edited:

Are you kidding me?

Typical example of "asshole" code as described in the article mentioned elsewhere in the programming forum

But I am an asshole, am I not?

Not really, you just hate everything

I don't hate efex.

UNLIKE ALL OF YOU!

As stated by my first (and last so far) assembly program, I find efeX to be a delightful gentleman

This is an interesting question, here's how I'd do it:

Have a number of layers like you currently do, where the ground floor is layer0 and those blocks above are layer1 or whatever. Then you can keep a track of the layer the player is currently on.

Now, vertical collisions: they should happen regardless of what layer the guy is on, but the guy should only collide if he lands on top but not if he is travelling upwards. Once the guy lands on a horizontal ground, his current layer switches to the layer of this floor.

Horizontal collisions: they should only happen if he is on the respective layer.

So in your diagram, the bottom guy is on layer0 so he can walk left and right as much as he wants, but he can also jump up through the step, land on the step, and now he is on layer1.
Once on this layer, he can't move right but he can move left and drop down onto layer0 and then move right.

How can I use static sf::image? I always get "error LNK2001: unresolved external symbol "public: static class sf::Image tile::tileimg" (?tileimg@tile@@2VImage@sf@@A)"

You have to define tile::tileimg somewhere in a code file. e.g.

sf::Image tile::tileimg;

This is going to sound stupid but im just starting out in c# and im trying to show a form something which in VB was easy with Form.Show
but all though in msdn it says you can do the same if i put that in it comes up with this error
An object reference is required for the non-static field, method, or property 'System.Windows.Forms.Control.Show()'

You need to call that method on an instance of the Form class.
You probably have Form form1 = new Form (); or something like that in the code. Then you do form1.Show();

Don't tell me the code doesn't work because it's not supposed to in this state.

i cant find the new form thing
FYI im using Visual C# 2k8 and i just clicked add about form in the solution explorer

Thanks overv, but do you know how static image could have possibly broken my collision?

Click around the files in the solution explorer.

I've recently been learning C++ and right now I'm toying around with some file I/O. While doing this I decided to try making a little program that would make a bitmap file. While I eventually got it working I noticed that for some reason when writing a number of type "short" as part of a structure to a file, it would be written as four bytes even though I've read that it is only supposed to be two. Here is an example of what I mean

#include <iostream>
#include <fstream>
int main(int argc, char* argv[])
{
	struct test
	{
		short t1;
		int t2;
		short t3;
		int t4;
	};

	test test1;
	test1.t1 = 1;
	test1.t2 = 2;
	test1.t3 =3;
	test1.t4 = 4;
	std::ofstream file("meh", std::ios::binary);
	file.write(reinterpret_cast<char*>(&test1), 12);

	std::cin.get();
}

This will only write the first three numbers to the file because the two "short" variables are being written as four bytes. Does anyone know why this does that?

It has to do with alignment of a structure.
Click here for further reading.

Edited:
You may try and optimize the structure of the struct (), but instead of telling the program to read in 12 bytes as hardcoded, you're better of passing it the parameter sizeof(test1)

That explains a lot. I'll have to take that into consideration in the future. Thank you.

slightly off-topic, I thought I was special with 60 posts since 2007, but you crossed the line even further

So after using lua for awhile I thought I'd try C#, and it's similar enough that I'm comfortable with it's structure. I want to try making a simple game, so XNA seemed like a logical choice.

However I wanted to download a 2d physics engine for XNA, and it seems that any I find do not work with XNAGS4 and/or VS2010.

Anyone have a suggestion for something other than XNA, or a compatible set of physics?

I think people said that Box2D is good, not sure.
Off-topic, are you still regular on the FSG forums or did you stop posting there?

I use Box2D XNA

As with all of the other ones, I'm presented with this when opening it.



Then I get a few things like this.



None of the sections said they had an error.



Bunch of errors.



So yeah, like I said, it isn't compatible.

Haven't posted on FSG in years.

I'm considering learning C# (and later XNA) together with C++.

I already have some experience with C++ so it shouldn't be that hard, right.

So my question is: is it worth learning?

XNA, Certainly. Good intro to games development. Hell, Beat Hazard was written in XNA and then stuck into a C++ Wrapper.

I thought it was completely ported to C++?

There you go. Equivalent code if you had a signum function defined:

public int SubtractOneHalfAndReturnSignum(double d)
{
    d -= 0.5;
    return signum(d);
}

Math.Sign in .NET

If I return a pointer to a derived class from a function, is it a bad idea to return it as std::auto_ptr to make sure it's cleaned up automatically? Because I'm separating the interface and implementation in a DLL, I can't return the class itself.

Well, that depends. It might be an inconvenience that you cannot copy an auto_ptr and keep both copies alive. Maybe try a shared_ptr instead, unless you are certain that passing and storing it via reference will always be fine.
You could also keep the memory-management in the DLL and free the memory when it gets unloaded (or rather upon DLL_THREAD_DETACH).

I think it's a good idea in general for a function that creates an object to return an auto_ptr rather than a plain pointer. You can turn it into a plain pointer or shared_ptr (by calling release() or passing it to the shared_ptr constructor) so you don't lose any capabilities, but you gain protection against leaks.

I just wanted to ask some advice:

This is the game i'm working on and i have the walls and the ground separate, so i do wall type collisions with the collision.walls(dark green) and ground type collisions with the collision.ground(green).
I was just wondering if i should keep doing it like this or possibly just have the collision as one big graphic; which one do you think would be more efficient/work better?