Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - bitano

Pages: 1 ... 4 5 [6]
76
Graphics / Re: Help! Regarding view and world drawing
« on: March 10, 2016, 09:11:16 am »
I probably shouldn't point this out but it is, in fact, possible to update automatically in the draw method but it can get really messy (the draw method is const so it can't/shouldn't alter anything).
I did do that for sw::Sprite3D so that it would work in the same way as a normal sf::Sprite - without needing an extra update method. Feel free to have a look through the code ;D
Will do! I wanted to put it all in one draw() function, but i can appreciate keeping the logic separated in favor of code tidyness. This game is a relatively ambitious project (for me), so that's why i'm aiming for the best / most efficient approach.

1) vector of sf::Image for each tileset (as you said)
2) create a temporary sf::Image and use the vector to provide the pieces you want to copy, then update the sf::Texture from that image.
3) use the sf::Texture to draw the vertex array (no render texture needed?)
Can't get any clearer than this :-). Awesome!

I'm not sure why you have a render texture although you can either use an sf::Image or an sf::RenderTexture in the place of the "temporary sf::Image" described above.
The render Texture in the third step was more meant as drawing to the render object. It could/should have been RenderWindow, but i wrote renderTexture because it still feels strange to draw tile world directly to the window, instead of drawing it in the background and then display whole thing once.
It had nothing to do though with the process of selecting tiles and updating using the vertex :-)

This game is going to be amazing! Can't wait to put it all together! :D

77
Graphics / Re: Help! Regarding view and world drawing
« on: March 09, 2016, 10:01:20 pm »
Thanks a lot for your patience and detailed replies, Hapax. I really appreciate you taking the time to help me out. I'm learning a lot in just a couple of days and I fully agree with the "Hero member" title :-D

The draw() method should (usually) be used to draw the vertices to the target, not prepare the vertices. You could simply have an update() function that updates the vertices, which you would update each frame before drawing.

Possibly something like this:
// windowLoop:
{
    handleEvents();

    updateGameLogicEtc();

    updateGraphicsEtc(); // includes tilemap.update()

    window.clear();
    window.draw(graphics); // include window.draw(tilemap);
    window.display();
}
The update function might look something like this highlighted code in the update method of sw::TileMap
Check. The highlighted code is very useful. Also, yes - It would make more sense to have a separate update function, keeping the draw() function more straightforward.

So, you want to create a texture programmatically and then use that for your tile map? Although render texture should work for that, I think a render texture might be overkill as it's not getting rendered to often.

An option is to use a temporary sf::Image to create the image texture that you want (you can copy parts of images around) and then transfer it to the sf::Texture that you use for the tile map.
Remember you can load file as images and only transfer to a texture when you need them. (sf::Texture internally uses an sf::Image to load the file and then transfers it)
Alright. So what if:

1. i'd use a vector <sf::Image> array (TileIndex), with each image representing a tile collection like the grass example i posted earlier -> [grasstiles image, dirttiles image, forestroad tiles, image, etc...]
2. Then use this vector <sf::Image> array as the source from which i copy the relevant tiles to a sf::Texture Tilesheet.
3. The Tilesheet is then used by the VertexArray to draw the sf::RenderTexture Tilemap (the visible part of the world).
...(4. bacon...?)

78
Graphics / Re: Help! Regarding view and world drawing
« on: March 09, 2016, 09:27:30 am »
Right. So first: Am i understanding correctly that i'm creating / populating the sf::VertexArray for every frame drawn (so in the draw() function)?

Secondly, seeing as vertexArrays work with positions of textures in a large tilesheet, I'm considering generating the tilesheet on a renderTexture when loading the level. Reason for this is that i store my tiles separately in their own files. During gameplay however, tiles can be affected causing them to change. A full grassplot can turn into a half grassplot or disappear alltogether. If i'd use a rendered tilesheet, i would need to check whether the changed tile exists in the tilesheet and if not, add it (at the cost of performance).

The contents of a tile file look like this:



When a grass tile is affected by certain effects, it then can pick the appropriate subtile looking at surrounding tiles.

A lot of assumptions here! Feel free to correct :D

...I was really looking forward to the bacon :(

79
Graphics / Re: Help! Regarding view and world drawing
« on: March 08, 2016, 10:53:02 pm »
OK cool. Thanks a lot for the input.

I get the offscreen drawing to prevent unwanted visual effects. No idea why i didn't think of that myself as i used to do that with some previous projects (not SFML related...the word blitting comes to mind, but can't recall from where :-D).
So yea...

1. Draw visible tiles to offscreen renderTexture
2. Draw PCs, NPCs and objects to offscreen renderTexture
3. Apply effects / mask / lighting / what not  to offscreen renderTexture
4. Draw the GUI to offscreen renderTexture
5. draw the renderTexture to the renderWindow
6. BACON

I think i understand how the vertex arrays work with a tileset straightfoward matrix of tile indices, but i'm struggling still with how it would fit into my current tilemap design. Same goes for sw::TileMap.

These seem to work only for single layer tilemaps. I'd like to work with a multi-layer tilemap though.
What i mean is, every wold tile is in fact an array of tiles so i can stack multiple tiles on the same spot.

For example: World tile (5,7) would have a tile vector which could contain the following tiles: water, bridge, sign.
So on that world spot you can see the animated water. On top of it a small, damaged bridge and on the bridge a small sign.

Just sharing my thoughts here for some feedback :-)

80
Graphics / Re: regarding view and world drawing
« on: March 08, 2016, 07:57:17 pm »
I think you may be looking for sf::RenderTexture.
Thanks! That's exactly it!

It should be fine to draw all the tiles directly to the window as long as the ones that are not in display are culled. Combining the tiles and drawing them as a vertex array would also significantly reduce the number of draw calls from, say, drawing each tile as a separate sf::Sprite.

I don't fully see the advantage yet of a renderTexture as opposed to drawing directly to the renderWindow (for the world tiles).
I can imagine setting up a renderTexture for the GUI and keep track of whether it requires redrawing (as the gui will change less often). But the game world is pretty much in constant change due to hero and monster movement and tile animations.

I'm quite used to culling hidden tiles, so that's alright. Thanks for the tip though.
I'm not familiar with the vertex array. Sounds interesting! I will look into this as well. Thanks!

81
Graphics / Re: regarding view and world drawing
« on: March 08, 2016, 11:33:32 am »
Giving it some more thought, i'd say that (next to having the map vector) i'd have to:

1. Draw the entire map to a huge canvas (maybe sf::Texture?)
2. in the draw function clip the part of the texture map that's shown by the view

If this is the way to go, wouldn't this generate a really large texture if i'd have a big world (say 500x500 tiles)?

Assuming tiles are 100x100 pixels, the texture data size in bytes would be something like:
4 (rgba pixel) x 100 x 100 x 500 x 500 bytes = 9.3 gigs (?!?!)

Clearly, i'm confused!

82
Graphics / Help! Regarding view and world drawing
« on: March 08, 2016, 10:52:00 am »
Hi,

I'm not experienced at all, but i did write a couple of games. I just started with a new one now, but since i want to do this right from the get-go i wanted to double check if the way i go about drawing the world map is in fact the right way to go (or rather - my best option)

Assuming an RPG like game with a tilebased map (standard stuff i suppose).

1. i'd load my map into a 2-dimensional vector (for x, y coords)
2. Each map location has a vector of tiles (so i can layer tiles: i.e: water -> bridge -> signpost
3. At least 25 frames per second i call the draw function
4. The draw function loops through the map vector and compares x,y coordinates with view x,y coords
5. Everything that's within the view is redrawn, keeping tile order in mind per map position

Does this make sense? Or is this highly ineffective compared to an alternative (like drawing the entire tile map only once and then update those tiles requiring change).

kind regards,
Bitano

83
General / Re: RenderWindow bounds?!
« on: April 10, 2015, 08:59:29 am »
I'm not quite following you. In my example i'm not allocating memory, am i? I'm just defining a function-local reference to data stored in another structure...Or so i thought.
Exactly... That's why my answer to the question "am I correct in assuming..." was "yes" :)

To clarify, std::vector cleans up automatically (this is RAII), and you don't have to worry about pointers to its elements. Just keep them valid as long as you use them, but that's a different topic.

Ah right. Thanks for the clarification and your patience. It's really appreciated :D

84
General / Re: RenderWindow bounds?!
« on: April 10, 2015, 08:41:21 am »
And am i correct in assuming i don't have to clean up this pointer at function end as it's only a reference and i have the actual contents stored elsewhere (in a vector array) anyways?
Yes. In general, it's very simple: for every memory allocation, you need a corresponding deallocation.

The best is still if you use RAII and avoid new/delete completely. STL containers, smart pointers and other abstractions can do most of the work for you.

I'm not quite following you. In my example i'm not allocating memory, am i? I'm just defining a function-local reference to data stored in another structure...Or so i thought.

Or are you referring to the vector array? I was under the impression those also get cleaned up in the destructor.
I'm not dismissing the use of RAII - i actually like it a lot. I'm not seeing its application though with regards to this specific question :)

85
General / Re: RenderWindow bounds?!
« on: April 09, 2015, 09:21:05 pm »
Kind of hijacking my own thread here, but it felt silly to make a new post for such a small (and somewhat related) question:

For readability in the code i'd still like to use function-local pointers.

So instead of having to address this->that->stuffz->thingies[4]->id each time i want to access a property, i'd instead use thingy->id

Is it still the proper way to define a pointer like:

Code: [Select]
ThingyClass *thingy = &this->that->stuffz->thingies[4];

And am i correct in assuming i don't have to clean up this pointer at function end as it's only a reference and i have the actual contents stored elsewhere (in a vector array) anyways?

Thanks!

86
General / Re: InGame scrollable window
« on: April 07, 2015, 12:21:39 am »
There are always multiple ways to achieve something.

Using a view should work just fine. :)

So very true. My main concern was whether this approach was actually a wrong one (since i want to do this right and am somewhat new to the views). But that doesn't seem to be the case so hurray!

Thanks :-D

87
General / InGame scrollable window
« on: April 07, 2015, 12:14:56 am »
Hi guys,

I want to have a scrollable window in my game (for instance to display an inventory).

I'd setup my own InvWindow class which will be part of my Gui class. For the scrollable part of the window i'm assuming i'd best use a separate sf::view to display the items in.

Is this assumption correct or is this the wrong way to go about?

88
General / Re: RenderWindow bounds?!
« on: April 03, 2015, 04:00:10 pm »
Excellent advice! Thanks.

Yes i am aware of drawing only the tiles / sprites that are actually visible in the view, but thanks for that :-).
My code could've been cleaner and was based on what i knew from older projects (actually did use new and delete, etc).

This too is the reason why i want to start all over and make the code as clean as possible from the get go. That's also why i raised this question. Not that i don't trust the SFML library (that would be silly), but that i might've made an incorrect assumption

Thanks again! I will certainly check out the provided links. Feel free to pass some other related links if you're aware of any :-)

89
General / RenderWindow bounds?!
« on: April 03, 2015, 03:34:24 pm »
Hi there!

Not too long ago i made a game which progressed pretty well, but for some reason crashed after approximately 30 minutes (sometimes 40). It seemed like one of my functions / pointers was leaking somewhere but i couldn't find any cause. As far as i could tell, i made sure to clear up any unused pointers.

I started considering that the leak was caused by one of the SFML functions i might have misinterpreted...I tried to troubleshoot some but in the end let it rest...

-----

Now i'm starting on a new game and this still bugs (pun...lol) me. What i'm thinking at the moment is that the most used function while the game is running is the one drawing tiles to the RenderWindow.

I realized that i never found out whether i should set the outer bounds of a RenderWindow.

Should i define the outer bounds of the RenderWindow somewhere?
What are the size limits of RenderWindow (considering i'd want to use a huge tilemap) ?
What if a function ended up drawing something outside the boundaries of RenderWindow (for example starting from negative X,Y coords)?

I hope i was clear enough on this and that someone is able / willing to help me.

Thanks!

Pages: 1 ... 4 5 [6]
anything