Server Help

[RAYfighter]

I wonder if there are some known guidelines for using LVZ images in a matter of client performance (fps) or if anyone can share some experience with different situations.

For example, a basic question would be:
If I want some planet on the map, say 1000 pixels in diameter, shall I use one big image, or I should definetly go with many 256 pixel squares? (and why 256? )

I know it may depend on particular GFX card which put your Continuum to slide show and which is rendered with ease, but I guess there might be some kind of recommendations or TIPS for effective planning of your LVZ.

[Mine GO BOOM]

1000x1000 image is pretty big for a client to render it. For those with good video cards, it is a snap and won't matter if its one 1000x1000 or a million 1x1 (well, maybe then). For a client that it would matter if its split, it will render like shit anyway you do it.

So, just make it an optional lvz, and do a single large 1000x1000 image. Those with problems can just turn off optional lvz.

[RAYfighter]

Thanks Ryan,

so it does not matter for a client which "slicing" I use - I can freely slice larger themes by their shape to safe space for example, right?

And how about overlaying sprites? Are mapobjects in top level death trap for a client in general? I mean, shall I use them very sparingly?

And again, if I have 1000 pixels wide space station, and let's say I want about 10 little flashing lights variously scattered all around the station. Would it be the best idea to try to reuse 1 little animation at all positions, or to not bother with seamless tilling and just use next higher level above the station bitmap with black-transparent fill?



And some other kind of question: we are limited by 4MB of filesize - is this limit of 1 single lvz file? Or total download for any arena?
I understand that offering anything larger to players for download might cause monitors flying outta many broken windows, but what are chances in case that 4 megs simply aren't enough? You want sounds, shipset, banners, animated mapobjects... and you can easily reach the limit. Shipset or sound pack can be offered for download from a website - what are other tricks to keep downloading of "level" small?
And what about updates of your arena map? Will client compare timestamp at files and only download updated stuff?




Anybody could share which problems he encountered when messing with LVZ?
(like for example with old tiles, if you ever tried to fill some large area with green or passable tiles, even checkered, client dropped fps down to 10 over it)

Such information collected in one place could really help to proper planning of good LVZ design, and hence to avoid try/mistake way

[Smong]

If you are having a huge image with flashing lights on it, make the lights a separate file to save space. Also the order in which you declare objects in the lvz is important as to their "virtual layer" in the real layer (AfterTiles).

For example I could have a newsbox image and a newsbox fade animation, two separate files with the same trigger (EnterArena), but different display times so it looks as if it fades away without having to make duplicate frames and a huge image. By having the newsbox scripted higher up the .ini than the fadeout it appears ontop in game.

The map/lvz udpates are based on a checksum of the file, not a timestamp.

Also keeping everything in 8bit and telling the players to use 8bit can speed things up a lot for people with "old" graphics cards.

Edit: learn from bad examples too, go in TW's battleships or rally or even Warzone CTF and that is the sort of thing my computer struggles with (server kicks me before my machine can load all the lvz and stuff).

[SuSE]

use .png for images (mine's info on .png)

4MB max filesize (per file)

don't fill large areas with tiles

remember that if you want custom ship images to be seen from the main UI, you must add the ship images to the misc:levelfiles= line (like "misc:levelfiles=whatever.lvz,ships.bm2")

I forget if it works with ship1.bm2, ship2.bm2, etc.

It shouldn't matter if the image(s) are actually .png's with their extensions renamed to .bm2

shipinfo.dat must also be added in this way

ship images in particular (probably shipinfo.dat, too) should be optional .lvz files (misc:levelfiles=+whatever.lvz)

I need to do a lot of testing on this problem, but that should cover it for now

radarh.bm2 and radarv.bm2 are no longer used, so don't bother with them

[RAYfighter]

[SuSE]

I believe Mine demonstrated how with the png compression programs you cannot get any other format to have a lower file size (lossless) than .png - but whatever floats yer boat

[Smong]

I think your shot at the lvz script should work, mine looks very similar.

Also if you want to make blank 1x1 pixel images for the stars/planets, I think 24bit .png might give smaller file sizes than 8bit (the 8bit one has a palette, whereas each pixel in the 24bit one has a colour)...oops, I should just have used 1bit, bleh.

Edit: OK, I just tested it with PSP7, pngcrush and a 19x2 image; 24bit seems to give smaller file sizes than 1bit if the whole image is the same colour.

[RAYfighter]

[Mine GO BOOM]

Just make the lvz be the same for each. The client will do a checksum match on the two, and see that it is the same, so it won't redownload it.