Custom Tilesets in Lemmix?

[Dullstar]

If you added the graphics directly in the levels, there *could* be oversized level files.

[The Doctor]

Is that not the point the previous three posts just tackled?

[EricLang]

If I use compression and include all graphics a level will be in between 20-40 KB.
Uncompressed will be much much bigger, because bitmaps use a lot of space (Lemmix uses 32 bits colors).
However, if I use compression the level-files will only be readable by Lemmix, which is a thing I maybe want to prevent. XML or inifiles are more transparent formats.

[ccexplore]

However, if I use compression the level-files will only be readable by Lemmix, which is a thing I maybe want to prevent. XML or inifiles are more transparent formats.

I'm not sure I follow.  The compression's mainly for the graphics right?  I'd guess that you can still get a reasonable size if you compress only the graphics, then the rest can still be uncompressed XML.

[EricLang]

That's true.
And yes, compression is mainly for the graphics.

[The Doctor]

Doesn't look like it.  This one, however, yes.d* be oversized level files.

No, actually it was. File size limitations, formats and methods to overcome them. Yes, those few posts before your own did tackle that issue.

Anyway...

I like the idea of compressing the graphics needed for each level into the level itself, with uncompressed XML. It sounds a bit like the Office 2007/2008 file format, which is essentially a zip file containing the resources and XML data for the actual document, and you can see the difference between a Word 2003/2004 and Word 2007/2008 document's file size is quite large in certain circumstances.

I still propose that level packs be one file containing all resources for all levels, so that if any levels in the pack share a particular tile (say, the crystals from the blue style), then it is stored once and referred to by all levels rather than have it present in every single individual file. It also keeps directories clean. (Nothing worse than going to play peoples' levels and you wind up unzipping more files from their pack than you have actual documents).

[Dullstar]

Never mind, those three WERE about size.

----------------------------------------------------------------------------------------------------------

Another idea would be to make it so that downloading the combined sets wouldn't be a huge problem.

{setname}_{terrainpieceID#}.{image format}
So, for, let's say the horizontal pillar in the Pillar set, or whatever you call it.

pillar_01.png

Why *.png?  No reason.  Just an example.

This would allow for custom tilesets.

A good idea would be to set up a tileset thing somewhere, too, for people to post their tilesets.

Such as, computer game tileset clones?  Like, cavestory-eggcorridor_01.bmp?
Or:  supermetroid-tourianruins_01.gif
sonic3andknuckles_sandopolispyramid.jpg

It would work great, and take less space in the long run!

[ccexplore]

It's possible to improve hard disk space usage by having the program automatically strip the bitmaps from a level you downloaded, and incorporate the bitmaps into some sort of "tileset store" where each bitmap is only stored once (so if you already got the bitmap from some other levels, no extra copies are stored).  The level editor can support the inverse, re-incorporating the bitmaps back into the level for the version of the level file that you upload to the web for others to play.

Although I still think hard disk space are comparatively cheap these days, so even a simple, naive,  wasteful approach should work fine.  If you're so out of hard disk space that you're only have a few dozens of MBs left, most likely Windows and other programs won't be running well anyway.

[The Doctor]

Still, do we want to commit to inefficiency for what could be a successful long term solution?

Also re: Dullstar's idea. That's how Lemmini currently works.

[Dullstar]

Exactly.  By the way, half the "huge level" argument is DOWNLOAD TIME.

Please read the recent posts in the thread, THEN post.

[The Doctor]

Yes, it can be so easy to forget that many many many many many many many many many many many many many many many many many many many many many many many ...

...

... many many many many many many people don't have fast broadband, or still have dial -up.

[Dullstar]

Exactly.

"HOLY ****!  IT'S A NEW FREAKIN' RECORD!  26.0 MPS!  AWESOME!"

And that about describes my...

Crap.  Down to 19.5.  Which is above average, actually.
I don't know if that's considered "slow" because I don't know what the general speed is, but that's just an example.

CRAP!  13.0 MPS at Very Low signal strength.

Translation:  Your Internet connection is connected, but it is low strength so Windows will lock you out of the Internet until you have gotten a better signal.

[ccexplore]

signal strength?  What exactly are you using anyway to connect to the Internet?

If you're relying on some random WiFi access point way outside of your house (eg. stealing some neighbors' WiFi, tsk tsk), then you get what you paid (in this case nothing) for.

[The Doctor]

By the way, any measurement of data transfer with an M in it (be it MB or Mb) is huge. Since MPS isn't a transfer rate, I assume you must mean something like KB.

And all of those speeds are indeed goshawful. >_<

But something I can sympathise with.

First rule of software development: you are not making the software for yourself, you are making it for the users. Those who may wish to play Lemmings may not have at least DSL.

[ccexplore]

Exactly.  By the way, half the "huge level" argument is DOWNLOAD TIME.

Please read the recent posts in the thread, THEN post.

Um, there are no posts in this thread that talked about download time until you mentioned it.

Thanks for making me waste time re-reading posts on the thread, Dullstar " title="Angry" class="smiley" />