Server Help

[SuSE]

I think his basic message is that lvz is cooler than tilesets because it's less limiting

[-zig-]

erm...i dont plan on the editor making anything for you aside from a lvl file and a ini. i think you missunderstand my intentions. merely a tool. which is nothing unless the person so inclined sets out to make a A.jpg or A.bmp or A.gif.

and as far as image formating goes. you can find most of that allready written free source. almost cut,paste and compile.


-zig

[Mr Ekted]

You sound like Qndre now.
_________________
4,691 irradiated haggis!

[Cyan~Fire]

Not quite. He's not saying "I heard from a friend that JPG is actually a bitmap renamed, which I have confirmed with a self-written ASM program which for some reason doesn't work."
_________________
This help is informational only. No representation is made or warranty given as to its content. User assumes all risk of use. Cyan~Fire assumes no responsibility for any loss or delay resulting from such use.
Wise men STILL seek Him.

[Mr Ekted]

OMG Cyan! You nailed him! $$

[k0zy]

[SuSE]

Qndre doesn't have screenshots of a functional program

[Smong]

I think for a text2lvz thing, it should look for patterns in the text and generate separate images of partial words. Having one image for each letter is going to decrease fps.

I'm not a mapper, but I find a 12x4 font block (a-z, 0-9, some symbols) leaves plenty of space for at least 5 tile blocks.

[Guest]

[Smong]

I don't think each tile is tested for collisions, simply each ship and each weapon.

Drawing the map would only require a lookup in some kind of table.
Depending on how the lvz objects have been implemented there could be at least one conditional to check (is it visible) increasing execution time.

[Guest]

good points, well see i suppose, but its been my experience so far, that it can handle quite a bit of abuse. my evo zone 7 megs, and thresh which is a whole lot more optimized both run respectably well, even on junk video card. 16 meg voodoo3 2000( well old(glide owned))

soon now i will have adding things working. and i will experiment some. i just seem to remember tiles just wreaking havoc on the engine.

member that tank zone that used a tiled bg? ive had alot of large ass images floating around on the screen, and never even came close to running as bad as that does. one draw is way way faster than 2 regardless of size. so maybe if you tiled a back with 16x16 tiles LVZ it will run just as horrible, but something makes me doubt it. which makes me think there is more going on with the tiles.

[Matzke]

i think a awesome idea to save time would be you could click and drag your mouse over a few tiles then u click the tile u want them on, and they'd be placed right there. for example some tilesets might have a tree, bush, or bunker that is a few tiles, u could drag your mouse over them and walla they can be placed on your screen, BIG time saver[/quote]
_________________
z0rz

[Mr Ekted]

That's equivalent to the Photoshop PEN tool. As I suggested before, two other similarly useful things are BRUSH tool and BUCKET tool.

BRUSH: Define a bunch of small(ish) pattern of tiles, select a pattern, and drop it onto the map all at once with a single click, as many times as you like.

BUCKET: Select a tile and click on the map. All touching empty tiles (clicked on empty space) or all touching similar tiles (clicked on existing tile) or all touching non-empty tiles (maybe shift-click) are filled with the selected tile.

[ZiGNoTZaG]

can be done, the tile brushes. the only thing to decide would be where to store the settings.

the fill of course, simply involves adding tiles around the origin tile until every tile included in the fill had all 4 of its sides touching another tile. this could easily end up filling you entire map with tiles. 1 million entries. a one million step undo? heh. there would have to be a limit.

[Mr Ekted]

Undo should be by change, not by tile. Fill is a single action. Undo states for large actions need to be block map/layer saves. I would recommend using compression. You can limit the region to just the affected tiles, store a sub-array of tile id's, then compress that block. Even if it's 50K per compressed undo region (which is really high), that's still 20 undo's per megabyte, which is nothing.

[ZiGNoTZaG]

like an array of dynamic arrays? not sure about the compresion. need more research.

[CypherJF]

You'd need to store all the modified tiles past value(s); and store em into some sort of an array but compress em before hand. That way you're not saving extra data that you don't need. ie: all 1024x1024 tiles. I think that's what ekted is trying to say.
_________________
Performance is often the art of cheating carefully. - James Gosling

[ZiGNoTZaG]

yeah ive started thinking about this and the best way i can think of is to have like an array of a set limit. such as 20 or 40. contained inside of this would be a dynamic array that you could size to the amount of objects selected.

that would handle large undos.



this would either have to polymorph for lvz or be two differant types.

[2dragons]

An easy way to do compression for tiles is Run Length Encoding (RLE). Lookup how bitmaps do it and you'll have yourself a good example.

[Mr Ekted]

Easiest way is to take the raw map (1024x1024 tiles) before the change occurs, and zlib compress it. Results should easily be less than 1 byte per actual tile, and should only take a few milliseconds.

[CypherJF]

Suggesting, to serialize the "map" object then compress it?

[Mr Ekted]

[ZiGNoTZaG]