Grid Sage Forums
- November 23, 2024, 05:28:39 AM
- 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 / png2rex - Rust Edition
« on: February 27, 2021, 10:22:55 AM »
Hi!
I just converted my old png2rex tool from C++ to Rust. You can find the new version here: https://github.com/thebracket/png2rex_rs
It now supports flipping the image (vertically or horizontally) and image resizing.
Just dropping this here in case someone finds it useful. I needed it for a project I'm playing with, and didn't feel like resurrecting the old C++ system now that I'm almost 100% using Rust.
(Edit - I must be dyslexic, I named the topic rex2png rather than the right way around)
I just converted my old png2rex tool from C++ to Rust. You can find the new version here: https://github.com/thebracket/png2rex_rs
It now supports flipping the image (vertically or horizontally) and image resizing.
Just dropping this here in case someone finds it useful. I needed it for a project I'm playing with, and didn't feel like resurrecting the old C++ system now that I'm almost 100% using Rust.
(Edit - I must be dyslexic, I named the topic rex2png rather than the right way around)
2
Everything REXPaint / Re: Submit projects for REXPaint website showcase
« on: February 22, 2019, 02:46:45 PM »
It's an ancient server, creaking along at the bottom of our data-center - but it's mine. :-p It's due for an upgrade, and I'll get HTTPS on there when it receives it. I think it's been sitting there for at least 5 years...
3
Everything REXPaint / Re: Submit projects for REXPaint website showcase
« on: February 22, 2019, 10:45:47 AM »
Hey!
If you don't mind, I'd like to add One Knight in the Dungeon to the showcase. It's mostly procedural generation, but vaults and special "boss" levels are all designed in REX Paint (and then converted into Unreal Engine tiles by the game code).
Homepage: http://oneknight.bracketproductions.com/
Short Description: One Knight in the Dungeon is a traditional roguelike, presented in modern graphics. It's intended as a gateway to the genre - introducing all the greatness of games like Nethack in a friendly, modern format. Choose from 6 starting packages, and customize with free-form skill-tree character development. Currently in pre-alpha, more widespread release expected soon.
Three images (pick and choose!):
A REX Paint map:
http://bfnightly.bracketproductions.com/oneknight/REX-NethertonManor.jpg
The resulting level, in-game:
A typical promo image I use:
http://bfnightly.bracketproductions.com/oneknight/REX-InGame2.jpg
http://bfnightly.bracketproductions.com/oneknight/SewerCeilings.jpg
Edit: for some reason my img tags aren't working.
If you don't mind, I'd like to add One Knight in the Dungeon to the showcase. It's mostly procedural generation, but vaults and special "boss" levels are all designed in REX Paint (and then converted into Unreal Engine tiles by the game code).
Homepage: http://oneknight.bracketproductions.com/
Short Description: One Knight in the Dungeon is a traditional roguelike, presented in modern graphics. It's intended as a gateway to the genre - introducing all the greatness of games like Nethack in a friendly, modern format. Choose from 6 starting packages, and customize with free-form skill-tree character development. Currently in pre-alpha, more widespread release expected soon.
Three images (pick and choose!):
A REX Paint map:
http://bfnightly.bracketproductions.com/oneknight/REX-NethertonManor.jpg
The resulting level, in-game:
A typical promo image I use:
http://bfnightly.bracketproductions.com/oneknight/REX-InGame2.jpg
http://bfnightly.bracketproductions.com/oneknight/SewerCeilings.jpg
Edit: for some reason my img tags aren't working.
4
Everything REXPaint / Re: A quick PNG to REX (xp) converter
« on: August 13, 2016, 08:04:46 AM »
The user-defined alpha ramp is a great idea (I'd thought about some sort of palette system, also, but I'm not sure how I'd best do that yet). I'll see if I can get that in there sometime soon; my time is a bit limited right now due to a sick baby, so I can't make any promises!
5
Everything REXPaint / A quick PNG to REX (xp) converter
« on: August 10, 2016, 11:37:45 AM »
Hey,
I don't know if this is useful to anyone, but for my current project I wanted to turn some PNGs into REX files. So I threw together a tool, and put it up on GitHub in case anyone can benefit from it. You can find the tool here: https://github.com/thebracket/png2rex
Basically, it lets you turn:
into this:
There's nothing super clever about it. It reads an RGBA PNG, and converts the RGB parts directly. The Alpha channel is transparent at 0, 1/4 filled at 25%, 1/2 filled at 75%, and a filled cell otherwise. Primitive, but it gets the job done!
I don't know if this is useful to anyone, but for my current project I wanted to turn some PNGs into REX files. So I threw together a tool, and put it up on GitHub in case anyone can benefit from it. You can find the tool here: https://github.com/thebracket/png2rex
Basically, it lets you turn:
into this:
There's nothing super clever about it. It reads an RGBA PNG, and converts the RGB parts directly. The Alpha channel is transparent at 0, 1/4 filled at 25%, 1/2 filled at 75%, and a filled cell otherwise. Primitive, but it gets the job done!
6
Everything REXPaint / Re: RLTK (Rogue Like Tool-Kit) now supports REXPaint
« on: July 02, 2016, 07:48:55 AM »
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.
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.
7
Everything REXPaint / Re: RLTK (Rogue Like Tool-Kit) now supports REXPaint
« on: July 02, 2016, 07:21:16 AM »
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).
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).
8
Everything REXPaint / Re: RLTK (Rogue Like Tool-Kit) now supports REXPaint
« on: July 01, 2016, 06:50:47 PM »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.
9
Everything REXPaint / Re: RLTK (Rogue Like Tool-Kit) now supports REXPaint
« on: July 01, 2016, 03:21:43 PM »
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.
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.
10
Everything REXPaint / Re: RLTK (Rogue Like Tool-Kit) now supports REXPaint
« on: July 01, 2016, 10:36:51 AM »
Awesome, thank you. I figured it was about time I registered here. :-)
11
Everything REXPaint / RLTK (Rogue Like Tool-Kit) now supports REXPaint
« on: July 01, 2016, 10:12:31 AM »
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.
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.
Pages: [1]