I am drawing a level with tiles on a grid - Grid/Tilemap. I need to fill a space of 100x100 units. I can do this in several ways:
Method 1. Break the picture into tiles of 1x1 unit size.
Create a grid of 1x1 unit size.
Draw on the grid until I fill a space of 100x100 cells (1*100=100).
Method 2. Break the picture into tiles of 0.1x0.1 units size.
Create a grid of 0.1x0.1 units size.
Draw on the grid until I fill a space of 1000x1000 cells (0.1*1000=100).
Method 3. Use method 1 and method 2 at the same time.
Create 2 grids and 2 tile sizes.
Where you can fill the space of 1 unit, draw with large tiles (prefer large tiles). In other places - small tiles.
In practice, I can only use method 2 or method 3.
That is, either fill the entire space with small tiles, or fill the space where possible with large tiles and the remaining space with small tiles.
Which method - 2 or 3, will be more productive in practice?
It is certainly not a thing for software that doesn’t even exist yet!!
Instead, get to work and try out your different methods.
If it works, great, you’re done!
If it has issues, fix it!
For all performance and optimization issues, ALWAYS start by using the Profiler window:
Window → Analysis → Profiler
Generally optimization is:
avoid doing the thing that is slow (easiest)
do it fewer times and store its result
do the slow thing less frequently over time
do the slow thing when nobody cares much (during level loading or in another thread, etc.)
find a faster way to do the thing (hardest)
DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!
If you DO have a problem, there is only ONE way to find out: measuring with the profiler.
Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.
Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.
Do not blindly reach for multi-threading or async… understand your performance problems first:
Remember that you are gathering information at this stage. You cannot FIX until you FIND.
Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.
Don’t forget about the Frame Debugger window either, available right near the Profiler in the menu system.
Notes on optimizing UnityEngine.UI setups:
When you are investigating a performance concern, you may even need to create custom tooling or scripts to clearly expose the issue and help you reason about possible solutions. This may even involve making special instrumented builds of your game capable of running on the actual problematic target hardware.
At a minimum you want to clearly understand what performance issues you are having:
running too slowly?
loading too slowly?
using too much runtime memory?
final bundle too large?
too much network traffic?
something else?
If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.
Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.
This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.
“Software does not run in a magic fairy aether powered by the fevered dreams of CS PhDs.” - Mike Acton
Your answer is not useful.
I asked a relatively simple and obvious question. I described the simplest example. And I would like to get a clear answer to it. The situation I described allows this.
Your question may seem straightforward to you, but anyone with enough experience understands that performance is highly contextual. It depends on everything happening within your game. Providing meaningful advice requires a full understanding of the context, including the specifics of your code. Performance isn’t something anyone can predict without seeing actual code, nor is it universally applicable to all scenarios.
@Kurt-Dekker’s advice is the most practical you’ll get: experiment with different approaches and see what works best for your situation.
Below are some examples (not exhaustive) illustrating why your question is abstract, generic, and difficult to answer clearly
What other code runs in your game? This will affect rendering performance.
What hardware are you optimizing for (e.g., cores, memory)? Do you target multiple platforms, such as desktop and mobile?
What is your desired framerate?
Is drawing the bottleneck, or is another part of the game slowing things down?
How to you define performance? Are you optimizing for execution speed, memory usage, or reducing heap allocations?
Are you working on a multiplayer game, a memory-constrained turn-based game, or something with a specific loop speed requirement?
Are we talking OOP, data driven so you read your data (coordinates etc) from somewhere? Is this somewhere a file? a network resource?
How are tiles stored and rendered? Are they all loaded into memory, or are they streamed based on camera movement?
What collections do you use for keeping your tiles for rendering?
What algorithms do you use and what are their complexities?
Are you employing an ECS architecture? Something else?
What are the target resolutions?
Is you artwork compressed? What about its size?
Those are just a few of the factors that affect performance which is influenced by countless factors, each branching into more questions, all of which intertwine. This complexity makes it impossible to provide universal advice.
There are a million things that can go wrong in programming, including performance, and if someone can think of a hundred of those before starting writing code is a genius. This means that even if someone is a genius, it’s better to spend his time implementing rather than speculating, he won’t even get 0.01% there.
What might seem simple to you, is only because you haven’t tried implementing it. You should learn to recognize the difference between the wrong answer with an answer you don’t like, but unless you implement something that is within your requirements and then ask for specific code advice, the only answers you might find acceptable are the ones that are more convenient.
No one can accurately answer your question because it is too broad, generic, and abstract. Programming isn’t like writing a book, more code gets discarded during development than what ultimately makes it into the final product. You should try you different options and find out for yourself what is within your acceptable requirements.
The choice between Method 2 (small tiles only) and Method 3 (combining large and small tiles) for your 2D game depends on factors like performance, memory usage, and rendering efficiency. Here’s a breakdown to help you decide:
1. Performance Considerations
Method 2 (Small Tiles Only):
Pros:
Simplicity in implementation: A single grid and uniform tile size are easy to manage.
Flexible level design: Small tiles allow for fine-grained control of detail in your level.
Cons:
Increased draw calls: Each tile is a separate entity, so filling a 100x100 space with 1000x1000 small tiles requires significantly more draw calls or batch processing.
Higher memory usage: A grid of 1000x1000 tiles requires more memory for tile data and possibly texture lookups.
GPU overhead: Rendering numerous small quads can overwhelm the GPU, especially on lower-end hardware.
Method 3 (Mixed Tile Sizes):
Pros:
Reduced draw calls: Large tiles cover more space, decreasing the number of rendering operations compared to small tiles alone.
Balanced memory usage: Fewer tiles overall mean less memory overhead for managing the tile grid and associated metadata.
Optimized performance: By using larger tiles where possible, you minimize rendering overhead while still allowing fine detail with small tiles.
Cons:
Increased complexity: Managing two grids or a hybrid system adds implementation complexity.
Potential fragmentation: If the level design frequently switches between small and large tiles, there may be inefficiencies in organizing the tiles.
2. Practical Scenarios
Method 2 is better if:
Your level design requires high detail everywhere.
Your engine or framework efficiently handles large numbers of draw calls and manages tile rendering with batching or GPU instancing.
Method 3 is better if:
Large areas of your level use repetitive or uniform tiles that can be covered by larger tiles.
You aim to optimize for performance on low-end or mid-range hardware.
Your engine can efficiently manage mixed-size tiles, possibly using a spatial partitioning system (e.g., quadtree or hierarchical grid).
Is it better to drink 3 8-ounce beers or 5 12-ounce beers?
Your question may seem simple, but anyone with experience understands that drinking is highly contextual. It depends on everything going on in your life. Providing meaningful advice requires a full understanding of the context, including the specifics of your life.
The outcome of a drink is something no one can predict without seeing your actual state, and it does not apply universally to all scenarios.
@Kurt-Dekker’s advice is the most practical you’ll get: experiment with different approaches and see what works best for your situation.
Here are some examples (not exhaustive) to illustrate why your question is abstract, general, and difficult to answer clearly
Who else is drinking around you? This will affect how much you drink.
Do you drink multiple types of beer, such as light and dark?
What is your desired level of drunkenness?
Is drinking a bottleneck in your life or is another part of drinking slowing you down?
How do you decide what is best for you? Do you drink faster, get drunker less, or spend less money?
Do you drink with friends, alone, or train for a drinking competition?
Are we talking about a bar, restaurant, or dive bar?
What might seem simple to you is only because you haven’t tried to implement it. You have to learn to recognize the difference between a wrong answer and an answer you don’t like, but unless you implement something that meets your requirements and then ask for specific code advice, the only answers you’ll find acceptable are the ones that are more convenient.
No one can answer your question accurately because it’s too broad, general, and abstract. Programming is not like writing a book, more code gets thrown away during development than what ends up in the final product. You have to try different options and find out for yourself what suits your acceptable requirements.
Peace to the world, Zen and joy to all. And I am beautiful.
///
I asked a simple question. Simple in a vacuum.
You came up with a million cases without knowing the answer.