Bay 12 Games Forum

Just letting you know and update for DF Remote will be released in the next 2-3 weeks (hopefully sooner), bringing support for the latest iOS versions and DF 0.47.05. Sorry this took so long.

Ooh wow

Some buildings, like roads, civzones and bridges I consider to be "ground" tiles and are not transparent intentionally. While some others may be left out because I forgot about them, so let me know if there are buildings that need to be added to the list.

iPad of course, to play Dwarf Fortress on it

Yeah, I was assuming the position of text wouldn't be hardcoded, since some of it can move around, particularly with DF updates. Avoiding the need to verify the positions of every string after every DF update would be nice.

First, it can be automated, at least if a string not found in a place it should be, it can be highlighted and a message logged. Most of the screens hardly ever change. Second, it's about providing a toolset for localisation, I'm pretty sure people who want to do the actual translation wouldn't mind keeping track of screen locations if that's the way to do it. Again, the locations don't have to be exact. For example, on the military screen there is some text/commands at the top-left, then lists in the middle, and more commands at the bottom-left. So only the top and bottom rectangular areas should be defined along with any strings that may appear there and their translations.

Another option is to search for text on the screen and translate it, ideally between when the screen is drawn and when it is displayed. This would probably be slow and unreliable at best, though.

I actually thought of this after seeing another localisation-related topic before reading it. I think this IS the best approach. There are not so many screens requiring translation, and the location of text on them is known too. Rendering of these screens can be intercepted, and text replaced - either with other predefined text or translating on-the-fly, or combination of both.

Look at a proof of concept I made - it translates text screens using Google Translate API (colours are lost at the moment, I know). Interestingly, the latest version of it allows to define your own glossaries, so the translation can be greatly improved in our case (when all texts are composed of pre-defined elements).

Some time ago I used Dwarf Fortress to benchmark servers offered by popular cloud providers. Because it's fun and because I needed to choose what to use for DF Remote. Sadly I've never managed to write an article about this in English. The code I used is available from https://github.com/mifki/dfremote-cloud-benchmark

This is how it works in the currently released version people play now.  I'm not sure how the SDL blits work down where they hit OpenGL, and yeah, I'd anticipate them to be slow (given how texture binds have worked in my own side projects not in SDL), but I'm not changing it too much from how it currently works, and it's pretty fast there?  Or has 44.12 been having trouble on some cards?

Oh, right... you're doing it all via SDL, so you're working with 2D renderer/print_mode... In that case currently there's no OpenGL involved at all, it's all purely software rendering. Which has problems of 1. high CPU usage (on my system DF uses 70% of one core in that mode when paused compared to 14% in opengl mode) - you may not notice it especially if you're developing on desktop, but people won't be happy with their laptops getting hot because of an extra CPU core being 100% busy doing software rendering, or it will just become a bottleneck later as there will be significantly more rendering operations than currently is; 2. it's pretty limited so any effects are either not possible or again must be done manually in software. SDL2 supposedly can use hardware acceleration for certain things, but I don't know any details.

I just don't know how to set up a DLL properly on windows...  I'm really tired right now (sorry! no sleep!) but there was some part of that which was quite irritating to get hooked up.  On OSX I know absolutely nothing.  For the process of the original ports, just getting it working on one OS was sufficient for everybody to work without having to see the rest of the code.

What if we find a way to solve the problem with Windows build lethosor mentioned that doesn't require too much of your time, is there a chance you would make libgraphics a separate binary on all platforms (on OSX it shouldn't be a problem)? This would make life of DFHack and related projects much easier in general, and would also make my concerns above not so important as you'd be able to continue coding rendering the way you prefer and we'd be able to make an optimised version of the library which can be just used in place of the original one if needed.