Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

6164 Excellent

1 Follower

About ferrous

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. If your scene has 100 objects, your original code will raycast against those 100 objects, looking for hits, copy the results of up to twenty objects that hit the ray, and then you check if those 20 objects are ground objects. By using layermasking, we first filter out the 100 objects for ground objects. (Of which there might be only one!) Then we do a ray test on those objects. So even if there is no GC difference, there should be a order of magnitude difference, especially as object count and complexity goes up. That and we eliminate the tag check as well. I don't recall if the single hit method returns the closest or not, it would be pretty garbage if it didn't, but I wouldn't be surprised if it didn't, or if it generated more GC that the non-alloc. Though I wonder how much it of a difference there is if compiling to their il2cpp code.
  2. I mean that you no longer need to check for multiple hits, therefore don't need to use the Physics.Raycast that returns multiple hits, which should theoretically invoke much less garbage collection than yours,since no array is required.
  3. Huh, funny, I just came across this post:, with the following comment: So, it sounds like a non-problem, if that comment is accurate.
  4. For an RTS, it might be fine. Depending. Like, for example, dragging a selection box, how would you do that in your game? Would you need to drag it in isometric fashion, or does the user draw a normal square? And if it's the latter would that make selecting units harder?
  5. What's the scenario you're describing here? A turret on a moving object trying to hit another moving object?
  6. ferrous

    Action points or not?

    Yeah, but then you force the player to figure out whether a weapon that costs 56 AP to fire is better than the weapon that costs 59 AP to fire. And the thing is, the difference is really negligible at that point. Unless you get a gun that costs < 50 AP to fire. Which would then be the better gun, unless its 48 vs 47 again. It's forcing the player to make a mostly busybody calculation in their head, as the granularity isn't really bringing anything meaningful to the table. You could try other ways to distinguish weapons than by how much AP it costs to fire them. Accuracy, ammo capacity, burst fire, damage, jam chance, etc. Though I think you should revisit your initial premise, why do you want to have a large variety of weapons that are the same caliber? Why do you want nine pistols that are all 9mm?
  7. Hmm. Inheritance in Unity is usually a sign you're heading down a bad path. Are you sure that shouldn't be a separate component? I think your clone is wrong too. You should Instantiate a new prefab and then copy the members, if you're actually trying to create a new object. Then StartCoroutine would work on it, and you wouldn't need the pickupmanager. (and it will probably prevent any future errors with trying to use a Monobehavior that isn't hooked up to Unity properly) Yeah, I could see update and check being slower, it probably has to load the whole Monobehavior into the cache, then unload it, because it can't tell that it's going to early out in the update method. So looping over 1000 monobehaviors all doing Update checks like that is painful, compared to a coroutine, which has time intrinsic to the coroutine itself, so it iterates over a much smaller object. Your priority queue method would also eliminate that loading of multiple monobehaviors.
  8. ferrous

    Get rotation angle from normalized 2D vector

    For shaders, yes, you will need to learn a shader language. Though they are fairly straightforward to learn, certainly less complex than any higher level language like C++ or Java. However, I wouldn't worry about tackling it until you're ready, you seem to have enough on your plate. If you end up bottlenecked for speed, then most certainly dive in and give it a try though.
  9. ferrous

    Get rotation angle from normalized 2D vector

    32 bit windows XP? It's kind of admirable you're targeting that, but that encompasses 0.22% of all Steam Users. You can pretty safely target higher OS versions at this point. (Other than that, I agree that fastest trig function is the one you don't call, and use the vector instead of the angle when you can) EDIT2: As this is for rendering, you could do all your work in shaders, which will be faster still. Maybe treat each sphere/circle/node of your worms as an instance and utilize instancing to rotate them in the vertex shader.
  10. I hate random flee chances. Have you considered a non random version? Something like the opponent always gets one free attack, but the player gets away. Or the player can always flee, but the option isn't available until after X turns -- could even make that level dependent, so against a weak opponent, X is 0, while a equal or harder opponent, X is 1 or 2 turns.
  11. Two things that tend to help a lot when trying to find the source of errors: 1) Debug.Log(), for example, if you printed out who was colliding with what, you might see what was causing the overflow. 2) Set some breakpoints, and attach a debugger. The latter, especially, is a very important skill to develop.
  12. Just a guess off the top of my head, but you've probably got a circular collision going on. Like, you are probably checking for collision against the very brick that is exploding, which causes a chain reaction of: Hit a brick-->do explosion --> oh we hit a brick --> lets explode -->oh we hit a break -->lets explode ..etc. The easy way to do this, is to instantiate the explosion and destroy the brick, then have the explosion have the script that does the overlap call in its update, which gets called on the frame after the brick is destroyed. (It also has a nice separation of concerns, bricks only do brick things, explosions do explosions.)
  13. ferrous

    Unity, how to deal with large amount of projectiles.

    Have a growing pool. Have the poolsize start at 150, but if you hit that cap, add 10 to the pool, etc. It's not all that different than what List<> and std::vector do under the hood. You can also shrink the pool by checking every so often, and seeing if you no longer nearing the current max poolsize, and freeing the excess. In unity, with an arcade shooter, one could also do Physics.OverlapCapsule, so one wouldn't have to sacrifice the bullets size.
  14. ferrous

    Unity, how to deal with large amount of projectiles.

    yeah, that is a common thing, the sphere is relatively expensive to render of the default primitives. there is a lo poly primitive asset pack, or you can make your own.
  15. ferrous

    Unity, how to deal with large amount of projectiles.

    Things that make projectiles slow: 1. Having them on a layer that intersects itself, they should be on their own layer that doesn't self intersect. If player bullets can intersect enemy bullets, then use two layers -- but they should still not self intersect. 2. Have them using a expensive collision primitive. Use a sphere or a circle. 3. Using an expensive to render mesh / sprite 4. Not using object pools, and instantiating a new projectile every time one is fired. Those are the usual gotchas. Failing those, I'd profile it and see. The built in unity profiler is easy to use. edit: One last one, if you have increased your physics rate, or messed with solver iterations
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!