Re:creation - a top down action adventure about undeads [hiatus]

[shadowmouse]

I was going to suggest that, but I thought having position independent from width would make it easier to add tiles as you could just add things at the end of the list with a position that isn't at the bottom of the image.

[Elias Daler]

It's hard to know the width of the tileset which would be enough. Sometimes I arrange tiles into large chunks, so then it's easier for me to create levels. Using enums is not possible, as it would require hardcoding.
So I think I'll stick with randomly generated ids for now.

[Hapax]

Using enums is not possible, as it would require hardcoding.

Yes, but only once 
Much better than having to re-assigning all the IDs manually and it's pretty lightweight.

Having customised textureRects for each tile seems like overkill for a tileset in a grid but it'll work. The added advantage of this is that you can then start to use irregular tilesets 

[Elias Daler]

Yes, but only once 

Huh? But I would need to change this enum each time I add new tile type. And then I would need to recompile. Nope!
And I don't plan to have customized textureRects, all I need is (x,y) coordinate, the tile size would stay the same for all tiles.

Much better than having to re-assigning all the IDs manually and it's pretty lightweight.

I would re-assign only those IDs which I would change in the tileset if I use the method which I talked about.

Suppose that level is stored this way:

GGGGGG
GGGGGG
GGRRGG
GGGGGG
...

G is a grass tile and R is a road tile.
Suppose tileset file looks like this:

x=0,y=0,id=G
x=16,y=0,id=R,
...

What if I've decided to move grass tile in other place in the tileset, like (32,32)?
All I need to do is replace x and y coordinates in tileset file.

x=32,y=32,id=G
x=16,y=0,id=R,
...

The level file would not change at all.
If I change the width of the tileset, nothing would change in a tileset, all I need to do is add new tile ids in a tileset file.

[Hapax]

And I don't plan to have customized textureRects, all I need is (x,y) coordinate, the tile size would stay the same for all tiles.

By customised, I mean that the textureRect's position is customised i.e. out-of-order. In fact, it could be off-grid if the x and y co-ordinates are texture resolution (and it could have a custom size), but I realise now you probably mean that the x and y would be grid positions e.g. x = 6 for the seventh tile on that row.

Much better than having to re-assigning all the IDs manually and it's pretty lightweight.

I would re-assign only those IDs which I would change in the tileset if I use the method which I talked about.

"Re-assigning all the IDs" here meant your original IDs, where you would have to change them all manually.

x=0,y=0,id=G
x=16,y=0,id=R,
...

This is where the enum could still be used: the "id"; you'd be using an identifier anyway.

[Elias Daler]

By customised, I mean that the textureRect's position is customised i.e. out-of-order. In fact, it could be off-grid if the x and y co-ordinates are texture resolution (and it could have a custom size), but I realise now you probably mean that the x and y would be grid positions e.g. x = 6 for the seventh tile on that row.

I originally thought about having x and y be positions on the texture, but now I realize than this is not necessary, grid positions are all that is needed.

"Re-assigning all the IDs" here meant your original IDs, where you would have to change them all manually.

Well, that's not that hard, I think

This is where the enum could still be used: the "id"; you'd be using an identifier anyway.

As I said before, I can't let myself hardcode stuff (there will be lots of tile types, sometimes near hundred or more), creating some file and then creating std::map from it  seems better for me.

[Hapax]

"Re-assigning all the IDs" here meant your original IDs, where you would have to change them all manually.

Well, that's not that hard, I think

I meant changing the the level manually, as was your first concern.

As I said before, I can't let myself hardcode stuff (there will be lots of tile types, sometimes near hundred or more), creating some file and then creating std::map from it  seems better for me.

Fair enough. Enums can get pretty long, pretty quickly 
The consideration with using an std::map is what to use as the key. Would that still just be an integer? A string?

[Elias Daler]

I meant changing the the level manually, as was your first concern.

I won't change the level manually, I will change the tileset manually, but maybe I'll write a short program which will let me do this with some cool GUI

Fair enough. Enums can get pretty long, pretty quickly 
The consideration with using an std::map is what to use as the key. Would that still just be an integer? A string?

Enums also make modding harder. People can't create custom tilesets that way, only redraw the existing ones.
I think I'll use strings because this would let me assign meaningful ids to some tiles.

[Hapax]

Going back to an earlier subject, I remembered that you had a problem with implementing a render texture. Did you fix this? An idea came to me randomly: the views on the render texture and window would need to be controlled individually. Odd views may have caused your vibration. I think that's the problem you were having, right?
If it's not this, or you fixed it anyway, just ignore this post 

[Elias Daler]

Going back to an earlier subject, I remembered that you had a problem with implementing a render texture. Did you fix this? An idea came to me randomly: the views on the render texture and window would need to be controlled individually. Odd views may have caused your vibration. I think that's the problem you were having, right?
If it's not this, or you fixed it anyway, just ignore this post 

I think that the problem I was having is that view's coordinates were not integer during screen shake (I forgot about that when I was trying to fix that). I'll come back to it later.

[Elias Daler]

Sorry for the lack of updates. Some RL stuff going on + I have lots of other stuff to work on/learn.
I'm mostly doing refactoring now and thinking about making some fundamental systems in the game better and more stable.
There's a lot of stuff to do to make game more polished. This is sometimes very hard and boring, but it needs to be done.
And I've almost completed the first article of "Using Lua in practice" series. I hope to release it today or tomorrow.

I'm also learning some OpenGL. What are some books/tutorials would you recommend? (Preferably OpenGL 3.x because my graphics card doesn't support OpenGL 4, heh).

[victorlevasseur]

Here is one I used to learn a bit of modern OpenGL : http://www.opengl-tutorial.org/

[Elias Daler]

Here is one I used to learn a bit of modern OpenGL : http://www.opengl-tutorial.org/

Thanks, I've read some articles there and they are pretty good

Also, Using Lua and C++ in Practice is out.

[dabbertorres]

I'm also learning some OpenGL. What are some books/tutorials would you recommend? (Preferably OpenGL 3.x because my graphics card doesn't support OpenGL 4, heh).

I'm a fan of https://open.gl/. It even has a guide of setting up an OpenGL context and input handling with SFML (along with SDL and GLFW).

[Elias Daler]

I'm a fan of https://open.gl/. It even has a guide of setting up an OpenGL context and input handling with SFML (along with SDL and GLFW).

Thanks, I'll check it out