Custom Sprite

hello silderan

if you want to attach simple data to a node or an entity you can use set_user_data() and get_user_data(), defined in the renderable api class:
github.com/RonenNess/ness-engine/blob/master/source/NessEngine/renderable/renderable_api.h

but what did you mean about not being able to inherit from sprite and use it in the tilesmap? smart pointers should not prevent polymorphism, perhaps I did something wrong or you misused it.

can you please post some code so I'll understand better the type of error you got?

thanks!


EDIT:

I made a test code and here's how you create a tilesmap with a custom sprite type. try to use it if set_user_data() is not enough for you:


// global pointer to the renderer - un ugly patchy patch!
Ness::Renderer* g_renderer;

// my custom sprite type
class MySprite : public Ness::Sprite
{
public:
MySprite(Ness::Renderer* renderer, const Ness::String& TextureFile)
: Sprite(renderer, TextureFile) {}
};

// function to generate my own customized sprites
Ness::SpritePtr CreateCustomSprites(const Ness::Pointi& index)
{
return ness_make_ptr<MySprite>(g_renderer, "tilemap.jpg");
}

int _tmain(int argc, _TCHAR* argv[])
{
// init and create a renderer
Ness::init();
Ness::Renderer renderer("Tilemap demo!", Ness::Sizei(800, 600));

g_renderer = &renderer;

// create a new scene
Ness::ScenePtr scene = g_renderer->create_scene();

// create the tilemap with the customized sprites and add it to the scene
Ness::TileMapPtr map = ness_make_ptr<Ness::TileMap>(g_renderer, "",
               Ness::Sizei(100, 100),
               Ness::Size(32.0f, 32.0f),
Ness::Size::ZERO, &CreateCustomSprites);
scene->add(map);

       ...
       ..


no need to apologize, the tutorials and docs are far from complete and it takes some time to get used to a new library.
never hesitate to ask any question, through them I get a useful feedback which I appreciate very much!

now regarding your error, the line:

inline SpritePtr& get_sprite(const Pointi& index) { return m_tiles[index.x][index.y]; }

raise the error because you return SpritePtr by reference instead of by value.

if you don't understand why this is an issue, here's a long, boring explanation:
the pointers ness-engine uses are std::shared_ptr, which are basically a template class that gets a raw pointer and count how many other shared_ptrs hold it (when a shared_ptr pass the value to another it increase the counter, and when a shared_ptr dies is decrease the counter). the shared_ptr delete the raw pointer automatically when the last reference dies.

now when you try to assign one shared ptr into the other it calls the assignment operator (implemented by std::shared_ptr), which eventually try to assign one raw pointer into the other, meaning the normal pointer cast rules of cpp apply. but when you pass the shared pointer by reference and not by value, it's like you are doing the following:


TileMapSpritePtr* a;
SpritePtr* b;
a = b; // <-- error!


now why is this a problem if they are both shared_ptr type? because its a template class, they are not recognized as the same type nor as inheritance of one another. its like two separated classes that has nothing to do in common.

long story short, remove the reference from the return value, i.e.:


inline SpritePtr get_sprite(const Pointi& index) { return m_tiles[index.x][index.y];}


now about what you said with having to remove the user data, I was thinking in an approach of "you created it, you will delete it", but since it can be a hassle in some cases, I added a boolean you can set when calling set_user_data() which will delete the pointer when the sprite is deleted.
as usual, this change will be part of the next version but already in git if you want it.

PS. why aren't you using the example code I provided to use custom sprites in a tilemap? are you trying to create a custom tilesmap as well? or change the one in ness-engine?

well I'm glad I asked about your purpose because ness-engine has a solution for you: just use a nodesmap!
you can check out the API here:
github.com/RonenNess/ness-engine/blob/master/source/NessEngine/renderable/nodes/nodes_map.h

basically a nodesmap works just like tilesmap, but instead of sprites you have nodes. in every node you can create as many sprites as you want. I used it to create the following example (sorry no source yet for this one, but I can send it to you in private if you like):



as for loading just parts of the map for huge maps: usually RAM is not an issue, but if you are talking about REALLY huge maps I think the best solution would be to use a matrix of nodesmap and load/delete nodesmap as whole when necessary (i.e. divide your whole map into smaller maps and load only the maps that are currently in screen or near it). I assume you want this for seamless maps transitions right?

I hope this helps, if you have any more questions feel free to ask

PS. the QT properties design pattern is interesting (and quite easy to implement with a hash table) I assume the return value is a union? Anyway I will consider it for possible future versions, but dont count on it for the near future.. thanks!

you were mostly right about your assumptions:

1. the dirt, grass, water, bridge etc.. are indeed layers of sprites, just like you said. I used a nodesmap and for every node in the map I created as many sprites as I needed on top of each other (every sprite == layer). so the result is like it was tilesmap but with as many sprites as needed for every tile spot. this way you can have dirt (bottom layer) with grass over it, and combine pretty much anything (you can even do dirt with grass and water over it to give a swampy look).
2. the walls are on a separated nodesmap then the tiles, because they use z ordering while the floor tiles don't need it. every piece of wall is a node in the walls nodesmap, and composed of several sprites combined together (wall side sprite, wall top sprite, and shadow). the advantage here is that you can create wall you can see-thought. for example, see the metal-bars gate behind the player? this is actually a wall type. if the player would stand behind it, the bars will be rendered on top of the player. in front of it, and the player will be rendered on top of the bars.
3. the objects (barrels, torch, trees, blood..) are individual sprites arranged in the same z-node as the walls and the player.

I added the texture of the wall and the bridge to clear things up:



you said: ""For that, I wanna make translucid some parts of scene. If node-map builds scene to increase performance, can I do that? Or can I only do it with sprites?""
what do you mean "if node-map builds scene to increase performance"? nodes map is basically a matrix of nodes, arranged by the size and distance you defined. but the "size" of those nodes is only relevant to the culling mechanism (which is extremely efficient in nodesmap). so.. nodesmap is totally dynamic and editable, except for moving nodes or putting objects larger then the defined size, which will result in wrong culling.

so in short: don't worry, your Guku will be able to break walls, and you can play with the nodesmap on the fly (add cloudy sprite to hide things outside the line of sight and even make the other entities invisible below it for better performance.

PS if you are looking for a real static nodesmap, there is the staticNode entity that convert as many objects as you like into a matrix of textures and can render thousands of entities at the speed of light (but those entities are 100% static and can't be moved or changed). the StaticNode can be good for a static none-animated tilesmap, but its kind of premature optimization if you ask me

nope, nothing static about tilesmap/nodesmap, stop insulting them

I'm familiar with Tiled, though I never used it. looks nice though, from the gallery it looks like they did a good job
feel free to share your ideas and insights from your project, as well as interesting screenshots and WIP stages

and have a happy new year!

to be honest I didn't fully understand your proposition (maybe a code would help) but I think you worry about memory and performance too much.

first, you need to understand how nodesmap work so you'll worry less about performance: the nodesmap calculate the first and last nodes that are inside the screen based on the distance and "size" of the nodes. so if you have a nodesmap in the size of 1000000x1000000 or a nodesmap in the size of 100x100, it doesn't matter; the performance would still be the same. only the nodes that are inside the screen boundaries will be rendered, while the others will not even be tested for visibility because they are assumed to be outside the screen. that's why if you move nodes in nodesmap it mess up the culling. so if your resolution is 800x600 and your tiles are 32x32 in size, rest assure every frame will only go over 25x19 nodes that will be processed and rendered.

as for RAM, an average computer today have at least 8GB of RAM. a sprite in ness-engine takes about 240 bytes (rough estimation), and a node about 200. so lets say every tile in your map is a node + 1 to 4 sprites, the RAM taken for every tile in your map would be 440 to 1169 bytes. lets say a map is in the size of 100x100 tiles, worse case will take 11.69 MB (worse case means every tile will have 4 layers of graphics). so if you implement smooth map transition in the most naive way, i.e. you load the current map and all its surrounding maps, it means that at every single moment you will have 9 maps of 100x100 loaded into your RAM. that's about 108 MB (in the worse case of 4 sprites per tile!). just for comparison: google chrome with about 10 tabs open can easily take over 130 MB (at least on this PC...)

what I'm basically saying is this: I think you should focus more on your gameplay and less on cool yet complex optimizations, especially if your focus is on memory optimizations which are less critical. my best advice is to start from creating a class that represent a single map batch, lets say 100x100 tiles in size, and focus on make that work. after that add the smooth transition (naive implementation with loading all the neighbors) and if that's not enough - time for optimizations

but that's just my personal opinion good luck on your project!


PS if you do write it I'd love to see the code, I just think you should save this optimization for later phases