Grid Sage Forums
- November 23, 2024, 06:42:15 PM
- Welcome, Guest
|
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
1
Everything REXPaint / Re: REXSpeeder - a new C++ library
« on: July 02, 2016, 11:02:09 PM »
REXLayer dtor should be empty. RAII.
2
Everything REXPaint / Re: mini-REXSpeeder for C++ v2
« on: July 02, 2016, 06:25:23 PM »
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.
3
Everything REXPaint / Re: mini-REXSpeeder for C++ v2
« on: July 02, 2016, 04:18:53 PM »
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...
4
Everything REXPaint / Re: mini-REXSpeeder for C++ v2
« on: July 02, 2016, 03:56:58 PM »
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.
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.
5
Everything REXPaint / Re: RLTK (Rogue Like Tool-Kit) now supports REXPaint
« on: July 01, 2016, 09:02:33 PM »
Absolutely nothing makes any difference in performance currently. Although if the max layer size goes up to 255 and people start allocating MBs of array<REXLayer, 255>, that could start to cause problems. I still don't approve of array<REXLayer, 9>, would prefer vector<REXLayer>. Flattened 3D arrays are awful for small libraries, slicing is excessively difficult to understand.
Gumix is also having problems with emscripten, I'm having problems too, I think it is the GC causing misery. I'm glad I never had to develop mobile apps with forced GC. Doubt that WEBAsm will solve anything, the GC is still there, right? Well, I don't know much about it.
Gumix is also having problems with emscripten, I'm having problems too, I think it is the GC causing misery. I'm glad I never had to develop mobile apps with forced GC. Doubt that WEBAsm will solve anything, the GC is still there, right? Well, I don't know much about it.
6
Everything REXPaint / Re: RLTK (Rogue Like Tool-Kit) now supports REXPaint
« on: July 01, 2016, 12:48:20 PM »
The overall situation is a bit unfortunate. REXSpeeder uses a fixed 4-layer array, mainly is Pyridine's inexperience in programming, he wants speed, thinks std::array is fast, which is true to some extent. Lack of forward compatibility is the unfortunate consequence. Lack of profiling to determine whether std::array speed increase is actually meaningful (no way it can be). Also, he has one vector for each layer, so the user must pay the std::vector cost anyway. Future risk of increased layers past 9, I can't really approve of fixed-size arrays, one library version per layer maximum increase is a bad idea.
Pyridine's REXTile format has alignment because of his initial uint32_t, since Kyzrati specified the character glyph to be 4 bytes, maybe in case he wants future UTF-32. Alignment forces gap between REXTile characters, so REXSpeeder reads one character at a time, which could be a problem, I haven't benchmarked, although likely negligible since the file is compressed. On the other hand, if Pyridine uses 4 uint8_t, that would also have problems if Kyzrati ever moves to UTF-32, since forcing the uint32_t out of alignment is a disaster. I can't say my library is faster either, because I don't use zlib, and the lack of compression outside of emscripten's automatic compression causes a disk read bottleneck, which is probably a far bigger issue than Pyridine's problem of reading one REXTile at a time.
Overall, though, absolutely none of this matters. Emscripten automatically compresses, zlib-on-zlib is a mistake, so my library works when using emscripten. You have to read the entire library to use it anyway, and mine is the easiest. But on the other hand, every time you want to change the .rex file, you have to unpack it manually, a pain. I don't like REXSpeeder because the user must read all the interface sugar. But it works, and I approve of his alignment choice, even though my own library did things differently. Some of REXSpeeder's other choices look rather strange, like reading nonexistent characters past the end of a file, but I guess they aren't errors.
Pyridine's REXTile format has alignment because of his initial uint32_t, since Kyzrati specified the character glyph to be 4 bytes, maybe in case he wants future UTF-32. Alignment forces gap between REXTile characters, so REXSpeeder reads one character at a time, which could be a problem, I haven't benchmarked, although likely negligible since the file is compressed. On the other hand, if Pyridine uses 4 uint8_t, that would also have problems if Kyzrati ever moves to UTF-32, since forcing the uint32_t out of alignment is a disaster. I can't say my library is faster either, because I don't use zlib, and the lack of compression outside of emscripten's automatic compression causes a disk read bottleneck, which is probably a far bigger issue than Pyridine's problem of reading one REXTile at a time.
Overall, though, absolutely none of this matters. Emscripten automatically compresses, zlib-on-zlib is a mistake, so my library works when using emscripten. You have to read the entire library to use it anyway, and mine is the easiest. But on the other hand, every time you want to change the .rex file, you have to unpack it manually, a pain. I don't like REXSpeeder because the user must read all the interface sugar. But it works, and I approve of his alignment choice, even though my own library did things differently. Some of REXSpeeder's other choices look rather strange, like reading nonexistent characters past the end of a file, but I guess they aren't errors.
7
Everything REXPaint / Re: Show off your REXPAINT creations
« on: June 24, 2016, 07:48:33 AM »
If you want cover flipping up, around the middle of the cover sweep, use half-blocks to enlarge the cover size at the top and bottom.
8
Everything REXPaint / Re: mini-REXSpeeder for C++
« on: June 04, 2016, 08:46:25 PM »
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.
9
Everything REXPaint / mini-REXSpeeder for C++ v2
« on: June 04, 2016, 11:44:04 AM »
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.
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.
Pages: [1]