Ravyne is right, color maps tend to be 16 bits in size. With no repeating tiles, this would lead to very poor file sizes.
There are 48 bit image formats out there, this could give you the extra layers you might need.
Storing Tilebased Maps in a PNG file. Any ideas?
Author
Well, I did some tests. I created a 500x500 fields "dummy map" with heavily differenciated field types on all layers. Means nearly no field is the same as its neighbours. (It would render out as nonsense-grain but the high difference will make it harder for the compression algorithms to squeeze the data). Find the image here.
Storing that data inside a PNG with my RGBA encoding resulted in a PNG file with a size of 288kb after optimization with OptiPNG.
Storing the data inside a JSON file resulted in a file with the size of 2.78mb - after a GZIP compression (which a HTTP server usually applies when serving the file), it came down to 1.09mb.
You see: even tough the PNG compression cannot work under its "natural conditions", it was still capable of recieving a MUCH better compression ratio.
Storing that data inside a PNG with my RGBA encoding resulted in a PNG file with a size of 288kb after optimization with OptiPNG.
Storing the data inside a JSON file resulted in a file with the size of 2.78mb - after a GZIP compression (which a HTTP server usually applies when serving the file), it came down to 1.09mb.
You see: even tough the PNG compression cannot work under its "natural conditions", it was still capable of recieving a MUCH better compression ratio.
This is an interesting idea. If you post this on github, let me know please.
When it comes to loading resources, you'll definitely want to take a look at Web Workers (if you aren't already using them).
https://developer.mozilla.org/en-US/docs/DOM/Using_web_workers?redirectlocale=en-US&redirectslug=Using_web_workers
When it comes to loading resources, you'll definitely want to take a look at Web Workers (if you aren't already using them).
https://developer.mozilla.org/en-US/docs/DOM/Using_web_workers?redirectlocale=en-US&redirectslug=Using_web_workers
Great topic, I have been thinking about this for a while now. Have you every heard of gif stockets? https://github.com/videlalvaro/gifsockets
Author
Yeah, I read about gifsockets on hackernews recently but I don't think you are able to make use of that. Basically a GIF animation is "streamed" from the server and I don't think you are able to access the single frames in that animation.
I also think you aren't even able to access the image object before the loading has finished, which will never happen with the gifsockets method.
@EmployeeNumber8:
Sure, web workers are interesting for processing the gathered resources, but this thread is more focused at how to transfer the information efficiently.
I also think you aren't even able to access the image object before the loading has finished, which will never happen with the gifsockets method.
@EmployeeNumber8:
Sure, web workers are interesting for processing the gathered resources, but this thread is more focused at how to transfer the information efficiently.
EmployeeNumber8 may have meant websockets, or webworkers in combination with websockets.
websockets are an interesting possibility, as the message is free-form* and the server could also push sections of the map to you pro-actively.
* websockets allow for both text and binary messages, however javascript itself has no "byte" type, and so there is no binary websocket communication to a javascript app. Text messages begin with 0x00 and end with 0xFF, with text in between, so you can use any encoding scheme that avoids premature 0xFF characters in the "string" of encoded data.
websockets are an interesting possibility, as the message is free-form* and the server could also push sections of the map to you pro-actively.
* websockets allow for both text and binary messages, however javascript itself has no "byte" type, and so there is no binary websocket communication to a javascript app. Text messages begin with 0x00 and end with 0xFF, with text in between, so you can use any encoding scheme that avoids premature 0xFF characters in the "string" of encoded data.
Using image editors as map editors is feasible with simple cases like Worms-like games with a few coded palette indexes (solid terrain, indestructible terrain, air, spawn point treated as air, etc.).
If, instead, there are multiple layers of many tile types, plus objects, plus many types of map field metadata, the map editor has to be a dedicated program, and PNG files will be an exported file format. Multiple aligned PNG files become feasible, and I suspect that multiple 1-channel files with separate data would compress better than a multichannel file.
If, instead, there are multiple layers of many tile types, plus objects, plus many types of map field metadata, the map editor has to be a dedicated program, and PNG files will be an exported file format. Multiple aligned PNG files become feasible, and I suspect that multiple 1-channel files with separate data would compress better than a multichannel file.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
