Server Help :: View topic - How to plan LVZ effectively? TIPS?

Server Help

LVZ/LVL Questions - How to plan LVZ effectively? TIPS?

RAYfighter - Wed Sep 24, 2003 7:42 pm
Post subject: How to plan LVZ effectively? TIPS?

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 - Wed Sep 24, 2003 10:33 pm
Post subject:

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 - Thu Sep 25, 2003 7:40 am
Post subject:

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 - Thu Sep 25, 2003 2:11 pm
Post subject:

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 - Thu Sep 25, 2003 8:58 pm
Post subject:

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 - Fri Sep 26, 2003 4:03 am
Post subject:

Smong wrote:

...
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.

Could you complete your neat tip with lvz.ini code lines? Shall them look like this:

[screenobjects]

;when player enters Arena he will see newsbox for 10 seconds
C-146,29,IMAGE1,AfterChat,EnterArena,1000

;after 10 seconds IMAGE2 (still newsbox) dissapears, thus revealing already looping 2 seconds long fadeout animation of the same newsbox
C-146,29,IMAGE2,AfterChat,EnterArena,1200

...so they are displayed at the same time, cuz they have same trigger (EnterArena), but since IMAGE1 is higher within the .ini file, it is displayed on top of any other overlapping image which are lower?

Akai wrote:

...
use .png for images

Sorry Akai but I would keep on a different oppinion here. Always decide where to use PNG and where JPG just compresses better. Also GIF, thanks to wide range of options within "SaveForWeb" feature in Adobe Photoshop 7 or their Image Ready, might work very well in certain situations.
Please keep in mind that we are still talking about 8-bit colour world.

SuSE - Fri Sep 26, 2003 11:58 am
Post subject:

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 - Fri Sep 26, 2003 1:17 pm
Post subject:

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 - Mon Sep 29, 2003 5:07 am
Post subject:

Akai wrote:

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

Lossless is where PNG can get beaten, it's obvious that if we allow JPG to "forgett" some data, it can win - again, keeping in mind that some images or themes (for example cloudy hires planet) doesn't need any crispy detail. But I won't focus on this problem anymore, since I guess it has been discussed enough.

I want to check another idea for lowering level download: if I have a sub-arena, using major graphics from main arena, can I target them from within sub-arena's LVZ? It would be effective if the player, who simply must have loaded main arena's GFX already, could reused them for sub-arenas as well. If it is a shipset, sounds, or even zone welcome banner.

Mine GO BOOM - Mon Sep 29, 2003 11:15 am
Post subject:

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.