The idea is to add a preview option to graphics packs, and tileset configuration within them. Ultimately it could also replace the current colorscheme preview.
A few things need to be done for basic PyLNP integration:
My code added to core/graphics, including PIL importing
Interface created in tkgui/graphics - maybe a Canvas in a messagebox?
Enable the colors-retrieval function (relies on core/colors)
Pass the correct tileset (currently just hardcoded for testing)
Write a plan each to display for FONT and GRAPHICS_FONT
Check the way colors are added conforms to DF
(optional) Also handle colors from the raws.
[Issue created by PeridexisErrant: 2015-01-29]
[Last updated on bitbucket: 2015-05-13]
[Comment created by Pidgeot: 2015-05-13]
Initial implementation pushed in commit 36f2df2, created pull request #49 for discussion of further refinement. Most notably, TWBT emulation is still missing.
[Comment created by Pidgeot: 2015-04-13]
That's basic drawing done - still need to hook everything into the UI so the right tilesets get used, updates happen live, etc.
It took 0.141 seconds to draw that, by the way; I think that's perfectly acceptable for this purpose.
[Comment created by PeridexisErrant: 2015-04-13]
Looks great!
[Comment created by Pidgeot: 2015-04-13]
The TypeError happens because the images I referred to are using a palette - they're not in a format that can be used with a mask (it needs to be RGBA or greyscale). Also, these images seem to use palette index 0 to indicate transparency. I've fixed that by adding a bit of code to catch these files, convert them to RGBA, and then apply a mask generated from the paletted image data.
I still need to figure out how to get PIL to do the right coloration. The calculation itself is quite straightforward, but I've not yet figured out how to get PIL to do it - worst case, I'll have to resort to calculating it manually (and then I have to hope it doesn't get too slow).
[Comment created by PeridexisErrant: 2015-02-05]
Awesome that it's happening!
No idea where the TypeError comes in. I started this while travelling, so CLA was simply the nice ascii set I had locally; the color-adding system I've got is apparently correct for tiles that don't have native color (which should be preserved). Unfortunately I couldn't get PhotoImage to work, hence the ugly gif-based workaround.
[Comment created by Pidgeot: 2015-02-05]
This is going to be on my todo-list for 1.0. I have a pretty good idea about how I'm going to tackle it; the main thing I have to do is figure out how to read and write the individual pixels (that will be required for rendering)
I do not, however, expect to do any work on this at least until I've had my CPU replaced.
Some minor notes, in case you do more work yourself:
Some tilesets don't seem to work, e.g. curses_640x300 and curses_square_16x16 (causes TypeError: an integer is required when paste is called). Not sure why; haven't checked thoroughly
This tileset should be great for comparing with DF rendering.
With PIL, you can save as PNG as well - PIL_image.save('preview.png', format='PNG') - this allows truecolor graphics, which is pretty much going to be necessary
You don't actually need to save to a file, you can just import ImageTk and use self.TK_image = ImageTk.PhotoImage(PIL_image) to show the image.
Here's a proof of concept.
The idea is to add a preview option to graphics packs, and tileset configuration within them. Ultimately it could also replace the current colorscheme preview.
A few things need to be done for basic PyLNP integration:
core/graphics, including PIL importingtkgui/graphics- maybe a Canvas in a messagebox?core/colors)FONTandGRAPHICS_FONT[Issue created by PeridexisErrant: 2015-01-29] [Last updated on bitbucket: 2015-05-13]
[Comment created by Pidgeot: 2015-05-13] Initial implementation pushed in commit 36f2df2, created pull request #49 for discussion of further refinement. Most notably, TWBT emulation is still missing.
[Comment created by Pidgeot: 2015-04-13]
That's basic drawing done - still need to hook everything into the UI so the right tilesets get used, updates happen live, etc.
It took 0.141 seconds to draw that, by the way; I think that's perfectly acceptable for this purpose.
[Comment created by PeridexisErrant: 2015-04-13] Looks great!
[Comment created by Pidgeot: 2015-04-13] The TypeError happens because the images I referred to are using a palette - they're not in a format that can be used with a mask (it needs to be RGBA or greyscale). Also, these images seem to use palette index 0 to indicate transparency. I've fixed that by adding a bit of code to catch these files, convert them to RGBA, and then apply a mask generated from the paletted image data.
I still need to figure out how to get PIL to do the right coloration. The calculation itself is quite straightforward, but I've not yet figured out how to get PIL to do it - worst case, I'll have to resort to calculating it manually (and then I have to hope it doesn't get too slow).
[Comment created by PeridexisErrant: 2015-02-05] Awesome that it's happening!
No idea where the TypeError comes in. I started this while travelling, so CLA was simply the nice ascii set I had locally; the color-adding system I've got is apparently correct for tiles that don't have native color (which should be preserved). Unfortunately I couldn't get
PhotoImageto work, hence the ugly gif-based workaround.[Comment created by Pidgeot: 2015-02-05] This is going to be on my todo-list for 1.0. I have a pretty good idea about how I'm going to tackle it; the main thing I have to do is figure out how to read and write the individual pixels (that will be required for rendering)
I do not, however, expect to do any work on this at least until I've had my CPU replaced.
Some minor notes, in case you do more work yourself:
TypeError: an integer is requiredwhen paste is called). Not sure why; haven't checked thoroughlyPIL_image.save('preview.png', format='PNG')- this allows truecolor graphics, which is pretty much going to be necessaryself.TK_image = ImageTk.PhotoImage(PIL_image)to show the image.