MapMaker - Startproject for SFML

[Otherian]

Hello Everyone,

so I've started playing around with SFML (and C++) the last days and wanted to get some feedback on my Code. I've created some sort of Tile-Map-Creator (similar to the one in the tutroial) which can build a 2D-Map out of Triangles and squares based on a level-matrix (and textur-matrix).

I thought two classes would be appropriate:
a) TileMap wich contains the texture-image and position data of certain texture-sections
b) Map Entity, wich loads the World (also drawn in EventLoop)

What do you guys think?
Am I doing something completely wrong or does it look ok to you?

Pictures:
Example-2D World
Used Tileset (Credits: Cave Story; With little Explanation of Variable-Names)

Code:
>> GitHub

[silverweed]

Is the code on Github supposed to work? There's a typo (unclosed string) in this file, and you're using

#include <SFML\Graphics.hpp>

instead of

#include <SFML/Graphics.hpp>

. Also, Map has its draw() method defined private, which makes little sense, and the naming convention you're using is incoherent: I suggest you choose either camelCase, PascalCase or c_like_naming and stick with that (when working with SFML the camelCase is the most natural choice).

[fallahn]

A private draw function is perfectly sensible when inheriting from sf::Drawable.

[SpeCter]

Is the code on Github supposed to work? There's a typo (unclosed string) in this file, and you're using

#include <SFML\Graphics.hpp>

instead of

#include <SFML/Graphics.hpp>

. Also, Map has its draw() method defined private, which makes little sense, and the naming convention you're using is incoherent: I suggest you choose either camelCase, PascalCase or c_like_naming and stick with that (when working with SFML the camelCase is the most natural choice).

Like fallahn said already, the private draw function is perfectly fine and the includes you mention are fine too.
The include you don't mention however is exactly the reason for the unclosed string error, because there is one additional quote #include "Tileset.hpp"" <-----------

[silverweed]

Like fallahn said already, the private draw function is perfectly fine and the includes you mention are fine too.

The backslashes aren't really "fine" actually: from the C++11 specs you read (paragraph 2.9/2):

The appearance of either of the characters ’ or \ or of either of the character sequences /* or // in a q-char-sequence or an h-char-sequence is conditionally supported with implementation-defined semantics, as is the appearance of the character " in an h-char-sequence.

which in short means that using '\' instead of '/' leads to not much more than undefined behaviour ("implementation-defined" is pretty explicit on this).

As for the private draw(), you're right: I didn't know it was friend with RenderTarget, so mea culpa.

The include you don't mention however is exactly the reason for the unclosed string error, because there is one additional quote #include "Tileset.hpp"" <-----------

That's what I mentioned here:

There's a typo (unclosed string) in this file

[Nexus]

which in short means that using '\' instead of '/' leads to not much more than undefined behaviour ("implementation-defined" is pretty explicit on this).

Don't confuse implementation-defined and undefined behavior, they mean different things. See here for an explanation of the terminology.

That is, using backslashes in include paths is permitted on certain implementations, but not advised for portable coding. There's no reason not to use forward slashes which work everywhere.

[silverweed]

which in short means that using '\' instead of '/' leads to not much more than undefined behaviour ("implementation-defined" is pretty explicit on this).

Don't confuse implementation-defined and undefined behavior, they mean different things. See here for an explanation of the terminology.

That is, using backslashes in include paths is permitted on certain implementations, but not advised for portable coding. There's no reason not to use forward slashes which work everywhere.

I'm aware of the difference in terminology, that's why I said:

to not much more than undefined behaviour

I meant to stress the fact that it's not a portable feature: what works on some platform/with some compiler may not work on others, and since it's so trivial to avoid this unreliability it's something worth fixing.

[SpeCter]

Argh sorry silverweed, I somehow overlooked the "and" in your sentence and thought you meant that the '/' '\' thing is supposed to lead to the unclosed string error, my bad.

[silverweed]

Argh sorry silverweed, I somehow overlooked the "and" in your sentence and thought you meant that the '/' '\' thing is supposed to lead to the unclosed string error, my bad.

No problem, I could've expressed myself more clearly

[Otherian]

Uh, I didnt even notice someone answered here... sorry, I was kinda busy the last days.
Thx for the feedback all

@silverweed
The Code on GitHub was ofc supposed to work and it did on my PC.
I wasnt aware of a difference between "/" and "\" so I didnt give much attention to it, but will fix this in the future. As stated already: Private-Draw fct works cause inheritance
I have a lot of problems with naming because I just started programming. I can't choose a right "way" for me... gues it's highly recommended to use one and stick with it and I should get this done asap T_T


Unfortunately I deleted the old Project from GitHub the last days because I started from scratch again to get it a little bit more structured. (besides the old one was either way just a "how to sfml" for me xD)

New things are:
> tried to include the concept of State-Machienes
> maker-surface to select tileshape / texture / ...
> it's now possible to actually map yourself with the desired shapes etc ^^''
> Save / Load levels
> 5 different TileLayers
> variable MapSize
> zoom, move, etc your map
> MapGrid
> ...

Currently Disabled:
> Tile-Size-Option
> In-game-Visibility

To-Do:
> Cleaning up some unnecessary functions in my classes and choosing a appropriate name-convention for my variables
(right now it's a huge mess because I just started to code and didnt look back  )
> Alpha-Support for texture
> Whole-Mode Menu
>> Draw: The one currently working
>> Select: Selecting multiple tiles with the mouse to fill all / delete all / Ctrl-X / ...
>> Objects: Special Objects like animated stuff / enemys / ...
> variable Texture-Size (currently the texture-pic has to be 720x720 with 72x72 per tile)

------------------------------
GitHub:
Click me ^^

Video:
(I'm too dumb to create a useable GIF without tons of artifacts...)

Pictures:

[Hapax]

In your picture, "F" would've been better to use in in "SFML" 

[FRex]

I tried to compile it with clang++ on Fedora but you still use \ in include paths and then I had some other errors so I just gave up...

[Otherian]

In your picture, "F" would've been better to use in in "SFML" 

Kay, fixed it

I tried to compile it with clang++ on Fedora but you still use \ in include paths and then I had some other errors so I just gave up...

Mäh, I didnt update the repository yesterday after reading about the "/" and "\" stuff... my bad. Finally fixed it now ^^''
What other errors do you get? I can't look into them if I dont know whats going wrong at other PCs. Could you make a screen of your compiler-log or smth?

[FRex]

I also get this kind of error in TileMap.hpp :
http://stackoverflow.com/questions/11692806/error-extra-qualification-student-on-member-student-fpermissive
Other than that it builds and works.

[Otherian]

I also get this kind of error in TileMap.hpp :
http://stackoverflow.com/questions/11692806/error-extra-qualification-student-on-member-student-fpermissive
Other than that it builds and works.

Wupsi, looks like a little bit too much Ctrl+C, Ctrl+V ^^''
I wonder why my compiler isn't saying anything about such kinds of errors. Guess it's "correcting" them intern but not even a warning occurred :<
Nevertheless, thx for your answers. I hope it works now


I had a general problem in my design and maybe someone can help. In principle my project should work like this:



The problem is: For example only the "TileMap-Class" (or maybe just the "Map-Class") should have informations about the actual level openend, the tile-number in x and y direction, tilesize, etc... but often I found it neccessary to access these informations also in the "MakerObjectManager-Class". One can simply say: Well, just make a GetXX()-Function and all should be fine, but I'm not sure about if its better to create such a function and call it everytime some information is needed or -and thats how I implemented it in the end- to create an own member for the variable in this classes, call the GetXX()-function ONCE and than only access this member again and again.
Is there some general rule how to approach this issue? Is it better to create an own member or call the GetFct each time you need the variable? 

Sorry for my bad english, I hope one can understand my question ^^