View world option implementation

During the weekend I finally managed to find some time to compile VCMI and tinker a bit with it.

I chose to experiment with world view option, as it looks it’s not implemented at all. I’m quite wary about changing too many things because this project is really big, so it would be pretty hard to foresee any side effects. Like exploiting some functionality that was designed for something else, etc.

Currently I have a semi-working implementation (well, not ready for committing yet, but let’s say the base functionality is mostly done) and I’d like to ask about some details before I finish it.

(in quite random order)

  1. The world view has different panel on the right (e.g. different CAdvMapInt buttons). Is there some nifty way to show/hide the buttons or I should manually (de)activate() them when needed?

  2. Does the CButton class support having “selected” button state in some way? E.g. in world view the selected zoom button should be highlighted (can’t check it now, but I’m pretty sure it’s the case). It seems that HIGHLIGHTED state is just for handling hover. This is a minor thing, but if it’s already possible then I could add it.

  3. These changes would break extraResolutions mod, because they need new panel background (and buttons’ positions as well). I can add a fallback to default image, but it still would look pretty bad.

  4. Can I “freely” change some json config, like adding new properties in resolutions.json (see point 3)? There doesn’t seem to be schema for that file but still, better safe than sorry. :slight_smile:

  5. What are the “requirements” to have the code merged into the project? Does the functionality need to be completely finished or a “raw” version could be submitted into the project and refined later (so that you can tell me right away that I did a Very Bad Thing :slight_smile: )?

  6. Should I use github [fork -> edit -> pull request] for submitting code (I’m not familiar with github, but it looks that it’s the correct thing)?

I hope to overcome the remaining problems (mostly involving drawing-maths :slight_smile: ) in the next few days (iiif I have the time to work on it :slight_smile: ).

Use Github, of cause.
It’s the only possible way to commit changes.
You can ask developers, how to work with it.
Personally I used it in summer, so I forgot most of actions :mrgreen:

Yes, at worst additional entries will be ignored.

Merging functional code sounds resonable, but the real trouble are regressions. We had many seemingly innocent merges that turned out to break something weeks later. I think it’s up to you to prove the code is ok and changes are necessary.

Yes, that’s why it was created :wink:

Well, as I said in the OP, I realise that the project is very complex and I try to modify as few things as possible. I didn’t touch anything server/communication related and barely anything outside adv map, so I guess the worst that can happen are some gui problems inside advmap panel. So far I played through one map and didn’t notice any problems outside of the world view.
Current implementation still has some issues, but I might try doing pull request today, as I’d consider it “functional” now.

Concerning fixed whitespaces (your comment on github) – I know, these were fixed automagically by IDE and I didn’t notice that.

So I’m going to do a pull request when I get home today and there’s a quite detailed summary of what was added and what the issues are.

[ul]] adventure options -> view world button changes adventure map mode to another mode:
[list]
] static terrain (no objects animations)
/:m]] disabled clicking on CTerrain
/:m]] no scrolling on edges (that’s how my WoG behaves at least); it could work, it just needs to be enabled in CAdvMapInt::mouseMoved
/:m]] map is overlaid with colored resources/mines/objects icons
/:m]] zoom buttons are functional, underground switch button is functional as well
/:m]] scaled surfaces are temporarily cached in MapHandler to speed up redrawing; redrawing with recreating surfaces would be really slow otherwise/:m][/ul]/:m]
] CAdvMapInt has now 2 panels that group all buttons from normal mode (end turn, options etc.) and from world view mode (zooms etc.) respectively and they are switched to (de)activated when needed (this kind of resolves question 1 from OP)/:m][/list:u]
There are several minor issues:
[ul]] currently selected zoom button isn’t highlighted (question 2 from OP)/:m]
] ui placement is slightly off and is hardcoded for now; I can try to move them to resolutions.json later/:m]
] zoom buttons’ scales might not be the same as in OH3, because I don’t have a way to check those/:m]
*] heroes’ flags aren’t correctly displayed (I disabled drawing them for now); I don’t really understand why this happens:
[size=75]basically it’s like this:

  • calling draw(flagSurface) works correctly (but isn’t scaled)
  • calling draw(scaleSurface(flagSurface, scale)) completely ignores color keying (scaleSurface is basically CSDL_Ext::scaleSurfaceFast, which, from what I checked copies format/palette correctly) – the whole blitted rect has cyan background[/size]/*:m][/ul]
    Aaand there is one bigger problem: with some drawing scales (generally the bigger ones), “mixed” tiles (between two types of terrain, e.g. water/sand) have cyan lines on them. I haven’t checked it in-depth yet; it looks like some scaling artifacts. It’s rather strange, because as far as i can see, the scaleSurfaceFast doesn’t try to interpolate colors or anything like that, so masked color should be still masked. Possibly it’s related to the way that “mixed” tiles are created?

Thanks!

I think they were incorrect in original version, in fact.

It certainly would be cool to have some interpolation there, since simple decimation in OH3 looks terrible. But this can wait for later.

I added the pull request on github.

I don’t know, for now I settled on 0.25/0.4/0.6 respectively. These values could possibly be moved to some config, but for now they’re hardcoded.

Yeah, at first it should look correct and only after that we should worry about enhancing it. :wink: Doesn’t scaleSurface (not the *fast version) do some kind of interpolation?

As a sidenote, I looked into this problem:

…and it looks like the incorrect drawing happens when a tile has some rotation in extTileFlags (if I change it to normal blit, it displays correctly, but obviously is not rotated). Will be checking further.

Edit ~ yeah, there’s definitely something strange going on in the rotation blitter. I made this example: http://i.imgur.com/Dp93QlD.png
Top images use blit8bppAlphaTo24bpp and the bottom ones blitter from getBlitterWithRotationAndAlpha. The first column is not scaled (base surface is blitted), and the rest is scaled with scaleSurfaceFast – as you can see, the rotated image is distorted at some scales (the lines would be cyan if blitter ignored alpha).
I can try to check what’s going on there, but that pixel magic is probably beyond my capabilities at the moment. :wink:

Edit ~ I managed to fix this problem by using another temporary surface (rotating image to new surface, then scaling, then blitting to screen). Probably not great with efficency, but everything displays correctly now.

Okay, I added one more commit and I think I’ll stop at it.

This was a big commit code-wise, but I tried to keep functional changes to minimum. It’s mostly abstraction and merging duplicated methods that draw normal map and world view into common ones (with abstracted draw calls to support scaling). I also abstracted puzzle map view as an extension of normal blitter, so there are no more puzzleMode checks all over the place.

Once again, I’ll list issues that could be fixed later, but this time nothing really important is left.
[ul]]first issue from previous list: currently selected zoom button isn’t highlighted – this is a minor thing that shouldn’t be that hard to fix, but currently I don’t see such functionality in CButton and don’t really want to extend it now/:m]
]panel/buttons placement is hardcoded (and not very precise) and should be moved to resolutions.json – I’m really not sure how to take this one on. There’s a lot of controls (labels/pictures) on the world view panel and defining every single of them in json seems silly. Currently panel is hardcoded to be drawn on the right-side of the screen, below the minimap, so I think for now it should work on all resolutions from mod. But still, it’s a temporary solution./:m][/ul]
Can’t really think of anything else. However I haven’t played OH3/WoG recently except testing, so I might have not noticed that something’s off.

So yeah, I don’t plan to update this branch for now (unless there are some fixes needed). Let me know if there are any problems that prevent merging it. :slight_smile:

I’m not into GUI, this has to wait for somebody else to review, most likely Ivan.

Sure. Thanks for info. :slight_smile:

It works with modded resoultions (tested 1366x768 and 1920x1080) but looks weird.


Yeah. My drawing skills are pretty much non-existent, so I just used OH3 panel background, no matter the resolution. Now that I think about it, I could add images with the correct size – original panel at the top and blank space at the bottom. However they would have to be placed in extraResolutions mod and, as far I can see, it’s not in the repository.
But sure, it’s a temporary solution.

It`s better to use “plain” background to fill up unused space. Use CMessage::drawDialogBox to prepare surface with desired size.

I added this functionality to the branch.

Edit ~ okay, I found a problem with my implementation, so stay tuned for a fix.
Edit ~ I guess it works correctly now. :slight_smile:

Issues so far:

  • zoom buttons highlight
  • map corners decorations flickering on zoom change
  • in H3 mountains, trees etc. are drawn with lower saturation
  • in H3 it is possible to scroll a bit “out” of map to see all objects near border better.
  • configurable widgets layout
  1. This probably should be added as CButton functionality. I can try to do it later, but I think it’s not that important.
  2. Hm, I didn’t notice it. I think that the corners are not redrawn until “updateScreen” redraw (every 8 normal frames). I can probably fix it today or tomorrow, should be a simple fix.
  3. This might be tricky. I’ll have to check H3 behavior – I thought view can’t be scrolled outside map at all.

Thanks.

Just a bit outside, 1-10 tiles. To be fine-tuned later. And this is also not important.

I fixed gems redrawing. Additionally added hotkey V to enter world view from advmap.

@4 I can’t really reproduce this one. I tried WoG/SoD (with and without heroes 3 hd) and it’s all the same: (screenshot from SoD)

Map is top-left as far as possible on 2x zoom; there are 3px wide line on the top and 1px on the left and it looks like a bug and not a feature, because this area is not redrawn (the more you scroll or change zoom, the more broken images are displayed there).

Im sorry, Ive incorrectly explained problem. It not about scrolling. One tile wide column/row on corners of map is even not rendering in your code.

Okaaay, I see now.
Apparently this happens because of weird drawing offsets passed to map handler. Originally initial position of advmap drawing was drawing bounds x/y (in my case: 7/7 – this is the frame around the map) + parent offset (which for me is… -7/-9). This worked for normal map, because camera could leave the map area anyway, but for world view it basically cuts off half of a first tile (first 7/9px).
This also explains why I had to add +1 to tile count for world view. :slight_smile:

Anyway, not adding parent offset to initial drawing position seems to fix the display. I’m not sure if this is THE correct solution though.