Hot answers tagged

5

This is very nice example of problem suited for A* algorithm. I will not go into details how to implement A* here as it has been done better before and this very easy to find, however this is how I would apply A* for your problem: As you can see, there is only a limited number of states that you can "move" to using single swap (14 for this case if I am not ...


5

Here is a solution without resorting to 3D coordinates or splitting your sprite into 1x1 elements, that works if your objects occupy rectangular areas of tiles. Let (ei,ej) be the coordinates of the bottom tile of entity e. I assume the x axis is pointing north-east and the y axis is pointing north-west, so that (ei,ej) has the smallest coordinate values ...


5

Brief : This answer suggest to break big sprites into one by one tiles so the zPosition for each sprite which is used to sort them in depth will work correctly. To understand my proposal you will have to stop thinking in tiles for a while, even if your finished game needs to guarantee that all objects will be tile aligned. I suggest you to adopt the same ...


4

Top right of the inspector right next to the little lock icon -> select normal. You should now see the sorting layers and order.


4

There's no real benefit to sorting those sprites by not-Pokemon index; the texture packer doesn't care what order the not-Pokemon are in, it cares about minimizing the atlas size. I'd just let it do its thing, the atlas file already specifies the position, dimensions, and other settings for each sprite. All you have to do is reference them by name.


3

Your premise is incorrect. If you send a bunch of transparent polygons (or anything else) to the GPU to be rendered, the GPU will draw them in precisely the order you defined them -- it will not sort them at all. The way you control which polygons get rendered first is to send them to the GPU first; either by putting them first in the index buffer (if you'...


2

I finally did it and found a quite simple solution, seems fast enough, I post it if anyone wants the solution. I created a class Point class Point { public: sf::Vector2f myPosition; float myAngle; Point(sf::Vector2f thePosition = {}) { myPosition = thePosition; } }; I made a vector of points : std::vector<Point> lightPoints ...


2

Before we can use Sort(), we need to know how to sort between instances of the type we are using. The error is complaining that you do not have the required sorting functions, which are sought out through an interface. An interface is basically a set of method signatures. Any class that uses that interface must implement the same methods. If you are ...


2

In interview, Ian Andrew, founder of Incentive Software, designer and co-creator of Freescape along side his brother Chris, said: Each element was held within a bounding box which enabled the z-order to be completed with one check rather than the thousands involved for each pixel. And Chris used a unique sorting system which really enabled the game to ...


2

Iterate over the vertices and store a running average of their positions to compute an estimated centroid position. Take your cutting plane and use it to form a quaternion or matrix you can use to transform vectors in the cutting plane back to a standard XY plane. eg: Quaternion toPlaneSpace = Quaternion.Inverse(Quaternion.LookRotation(planeNormal)); ...


2

Per @DMGregory Unity's "Vertical Layout Group" component handles this natively. I created an empty gameObject and made all of the "slots" for objective names/descriptions children of it. I added the Vertical Layout Group component to the new parent gameObject. Now, when my objectives are set to !visible, I've scripted it such that they'll ...


2

I'd argue that allowing the towers to disperse the firepower over multiple priorities is the opposite of "robust", because the towers would tend to avoid finishing the targets. To get a better mental model of priority, think about the cost of missed opportunity: how much damage would the player take, if given enemy would be allowed to pass. For ...


1

I would implement a Z level system: create a draw_texture function that takes the Z level of the object (which could be determined by its position), and instead of rendering, store the texture and src/dst rects in an array representing the Z level (you could have one array for each level, or a matrix, where each row would be a Z level). Then create a ...


1

Well I got a few tips for you to try to get it working : I'm not really sure what the exact issue is. I think it might might actually be a bug in Unity. Anyways, it deals with the SpriteRenderer and the order in which it is applied to the gameobject (relative to the Particle System).Try to remove the SpriteRenderer, and then add it (or just create a whole ...


1

I'm going to agree with @Sidar in the comments- this probably isn't an issue, and I don't see a better implementation given the libraries you're using. If you look at the Ashley/libGDX implementation, the SortedIteratingSystem ultimately uses TimSort each time you resort it. While TimSort has a big-O of O(n log n), when working on a nearly-sorted array it ...


1

I see you're using the default "Chunk" draw mode for your tilemaps. As noted in the documentation for Tilemap sorting: When set to Chunk Mode, the Tilemap Renderer handles Sprites on a Tilemap in batches and renders them together. They are treated as a single sort item when sorted in the 2D Transparent Queue. This reduces the number of draw calls to ...


1

Put your objects into a std::vector (or even std::array) and then use std::sort with a custom comparator. After that, if necessary, you can assign the indices in the list to the corresponding objects. std::sort(objects.begin(), objects.end(), [](const auto& a, const auto& b) { return a.score > b.score; }); Now objects contains the items ...


1

Your algorithm only appends links to a chain to the first encountered pair in the chain, but it does not ensure a is the first item in the chain. The result is that an example like { 1,2, 0,1, 2,3} will sort to {1,2, 2,3, 0,1} instead of {0,1, 1,2, 2,3}, so links might be split up. You could check whether the pair at b comes before the pair at a, but with ...


1

Deferred sort (lazy so it only sorts at the last moment before the sorted values are needed) as you've done is the typical approach I've used in the past, so I'd say your current solution is pretty good. Depending on your insert/remove demographics (i.e. the ratio of inserts / deletions to items that stay the same each frame), you may get slightly higher ...


1

If you are precomputing this sorted array once only, then this is perfectly fine (even doing an actual distance calculation with square roots is probably ok in that case). If your entities are moving around and you have to resort this array every frame then you will probably want to implement an acceleration structure of some sort, like a Quadtree in order ...


1

In Text Mesh Pro, you can use overlay shader to render alway on top. And for normal rendering, you can use Distance Field Shader. Here is the demo.


1

If batching is a bottleneck then you might want to sort them by depth and material and also perform a bounds check to see if they overlap. But you're probably going to spend way more time in sorting and checking than just plain sorting and having a less performant batching. I guess your mileage may vary but if you're writing a generic batcher I'd stick to ...


1

What you've described (Painter's Algorithm) is indeed the way it's usually done. There are however maybe a few things to consider in addition: If you're sorting by object, then there are some limitations. These might not be super important in your case, but if you have a lot of complex objects with transparency, your sort might break in situations like this,...


1

You will have to sort the sprites based on their bounding box and start drawing things from back to front. In order to be successful with this you'll have to apply a mapping from the 3D coordinates (which seem dimetric to me) to the screen coordinates. Height differences translate directly into an offset in the y-coordinate while movement along the oblique(?)...


1

The order in which they are drawn is deterministic. The GPU will not randomly decide which polygon to draw. The order is controlled by the order you supply the draw calls in and the order of the indices in the index buffer. Often you will want to manually sort your polygons and then send them as a batch to the GPU. I do not know which framework you're using ...


1

When you specify layout (location = x), the compiler is supposed to respect that absolutely. It should not be changing the uniform locations as long as your specified layout is valid. If you're absolutely sure it's not your fault (double-check you're not re-using any locations across all active shader stages, for instance), then it does sound like a driver ...


Only top voted, non community-wiki answers of a minimum length are eligible