ID:2242927
 
So after some interesting testing i discovered how the map maker was upgraded to handle huge icons and images and was wondering which is better in terms of performance. i wanted to predesign chunks of the map in terms of huge icons like say 512x512 and did that for the landscape would it make the game online lag alot? or at all? vs the small every tile being the usual 32x32? in just the offline test i didn't notice any lag with big icons but no clue if online changes. any info would be great om this matter
You're better off sticking with individual tiles. DS has some logic regarding big icons that tries to deal with issues like unseen small-tile turfs being pushed underneath a big-icon turf. Individual tiles are simpler and will also save you memory because you won't be loading huge icons.
Let's assume that you have a game where the main character occupies roughly a 32x32 pixel area.

Obviously, the less objects there are in the viewport, the less time the view will take to send, so on the surface, your analysis might be accurate, that a 512x512 (16x16 tile) individual icon would be a great way to go about things.

Looking back in time, there were many games that actually did this. Ultima 7, for instance, used 256x256 pixel chunks for their gameworld's map, with houses and trees and whatnot as individual objects on top of the map.

However, you have to be aware of how BYOND works not just with view sending.

1) Loading icons takes time, and each icon occupies its own texture. If you have a 512x512 icon size, you are looking at maybe 4, maybe 16, or maybe 64 icon_states per icon file before you max out a single texture atlas, depending on the user. Loading one of these big ass files will actually fully lock up DreamSeeker, because loading files takes time and BYOND expects DS to do it in a single tick with no breaks. Nothing else can happen while DS is pulling a texture from the RSC into memory, and there aren't many good ways to force a texture load ahead of time because BYOND makes things easy on the developer by punching the competent ones in the balls.

2) BYOND also manages collision and movement related code. BYOND is a tile engine. Meaning for each movement, all objects within the turfs between the starting and ending point will be included in movement obstacle queries. Bigger turfs will probably have a much larger number of objects in them that aren't even remotely nearby the movement. Much more so than you would probably need given a 32x32 tile size on account of the fact that the turfs themselves will be used for density and collision in the 32x32 example, while only objects can be used for 512x512.

3) Any kind of lighting or opacity system will have to be handrolled because the lighting system is purely tile-based. A larger world.icon_size means a mess of fun.

4) Your movement functions are gonna get a hell of a lot more complex to cull inappropriate failure/success cases.

And there are probably more reasons why you will lose performance. So basically, there's a tradeoff. Don't worry about how to make a fast game. Worry about how to make YOUR game faster. And even then, don't worry about it until after you've got a game.
In response to Ter13
Ter13 wrote:
Let's assume that you have a game where the main character occupies roughly a 32x32 pixel area.

Obviously, the less objects there are in the viewport, the less time the view will take to send, so on the surface, your analysis might be accurate, that a 512x512 (16x16 tile) individual icon would be a great way to go about things.

Looking back in time, there were many games that actually did this. Ultima 7, for instance, used 256x256 pixel chunks for their gameworld's map, with houses and trees and whatnot as individual objects on top of the map.

However, you have to be aware of how BYOND works not just with view sending.

1) Loading icons takes time, and each icon occupies its own texture. If you have a 512x512 icon size, you are looking at maybe 4, maybe 16, or maybe 64 icon_states per icon file before you max out a single texture atlas, depending on the user. Loading one of these big ass files will actually fully lock up DreamSeeker, because loading files takes time and BYOND expects DS to do it in a single tick with no breaks. Nothing else can happen while DS is pulling a texture from the RSC into memory, and there aren't many good ways to force a texture load ahead of time because BYOND makes things easy on the developer by punching the competent ones in the balls.

2) BYOND also manages collision and movement related code. BYOND is a tile engine. Meaning for each movement, all objects within the turfs between the starting and ending point will be included in movement obstacle queries. Bigger turfs will probably have a much larger number of objects in them that aren't even remotely nearby the movement. Much more so than you would probably need given a 32x32 tile size on account of the fact that the turfs themselves will be used for density and collision in the 32x32 example, while only objects can be used for 512x512.

3) Any kind of lighting or opacity system will have to be handrolled because the lighting system is purely tile-based. A larger world.icon_size means a mess of fun.

4) Your movement functions are gonna get a hell of a lot more complex to cull inappropriate failure/success cases.

And there are probably more reasons why you will lose performance. So basically, there's a tradeoff. Don't worry about how to make a fast game. Worry about how to make YOUR game faster. And even then, don't worry about it until after you've got a game.

Out of curiosity, creating a large tile (lets say a tree with the dimensions: 42x120) and setting it's bounds to something like 16x16 ONLY and manually adding density to the trunk area ; Would that prevent the major calculation issues you mentionned above? ("Bigger turfs will probably have a much larger number of objects in them that aren't even remotely nearby the movement. ")

Would that be some sort of "hack" to prevent all the calculations that happen with movement and Bump()?
@Kidpaddle: There's nothing wrong with a turf with larger than tile-size visual bounds. The only thing I was talking about was using a very large world.icon_size with a much smaller mob bounding area.