You guys are making amazing progress.
If you call this progress:
Anyway. Loading a second .png crashes the program. After adding a few debug flags it seems the crash happens in the reload_tileset() function, which actually does the loading since even the load_tileset() function does nothing:
int sx = w / tile_width;
int sy = h / tile_height;
The crash is there. So I’m guessing it may be a divided by zero crash. In fact what I’m doing is to skip all the json side of things. And it seems that tile_width is actually initialized into load_tilejson_from_file()
So now I’ll try to give hard values to those variables. I’m really just trying to do it bluntly, then whenever it actually works we’ll think about making it smoother.
You’ve got more progress than me. I still can’t get the 0.A master to compile. Probably wrong setup of dependencies. Will figure it out later.
Dang, that menu actually looks kinda cool.
But it melts my eyes, so there’s that.
I got the new version to compile just fine over here on windows mingw. Mind you, I tweaked the #includes a bit see #6410
Could you figure out what I’ve tried to do?
Duplicating the png reading functions to have two tilesets active doesn’t seem a big deal, but we’ll probably need a function that reads ASCII color+glyph from the json files with all the object entries, and then figure out how the png is indexed to pick the correct tile number.
See this for an example of how this second png is organized:
I really don’t think we should use a PNG with the colored tiles included. We can recolor them on the fly with SDL2. This will use around 16 times less memory and not be appreciably slower.
You really shouldn’t try and load two complete tilesets at the same time. If that is what you are actually doing. I really don’t see the benefit to this.
Send me a message with exactly what you want the end result to be and I can advise you a bit on what you need to do.
I think that HRose and I both want the same thing, and I’ve been telling you exactly what I wanted to see in the game for a while now. And it does necessitate loading a second PNG tilepage. In the end, the game must have three tilesets loaded: One “curses” set of generated console font, for UI; one ASCII set loaded from a provided PNG; and one object graphics tiles set loaded as it is now. The game must use the generated font tiles for UI only, and use a combination of ASCII and graphics tiles for main viewport display. It should effectively look like this:
Note lack of “unknown” tiles for monsters that don’t have tiles defined. Right now this effect was achieved with your Tileset Editor program’s ASCII generation function, with subsequent manual editing of the resulting PNG to replace ugly shrunken text with HRose’s colored ASCII.
(The UI doesn’t have to use the curses font as it can load PNGs already, but I find the sidebar quite wide enough as it is, and the default terminus font is pretty good for displaying text.)
I like it…
So, after setting tile_width and tile_weight the second tileset.png is loading. The game works without crashing.
Obviously it’s not using the second tile at all. So now I have to figure out the drawing function to make some tests and see if I can print something from the second tile instead.
I think I already hit a wall.
If the functions that draw the tiles are within the tile object, then I can’t call a different object from within the first tile object.
So how the hell do I tell it to use a ASCII fallback tileset if we are in a specific tile object already? I can’t do this from inside the object. And the function that looks up which tile to draw seems to be within the object.
Ugly attempt part 2.
To bypass the whole two tile thing, I now pasted my ASCII fallback png right into the tile png:
Tiles Created: 5824
It loads fine, runs fine. Obviously the ASCII tiles aren’t being used, but at least they are indexed and accessible.
Now I’m trying to reverse engineer the tile_ids->find()
I’m guessing that in any case these functions are only looking into tile_config.json, so how the hell can we look into the data json to retrieve symbol+color?
Anyway, tile_ids are put into tile_id_iterator, and that’s tile_id_map::iterator
I can’ currently find where tile_ids->find() is defined.
What happens next is:
tile_type *display_tile = it->second;
then
draw_tile_at(display_tile,screen_x,screen_y,rota);
So I need a way to first check for symbol+color into the data json, then give a correct value to display_tile, since I have no idea what it contains until I find where it’s defined.
We are a LONG way to get this done. It doesn’t look like it will happen, at least if I have to do it myself.
Yeah, well it’s enough. I’m done wasting my time when someone who knows the game could probably do this in half an hour.
I have no way of looking into the data json from the tile object, so this is way beyond my skills and the convoluted design of Cataclysm.
So, again, I’m done.
[quote=“Sean Mirrsen, post:168, topic:3676”]I think that HRose and I both want the same thing, and I’ve been telling you exactly what I wanted to see in the game for a while now. And it does necessitate loading a second PNG tilepage. In the end, the game must have three tilesets loaded: One “curses” set of generated console font, for UI; one ASCII set loaded from a provided PNG; and one object graphics tiles set loaded as it is now. The game must use the generated font tiles for UI only, and use a combination of ASCII and graphics tiles for main viewport display. It should effectively look like this:
Note lack of “unknown” tiles for monsters that don’t have tiles defined. Right now this effect was achieved with your Tileset Editor program’s ASCII generation function, with subsequent manual editing of the resulting PNG to replace ugly shrunken text with HRose’s colored ASCII.
(The UI doesn’t have to use the curses font as it can load PNGs already, but I find the sidebar quite wide enough as it is, and the default terminus font is pretty good for displaying text.)[/quote]
This is amazing!
By the way, the big problem here is that the tile code works on a completely different level than curse.
This means that tile functions don’t have even the vague idea of what a “color” or a “symbol” is. The tile functions know a bed is a string ID “bed”, and then it looks up to the tile number associated. THERE’S NO FUCKING WAY to recognize the bed as a ‘#’ standard. We have the IDs of objects, but nothing else. So we don’t know anything that is associated with that IDs in the data json.
There’s obviously no way for each frame and each single tile to search through all the data files and find a specific ID. It’s insane. So the only way I could think to do this, would be about initializing a kind of library object specific for ASCII fallback and to store along with the tile object. So we go through ALL the data json, and store every ID with matching color and symbol. At that point you actually can have a simple lookup by using that library object.
But that means writing a json parser that builds the object and a lookup function. All stuff beyond my level. And probably beyond the interest level of those who could do it.
At this point it seems the quickest workaround is to get Chase’s tileset editor to generate custom ASCII tiles for all missing objects. Literally the only thing missing is the “custom ASCII” bit, as the program already does everything else. I have exactly zero experience with Java though, so even with the project on GitHub, I’m kinda skeptical of my abilities to add it. I don’t think I can’t try though. 
Narc0tiq in chat was helping.
Unsurprisingly, this can be done in a couple of lines of code. This already compiles:
long whatsymbol;
long whatcolor;
if (it == tile_ids->end()) {
whatsymbol = furnmap[id].sym;
whatcolor = furnmap[id].color;
}
We need to find all the maps available to cover each thing that can be drawn.
Then we need to figure out how to convert those longs and use them to point to the right tile.
I really hope this doesn’t get abandoned, it’s my favourite tileset 
I hope that a decent solution gets hammered out soon, if at least for my tendency to get mauled by random #'s.
Actually something is getting done. Discussion is ongoing:
Even when it works it will probably still have its shortcomings. Performance could also be an issue here.
Got ASCII fallback working locally.
Tomorrow I’ll post a package that includes everything, to test.
There are some issues with stuff that uses two colors, so in those cases the color you see might be wrong. But in general it should be now be impossible to see the “unknown” tile. Everything missing is shown in ASCII.
There’s stuff that breaks the function, like walls. But that’s stuff that should be already covered by the tileset. Plus tomorrow I’ll try some code that fixes that too.
It’s a very ugly implementation, but it works.