Big Map JPG (2048x2048) in Design Philosophy

ID:151634
 
Nov 20 2009, 4:39 pm
So I thought I'd try to see if I could get a game running with a 64x64 map and one big fat 3D rendered 2048x2048 jpg image. Well, it runs, but it runs slow. Problem is I'm not sure what exactly is slowing it down. If I broke up that image into maybe 16 smaller images, would it make any difference, for example? Or is it just too much information crammed onto the game screen for BYOND to handle, regardless of how I break it up? Any thoughts?
#1 Nov 20 2009, 5:08 pm
If your view is set to 64x64, then that's why. BYOND appears laggy when the view is too big.
#2 Nov 20 2009, 5:56 pm
In response to Jeff8500 (#1)
The view is 15x15.
#3 Nov 20 2009, 7:04 pm
In response to Foomer (#2)
That's odd. Is the image the only thing in the world? If not, did you check the world's profile?
#4 Nov 21 2009, 3:21 am
If it was getting properly displayed, despite of being one large image, it would hint at the whole map being set to the client, which is supposedly fixed in the new release.
Else, if there is only one tile to the image, it should have vanished from view, soon as the tile it was attached to left the viewable area.

I would guess that splitting the image into 128*128 chunks should resolve your problem.
#5 Nov 21 2009, 3:26 am
In response to Schnitzelnagler (#4)
I'm still using an older, pre-beta version, so any fixes wouldn't be working for me yet.

And I did split it up into 16 512x512 sections and that helped quite a bit. Splitting it up into 128x128 sections would take me all day.

If anyone wants to check out my little experiment, they can download it here:
http://www.byond.com/members/Foomer/files/randomstuff/ AltMoveRacingDemo.zip
#6 Nov 22 2009, 1:10 pm
In response to Foomer (#5)
compiled and ran in 1050, i get strange tiling: http://img524.imageshack.us/img524/9978/altmovedemo.png

i'm interested in what you do to fix this

python (using PIL) script to save you time in the future:

import Image

track = Image.open('track.jpg')
width, height = track.size[0], track.size[1]
code = open('rendered.dm', 'w')
code.write('turf\n')

for x in xrange(0, width, 128):
  for y in xrange(0, height, 128):
    name = 'rendered-%ix%i' % (x, y)
    track.crop((x, y, 128, 128)).save('%s.jpg' % name, 'JPEG')
    code.write('\n\t%s\n\t\ticon = \'%s.jpg\'' % (name, name))

code.write('\n')
code.close()
#7 Nov 22 2009, 1:24 pm
In response to Crashed (#6)
Crashed wrote:
compiled and ran in 1050, i get strange tiling: http://img524.imageshack.us/img524/9978/altmovedemo.png

i'm interested in what you do to fix this
...

That's because he's using a version before native big icon support (I assume that's what he means by pre-beta).

Adding "world/map_format = TILED_ICON_MAP" would fix it, or he can rearrange his code to take advantage of native big icons.

Anywho, what you're seeing is a result of native big icon size support. Any old atoms with large icons that were placed with "Add" in the map editor, or were created with code that was relying on large icons to be broken into 1,1;1,2;ect at runtime, will now show the entire big icon instead of the icon's tile-sized parts.

Foomer, you should try updating and seeing if the native big icon support gives you a performance boost. Although you'll still have to break the image up to ensure the client can see it.
#8 Nov 22 2009, 9:31 pm
In response to DarkCampainger (#7)
Given the way Theo's altmovedemo works, I'd still need small 32x32 sections of map to determine collision detection. I realize this is hardly ideal, and I'd much rather find a better way to do it, but for now...