Guest WiseCherub Posted April 13, 2004 Report Posted April 13, 2004 Ok, I don't pretend I know lots about SS mapmaking, but I notice a limitation and its to do with Tilesets. I think the tileset limit is like 256? Sort of the same idea of character sets or FONTS. Does anyone know or think it could be done for future revisions of Continuum? Like have a limit of 2^16 different tiles limit. 65000 different tiles should be more than ample for generating some real nice maps. Perhaps there is a way to increase the tileset quan!@#$%^&*y, I don't know myself.
Yupa Posted April 14, 2004 Report Posted April 14, 2004 you can have as many 'tiles' as you like using .lvz and traditional tiles check out http://shanky.com/server for more info on .lvz
Dav Posted April 14, 2004 Report Posted April 14, 2004 although a larger base tileset would be a nice addition
Yupa Posted April 14, 2004 Report Posted April 14, 2004 would be a waste of programming time better to make everything .lvz along with an editor to make the combination simple or make tileset size, characteristics, etc defined in a text file or something
Smong Posted April 14, 2004 Report Posted April 14, 2004 One way to store the map is as a 24bit .png image. This way it is compressed and you can have one type of tile per colour. You can even use one channel as modifier (fly over, etc). Maps can be edited with a paint program and could be any dimensions. Also easy to draw shapes and copy/paste. The tileset would of course have to be a separate image.
Grelminar Posted April 15, 2004 Report Posted April 15, 2004 The PNG format is actually quite flexible: it's easy to embed arbitrary data in a PNG file (in a new chunk type) and have it still be compatible with all programs. You'd have to make a special program to do the embedding of the tileset into the level file, though.
Guest WiseCherub Posted April 15, 2004 Report Posted April 15, 2004 Thanks for feedback concerning increasing tileset size, I'll look into this further. But whether future versions of continuum increase the tileset size the remains to be seen; that would be a good thing. Yes, of course you should know that in the end, the game needs to use raw bitmap graphics to do the tiling or graphics efficiently for a real time application. ps: funny sidenote, when I was looking into programming the Gameboy Advanced, its custom Acorn Risc processor has builtin lvz compress/decompress microcode.
Yupa Posted April 15, 2004 Report Posted April 15, 2004 the game needs to use raw bitmap graphics to do the tiling or graphics efficiently for a real time application...?
Telson Posted April 16, 2004 Report Posted April 16, 2004 the game needs to use raw bitmap graphics to do the tiling or graphics efficiently for a real time application...? Jpegs are just as good, dont even think about bm2 files I agree that it would be a waste of programming to increase the number of tiles.The more tiles on a map.. the more you lag.. That Dragon Ball Z Zone for exampleor ?go tankwars in 17th Parallel. Another thing about tiles is that players use them for the wrong reason. An example of this is.... WASTING 26+ tiles on font text. LVZs make tiles unlimited and more flexible...
Dav Posted April 16, 2004 Report Posted April 16, 2004 bmp is still large! png, gif and jpg are the best choice.
Himura Kenshin Posted April 16, 2004 Report Posted April 16, 2004 telson that is not true the more tiles on a map dont make you lag. I am working on making a map totaly out of a PNG file put it in a lvz then for tiles just use facts and no more tiling for me
»CypherJF Posted April 16, 2004 Report Posted April 16, 2004 actually, it depends. older machines more clumped tiles will cause the player to lag, as continuum and subspace didn't pre-render the soon to be seen map, so it has to redraw it each time (if i understood jeff p's notes, and what mr ekted had been talking ot him about)... yeah anywho, meh, anywho
Guest WiseCherub Posted April 18, 2004 Report Posted April 18, 2004 Do you all think that your graphic card's processor can just take jpg files and display as is? If you do, then your a newb programmer, sorry to say it. With graphic cards you have Video Ram buffer and it uses a bitplane format in RAW bit format. Then the RAMDAC (RAM to Digital to Analog Convertor) just scans/refreshes through this video ram buffer and converts them to analog voltage signals so you get display on your monitor. So if you use jpeg, png..etc graphic formats, the cpu must in the end convert these graphic formats to bitmap format. Thus, taking unnessary cpu cycles in a real-time application (a video game). I'm only arguing with the point about graphic cards being able to directly interpret jpeg, png..etc graphic formats, which is false. But I agree get rid of bitmap format, and make sure when the game initializes it converts the jpg image to bitmap format only once.. not every 1/60th of a second or so. Now some will say, well computers are so fast we can now get away with this. Naw, you just a lazy bloatware programmer. Sadly, the Newest generation of computer programmers don't have respect for the hardware that makes their code possible.
Yupa Posted April 18, 2004 Report Posted April 18, 2004 telson that is not true the more tiles on a map dont make you lag. I am working on making a map totaly out of a PNG file put it in a lvz then for tiles just use facts and no more tiling for me tiles and lvz-placed images are almost exactly the same thing
»nintendo64 Posted April 29, 2004 Report Posted April 29, 2004 if you cannot reply with something useful, then don't. It's annoying to be reading a thread just to find this insults a long the way. -nintendo64
warhunter Posted May 17, 2004 Report Posted May 17, 2004 No SuSE, its not the same. Continuum draws all the tiles as well as the .lvz bitmaps. Its much more on the system to draw all those bitmaps on top of other tiles. Just try to make a map using 256 bitmap images, and 1 tile to denote walls. You will see how much more it lags. If you place a 16x16 bitmap directly over a tile, Continuum still drew that first tile, so its 2 times the work, for essentially the same effect. So increasing the tileset size WOULD be good. It will increase map file size though, but thats not too big of a deal with all these broadband connections.
Yupa Posted May 18, 2004 Report Posted May 18, 2004 it's hard to believe you bumped this old--*BAD WORD*- thread, but here we go No SuSE, its not the same. and? I said: tiles and lvz-placed images are almost exactly the same thing about increasing the tileset... allowing for an easy way to have more tiles would be good, yessimply increasing the size of the .bmp file used for tilesets, however, would be a lame waste of time compared to a more elegant solution
»ZiGNoTZaG Posted May 21, 2004 Report Posted May 21, 2004 a modern brand name video card should have no problems displaying tons and tons of lvz images. as long as you keep them small. and im not talking 200$ card. im talking 40 buks, older gforce or radeon with like 64 meg of ram. continuum is quite capable of displaying alot of graphics. will it run the same as 256 color 8-bit old school crap looking vie type zone? of course not. will it still have acceptable frame rates and look so much better? yes. i put up for example any zone that displays a solid BG image. they run fine. well at least they do on my geforceMX-440(nothing special). now if you can tile the whole back and still have it run smoothly, then there is nothing stopping anyone from placing a few lvz tiles over the standard tiles. in this way you get as many tiles as you want. and im willign to bet, if done in a thoughtfull manner, the player wont be able to tell you whats what. having to draw 2 16x16 images, instead of 1 isnt going to kill performace. maybe what really should be thought about is the way cont handles the drawing of things.such as not drawing tiles that are covered by LVZ.
»ZiGNoTZaG Posted May 22, 2004 Report Posted May 22, 2004 sorry to DP but a few more reasons why this a bad idea. first, jpgs and other images are almost always preconverted from jpg or whatever to an array of bits when you intialize the program. basically if you load an image onto a directdraw surface such as a backbuffer, it is allready a bmp. and since in most games this loading occurs before it acttualy has to display it, this is a moot point. only bad game design would make this a problem. not that i could do better, but i can see the flaws. whats more, ive seen no perfomace diffarance between the jpg and bmp versions of my EVO zone. which you can see below in my sig, doesnt fool around. onto the tiles, currently the map stores the tile in binary, meaning it uses structs of bytes to store the tile information. in one byte you can only store valid values from 0-255. so lets say you add 190 more tiles to the existing190. then you can no longer store the tileID in a byte. and who knows what deep implicaitons that could have on the whole rest of the program. not to mention increasing the map size by what could be double when all is said and done. at this point lvz keeps old SS and continuum two distinct beasts. no changes are made to ss that would affect the perforamce at this base tilelevel.
Recommended Posts