LVZ Mapping

[L.C.]

Subspace supports a maximum of 256 tiles, with half of them hidden and locked away (though usable). Continuum supports the fabulous LVZ, when now I begin to wonder if PriitK had more in mind than what we know. As some may know, Drake's Continuum Map Editor (DCME) supports in-editor LVZ editting and placement. One feature of it that I noticed is that you could align graphic objects to the grid. So if you had something with dimensions in any multiple of 16 pixels, you would basically have an ordinary tile, right? You could take some of the tiles in your regular tileset and convert it to seperate 16x16 images, and using that to replace your regular tileset. Now what if you used this technique to import a tileset of 512, 768, or 1024 tiles into DCME (which would convert each tile into a seperate image of its own) and it would be treated just like a regular tileset?

 

Wait! How would I define the special effects of tiles (such as Fly Under, Fly Over, Solid, Warp on Contact, Bounce or Stop Projectiles, No Bricks, Remove Projectiles on Contact, etc)? Well this is where DCME could come in. DCME could have an "LVZ Mapping" mode and a "Normal" mode (Normal mode being what it is now).

 

You would import your tileset (it would be the same width as a standard tileset, but a height having any multiple of 16 pixels), which would then be your tileset palette (just like your Normal mode, standard tileset). Select a tile and select a special affect, then map away!

 

This is how it is done. DCME stores the tileset data in a special LVL file (that cannot be executed by Continuum or Subspace). Pretty much this is exactly like LVL but with the exception of the tileset dimensions, size, and special affects. This is written almost in DCME's own fancy language. One cannot just save this and test it in Continuum. How this works is that when one is ready to test it in Continuum, they must "compile" the map. When they compile the map, DCME will first take the tileset and split each tile into its own 16x16 image. All the tile images will be stored in atleast one LVZ file. Then DCME will go through and place blank tiles of appropriate special effect under your LVZ tiles appropriately.

 

There are 17 different special effects. Infact, here is how the right panel of DCME could look like in LVZ Mapping mode:

 

<!-- START ILLUSTRATION -->

.____. .____.	 .____.
|_->_| |	|	 |	|
   |	| <-> |	|
   |____|	 |____|



			Tileset
._____________________________________. ._.
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| |^|
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| |-|
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| |#|
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| |-|
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| | |
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| | |
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| | |
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| | |
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| | |
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| | |
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| | |
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| | |
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| |_|
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| |V|

		   Wall Tiles
._____________________________________.
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|

			Generic
		 .___________.
		 |_|_|_|_|_|_|



 Door	  Door
._______. ._______.
|_|_|_|_| |_|_|_|_|



Map Border
._.
|_| Classic 1-Tile
|X| Custom Bordering
 -



Translucancy

(_) Opaque (Black tiles will not be transparent)
(_) Transparent (Black tiles will be transparent)



Inanimate Tiles

(_) Solid (Tile 1)
(_) Safety (Tile 171)
(_) Goal (Tile 172)
(_) Fly Over (Tile 173)
(_) Fly Under (Tile 176)
(_) Visible on radar, ships can go through, items bounce off or suspend  inside, thors go through (Tile 191)
(_) Visible on radar, ships can go through, removes items upon contact (Tile 241)
(_) Invisible on radar, warps ship on contact, items bounce and thors removed (Tile 242)
(_) Solid (Invisible on Radar) (Tile 243)
(_) Invisible on radar, limits green/flag/brick spawn (Tile 254)



Animate Tiles

(_) Small Asteroid (Tile 216)
(_) Large Asteroid (Tile 217)
(_) Space Station (Tile 219)
(_) Wormhole (Tile 220)
(_) Fly Under (Tile 255)
(_) Enemy brick: Invisible on radar, items go through, ship gets warped by time (Tile 252)
(_) Team brick: Invisible on radar, items and ship goes through (Tile 253)



Animation List

/-------------------------------------\ ._.
| ------- -------			  | |^|
| |worm | |custo|			  | |-|
| |hole | |m ani|			  | |#|
| |anim | |m 4wh|			  | |-|
| ------- -------			  | | |
| ------- -------			  | | |
| |worm | |custo|			  | | |
| |hole | |m ani|			  | | |
| |anim | |m 4wh|			  | | |
| ------- -------			  | | |
| ------- -------			  | | |
| |worm | |custo|			  | | |
| |hole | |m ani|			  | | |
| |anim | |m 4wh|			  | | |
| ------- -------			  | |_|
\-------------------------------------/ |V|
									 -
   ._____. ._____. .________.
   | Add | | Use | | Delete |
   ------- ------- ----------

___________________________________________



 Position:	 X= 0 - Y= 0 (A1)
 From:		 X= 0 - Y= 0
 Size:		 1 x 1
/-----------------------------------------\
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
|					  |
\-----------------------------------------/

<-- END ILLUSTRATION --!>

 

The only thing that should not be in the above illustration are the following kind of things:

> (Tile xxx)

> Any form of description such as... "Visible on radar, ships can go through, removes items upon contact"

 

The tiles with descriptions like these have no name. We need to assign one that fits just right, and one that VIE might approve of if they were still in development of Subspace.

The (Tile xxx) is for whoever is going to code this into DCME. Those are the tiles DCME will use when it compiles the map. If you selected the bubble for [inanimate Tile, Solid], then when it gets to the part where it will lay actual tiles from the normal 128/256 tileset (that Continuum recognizes), it will use Tile 1 for this kind of LVZ Tile. If you were to open the final result in SSME or DCME, you would only (if at all) see black tiles in the map and perhaps DCME's default graphics for things like the Wormhole, Asteriods, and the Spacestation. There isn't really any decompiling into this thing, unless you went through some intensive coding to make a decompiler in DCME (that would take an LVZ and LVL file, and do its best to recognize and convert to an LVZ Map).

 

An LVZ Map (uncompiled) could be in the file format such as *.lvlz or *.zlvl or *.lvzl. Atleast something that makes sense or reasonable to use. The LVZ Map will be different from the LVZ features in DCME alone, while in LVZ Mapping mode. LVZ Map material will be treated like normal tiles, as if Subspace/Continuum really did support such abilities. LVZ will be apart from LVZ Maps. The LVZ Map file (uncompiled save) will be much like a standard LVL, but with a few exceptions and limitations removed. Then when it comes to compiling, it will take the tileset itself and find all the tiles that were used in the map. After finding all the tiles used in the map, it will take those and turn each of those tiles into a 16x16 image of appropriate compression and extension. Then it will place those images where you tiled them in the LVZ Map file (uncompiled), so that it would look exactly the same in Continuum as if you were looking at the LVZ Map (uncompiled) file itself.

 

There are two layers to this: LVZ and Map. After it has laid the LVZ Tiles down into their proper locations on the grid, it has finished the LVZ layer (which is above the Map layer; aka Above Tiles). Next is the Map layer. In the Map layer DCME will take the (Tile xxx) of each tile in the LVZ Map (uncompiled) file and place that accordingly under the LVZ tiles.

 

The whole Animation List part will only appear if you select something from the animate list. If you do, it will make this section of the panel appear. It is like a file browser, only that these are actually (and literally) saved into the LVZ Map file itself when you add something. The default animation of something (ie. wormhole, spacestation, asteroids) should be built into DCME. In this file browser, it will have it laid out like icons Windows XP. These icons are the size of the tile we are dealing with, and are animated (to clarify that: these ICONS are ANIMATED). You can add as many animations of the specific animate tile you have selected as long as your system has the harddisk space, CPU power, RAM, and video acceleration power to handle it.

 

When you select an animation (click on it), its thick borders will turn some color. When you click on Use while having the animation you want to use selected, it will change the border to something like pure blue (0 0 255). When you put this tile on the map, it will by default not be animated. There should be a toggle icon somewhere in the toolbar that toggles whether animation-capable tiles are animated or inanimate at their first frame. When you Add an animation, you can browse your PC for any image. It must have the correct dimensions for each frames for the tile you have selected (so you can't have twice the size of the Large Asteroid and try to use this animation for the small asteroid; for small asteroids, you have to have an image where each frame is 16x16, and you must have the frames in the image ordered exactly as they are in the default Continuum graphics).

 

The doors: you should be able to select a tile from the LVZ Tileset, then select one of the 4 boxes for any of the two Door tilesets. Whatever tile you had selected from the LVZ Tileset will go into the tile box you selected in one of the door tilesets. Whatever you put in these boxes will actually be going onto the Normal Tileset (the one that Continuum recognizes). See TilesetNormal.bmp; notice how only the doors and the turf flag are in that while everything else is black. What you put into the door tilesets in the above illustration, is exactly what goes into this tileset file. This tileset file will be the tileset of the compiled *.lvl file.

 

For map border. You have two options: either to put a tile into the first option to use as your map border, or select the other option. The first option is NOT a checkbox -- infact it is just like the above Door tileset pairs. Just select a tile and click on this tile box (it will show the tile itself in this box). If you check the second option, it will gray the first option and make the first option unusable until you uncheck the second option. If you have the second option checked, Tile 20 (the tile used for map border) will be black, like the rest of the normal tileset.

 

Now I will carefully illustrate what specific LVZ render layers will be used for each tile option. The following illustration is NOTHING in DCME, but a random and generic text illustration:

 

<!-- START ILLUSTRATION -->

// Here are my choices:
// BelowAll, AfterBackground, AfterTiles, AfterWeapons, AfterShips, AfterGauges, AfterChat, TopMost

Inanimate Tiles

(_) Solid (Tile 1)
// AfterTiles
(_) Safety (Tile 171)
// AfterTiles
(_) Goal (Tile 172)
// AfterTiles
(_) Fly Over (Tile 173)
// AfterTiles
(_) Fly Under (Tile 176)
// AfterShips
(_) Visible on radar, ships can go through, items bounce off or suspend  inside, thors go through (Tile 191)
// AfterTiles
(_) Visible on radar, ships can go through, removes items upon contact (Tile 241)
// AfterTiles
(_) Invisible on radar, warps ship on contact, items bounce and thors removed (Tile 242)
// AfterTiles
(_) Solid (Invisible on Radar) (Tile 243)
// AfterTiles
(_) Invisible on radar, limits green/flag/brick spawn (Tile 254)
// AfterTiles



Animate Tiles

(_) Small Asteroid (Tile 216)
// AfterTiles
(_) Large Asteroid (Tile 217)
// AfterTiles
(_) Space Station (Tile 219)
// AfterTiles
(_) Wormhole (Tile 220)
// AfterTiles
(_) Fly Under (Tile 255)
// AfterShips
(_) Enemy brick: Invisible on radar, items go through, ship gets warped by time (Tile 252)
// AfterTiles
(_) Team brick: Invisible on radar, items and ship goes through (Tile 253)
// AfterTiles

<-- END ILLUSTRATION --!>

 

As you can see, most of them are just AfterTiles. I'll talk about how we can use the other LVZ options to advantage later. Right now is not appropriate to talk about it.

 

Now as for LVZ tilesets and limits. The maximum width should be 160. The maximum height should be no more than 2048 pixels (and heights must be a multiple of 16). You might say 2048 (128 rows, 19 tiles per row) is quite a large amount of LVZ Tiles, and possibly that no one would ever need that many. Don't say that, please. You and I may not, but you never know. I think a lot of us have hit some limits with Continuum now that we did not just a few years ago..only because we had not gone that far yet. Someone out there might have a use for that many, and again it completely depends on whether someone's machine could handle this or not. Compared to standard LVL files, I think to certain degrees (depending on numerous things) LVZM will be smaller and bigger in filesize. But you know what? Most people nowadays have stronger connections and computers than they did years ago. Continuum should be able to handle all this. DCME must be aware of some LVZ limits before and while compiling. DCME must know the maximum filesize per LVZ, maximum number of loadable LVZ files, maximum characters per LVZ filename (including extensions), etc. It must appropriately compile (and/or generate) the LVZ files and the LVL file. Compile times are based upon the power of the machine compiling it.

 

LVZ overrides may be possible. Infact maybe there should be a compiler option where it will compile it for an LVZ-Override based compile or not. If not, then it will be where you have to put the .lvz into the settings *.cfg file(s). If it is override, it may give Subgame players an advantage to certain spectrums (such as possibly loading more LVZ content, greater filesizes, or basically exceeding a few Subgame limitations). To ASSS, the override would only be a disadvantage. The purpose of this is so that atleast ASSS and Subgame servers can take advantage of LVZ Mapping one way or another.

 

One thing I forgot to mention. When you select a tile and its effect, DCME will cache that into the *.LVZM file. Say you draw two lines. One of the lines uses Tile 631 with the Solid effect, while the other line uses Tile 122 with the Fly Under effect. First you draw the one with Tile 631. Then you select the Tile 122 and its effect, and draw it. Now you select Tile 631 -- instead of having to select the effect again, the previous effect you used for that tile will still be there. When you save your LVZ Map (*.LVZM), it will cache all these small details into the file itself so that next time you load it up, you won't have to go back and reselect a few effects.

 

A new tool option for this mode, specifically. The eyedropper should have a part in the toolbar where you can select how it will "eyedrop" for you. You should be able to have it "eyedrop" by only selecting the LVZ Tile, the Tile Effect, or Both.

 

What about black pixels (0 0 0, #000000) being opaque or transparent? Ask Aquarius -- he should have some insight on how this could be done. I believe he was the one that told me that there is a way to do this without changing the RGB to (1 1 1) and stuff. By the way, I could almost swear that even (1 1 1) would be interpretted to be a transparent color by Continuum. I remember making the LVZ Scoreboard for DBZ and having problems with this. I couldn't even use (1 1 1), which came to my surprise. Once you find/figure out how to do transparency/opaqueness for black pixels, I think there is a possible advantage to this for a few tiles. Since the normal tileset will mostly be black, whatever parts of it will be opaque in Continuum will simply be opaque -- not something that can be changed (unless you find another tile with the same properties that supports transparency).

 

As for the brick and green-prize tile; unfortunately there is a nasty twist to this. DCME should have something somewhere about replacing the brick and prize graphic (through LVZ) with a completely blank (black, 0 0 0, #000000) graphic if you use a custom animation. By default when you have an animate tile selected, it will have the default Continuum animation as the one selected and "Use"d. That should actually be the third icon in this little animation browser. The first icon should be some generic "NO IMAGE," and the second an "INANIMATE TILE" picture. If you select INANIMATE TILE, it will somehow let you choose which tile you want, and just generate an LVZ graphic replacement (upon compilation) using the tile you selected. It should ask whether it should resize the tile to fit the frame dimensions or just loop/repeat the tile in each frame dimension. It would look like it was animate (might be weird, but who knows).

 

The Generic Tileset category will contain the following: Small Asteroid #1, Large Asteroid, Small Asteroid #2, Space Station, Wormhole, Eraser. Eraser isn't really a tile, but whatever. It's a function and I don't think people will mistake it for a tile. This pretty much contains all the "tiles" that are animated. The LVZ Tileset is pretty much a raw tileset without any set order (such as Tile 20 in the LVZ Tileset being a border tile; there isn't any of this). The LVZ Tileset has no properties. The mapper sets the properties through available options after selecting a tile or animation.

 

Of course, they may be one or two more steps involved in this process compared to Normal Mapping, but I think it is well worth it. I think if it is programmed and designed correctly (including it being extremely newbie friendly, with the least amount of time required to learn how to do something) it has a chance to revolutionize Continuum. There are so many more options out there if this can be done through a map editor with a map editting perspective. There wouldn't be a 128/256 tile limit (there would, but we would emulate out of it through LVZ).

 

All that I have said above is the first stage to getting this "second-half" into DCME. The whole start to it all. The following is future stages, ideas, comments, etc.

 

As time goes, optimizations could be made to how DCME compiles it. Maybe DCME in the future does not need to individually split the tileset up into 16x16, but perhaps generate a 1x16 (tile-wise) part of a wall using one tile (this would be usually more efficient than do have more wasted bytes in the INI file of the LVZ for each tile). The INI will be the largest part of one of these LVZ files. Infact, if all the images could be loaded into one LVZ while another LVZ is made almost entirely of an INI file alone, that would be even more efficient. Store all the images in one or so LVZ files, and have one or so LVZ files for the INI (containing the coordinates and stuff of each tile/map object).

 

I said that I would talk a bit about the other LVZ layer options. Maybe in the future there could be an additional, third mapping mode called "LVZ Mapping (Advanced)" or "(Expert)." The interface might be a bit more cluttered, but hey -- it is the Advanced or Expert mode to LVZ Mapping. In this mode in the right panel where you select the tile effect, there might be an Advanced/Expert Effects category, where an individual could select a specific LVZ layer mode.

 

 

 

 

 

Flags (Turf and whatnot) and Doors cannot be done by LVZ. It requires additional programming that is unrelated to DCME. ASSS, a Bot, or something could be coded to handle this stuff. What would be handled is when a door turns on and off, and to whom and what a flag looks like when captured and uncaptured. This can be left to other people to do; it is not DCME's job to handle this. So in short conclusion, doors and flags will pretty much be unchanged. This is some previous note I jotted down:

If you wanted to do flags, you would have to have a Bot or something to change the animation at exactly the right frame between Team and Enemy captured animations.

If you wanted to do doors, you would have to have a Bot or something to toggle the animation on and off whenever doors opened and closed.

 

Guess how long it took me to write this up.

Edited June 24, 2007 by L.C.

[Dav]

problem is wont that many lvz make the FPS rate of the game quite laggy?

[L.C.]

Instead of a tile-to-tile when it compiles, it could compile the LVZ Map by simply taking a screenshot of the entire map (one big image), and split it into any defined image sizes (ie. 512x512 images). !@#$%^&*uming that most of the map will be just solid tiles, it's a big plus for solid tiles.

 

So it could take each of the 17 effects and make one big full-map screenshot of them. Then size down the canvas to the lowest possible. Then chop the image up into any defined sizes (32, 64, 128, 256, 512, 768, 1024 squared; etc. Anything with a multiple of 16). I think this might be more FPS efficient compared to Normal Mapping if this is how LVZ images are compiled. -_-

Edited June 25, 2007 by L.C.

[L.C.]

Here's an example.

 

This is the center safety of SSCI Dragonball Z, probably one of the most FPS draining parts of the map. On 1280x1024 with my 6800XT (256MB GDDR2 AGP), I would get 22 frames per second and below just hanging around center safety. After I overclocked the card from 300mhz/525mhz (GPU/Memory) to 350mhz/625mhz, I would usually get 40 and above (44 on average). Now I took the center safety and chopped it up accordingly. I saved each image as _x-y.gif. Where is obviously the LVZ layer it is set to; x is the numerator and y is the denominator for the total number of the same LayerMode LVZ-Maps. Since each image had less than 256 different colors, I got the advantage to have Photoshop save these GIFs with indexed colors (meaning that whatever different colors these images have will be the color palette in the saved GIF itself - as long as it is under 256 colors though; 256 is the max GIF can hold according to Photoshop). If you were to exceed 256 colors, the way I would sometimes do it is same one in GIF, JPG, PNG, and maybe some other supported format. Then compare the filesizes and qualities to determine which one is the better pick from the format to use. DCME should do likewise to provide the most efficient, the least demanding in space, LVZ-maps.

 

So I test this out. From the very center of the safety, I get a grand 20+ more FPS than I would with Normal-Maps. And around the whole structure, I get an additional 20 to 100 frames per second. Compared to flying around the safety with Normal-Maps, the LVZ-Map skyrocketted my FPS above 100 fps here and there. Infact I did not even get past frames per second with the Normal-Maps just flying around the safety. As for AfterBackground_1-1.gif, I didn't even need to include that there, since it was pretty much 100% black. I'm too lazy to go research about the opacity and translucancy.

 

Download the test map (only contains LVZ-Map) from http://www.hlrse.net/Qwerty/LVZMapping.rar

Edited June 25, 2007 by L.C.

[Samapico]

I didn't read it all yet... but if it's what I think, I see a big problem with this...

 

So if I get it right, you'd like to have all graphics handled by LVZ's... like each tile would be a 16x16 tile instead... And we'd just lay a black or transparent solid tiles under the needed lvz images...

 

BUUUUUUUT....

sadly, we can only define 255 different images in a LVZ (that is the total of all lvz's used in a single arena, so splitting lvz's won't help)

 

And yes, tiles affect more FPS than larger lvz images... a bunch of smaller lvz images wouldn't change anything though. But the fps issue is only a concern when alot of flyover or flyunder tiles are needed anyway

[Smong]

That is really long so I just skimmed it and read the replies.

 

I don't see any point adding more 16x16 tiles through lvz or any other means. Lvz and map editors already let you place map objects of any size anywhere on the map. If you have experience with other games/image editors you may know each image as the equivalent to a "prefab" or a "brush".

 

The 255 image limit, while I'm not an expert on this I would imagine it is per lvz file.

[Samapico]

no it's not per lvz... when the client loads lvz's, it reads all images definitions from all lvz's and re-!@#$%^&*ign them Image# from 0 to 255...

 

For that reason, you can safely have 2 IMAGE0 definitions in diffrent lvz's, cause the client will re-!@#$%^&*ign those ID's anyway.

 

source: !@#$%^&*S Wiki - LVZ

Continuum only supports 256 different images in all of your lvz files combined. If you exceed this limit, toggling the 257th image will turn on the 1st image. This is often undesired, so be careful.

[L.C.]

Well, yup..you guys did miss detail. I think I later mentioned that a better idea instead of 16x16 tiles and hundreds of entries was to take screenshots of the entire map for each effect, then split it into smaller images if necessary. Load up a single LVZ as much as possible before making LVZM1, 2, 3, etc.

 

Post #3

Instead of a tile-to-tile when it compiles, it could compile the LVZ Map by simply taking a screenshot of the entire map (one big image), and split it into any defined image sizes (ie. 512x512 images). !@#$%^&*uming that most of the map will be just solid tiles, it's a big plus for solid tiles.

 

So it could take each of the 17 effects and make one big full-map screenshot of them. Then size down the canvas to the lowest possible. Then chop the image up into any defined sizes (32, 64, 128, 256, 512, 768, 1024 squared; etc. Anything with a multiple of 16). I think this might be more FPS efficient compared to Normal Mapping if this is how LVZ images are compiled. -_-

 

It can be done. Forget about the whole 16x16 per tile/per lvz/per whatever thing.

 

 

EDIT :: And to mention that not only would it be more FPS efficient compared to normal mapping, but it would be more efficient than to have all your tiles as a 16x16 image per tile in the LVZ. I would find it a bit hard to believe if it couldn't be done in under 256 different images like this, especially if you're using somewhere between a maximum of 768 to 1024 squared screenshot/image sizes. Look at my example LVZ-map to get an idea what I mean.

 

If you haven't looked at the LVZ Map Example I gave and read the above details, then you're outdated from this topic. Catch up.

 

 

EDIT2 :: If you think 128 customizable tiles is enough, then that's you. For ages I have been wishing for more tiles. After gaining access to the next 128 through DCME, that was only part of a relief...until I found out that you can't customize those tiles, which makes almost all of the extra tiles 100% useless. This is for the sake of efficiency, variety, and larger and more optimal tilesets. If you made a small base entirely of Solid LVZ tiles that is the size of 1024x1024 pixels, then what DCME would do is take a screenshot of that base as a 1024x1024 image and turn it into one LVZ graphic. Then it would do the rest of the compiling that needs to be done. -_- I feel now that I have fully clarified this well enough that I'm sure you can understand it perfectly fine. :X

Edited June 26, 2007 by L.C.

[Samapico]

Well, yup..you guys did miss detail. I think I later mentioned that a better idea instead of 16x16 tiles and hundreds of entries was to take screenshots of the entire map for each effect, then split it into smaller images if necessary. Load up a single LVZ as much as possible before making LVZM1, 2, 3, etc.

can you imagine how huge the total filesize will be? Instead of having to load a 304x160 tileset, you need to load maybe 20 1024x1024 images

your lvz is 75k for a small section... A map could easily need 20 of these sections. That would be 1.5MB for a map that would normally be ~100k

 

And the limit is 256, not 128. However, if you use 256 tile-images, you can't have any other image in your map anywhere...

I think having a couple of customizable tiles would be a nice idea... And you don't need hundreds of them :/

[L.C.]

you need to load maybe 20 1024x1024 images

Not unless you used all 1048576 tiles up. If you drew a lines in the middle of nowhere that is 1x16 (units) and is AfterTiles, then it would make a single screenshot of it. And depending how far away you make another structure/object, it might decide or not to include that in the same image.

 

Indexed Colors on GIF makes decent compression (but isn't always the best extension to use), and since we're mostly dealing with 256 colors it also makes a big plus.

 

can you imagine how huge the total filesize will be?

 

And the limit is 256, not 128.

Of course it is, but I partially disagree for the fact that about 95% of those extra tiles are 100% useless. Only a few of them can be used for their special effect (although brick and prize has a tile graphic of their own). As I recall, you (or Samapico) had told me that it isn't possible to change this. Maybe you should just cut out the majority of the useless tiles in the extra tiles to reduce the size of the tileset in DCME.

 

You wouldn't literally have 20 1024^2 images. DCME would make the images as small as possible by cutting out unneeded margins of pure black (unless there is a tile in there with Translucancy turned off / Opacity on) and saving it in 1 to 3 different formats (hidden; only might do this for filesize and quality comparison).

 

Some people would rather spent extra bytes to have greater performance and abilities (such as being able to assign an effect to any tile on their tileset, which is the way it should have been done in the first place).

 

that would normally be ~100k

A map could easily need 20 of these sections.

Optimization. DCME cuts out unnecessary parts of the image and does whatever it can to get the best quality and best (lowest) filesize.

 

And you don't need hundreds of them :/

Whatever. I need a lot more than 128. The complaint I've had personally for atleast 5 years has been that "128/256 tileset is way too fricken small; I need more tiles with different effects!" Since when did you and Samapico actually start playing Subspace/Continuum and getting to know everything about it? :X (I don't doubt it, but the last time I saw a response to this was that you guys didn't know too much of anything in Subspace, but atleast enough to start off a simple map editor.)

 

 

 

Atleast give it an experimental try. -_- If you've got nothing better to do and is too lazy to fix some bugs and glitches...

[Samapico]

And the limit is 256, not 128.

Of course it is, but I partially disagree for the fact that about 95% of those extra tiles are 100% useless. Only a few of them can be used for their special effect (although brick and prize has a tile graphic of their own). As I recall, you (or Samapico) had told me that it isn't possible to change this. Maybe you should just cut out the majority of the useless tiles in the extra tiles to reduce the size of the tileset in DCME.

I was talking about the limit of the number of different LVZ images. So it would be possible to add 256 customizable tiles...

You wouldn't literally have 20 1024^2 images. DCME would make the images as small as possible by cutting out unneeded margins of pure black (unless there is a tile in there with Translucancy turned off / Opacity on) and saving it in 1 to 3 different formats (hidden; only might do this for filesize and quality comparison).Some people would rather spent extra bytes to have greater performance and abilities (such as being able to assign an effect to any tile on their tileset, which is the way it should have been done in the first place).

The performance isn't much of a factor. !@#$%^&*igning effects to tiles can be done another way, keep reading

 

 

And you don't need hundreds of them :/

Whatever. I need a lot more than 128. The complaint I've had personally for atleast 5 years has been that "128/256 tileset is way too fricken small; I need more tiles with different effects!"

Actually... there are 190 normal tiles, not 128.

 

Since when did you and Samapico actually start playing Subspace/Continuum and getting to know everything about it? :X

(I don't doubt it, but the last time I saw a response to this was that you guys didn't know too much of anything in Subspace, but atleast enough to start off a simple map editor.)

wtf? who said we don't know anything in subspace?

 

 

I like the idea of adding custom tiles !@#$%^&*ociated with lvz's... but implementing it with large images isn't the way to go imo... For the small fps upgrade, it's not worth the complexity of coding such a thing... and it will be impossible for the developper to plan the number of images used by his 'tiles'. The limit of 256 different images in ALL lvz's used by a map is often a big factor.

What I'd do is add another tileset that allows you to setup 256 things. I say things... because they could be simple images of any size... or tile-sized images to which you !@#$%^&*ociate a tile# that will be laid under it everytime you use it... or even a larger image, say 10 tiles x 10 tiles, to which you !@#$%^&*ociate a pattern of tiles that would go with it.

So if you want to optimize fps, you could create your own big sections where needed.

Actually, the whole mapobjects thing could be done that way. You'd setup your mapobjects in that... virtual tileset... or imageset... or... bleh it would need a cooler name.

hm, it should be possible to setup more than 256 of those, if some use the same images with a different tile setup.

 

This would allow for even more flexibility, as you could have a 100 tiles x 100 tiles image, and define all the tiles needed to fit it

[L.C.]

wtf? who said we don't know anything in subspace?

k that's not what I meant. Nevermind about it. :S

 

there are 190 normal tiles, not 128.

I was being very vague.

 

ut implementing it with large images isn't the way to go imo... For the small fps upgrade, it's not worth the complexity of coding such a thing

Don't you think it'd be worth it for having the ability to have whatever effect for whatever tile you want?

 

The last part of your reply kind of confuses me. :?

 

No hard feelings, by the way. :\

Edited June 27, 2007 by L.C.

[Samapico]

Don't you think it'd be worth it for having the ability to have whatever effect for whatever tile you want?

defining preset tiles to go with mapobjects would do just the same, and allow to easily repeat patterns and such

 

The 'hard' part to code I speak of is if you put parts of map in larger images and optimize to have relatively small images... That would get very complex to code, and would cause huge compatibility problems of all sort... Even saving and loading a map the same way it was would be hard. Plus, as I said, the developper loses all control over the number of images used in his tiling.

 

Instead of that, I'd simply change the whole way 'mapobjects' work... They'd not only be an image, but also have tiles !@#$%^&*ociated with it (if you want to)

and... perhaps you could even lay them the same way you lay tiles (i.e. draw lines, filled rectangles... etc.)

[Smong]

no it's not per lvz... when the client loads lvz's, it reads all images definitions from all lvz's and re-!@#$%^&*ign them Image# from 0 to 255...

I think it does this per-lvz, not one pool for all lvz. Image#'s do get renumbered, but only because their original numbering isn't stored in the lvz, it's implied. Buildlevel even adjusts image#'s in your screen/map object definitions to match any renumbering of the image#'s.

 

For that reason, you can safely have 2 IMAGE0 definitions in diffrent lvz's, cause the client will re-!@#$%^&*ign those ID's anyway.

I think you are allowed two IMAGE0's because cont first looks for an image match in the same lvz file, if it can't find one it will fallback to all other open lvz files.

 

source: !@#$%^&*S Wiki - LVZ

Continuum only supports 256 different images in all of your lvz files combined. If you exceed this limit, toggling the 257th image will turn on the 1st image. This is often undesired, so be careful.

What this could mean is you can't address more than 256 images since it's restricted by both the lvz format and the network protocol (8bit datatype). When you send an "image change" command you are sending both an object id and the image to change to. !@#$%^&*uming the simplest case, the object id being unique across all open lvz, then cont will try and change the image to one that is in the same file the object came from, if it fails it will fallback to other open lvz files.

 

Edit:

After some testing I have decided on several things:

- New !@#$%^&*umption: If cont can't find an object's image in the same lvz file it does not fallback to other lvz files. I haven't proved this, only seen buildlevel throw an error when you try and use an object with an image that hasn't been defined.

- There's a max of 255 image#'s per lvz, you can put more in but cont will reject all the script in that lvz file, I didn't check if it rejects the entire file (including any replacement graphics).

- There's a max of 256 images internally (so what I originally said above was wrong). Once all slots are filled anymore images are discarded. This limit was probably put in so resolving objects to images happens in a finite amount of time, not sure why it is so low though, imagine if the weapon limit was 256 weapons.

Edited June 27, 2007 by Smong

[L.C.]

That's the problem with Continuum nowadays. PriitK should just get back onto his arse and "unlock" Continuum to give it a few more years. All the limits we now know (in my opinion) are too small. You would probably disagree, but the 190/256 tileset is way too small, and so is the different special effects that you can assign to a number of tiles (it would be nicer if the mapper could just choose one), the maximum map, news, graphics, and LVZ filesize limits, the fact that the news is plain/rich text without any support for some decent limited or restricted HTML (maybe even BBCode with some things like [backgroundcolor]), more than 256 maximums, etc. Perhaps "unlimited" as long as the machine can handle it. He should even add in an entry to the server.ini that could control maximum Subgame upstream and downstream speeds, and maximum upstream and downstream speeds per user, and even just a simple HTTP content server ability (this would be more efficient than Subgame, because then Subgame might be losing precious bandwidth to downloaders while peole might be playing). Edited June 27, 2007 by L.C.