MAPVIEW upgrade

[kevL]

I compiled MapView under Ubuntu 16.04 with only 1 warning after changing the target framework to "Mono/.Net 4.5". So far, there are 2 problems:

1. I can't make windows large — the upper limit is 632x481 pixels (630x433 without title, menu and borders). The version from https://github.com/ratzlaff/XCom-tools doesn't have such problem.

I can't say for sure, but it could be the effect of this workaround:

https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainWindow/XCMainWindow.cs#L173
vs
https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainWindow/XCMainWindow.Designer.cs#L451

at some pt I found that the designer of SharpDevelop IDE was increasing the size of some Forms incrementally, so I set a MaxSize for such form(s) in the designer, which stopped the repetitive increase, then in the constructor of the Form(s) the limitation gets removed.

that could be what's hampering things in Ubuntu/4.5 somehow

TileView, TopView, RouteView and TileRouteView windows have no resizing problems. They even have better decorations. Options and Configurator windows use the same decorations as the main window, but can be enlarged.

2. The tiles are not transparent. See the attached "mapview-linux.png". Ratzlaff's version has the same problem.

Any suggestions how to fix that?


Ah, finally found this post: https://openxcom.org/forum/index.php/topic,1321.msg103891.html#msg103891

But MapView doesn't work in Wine-staging 4.0-rc2 either.

UFO1A.MAP doesn't appear in the new version. What's wrong?

i removed any unused Maps (ie, unused in original XCOM) from the default MapTilesets configuration. If you want UFO1A (or any of the others) in, add it in /shrug

am glad you got it to build, am sad that Mono hasn't been updated yet. (Perhaps there's a 3rd party PNG decoder that can plug-in to Mono, idk)

[tkzv]

I can't say for sure, but it could be the effect of this workaround:

https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainWindow/XCMainWindow.cs#L173
vs
https://github.com/kevL/OpenXCOM.Tools/blob/master/MapView/Forms/MainWindow/XCMainWindow.Designer.cs#L451

at some pt I found that the designer of SharpDevelop IDE was increasing the size of some Forms incrementally, so I set a MaxSize for such form(s) in the designer, which stopped the repetitive increase, then in the constructor of the Form(s) the limitation gets removed.

Looks like it. The funny thing is: after a few launches the window started behaving correctly.

i removed any unused Maps (ie, unused in original XCOM) from the default MapTilesets configuration. If you want UFO1A (or any of the others) in, add it in /shrug

UFO1A is the small scout: https://www.ufopaedia.org/index.php/MAPS#UFO1A.MAP_.28Small_Scout.29

am glad you got it to build, am sad that Mono hasn't been updated yet. (Perhaps there's a 3rd party PNG decoder that can plug-in to Mono, idk)

There's got to be some way. I'll ask around.

[kevL]

UFO1A is the small scout: https://www.ufopaedia.org/index.php/MAPS#UFO1A.MAP_.28Small_Scout.29

oh right, i should have left that one in ... i get the small scout confused with the spherical scout ...

[tkzv]

Long story short, there's no readily available fresh GTK3# package. For now I replaced the calls to Graphics.DrawImage with manually checking and drawing every pixel. Looks OK for wall sprites, but not OK for floor and content. And the speed is low. But it works. Maybe a faster processor can help

Anybody is welcome to try. The source is here: https://github.com/tkzv/OpenXCOM.Tools
The relevant commits are:
https://github.com/tkzv/OpenXCOM.Tools/commit/28fb294da7e723e0f860d1dd3f56b19a98e62c85
https://github.com/tkzv/OpenXCOM.Tools/commit/de7a5d975a8fa104551a383b5cc992ac5eae0765

[kevL]

cool. very cool

... what's wrong with floor & content sprites? (*curious)

[tkzv]

cool. very cool

... what's wrong with floor & content sprites? (*curious)

They are drawn only partially.

[kevL]

it sorta looks like the drawing sequence is clearing pixels of previously drawn sprites ... *

note, tilepart-type visibility can be toggled for each type in TopView->Visibility (might be useful somehow)


It seems that true transparency is ultimately req'd.



* perhaps if your algorithm checks the color of the current pixel, as well as the color of the pixel-to-be drawn, and if the first is non-0 and the second is 0, pass the old color to the new pixel (?)

[tkzv]

it sorta looks like the drawing sequence is clearing pixels of previously drawn sprites ... *

It does look that way, but the algorithm simply skips black (supposedly transparent) pixels. It doesn't draw anything in their place.

* perhaps if your algorithm checks the color of the current pixel, as well as the color of the pixel-to-be drawn, and if the first is non-0 and the second is 0, pass the old color to the new pixel (?)

I don't know how to draw a single pixel. This is why I draw them as rectangles

note, tilepart-type visibility can be toggled for each type in TopView->Visibility (might be useful somehow)

What is it used for?

Speaking of which, what does _spriteShadeEnabled do? Now I just copy everything pixel by pixel regardless of _spriteShadeEnabled value.

It seems that true transparency is ultimately req'd.

Of course. It's faster

[kevL]

It does look that way, but the algorithm simply skips black (supposedly transparent) pixels. It doesn't draw anything in their place.

y, that's ... odd ....

I don't know how to draw a single pixel. This is why I draw them as rectangles

i think it's just a 1-pixel rectangle /lul, at least that's how i do it
hm,
System.Drawing.Bitmap.GetPixel()
System.Drawing.Bitmap.SetPixel()

but it'd be complicated 'cause you'd have to get the pixel out of the client-area ... i'd think ... and compare it with the pixel in the sprite ... or something like that ... ie, lots of deltas and what not

What is it used for?

TopView->Visibility [F1,F2,F3,F4 when TopView has focus] - these toggle on/off the drawing of tileparts (the blob-representations in TopView itself, and any sprites of that parttype in the MainView window). So if you want to see the floorparts that are directly behind, therefore hidden by a wall, the wall-parts can be toggled off to show the flooring ... etc. It's purely for visual convenience and doesn't affect saves at all.

But i'm thinking that by toggling parts on and off, you could get a better idea of what's actually going on with those floor and content sprites.

Speaking of which, what does _spriteShadeEnabled do? Now I just copy everything pixel by pixel regardless of _spriteShadeEnabled value.

spriteshade gets enabled when user sets spriteshade between 10..100 in Mainview Options. It's a gamma-adjustment for sprites (i run my monitor dark and need sprites a bit brighter).  Otherwise, spriteshade is disabled since SetGamma() is a sort-of-expensive call

I don't think it's important here, esp. if you haven't turned sprite-shading on in Options.

note: MainViewOverlay handles sprite-shading ... it's kinda confusing because SpriteShade is stored as an int (because options doesn't like floats, last i checked) which is then converted to a float-value SpriteShadeLocal, and that is used for the gamma

[RSSwizard]

I ended up getting a new computer so the previous issue might've gone away.
Are there any compiled (current) versions of MapView2?
Im not a coder so I cant compile anything.

[kevL]

Here's a recent build for Windows (.net 3.5 required)
https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md


ps. I strongly suggest not installing to Program Files.

[RSSwizard]

Thanks matey. It works like a charm.
(program files? geez I almost never do that, I toss everything on D: drive)

[luke83]

So was building some maps and when i returned they are all garbled ( see image below), now i am assuming this is because i have too many tilesets used on this mapset, my question for the experts is:
 Is this a limitation that OXC has overcome and its only just Mapview that is not updated OR does OXC have this same restriction ( and just has not been updated)?  In the old days i remember there was a limit but i thought OXC overcome all these pesky issues.

[Solarius Scorch]

Hi Luke,
The limits on OXC maps are the same as in the original game, because it's the same file format.
Therefore, you are limited to 256 tiles per terrain (doesn't matter if it's in one or multiple tilesets).
There are however several tricks you can use:
1) Destroyed tiles are not saved in a map, so you can go over 256, as long as the excess tiles are limited to destroyed tiles. So try putting destroyed tiles at the end of your last tileset.
2) UFOs and crafts use different tilesets. If your particular map does not include them, you can make a terrain block with different tilesets and spawn it as a UFO/craft.
3) If you're using OXCE (like pretty much any serious modder these days), you can combine terrains by defining another terrain in the mapscript. (This is the most robust option, unless you are only a few tiles over the limit, in which case it's better to just use option 1.)
If I think of anything else, I will also mention it, but for now that is all.

[luke83]

Thanks Mate, I am about 50 over the limit which should be fine, i was being Lazy anyway and i just importing Several Custom Tilesets from other maps instead of only what i needed so  i will just bite the bullet and make another Custome Tileset for this map also .