Server Help

Samapico · Posted: Tue Nov 21, 2006 6:05 pm Post subject: eLVL and 24bit bitmaps?

when saving a eLVL map... the bitmap header bfReserved1 field needs to be set to the location of the first byte of eLVL data, which is right after the bitmap...
bfReserved1 is an unsigned 16bit value (max. ~65000) ; for 8 bit tilesets there's no problem (it will be set to 49720) ; but for 24bit tilesets, it would mean we need to set that value to something like 145000, which is impossible.

Does that mean it is impossible to support eLVL AND 24bit tilesets at once? Or did I just miss something Ã´.o
_________________
(Insert a bunch of dead links here)

Smong · Posted: Tue Nov 21, 2006 6:42 pm Post subject:

I also noticed this a few weeks ago and it's an oversight. Hopefully grelminar will say something official and adjust the format while bak is still around to maintain clt (obviously you are still here to adjust dcme accordingly). It would probably also require a new server release as well.

You could also store the tileset in a special chunk, but obviously cont doesn't support that yet.
_________________
ss news

Samapico · Posted: Wed Nov 22, 2006 6:52 pm Post subject:

Is Grelminar aware of this? Does he read these forums often?

BDwinsAlt · Posted: Wed Nov 22, 2006 8:29 pm Post subject:

He reads it every now and then. Send him a pm to read this topic.

Mine GO BOOM · Posted: Wed Nov 22, 2006 10:16 pm Post subject:

Or better yet, file a bug report so he can track it.

Samapico. · Guest Offline

pm'ed and reported a bug in that place...

What does CLT do with 24bit tilesets? shrink 'em to 8bit? Ã´.o

arr... too lazy to login

Bak · Posted: Mon Nov 27, 2006 10:59 pm Post subject:

yeah, I had 24-bit bitmap support in before but took it out.
_________________
SubSpace Discretion: A Third Generation SubSpace Client

Grelminar · Creator of Asss Joined: Feb 26 2003 Posts: 378 Offline

I never realized tileset bitmaps could be 24 bits :)

Anyway, the fix seems pretty simple: let's use both reserved fields for the offset of the metadata, which gives 32 bits, which is more than enough. Because the second reserved field follows the first, and all of this is little-endian, it should be as easy as getting rid of the second field and making the first 32 bits, and it'll be fully backwards compatible.

Any objections or comments?

Smong · Posted: Sun Dec 10, 2006 7:06 pm Post subject:

Comments? Yeah I thought you were never coming back you've been gone a long time

Samapico · Posted: Mon Dec 11, 2006 11:31 am Post subject:

That's what I was thinking. But me thinking it isn't enough unfortunatly, because the ASSS server needs to be fixed that way as well

Next version of DCME will be released for supporting that

Grelminar · Creator of Asss Joined: Feb 26 2003 Posts: 378 Offline

Three weeks? That's not so long. If I ever "leave" I'll let you know. But I'm not even sure what that means, since I'm not "here".

I went on vacation, and when I got back I decided not to turn on my computer for a while. I'm still around, just checking in less often.

Though, to be honest I haven't spent significant time on SS stuff in a while. That's one reason I want to give more people write access to the mtn server, so I'm not a bottleneck for getting fixes like this committed. But nobody seems to want it...

KrynetiX · Posted: Mon Dec 18, 2006 2:01 am Post subject:

I can completely understand putting LIFE before AS3

I assume you would work on some things if you had some sweet ideas, but, it seems nobody has even tweaked their AS3 zone's to it's fullest potential yet so there is really no reason to update, only thing to keep up to date on are bugs and I haven't seen any of those yet..
You did a great job by creating a new server with awesome features and yeah, open source, you did enough work to retire buddy

Cyan~Fire · Posted: Mon Dec 18, 2006 11:28 am Post subject:

No project is ever finished. No developer may ever retire.
_________________
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.