Print

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

[thebracket]

I just wanted to let you know that RLTK (my modern C++ roguelike toolkit) now supports REXPaint. I integrated REXSpeeder (full credit to Pyridine) - with some changes to make it fit the coding style of the rest of the library - and added the appropriate drawing code to apply sprites to virtual terminals. This version only renders the first layer; that's on my short-list of things to remedy soon!

It's very much a work-in-progress, but there's enough meat there to build a game. You can get RLTK at https://github.com/thebracket/rltk.

[Kyzrati]

Hey thebracket! I'll add it to the resources page, too.

[thebracket]

Awesome, thank you. I figured it was about time I registered here. :-)

[Mreuwu]

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.

[thebracket]

Erm, that was random. Wrong thread?

REXSpeeder's std::array is actually from a PR I submitted. The original was fixed size, and I dropped it in there to tidy up some new/delete[]. It wouldn't hurt performance in any practical sense to just size a vector to (w*h*n_layers) at creation and have one big structure (you only pay the allocation cost once, and a vector has the same access characteristics of a C-style array on any sane implementation) - but the REXPaint format I've seen specifies 4 layers. I honestly can't see any reason for more than that, but if that layer number starts changing, it's a trivial fix - so I'm sure Pyridine or I will implement it.

Padding; I'm pretty sure that the objective isn't to handle unicode - it's to handle oversized character maps (which are basically sprite sheets). I'm pretty sure it doesn't make any practical performance difference, especially when reading through zlib (which is doing its own buffering/magic to begin with - so the number of bytes you read *isn't* what is read from the disk to begin with). If you *really* wanted to not care about alignment, just pad the tile struct you are reading and do a big read at once (or even better, just mmap the file - that's *fast*). It's not like we're dealing with huge files here, though!

As for Emscripten support - have fun with it. Used it for several projects at work, and I'll be a happy man if I never touch it again until webasm is natively supported (with a proper DOM interface). Yikes, what a mess, just to get vaguely usable math performance out of a browser.

[Kyzrati]

thebracket is correct in that there would never be support for Unicode, as the point is simply to use basic integers for sprite sheet indexes.

I honestly can't see any reason for more than that, but if that layer number starts changing, it's a trivial fix - so I'm sure Pyridine or I will implement it.

The specification includes an indicator for the number of layers in the file, allowing nearly unlimited layers (in theory, since you can't edit that many in RP). And just yesterday I added optional support for up to 9 layers in RP itself because already a number of users have asked for more than 4

Literally minutes after you made your RLTK post today I released 1.03 including this!

[thebracket]

Literally minutes after you made your RLTK post today I released 1.03 including this!

Haha, that's always the way. I guess I know what I'm doing in the morning. 

[Mreuwu]

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.

[thebracket]

I just pushed a version of RLTK that can support an arbitrary (well, bounded by an int) number of layers. It also renders multiple layers properly.

I took Mreuwu's advice and stuck with an std::vector<rex_layer> in my implementation for now. If there's a need for hundreds of them to be handled at once (which there might be, with the way Black Future is going!), I'll switch to a single vector rather than a vector of vectors - the latter is just asking for cache issues when data sizes start to get big.

I'll get it back-ported over to Pyridine's version and submit a PR shortly. It's a pretty trivial change. (UPDATE: I've submitted a simple PR that does this upstream).

[thebracket]

Regarding Emscripten - it's a decent idea, but for now it's an odd fit - compiling LLVM into a bytecode and then executing that in JavaScript (assisted on some browsers; Firefox is much faster when running the code I've worked with). It mostly works, but there are a lot of pain points - mostly regarding getting data in and out of it. I didn't find the GC to be too much of a problem, since the "memory" is basically a big array it isn't collected. Rather, I had problems with performance being very inconsistent between browsers, and the mechanism for invoking (and passing data in/out) took a lot more head scratching than I'd like. Admittedly, it was a year ago - but I couldn't help but think that for now I was better off using JavaScript+Canvas (or GL) for a lot of things.

The project we worked on has a public demo here: http://wisptools.net/tools-viewshed.php?r=20&th=20&lat=38.9589451&lon=-92.32251199999996 (you may have to refresh if the map doesn't come up; it's under *really* heavy load right now). We tried and tried, and couldn't get the performance we wanted in native JS - but the math performance of porting our C++ to Emscripten saved the day. It's a pretty heavy-weight application (and that tool just touches the surface) - for any point on the globe, it downloads terrain height (at a 2 degree resolution in most areas) and landcover data (from LandSat) and ray-casts (taking into account curvature of the Earth) to determine what points are visible. The main application also does ITM/Longley-Rice calculations to determine radio signal strength at the receiver, but that requires that you sign-up on the main RFPlanner app. Depending upon your tower parameters, that can be a *lot* of data to crunch. Unfortunately, it took quite a bit of massaging our otherwise portable code to get it running. Admittedly, this was over a year ago - so the tooling may have improved.

What I'm hoping for webasm is that, once it is supported natively in all major browsers (it's getting there), it will take a lot less fiddling around to get it to execute. If their plans to support threads materialize, then it could be a HUGE win for me. Unfortunately, until native support arrives it isn't something I can deploy - so I can't spend too much time on it. If the ideas for webasm that are slated to arrive later materialize (proper DOM interaction, and a better bridge between JS and WASM) then it could become hugely useful. I would *love* to be freed from JS for web application development; we're just not there yet.

I also didn't try and support it for RLTK because the library uses SFML, and last I checked they haven't shown much interest in Emscripten as a platform.