-
Hi, I'm new here, and I'm creating a game using SFML. It's a 2D isometric game with coherent terrain generation using perlinnoise. What I am doing is creating a dynamically allocated array of sf::Sprite objects to draw to the screen during my render method. The array is somewhere in the neighborhood of 65k elements in the current state (this will probably be a medium sized map and will increase to upwards of 300k if possible). So I'm having to dynamically allocate the memory before assigning the sprite textures and positions in isometric 2d space. My question is this... won't I have to delete the array at program shutdown? I tried doing so but, no matter where I put the delete statement the debug output says I'm trying to delete an invalid pointer. Do I have to delete this array or is SFML doing that for me? And while I'm at it I should probably ask if there is a better way to do what I'm doing?
-
Make it an array of smart pointers (std::unique_ptr (http://en.cppreference.com/w/cpp/memory/unique_ptr) most likely, alternatively std::shared_ptr (http://en.cppreference.com/w/cpp/memory/shared_ptr) if you need shared ownership). Then when the array goes out of scope the shared pointers will take care of deleting the objects they point to.
See also: Why RAII rocks (http://bromeon.ch/articles/raii.html)
-
What about using a std::vector?
Also with that amount of sprites, it might be better to use a vertex array. ;)
-
Ok, options are as I see it based on responses:
1. std::unique_ptr <-- I've never used this before though I do know about it a little bit. So I'm at a loss here as to how I would use this for my purposes.
2. std::vector <-- I've used this extensively before in the past in other applications. I really like it for keeping track of dynamic lists of things. I think this would probably suite my purposes a bit better, but question is does this handle memory allocation for me? I forget.
3. vertex array <-- I remember reading about this somewhere, but I don't remember what it is and even less how to use it for what I'm doing. Could someone give me a small run-down on what this is exactly, it's not like a vertex buffer from OpenGL / DirectX is it?
Are there any other options here that I should be aware of? And another question is what would be the comparable performance gains for the above methods?
-
Ok, I've already answered Question number 3 about vertex arrays. They are apparently similiar to vertex buffers that I'm used to working with before to create mesh objects. Question is how would I dynamically create a mesh that could display my 2D textures in the right positions? Would it need to be Triangles or a TriangleStrips? I'm a bit confused as to how to proceed.
-
Take a look at the article Jesper linked (RAII).
However in your case I don't think an unique_ptr would make sense.
A vector is basically a dynamic array, so yes, no need to manually management memory.
Also this is basic C++, you should really learn C++ first properly.
See the tutorials about the vertex array.
My personal suggestion is to use a std::vector<sf::Vertex>.
Sprites are essentially just Quads, so that'd probably be the best primitive.
-
Well, I am self taught. I'm sorry if I came off as incompetent. I just couldn't remember if std::vectors were dynamically allocated or not. I have been programming C++ and C# and Java and many other languages now for at least 10 years off and on... I think I know enough about the basics for the most part. And this is not my first game project, but it certainly the most complex project I've under taken.
-
It doesn't really matter how many other programming languages you know or how long you've been working with these. Because none of these other languages have the C++ standard library and regardless of how long you've been writing C#, you won't magical know it either. Keep in mind here, I'm not trying to offend you, but I'm trying to help you. ;)
-
Also, just to clarify my post earlier, I already looked up the documentation on the Vertex Arrays. I understand better now, these are very similar or practically the same as Vertex Buffers in DirectX and OpenGL with the addition of dynamic memory allocation (and I'm assuming a few other features) built in. My question was, how do I go about building a mesh object with this that could display all of the isometric pixel art textures that I've created in the correct order (to keep the appearance of 2D). I understand how to use it in a basic fashion just based on reading the docs.
What I really need to know is if I would get more performance from using triangles (for separated Quads) quads (for separated Quads) or trianglestrips ( for connected Quads)? And if it is the last one, I'm at a complete loss as to how to go about creating a mesh with connected Quads that would actually display the textures in the fashion that I want. Does anyone have a resource I could look at that deals with this exact issue?
I'm not asking to be spoon fed just looking for some help here.
-
It doesn't really matter how many other programming languages you know or how long you've been working with these. Because none of these other languages have the C++ standard library and regardless of how long you've been writing C#, you won't magical know it either. Keep in mind here, I'm not trying to offend you, but I'm trying to help you. ;)
Ok well, I have worked with the std library pretty extensively and I've used vectors before, I just forgot that they were dynamically allocated because I haven't used them in a while. This is not to say I do not understand the concept of a dynamic array because I do. And I don't think anyone even fully refreshed on the topic knows every single aspect of standard library off the top of their head. At least I don't even though I've worked with it pretty extensively, I have to refresh myself especially if I am coming back from a hiatus from programming. I do not particularly think this means I don't know C++, just that I have memory issues. There is a difference in my mind between refreshing my memory in one aspect of the standard library and "you need to learn C++" which yeah does seem like a bit of an insult. It's really ok though, I'm over it. I just want some help here on my project.
-
I understand better now, these are very similar or practically the same as Vertex Buffers in DirectX and OpenGL with the addition of dynamic memory allocation (and I'm assuming a few other features) built in.
No, OpenGL Vertex Buffer Objects (VBOs) are a different concept, they reside completely in video memory on the graphics card.
What I really need to know is if I would get more performance from using triangles (for separated Quads) quads (for separated Quads) or trianglestrips ( for connected Quads)?
It really depends on your hardware and even more on your driver, it's difficult to say that in general. Chances are that quads are split into triangles anyway. I would use the simplest geometry (quads) unless you get real performance issues. Of course, you can also do a benchmark.
And don't be upset about the C++ comment, we advise everybody who's not certain at the STL and memory management to refresh those topics, as they're really crucial, and knowing them well can save you a lot of trouble and time :)
-
Yeah, I apologize for getting upset. It probably is good advice, to refresh myself on these concepts and will do so as I go along.
Anyways moving on, that's very interesting that you say they are a completely different concept from VBOs, so these Vertex Arrays give access to the CPU as well I take it and that's why they would be manipulated alot easier? Any resource you could give me that might clarify the difference? I'd really like to understand as much about the Vertex Arrays as possible before I move on. And I did read all the documentation page on them but I must be missing something fundamental here.
Also, someone on another forum suggested I map the textures on to small 3d cube primitives by unwrapping them in a isometric style orthographic projection, but I am unclear on some of the details on that. Any ideas what might be the advantages of doing that over using Quads or sprites?
And about the benchmark. I'm reading on the SFML clock class right now. Would I do a benchmark measuring the framerate with that or are you just talking in general? Because this is a project I'll eventually want to make commercial (if it turns out well) I'd probably have to do some testing on different systems then to get a minimum system specs requirement.
-
so these Vertex Arrays give access to the CPU as well I take it and that's why they would be manipulated alot easier?
Their vertex data is just stored in RAM like any dynamic array (in fact, sf::VertexArray stores a std::vector<sf::Vertex>). When the vertices are drawn, the whole vertex data is uploaded to the graphics card. The corresponding code can be found here (https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/RenderTarget.cpp#L264-L278). The functions glVertexPointer, glColorPointer and glTexCoordPointer specify where the data for vertex positions, vertex colors and texture coordinates lies. Upon calling glDrawArrays, this data is loaded from the RAM to the graphics card's memory.
Any resource you could give me that might clarify the difference?
You could have a look at the documentation of the above-mentioned functions on www.opengl.org, for example https://www.opengl.org/sdk/docs/man/html/glDrawArrays.xhtml. Or https://www.opengl.org/wiki/Vertex_Specification. Don't confuse this technique with Vertex Array Objects (VAOs) -- it's merely a way of passing all the data to the graphics card at once, instead of once for each attribute in each primitive (old-school glBegin/glEnd rendering).
Also, someone on another forum suggested I map the textures on to small 3d cube primitives by unwrapping them in a isometric style orthographic projection, but I am unclear on some of the details on that.
Why would you need a cube for 2D rendering? I don't know what he meant.
And about the benchmark. I'm reading on the SFML clock class right now. Would I do a benchmark measuring the framerate with that or are you just talking in general?
Don't measure frame rates, they're not expressive. Measure times. Yes, you can use sf::Clock for that.
But keep in mind that a proper benchmark must fulfill the following conditions:
- The operation to measure must take up most of the time while measuring
- The operation must be repeated a sufficient number of times (you can't measure a single function call)
- Make sure the order of operation doesn't affect the result, randomize where necessary
- Compile in release mode, and without running debugger, and with full optimizations
And to be honest, I think you should invest your time better than deciding between quads and triangles. First, there are most likely other performance bottlenecks in your application. Second, if you find out that this should be a real issue, you can still change it within minutes. Of course, that requires you to build a reasonable abstraction so that you don't deal with raw sf::VertexArrays in hundreds of places, but separating graphics from the game logic is a good idea anyway.
-
However in your case I don't think an unique_ptr would make sense.
unique_ptr may not be the best fit, but that suggestion was triggered by the original question mentioning an array of dynamically allocated types. And for dynamically (heap) allocated objects std::unique_ptr is very often the natural thing to use :-)
Ohh and btw, I completely agree with using a std::vector (or sometimes a std::array) over a build-in array in most situations. Vector is definately the "go-to" container unless you have special needs and really know what you are doing and why. :-)
-
Ok, I'm back with a few more questions. This time about the Vertex Arrays. Should I make a separate post to be asking this stuff since this problem is basically resolved or is it ok to post here?
Anyways, I need a bit of help with the output I'm getting from the draw call to the VertexArray.
I'm using this code so far to create the vertex array:
int chunks = 16;
int blockCount = 64;
int blockSize = 32;
int depth = 10;
int layer = 0;
noise::module::Perlin perlinNoise;
for(int c = 0; c < chunks; c++)
{
for (int x = 0; x < blockCount; x++)
{
for (int y = 0; y < blockCount; y++)
{
// Get the depth value.
float nOffX = (float)x / (float)(blockCount - 1);
float nOffY = (float)y / (float)(blockCount - 1);
float nX = 128.0f + nOffX * (256.0f - 128.0f);
float nY = 128.0f + nOffY * (256.0f - 128.0f);
int maxDepth = lround(perlinNoise.GetValue(nX,nY, 0) * 10);
maxDepth = noise::ClampValue(maxDepth, 0, depth);
for (int z = -1; z < maxDepth - layer; z++)
{
// Adjust for Isometric Coordinates.
int isoX = (((x - (z * 2)) + y) * blockSize / 4);
int isoY = ((y - x) * blockSize / 2);
isoX += (blockCount * blockSize / 2) - (blockSize / 2);
isoY += (blockCount * blockSize / 2) - (blockSize / 2);
terrain[0 + (c * (x * blockCount + y))].position = sf::Vector2f(isoX, isoY);
terrain[1 + (c * (x * blockCount + y))].position = sf::Vector2f(isoX + blockSize, isoY);
terrain[2 + (c * (x * blockCount + y))].position = sf::Vector2f(isoX + blockSize, isoY + blockSize);
terrain[3 + (c * (x * blockCount + y))].position = sf::Vector2f(isoX, isoY + blockSize);
terrain[0 + (c * (x * blockCount + y))].texCoords = sf::Vector2f(0.0f, 0.0f);
terrain[1 + (c * (x * blockCount + y))].texCoords = sf::Vector2f(32.0f, 0.0f);
terrain[2 + (c * (x * blockCount + y))].texCoords = sf::Vector2f(32.0f, 32.0f);
terrain[3 + (c * (x * blockCount + y))].texCoords = sf::Vector2f(0.0f, 32.0f);
}
}
}
}
And I'm getting a very stretched output that seems to stem from the origin of the grid.
(http://i.imgur.com/TlKRT5O.png)
What am I doing wrong here? I don't think it's the texture coordinates although I could be wrong, the docs say that the texture coordinates are not normalized and that they are in pixel coordinates of the desired texture (mine is a 32x32 isometric pixel art block).
So I'm wondering if it's not the way I'm plugging in my isometric coordinates for the blocks.
-
It looks more like the vertex position is off. Run your debugger and check the values, or cout them and check it manually.
-
Yeah I'm pretty sure that it has to do with the way I am referencing elements of the vertex array. I'm trying to treat the vertex array which is 1 dimensional like a 4 dimensional array where the dimensions are chunks, x position in chunk, y position in chunk, and vertex index. I have found alot of ways to reference 2 or 3 dimensions as a 1 dimensional array but not 4 dimensions. Any tip on how to do this? Or am I going about this completely wrong?
-
This is how I am declaring my vertex array:
In class header:
sf::VertexArray terrain;
In setup function:
terrain.setPrimitiveType(sf::Quads);
// chunks * chunk width * chunk height * number of vertices per quad
terrain.resize(16 * 64 * 64 * 4);
Is this incorrect?
Edit: Also, one other thought had occurred to me. Can I make an array of VertexArrays? If I can do this then I can simplify my code to treat each chunk individually and use the per chunk info as a 3d array. I like this option because it makes a bit more sense to me... and I don't really want to proceed until I know for sure how to go about doing this because I am dealing with large objects and I'm worried about memory and performance problems.
-
Can I make an array of VertexArrays?
Yes, vertex arrays are ordinary C++ objects, so you can put them wherever you like. I would use STL containers instead of raw arrays however. And if you have too many arrays, you're essentially defeating the point of using sf::VertexArray for fewer draw calls.
// chunks * chunk width * chunk height * number of vertices per quad
terrain.resize(16 * 64 * 64 * 4);
Is this incorrect?
Generally, multiplying each dimension seems correct. Since I don't know exactly what you mean with chunks and if you have everything uniformly spaced, I can't tell.
But you completely ignored eXpl0it3r's advice of having a look at the debugger. By doing so, you'll immediately find out if you do something wrong. For "mathematical" stuff like index calculation, it sometimes also helps to draw the problem in a simplified way on paper and verify if you're thinking correctly.
-
Oh I didn't ignore his advice, I just didn't mention that I looked at the debugger after I realized something was probably wrong with the indexing. :)
Something is indeed wrong with the indexing and I've almost fixed it but not quite (at least the cubes are not being stretched across the screen now lol):
terrain[(c * chunks) + (x * blockCount) + (y * blockCount) + 0].position = sf::Vector2f(isoX, isoY);
terrain[(c * chunks) + (x * blockCount) + (y * blockCount) + 1].position = sf::Vector2f(isoX + blockSize, isoY);
terrain[(c * chunks) + (x * blockCount) + (y * blockCount) + 2].position = sf::Vector2f(isoX + blockSize, isoY + blockSize);
terrain[(c * chunks) + (x * blockCount) + (y * blockCount) + 3].position = sf::Vector2f(isoX, isoY + blockSize);
terrain[(c * chunks) + (x * blockCount) + (y * blockCount) + 0].texCoords = sf::Vector2f(0.0f, 0.0f);
terrain[(c * chunks) + (x * blockCount) + (y * blockCount) + 1].texCoords = sf::Vector2f(32.0f, 0.0f);
terrain[(c * chunks) + (x * blockCount) + (y * blockCount) + 2].texCoords = sf::Vector2f(32.0f, 32.0f);
terrain[(c * chunks) + (x * blockCount) + (y * blockCount) + 3].texCoords = sf::Vector2f(0.0f, 32.0f);
Is what I'm using at the moment to input the positions and texture coordinates to each quad. Something's still not right, so I'm going to probably output a section of the indexes and find out what the indexes actually are being set as.
As far as what chunks mean, I'm planning on rendering the groups of blocks as "chunks" (term used in voxel games such as minecraft to denote the block of the level that is actually loaded to the screen). This way I can have a large map without incurring huge performance issues from having too many quads being drawn. In this instance my chunks are 2d sections of Quads that I want to render (i.e. the stuff the player is actually looking at).
-
Yes, the indexing is wrong.
This time, you ignored my advice :P
Take pen and paper and check for a simple example why the indexing is wrong, and how you could improve it. That's how you solve problems as a programmer -- imagination, pen&paper, debugger... they're all engineering tools that you need to combine.
You said:
I have found alot of ways to reference 2 or 3 dimensions as a 1 dimensional array but not 4 dimensions.
If you know how to do it for 3D, you'll recognize the pattern, and you can extend it for 4D easily ;)
Oh, and use functions to compute the index, code duplication is terrible.
-
I decided to cout all the indices since it was becoming a bit of a pain to compare in debugger each step, it's giving me output like this small section of indices:
608, 609, 610, 611
608, 609, 610, 611
608, 609, 610, 611
384, 385, 386, 387
400, 401, 402, 403
416, 417, 418, 419
416, 417, 418, 419
432, 433, 434, 435
432, 433, 434, 435
432, 433, 434, 435
Each row of four is an index being referenced inside the "z" loop (or the last loop of the terrain generation) so it is the 1st to 4th element in the array at that block location if that makes sense.
This tells me that there is still something wrong with the indexing of the array elements as I can see that the numbers are being repeated frequently (meaning the blocks are being drawn ontop of eachother). Still experimenting with ways to fix this, I am close but still missing something.
-
Just want to mention a quick thing in relation to the original post.
If we are talking about "shutdown" as in "terminating the application", then it can sometimes make perfect sense to purposely leak objects. If the destructors of the objects are either trivial or otherwise perform no work that is persistent and we are terminating the application anyway, then leaking the memory and letting the OS clean up can be a perfectly valid (and fast) strategy.
I know the topic of this thread has moved on, just wanted to make that one point.
-
This tells me that there is still something wrong with the indexing of the array elements
Yes, read my post; I extended it afterwards.
Don't get it wrong, I consider it absolutely crucial that you learn how to solve such problems on your own, because you'll encounter them again and again as a programmer. (And btw, it has nothing to do with SFML, again...)
One possible approach is also to solve the problem starting with small pieces: compute indices for 2D, then 3D, then 4D. As I said the pattern is always the same.
Still experimenting with ways to fix this, I am close but still missing something.
Don't just "experiment" (aka random trial and error), approach the solution systematically.
-
Alright, it's fixed! Yay finally. Thought I'd share the result for those interested. This is the working relevant code I'm working on:
void Game::generateTerrain()
{
noise::module::Perlin perlinNoise;
cout<< "Generating Terrain: " << endl;
// Initialize the map variables.
mapWidth = 4;
mapHeight = 4;
chunkWidth = 8;
chunkHeight = 8;
blockSize = 32;
mapDepth = 5;
layer = 0;
for(int mx = 0; mx < mapWidth; mx++)
{
for(int my = 0; my < mapHeight; my++)
{
for(int x = 0; x < chunkWidth; x++)
{
for(int y = 0; y < chunkHeight; y++)
{
// Get the depth value using Perlin Noise.
float nOffX = ((float)x + (float)mx) / (float)(chunkWidth - 1.0f);
float nOffY = ((float)y + (float)my) / (float)(chunkHeight - 1.0f);
float nX = 128.0f + nOffX * (256.0f - 128.0f);
float nY = 128.0f + nOffY * (256.0f - 128.0f);
int depth = lround(perlinNoise.GetValue(nX,nY, 0.0f) * 10.0f);
depth = noise::ClampValue(depth, 0, mapDepth);
for(int z = -1; z < depth - layer; z++)
{
// Calculate the isometric x and y coordinates
// Each corner of the rectangle that holds the cube forms a right triangle with an opposite side of 16 pixels.
// We know this because the whole side of the rectangle is 32 pixels long and the side we can easily measure
// is half of that length (where the cube's bottom point meets the line.
// This opposite side is at an approximate 26.565 degree angle, which is the angle of 2:1 resolution isometric projection.
// This gives us the equation (adjacent) a / 16 = tan(26.565) or solving for a = 16 * tan(26.565) which equates to approximately 8 pixels.
// This means that our adjacent side is roughly 1/4 of our rectangle side.
// To get our isometric values we want the rectangles to overlap so that we have an "overlap rectangle of 16 x 8 pixels.
// This is the same as saying because we have a 2:1 perspective we need the overlap rectangle to be twice as wide as high.
// Or the equation is 1/2 width x 1/4 height or 1/8 x width X height for the area of the overlap rectangle.
// So to get the "isometricX" value we adjust along both the x and y 2D axis like this: ((x - y) * (blockSize / 2))
// And to get the "isometricY" value we adjust along both the x and y 2D axis like this: ((x + y) * (blockSize / 4))
// To input the z or "depth" value we adjust along both the x and y 2D axis like this:
// isoX = ((x - y) * blockSize / 2) + (z * blockSize / 2)
// isoY = ((y + x) * blockSize / 4) + (z * blockSize / 2)
// chunkOffsetX = (mx - my) * chunkWidth * blockSize / 2
// chunkOffsetY = (mx + my) * chunkHeight * blockSize / 4
int isoX = ((mx - my) * chunkWidth * blockSize / 2) + ((x - y) * blockSize / 2);
int isoY = ((mx + my) * chunkHeight * blockSize / 4) + ((x + y) * blockSize / 4) - (z * blockSize / 2);
cout << isoX << ", " << isoY << endl;
sf::Vertex v1, v2, v3, v4;
v1.position = sf::Vector2f(isoX , isoY);
v2.position = sf::Vector2f(isoX + blockSize , isoY);
v3.position = sf::Vector2f(isoX + blockSize , isoY + blockSize);
v4.position = sf::Vector2f(isoX , isoY + blockSize);
v1.texCoords = sf::Vector2f(0, 0);
v2.texCoords = sf::Vector2f(32, 0);
v3.texCoords = sf::Vector2f(32, 32);
v4.texCoords = sf::Vector2f(0, 32);
terrain.append(v1);
terrain.append(v2);
terrain.append(v3);
terrain.append(v4);
}
}
}
}
}
}
And the output looks like this so far:
(http://i.imgur.com/PuH0IN8.png)
So once I realized there was an append method to the VertexArray it was rather easy to add the Quads at the correct index. Don't know if this will cause problems later with trying to reference the blocks for removal or adding new blocks but I think I'm on the right track at least. :)
Right now the terrain is not looking the way I want but that is more due to the noise algorithm setup I'm using I think. And of course if you look carefully all the chunks are the same (which is not what I want) so I need to fix that as well.
On a side note, running this program makes my graphics card "hum" or whistle very faintly ( at least I think this is the graphics card ), I don't know if this because of Linux or if it is because of something else (perhaps I'm doing something wrong). The total number of vertices for this map is something like 20000 (well below the limits of a modern graphics card like mine). So I'm confused as to why it is doing this. Anyways I will test the code in windows, to see if the problem is the same there.
-
Ok, so I did some more research on the buzzing or humming noise I was experiencing yesterday... I think it may be coil vibrations from the graphics card. Surely this is not normal for an application with so few quads being rendered. Could this possibly be due to me not limiting the framerate yet? I also read that vsync can be related to this problem in some way.
I haven't tested on windows yet but will do that shortly.
-
Yes, that's most likely coil whining and it probably happwns because you're maxing your GPU by not limiting the framerate. VSync will help since it limits the framerate as well.
Just don't mix setVerticalsyncEnabled and setFramerateLimit!
You most likely also hear it when you run a graphics heavy game without framerate limitation. ;)
-
I've never noticed it before, but it sounds like I need to limit the frame rate regardless and it may remove the problem. I can't very well be maxing out peoples graphics cards while playing my game and causing noise issues. I mean after all I am just displaying about 5000ish quads which is not much for a modern game. :P
Ok, back to the tutorials on how to set and limit framerate. Also, with the don't mix the enable vsync and limit framerate options you are saying don't mix those? I don't plan on it but why don't I want to do that (just for my knowledge).
-
Enabling vsync already limits the framerate, it wouldn't mean anything to mix both.
-
VSync is done in the graphics driver and the framelimit is implemented in SFML with putting a thread to sleep. Having both active will lead to the mechanisms to counteract.
Learn about both more and it will be logical. ;)
Also not every GPU suffers from coil whining.
-
Ah I see, sorry don't know much about Vsync that's the reason I asked (always wondered what that option was in games). So, one is a hardware solution framerate limit and the other is a software framerate limit. I should probably (in the final version make vsync enable an option). However for now I'm going to use the "window.setFramerateLimit(60);" shown in the documentation example. I tried it in my initialization method and the coil whine is gone completely so It was a framerate problem. I suspect this is not OS specific so probably would have occured in Windows as well.
I will do some more research on Vsync before implementing it.
-
I tried it in my initialization method and the coil whine is gone completely so It was a framerate problem. I suspect this is not OS specific so probably would have occured in Windows as well.
What doesn't make sense when we tell you it is because you maxing out the GPU? This isn't related to framerates or what OS you are running. When you tell the GPU to work as much as possible that will cause stuff to max out and cause the whine. This would happen if you ran any game at max settings that loaded down your GPU.
-
@ zsbzsb : I'm not sure I understand what you mean... the GPU appears to have been maxing out because of the unlimited framerate. I mean otherwise why would limiting the framerate get rid of the problem? And no I have a GPU that can run most modern games at max settings without maxing out. So I don't know what you mean by that either.
-
Ok, I have another issue I'd like to ask about. How am I going to go about handling clipping for the sprites (movable characters)? My only thought on this is to also put the sprites into the vertex array and draw those to the screen at the same time so that hopefully the objects draw in the correct order and produce the clipping result that I want? Is there a better way to do this in sfml that doesn't involve meshing together all sprites in a single object? I already know based on what I've read here on the forums that sfml does not have z-depth for a variety of reasons so I need some other way to go about handling this.
-
What do you exactly mean by "clipping"? It seems like you're using the term a bit differently.
Concerning Z order, the only thing you can do is sort the sprites or vertices, so that they are drawn in correct order. If your sprites have stable addresses, you can use a data structure that stores pointers to them.
-
Yeah sorry, I don't know the exact term for what I'm looking for perhaps it would be better called "layering". Anyways as far as I can tell sfml doesnt have built in layering functionality (i.e. moving sprites behind other sprites). So it seems what you said (which is similar to what I thought) is that it would be best if I simply drew all the quads together in a single vertex array so I can get the order correct. I just needed confirmation of that thanks. So that is a bit of a problem because the type of game I'm building is going to be a "kingdom builder" type game where you can mine blocks and create structures from resources. So some of the indexed sprites might be removed or new ones added at any given moment right?
-
There are always multiple options.
The simplest regarding drawing logic would be to have one vertex array where the vertices have been ordered correctly.