TileMapping

[echo55]

Hi everybody,

I'm currently into a project who use tilemapping, i've already done the code but i have a problem with draw2dImage.

This is the prototype :

draw2DImage ( const video::ITexture * texture,
const core::rect< s32 > & destRect,
const core::rect< s32 > & sourceRect,
const core::rect< s32 > * clipRect = 0,
const video::SColor *const colors = 0,
bool useAlphaChannelOfTexture = false
)

I used the third parameter for crop my tileSet into one tile, i do this like that:
I have set a tilewidth and a tileHeight but it doesn't work very well.

for example the thirst tile
rect<s32>(0, tileHeight, tileWidth, tileHeight * tileWidth)

the second tile
rect<s32>(tileWidth, tileHeight, tileWidth * 2, tileHeight * tileWidth)


I think i don't understand very well the different coordinates for the rect.

Please can you help me? =)

Thank you

[mongoose7]

I think you want
(0, 0, w, h)
(w, 0, 2*w, h)

[echo55]

It's not (x1, y1, x2, y2) ?

[mongoose7]

Yes, it is. That's what I wrote.
x1 = 0, y1 = 0, x2 = w, y2 = h.

[echo55]

MMh ok , i didn't think things like that , thank you =)

[echo55]

Oh sorry for double post but do you have some good websites for tilemapping?

[echo55]

I definitly don't undestand how these coordinates are working.

I'm working on it and try to implement an index which can switch between tile but it doesn't work.

_driver->draw2DImage(_tileSet, irr::core::position2d<irr::s32>(posx, posy), (currentIndex *_tileWidth), 0, (currentIndex *_tileWidth), _tileHeight), 0, irr::video::SColor(255, 255, 255, 255), true);
I increment my index when i want the next sprite .

[CuteAlien]

Your 3rd parameter isn't a rectangle.
Maybe your life will be a little easier if you set all variables first and then pass them in the next step.
Avoid having one horrible big long line :-)
So like:

Code: Select all

 
core::position2d< s32 > destPox(posx, posy); // Screen position
// Using 2 tile-indices is probably easier. Otherwise you have something like tileIndexX = (currentIndex%numTilesWidth) and tileIndexY = (currentIndex/numTilesWidth)
core::rect< s32 > sourceRec( tileIndexX*tileWidth, tileIndexY*tileHeight, tileIndexX*tileWidth+tileWidth, tileIndexY*tileHeight+tileHeight );
core::rect< s32 > * clipRect = 0; // probably don't need that for now - you can prevent drawing outside some rectangle with it.
SColor color(255, 255, 255, 255); // ignore for now
bool  useAlphaChannelOfTexture = true; // You probably want false for the background (is faster) and true for foreground figures (you need transparency for those)
driver->draw2DImage (   tileSet, destPos, sourceRect, clipRect, color, useAlphaChannelOfTexture);
 

Also minor note: In c++ variables with underscore first like _driver are reserved by the implementation (aka the compiler). You should not use them yourself in your code. Having the unterscore after ther variable like driver_ is legal (but ugly with pointers... driver_-> ... yeah...).

[echo55]

I managed to do it =)
Thank you for your advice , i used _ for variable when they are in a class,

[Cube_]

Also minor note: In c++ variables with underscore first like _driver are reserved by the implementation (aka the compiler). You should not use them yourself in your code. Having the unterscore after ther variable like driver_ is legal (but ugly with pointers... driver_-> ... yeah...).

Technically a variable that starts with an underscore followed by an uppercase character is reserved _Driver is reserved _driver is perfectly fine.

The relevant C++ standard

17.4.3.2.1 Global names [lib.global.names]

Certain sets of names and function signatures are always reserved to the implementation:

Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.
Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.165
165) Such names are also reserved in namespace ::std (17.4.3.1).

C's standard also applies (except where the C++ standard says otherwise, for example when _driver would be allowed):

7.1.3 Reserved identifiers

Each header declares or defines all identifiers listed in its associated subclause, and optionally declares or defines identifiers listed in its associated future library directions subclause and identifiers which are always reserved either for any use or for use as file scope identifiers.

All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
Each macro name in any of the following subclauses (including the future library directions) is reserved for use as specified if any of its associated headers is included; unless explicitly stated otherwise (see 7.1.4).
All identifiers with external linkage in any of the following subclauses (including the future library directions) are always reserved for use as identifiers with external linkage.154
Each identifier with file scope listed in any of the following subclauses (including the future library directions) is reserved for use as a macro name and as an identifier with file scope in the same name space if any of its associated headers is included.
No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.

If the program removes (with #undef) any macro definition of an identifier in the first group listed above, the behavior is undefined.

154) The list of reserved identifiers with external linkage includes errno, math_errhandling, setjmp, and va_end.

They both clearly state that double underscores and underscores followed by uppercase are reserved, lowercase is just fine.

HOWEVER an important caveat is that an underscore followed by anything is reserved ONLY in the GLOBAL namespace.

For a practical example:

Code: Select all

int _variable = 4; //INVALID
 
int main {}

Code: Select all

int main
{
    int _variable = 4; //VALID
}

I managed to do it =)
Thank you for your advice , i used _ for variable when they are in a class,

That is fine, it's not in the global namespace.
In fact, an extremely common naming practice is to name private class members with an underscore
For example:

Code: Select all

class IExampleClass
{
public: 
    int variable;
private:
    int _pVariable;
}

EDIT: I should mention that I personally don't necessarily condone this standard as it may cause conflicts due to implementation bugs or implementation differences to reference standard.
I personally name things as such:

Code: Select all

variable; //normal variable
pMember //private/protected member
iClass //interface class
vClass //purely virtual class
/*etc, the standard being lowercase letter describing the purpose of the object followed by the rest of the name in camelcase. if it matters I also make distinctions such as pVariable for protected p_Variable for private - although that's only if the class uses protected members (rare, I'm not a fan of them), if it is nontrivial, and if it's important to know if it's private or protected at time of using it (usually not the case).*/

[CuteAlien]

@aaammmsterdddam: Thanks, I did indeed not remember the details. So underscore followed by lower-case character and not in global namespace is indeed fine.

Irrlicht uses (mostly, exception are core-classes) variables starting with Upper-case are member variables. All others are lower-case.
Also a rather common style is to use mVariable or m_variable for member variables.

I don't think using pMember is a good idea as p is used by many coding guidelines to denote pointers. I try to avoid adding anything to variable names unless there is noticable gain from it. I for interfaces and C for classes in Irrlicht kinda make sense as we have a lot of those. Having some distinction between members and local variables also helps in my experience so I use that generally (also most guidelines I worked with had that one).

@aaammmsterdddam: Not sure what your difference between an interface class and a purely virtual class is as that is not a c++ thing. Do you mean interface as in the Java sense as having zero implementation code? That sounds to me like a risky naming scheme which might force you to rename an interface class at some point (which is the thing a library at least never ever should do). But maybe having java-style interfaces is important to your project for some reason...

[Cube_]

I don't think using pMember is a good idea as p is used by many coding guidelines to denote pointers. I try to avoid adding anything to variable names unless there is noticable gain from it. I for interfaces and C for classes in Irrlicht kinda make sense as we have a lot of those. Having some distinction between members and local variables also helps in my experience so I use that generally (also most guidelines I worked with had that one).

hmm... you have a point, I may revise this. Although I use the [all lowercase] _ptr suffix specifically for that (such as device_ptr) if it is at all non-obvious that it's a pointer anyway.

@aaammmsterdddam: Not sure what your difference between an interface class and a purely virtual class is as that is not a c++ thing. Do you mean interface as in the Java sense as having zero implementation code? That sounds to me like a risky naming scheme which might force you to rename an interface class at some point (which is the thing a library at least never ever should do). But maybe having java-style interfaces is important to your project for some reason...

zero implementation, I very rarely use interface classes in that sense - although they have some use so my coding standard specifies it.
Although my standard is in need of a good refactoring, as is a lot of my core classes and those come first (or do they come last? I'd probably have to at least refactor names again if I don't update my standard first...)

[CuteAlien]

As long as it's your own projects anything that works for you is fine anyway :-) I changed my own guidelines a few times already - don't care too much anymore. Only when it comes to libraries I really care.