Tag Info

Hot answers tagged

5

First of all, unless you have an exorbitant number of entities, assigning them to a sector on every logic frame is most likely performance-wise negligible. That said, it sounds like you are in over your head. Either your game doesn't actually need spatial partitioning, or what you are trying to create is too advanced for your level. The point of spatial ...


5

I have good news and bad news for you: The Bad News: I don't know or remember any Java library that does what you want The Good News: It's really easy to implement this type of algorithm yourself! Here's a couple, you can mix them to optimize your collision detection depending on the type of shape. BB Collision Detection You can imagine a box around ...


5

100 pixels per unit would mean a sprite that's 100 pixels would equal 1 unit in the scene. It's simply a scale to say how many pixels equal one unit. This can affect things like physics. A lower pixels to units setting would require more force to move one unit than a higher pixels to units setting. Yes, there may be times where you'll want to manipulate ...


5

Yes, they are more efficient. Depending on your specific hardware and driver, massively so. The basic idea is that you want to minimize state changes. Changing the active texture is a state change. In many cases the GPU can only handle rendering with a single state at at time. If you think of all the dozens/hundreds/thousands of shader cores that a GPU can ...


3

As already pointed out in the comments and answer: This can be arbitrarily complex. Particularly, depending on the exact use case and performance requirements, you can employ some rather sophisticated data structures in order to make these tests fast. The bounding box test is the simplest one that should be done in any case (and in fact, could already be ...


2

Yes, using texture atlases is more efficient than using individual images. It largely boils down to two things: The images have to be transferred onto the GPU in order to be drawn to the screen. Sending one large image is going to generally be faster than sending a ton of small images. State changes on the GPU are expensive, and switching textures is a ...


2

This is one of "truths of old days" and no longer important (that much important). While using one texture is definitely more efficient(switching texture, as every operation, introduces some overhead), on today's hardware is not that big difference and the extra performance is generally not needed. If you have hardware capable of rendering millions textured ...


2

Answering the question in your title, units in Unity are arbitrary. It's just a number; the most common interpretation is that 1 unit means 1 meter, but that's just the most commonly agreed upon value. You could decide 1 unit = 1 foot, or 1 unit = 1 inch, etc. As for why you would use the default setting of 100 pixels, it's because the physics system ...


2

I think I would store two sets of coordinates. One used for drawing your objects DISPLAY POSITION and a second used for keeping a TRUE POSITION. This way you can draw sprites with rounded coordinates to eliminate the distortion caused by fixed size of your view area. But this also allows you to keep the exact location without influencing any of your ...


2

Rigidbodies can be said to operate in two modes: Non-Kinematic has physics driven movement, the physics engine will consider any forces brought to bear on the object to calculate and apply changes to velocity, rotation and position. Kinematic lacks physics driven movement, the physics engine will not cause this object to move and any forces on the object ...


2

A few things catch my attention off the bat. First: filedata = sr.text.Split('\n').Select(s=>s.Split(',').ToList()).ToList(); Feels highly dubious to me. Are you sure this is doing what you expect it do be doing? Second: float halfWidth = mainCamera.aspect * (mainCamera.orthographicSize/100); float tempYOffset = ...


2

This does not necessarily have to be as computationally expensive as you imagine. First of all, as you hinted at, you don't have to check every entity; just the ones that are moving. As such it might be wiser to have individual entities update their grid cell in their update method. As for checking coordinates, there are a few optimizations you could make. ...


2

You don't have to check every entity, every frame. You only have to check entities when you move them. Further, since you're using a grid system, you can just check to see if they've crossed a boundary. For example, if they're currently in grid 5,5 and you have a grid line every 10 units, you only have to do a modulus on their current x and y coordinates ...


1

yeah, all solutions have already been made... i'll just add some more code (i'm rather from stackoverflow ^^) assuming you're using bounding box assuming you use plain java (java.awt) . List<Shape> shapeList = ...; //you know where you get them Shape exampleShape = shapeList.get(0); Rectangle2D boundingBox = exampleShape.getBounds2D(); see ...


1

If you know the canvas is a rectangle then this simplifies to the case of checking if the bounding rectangle of the shape being drawn is contained within the canvas' rectangle. That's a fairly efficient check to run, and (generally) finding the bounding rectangle for your shape should be fairly easy (just finding the minimum and maximum x and y coordinates) ...


1

The frame you're in is irrelevant. You don't do this every frame. When the entity moves just check if it's in a new section and update it as needed.


1

Your best bet is to not generate tiles but generate and manage chunks which contain tiles. If you think about chunks as a fundamental part of the design then the issue may go away. I faced a similar issue in 3d with building my voxel engine. You likely want to do something like ... class Map { public Size Size { get { ... } } public ...


1

You need to handle your map in chunks/tiles of fixed size.. and only keep the chunks in the immediate vicinity of your player actually on hand at any moment (out to whatever view distance you feel is reasonable) As the player crosses a chunk boundary, you add new chunks in the direction of movement, remove them behind the player, and keep going. If you are ...


1

The question appears to be about how to go about selecting the correct tiles after generating a map, so that is what I'll answer. What you are talking about is called "autotiling" or "auto tiling" (depending on who you ask). Here's a simple-ish method for handling that: Given a single tile, we can find it's neighbors. Each tile then has a 4 bit state for ...


1

I suspect your issue lies in the way a sprite batch works in MonoGame. The performance cost is coming from using different textures for each tile. Let's take a peek into the MonoGame source code and see what's going on. If you follow the code down through SpriteBatch.End you eventually end up in the SpriteBatcher.cs class around about here: ...


1

To get to your main question, whether or not to influence the vertices before or during the shader, using a shader is preferred. If you know how to write a routine that can take into account the viewport and coordinate system, using a shader is preferred as it allows many sprites to be adjusted in parallel. Also, it ensures the "cosmetic" coordinates stay ...



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