Considering WPF is more than 10 years old and no major improvements have been done since like 2012... I'd say it's beyond "evolving phases" 
(just saying those quoted pros and cons are very old and by now most of them not true anymore)
Really... technology is the least of our worries in such a project (in a sense: it makes no difference at the end of the day).
Well WinForms is as old as Windows itself.
As a shameless WPF fanboy I will say it is much easier for making custom UIs and controls like you would find in editors, rather than trying to hack around boilerplate Windows UI with Forms. It's true that the Visual Studio designer is better at WinForms than WPF, but it feels better to write WPF by hand anyways.
Sure, technology is not that important to the end-user, but it is important to the developer so these projects will actually end up somewhere besides the cutting room floor...
One thing I would suggest is looking into being more cross-platform. MapEdit's biggest gripe has always been its Windows-ness, so even if you're using .NET I would suggest checking what technologies are/will be easier to port in the future as Microsoft develops .NET Core / Xamarin. Being able to make maps on the go on a tablet would be amazing.
I was probably just inferring hostility, I don't believe anyone meant me to feel that way.
Warboy,
I was going over the data files today and reading on ufopedia. I am using a hex editor to get a rough idea of things which worked great for the MCD files, they are very straight forward in each set of 62 bytes. The BAT and PCK files on the other hand I am having difficulty locking them down.
As I understand the BAT info about UFO from ufopedia, BAT files detail the start of sprite files inside the PCK files using 2 bytes of info(converted to dec/pixels?). It's not explained if the 2 byte data sets begins at the start of the file or later; I think they start right at the beginning because they each have 00 00. More importantly if the file references an uncompressed PCK file or the compressed PCK file.
The PCK file info explains decompressing by reading the first byte and skipping down the following rows, do I assume the rows are 32 bytes in length to match the sprite dimensions? Not sure how to know how large I should organize my rows so I can count downwards.
PCK files are super straightforward:
- TAB files (if available) are just a list of offsets for each sprite. They index directly into the PCK bytes, so to load sprite 3 you just start reading from PCK[offset3] until you reach PCK[offset4] (or the end of file).
The only catch is that while UFO only uses 2-byte offsets, TFTD sometimes uses 4-byte offsets, but you can just hardcode or guess it.
- PCK files are just a list of pixels (compressed or otherwise). They always have the same dimensions, so you can assume they're always 32px in width. In fact if you're loading the whole file at once you don't even need the offsets, as every sprite has an explicit "end of sprite" delimiter byte.
