Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mreuwu]

Features:
0. doesn't use zlib, so to use .xp files, you have to use 7zip to extract their contents first (i.e. right click, extract here). If there's no compression anywhere, this will result in a slowdown if your .xp files are large.
1. only reads files. no saving. no transparency tests. no flattening. no creating new RexFiles. whereas REXSpeeder can do those things.
2. header-only: include the 3KB file and that's it, no need for configuration changes or libraries
3. no exceptions. instead, dumps errors in the std::cerr stream and then abort()s, so in case you're wondering where a bug is in your program, then wonder some more because this library sure won't tell you any useful information
4. if the .xp file is maliciously crafted, and you try to use the vector<> layers directly, then you are vulnerable to a buffer overflow. using getTile() is safe. I'm too lazy to fix this at the moment.

License: I place my changes in the public domain. This builds upon the existing REXSpeeder library, which is MIT-licensed. But the two libraries are only superficially similar now.

[Kyzrati]

Ouch, can't use zlib? Everybody uses zlib

Funny that you can use 7zip to extract an .xp file; never thought of that

Thanks and I've added this to the resources page!

[Mreuwu]

7zip is robust WRT extensions; you can take a .zip file and rename it .txt and 7zip will extract it perfectly anyway. You can extract things like .cab and .iso.

[Pyridine]

In my experience, not every library loads files instantly. Sure, for like 20x20 files it doesn't matter how you load it, but I've seen big differences for files as small as 60x60. And for, say, game development, every millisecond counts.

Anyway, I'm impressed by the simplicity of your library. You certainly seem to know your stuff.

[Mreuwu]

Since Kyzrati stated he won't go UTF-32, and instead is thinking about sprite sheets, then you should use my 4 x uint8_t instead of the uint32_t, and then merge your read operations. There's no way the extra 3 bytes can be used without breaking compatibility, since sprite-sheet files are assumed to be a fixed 16x16 grid, since there is no place to specify width and height of the sprite sheet. Even if the rationale was future compatibility with arbitrary-sized sprite sheets, it is still a mistake since it would require a breaking change in the .rex specification. The width should not have been 4-bytes. Too late now. Although it still doesn't matter much because the 0s are compressed away.

Your REXSpeeder library also has a buffer overflow if the width and heights are maliciously set for each layer. I guess mine does too since I let the user rummage around the vector directly, which is why my getTile used .at() to avoid these problems. But I forgot about the public vector. My bad.

[Kyzrati]

Even if the rationale was future compatibility with arbitrary-sized sprite sheets,

This is an eventual goal. The current restriction to 16x16 spritesheets is again only a UI limitation, and there is nothing internal to REXPaint that limits it to 256 characters. In Cogmind for example, the same underlying system uses hundreds more values than CP437 to mix multiple spritesheets together, they just can't be edited in RP itself.

So later on (with a more advanced UI), users would be allowed to specify as large a spritesheet as they want--it's actually the most requested feature so far since REXPaint's introduction . This wouldn't have any impact on the specification, though, because images don't carry any spritesheet data, merely an integer index independent of whatever font is chosen.

[Mreuwu]

Ok, and how do you go from an integer index to a location in an arbitrary-sized sprite sheet? If the index is 300, it means very different locations for a 14x30 sprite sheet or a 100x200 sprite sheet...

[Pyridine]

> Since Kyzrati stated he won't go UTF-32, and instead is thinking about sprite sheets, then you should use my 4 x uint8_t instead of the uint32_t, and then merge your read operations.

Yes, I think I'll try and see if I can do that. That would cut down immensely on the number of reads. As for the possible future capability of XP to index arbitrarily-sized spritesheets, I think it's best to build the library to support what XP can actually do now, as opposed to what it may do later. Particularly if that allows code simplification.

> Your REXSpeeder library also has a buffer overflow if the width and heights are maliciously set for each layer.

I'm not worried about security for REXSpeeder until the need arises. Feel free to convince me otherwise. But if this particular vulnerability can be fixed with just an at() then I might as well fix it. thanks.

[Kyzrati]

Ok, and how do you go from an integer index to a location in an arbitrary-sized sprite sheet? If the index is 300, it means very different locations for a 14x30 sprite sheet or a 100x200 sprite sheet...

Good question. My intent would be to keep it as it is now, simply handled in row-major fashion. Using the current layout as an example: 0-15 on first row, 16-31 on second, and so on.

Also, my guess is the future UI would likely always have a width of 16, but with an arbitrary height accessible via vertical scrolling.

Really though, these are UI/editing considerations without any real impact on what is stored/read from an image, instead only determining how you might want to lay out a spritesheet itself, and interpret the indexes in the end-use program.

[Mreuwu]

Ok, I understand what you mean. The sprite sheet dimensions are a sprite sheet property, not a .xp file property. So it does make sense to have 4-byte indices.

[Kyzrati]

Right, I wanted to keep .xp files to the bare minimum of data so they're really flexible. It's basically like building a roguelike where the font you use is independent of the game data itself. Of course, as one user has requested it would be nice to have a variable amount of space in the header for optional meta data, but I don't really want to mess with the structure, so it continues to remain as it was years ago...

[gumix]

  i can sacrifice separate layer for metadata though.

[Kyzrati]

That's what I do . And it has the advantage of providing positional data as well. So now we have 8 extra layers for that!