800x480 resolution

I’m not an artist too, sorry. But it sounds like if someone would create interfaces with smaller buttons, you could use them, right? If yes, I could at least give it a try, but please don’t expect anything stylish. :stuck_out_tongue:

Thank you very much! (In fact the scrolling works fine, we’d just need to have it switch back to plain 800x480 when it comes to creating a game)

Is it for performance reasons? The scaled images could be cached, so scaling operations would only need to be done once.

Yes, if we had graphics, we could use them in VCMI.

It’s mostly for performance reasons. And caching seems to be to hard for me because all graphics coordinates would be altered too… it’s possible but hard, time consuming and even more bug-prone than scrolling.

Found something here:
heroescommunity.com/viewthread.p … enumber=30
There is even archive with smaller buttons but it still have pieces of background so you’ll need to ask authors either for making 800x640 version for you or give buttons with transparency.

Not sure about second case. AFAIK image format for H3 (*.def) doesn’t handle transparency well. Usually 32-bit *.png will help in this case (and they do not limited by 256 colors) but VCMI can’t load them currently.
Maybe it is time for impementing this? I doubt that designers are eager to learn how to use all that weird (IMO) tools like DefTool or ResEditor.

EDIT:
Found more interesting download in that thread:
mediafire.com/file/nzgnwziyt … _v.1.1.wog
*.wog file is just a usual *.rar archive with changed extension
Extract all *.def from it to /Sprites folder
Update to rev 1779 (minor fix for correct loading)

Now you only need to fix positions (currently hardcoded)

I’ve changed the screen scrolling to drag-and-drop, but I’m afraid getting it working in-game is way too time consuming for me now. Since it’s not the most important feature to be done there are two options:

  1. I stop developing screen scrolling and leave what I have done hoping someone could take it over in the future.
  2. I stop developing it and revert all changes. It will make the code a bit nicer.

I’m not sure which option is better so I’m waiting for suggestions.

I think you have to revert it.

How did you get it? IT works for me…
BTW: you need to set resolution and screenSize to the same value to get the old behavior and resolution command could work wrong, but that is easily fixable.

Why not just make buttons smaller or arrange them horizontally?
(Assuming that we have graphics for buttons)

But the buttons are the smallest issue. Scenario selection screen (along with advanced options) will need more changes to fit 800x480.

AFAIK the menu buttons are the only ones marked with background. :slight_smile:

Well… .def has it’s ten magic transparency colors. And if other colors in palette have set transparency channel, VCMI should acknowledge that. Whether it’ll work depeneds if we use SDL blit or our controversial function that handles per-pixel alpha (cf optimization thread).

  1. Memory :frowning: 32-bit png will take 4x memory of 8-bit def.
  2. Def is format for animations, png is single graphic.

Nevertheless offering alternative format for animations is certainly worth of considering.

I’ll try to move them to the settings.txt soon :slight_smile:

You are right. One more such button is shield “Back” on not implemented campaign menu but there is no need to change it.

I always thought that background on H3 buttons was because of bad support of transparency in def… Thanks for clarification.

  1. Ah. Forget about that. But since png can be 1\8\24\32-bit offering png support can be without extra memory usage.
  2. Say that to Wesnoth devs :stuck_out_tongue:
    one png = image, several pngs = anim.

Indeed. Probably open a thread tomorrow.

IMHO we should get rid of it before the effort gets too high. It’s not a clean solution anyways, it would have been a really nice workaround until scaling and/or smaller buttons are implemented.

But wait: Did you also make it switch back to 800x480 after creating the game? If yes, then we could just keep it and really profit until we have the scaling/button solution. Or is exactly that switch the time consuming part?

Either way: Thanks for the hard work! :slight_smile:

You guys know best how and what can be done. My favorite choice would be dynamic scaling graphics. You could keep the current settings.txt thing, but make the resolution irrelevant. Change the class names to something like “minimal” and “original” maybe “double size”. So now the resolution is queried from the machine and just the layout of all buttons and menus is chosen from settings.txt. You could arrange the buttons like in H3 with the “original” settings, and make it tiny and minimal with the “minimal” one. For those who have bad eyes, provide a “double size” config that scales all the buttons double the normal size. Aaaand, you could still offer a resolution choice, for those who don’t want to play at native resolution which just overrides the queried one, still using the user-defined layout configuration. Does that make any sense?

Yes, I think it makes a great deal of sense. :smiley:

Best regards,
Steven.

What do you mean by “switch back”? I didn’t manage to get in-game interface working with scrolling, but game setup menus worked fairly well.

You mean automatic detection of user’s resolution and 3 different layouts for each resolution (minimal, original, double size) ? Nice idea, but we need graphics to do this…

I mean the problem I had before was that I had to use 800x600 in order to be able to use the scrolling feature. This also meant, the ingame advMap would not work, because my screen is only 800x480. That made the game crash as soon I clicked on “Begin”. BUT: After your latest changes, the scrolling works with all the resolutions set to 800x480, and I can start the game without a crash. Therefore I’d like to ask you to keep this feature until a better solution was implemented. I hope this is an option?

[x] 3) Stop developing and revert all changes after any better solution was implemented. :slight_smile:

BTW: Thanks again for this nice fix!

Yes, indeed. But it’s not about the 3 different layouts, we could have 10 or whatever. It’s just the idea behind it. So yes, we need graphics indeed. I hope Chris may give it a try. And I also downloaded the H3 bmp graphics file by Ivan (Thanks BTW). I’m not really good at this graphics stuff tho…

Do you think the liked files by Ivan are usable for that attempt? (Smaller buttons and stuff)

I think I could leave it “as is”. It just needs a few simple fixes I could do.

Those files contain graphics from Heroes III in a more common format, so they could be helpful.

Appreciate it. But I have to admit, I did not test the gameplay when I told you it’s working. The menu is perfect, but at least at 800x480 the advMap is really unusable now. See below.

I meant the files in this thead.


Why not try it yourself?

Just noticed problem with that files - while visible part of that buttons is small enough for 800x640 actual images are still big: large area around buttons is transparent but still clickable. Either VCMI should check transparency below pointer (like it done with town buildings already) or you’ll need to trim that images (ask author or try to do this yourself).

As I wrote, I didn’t manage to get VCMI working in-game along with scrolling - and I won’t fix that because it’s way too complicated. The question is if we should keep it for game setup (as a showcase or something) or not.

I’m sorry, I’m not familiar with the code. I thought you’d have to change some parts to rearrange the buttons? Correct me if I’m wrong.

Did I understand it right? You’d either have to check for transparency to remove the clickable area around the button (makes sense), or trim the (background) image to match 800x480? But how would the latter fix the clickable area around the button? Or do you mean to remove all the transparent area from the button images?

Sorry, I did not mean to be offensive in any way. I misunderstood that, thought you meant implementing scrolling ingame like in battles or town (where the bg images are still 800x600), because otherwise no scrolling is needed (Adventure Map is fine at 800x480).

Well, sad as it is, I guess being able to start a game is more important than being able to scroll the menu? I’m not the ultimate jury though, anyone else has thoughts about it?

EDIT: One question about the transparency: Is it possible to have partial transparency in buttons? Like fading the transparent colors into the button? Or is the exact RGB mixture necessary to make it transparent? (The latter way would make it difficult to not use background parts in the button and still have them stylish).

Of course if both thing could be implemented (the scrolling in the 800x600 views and the 800x480 adventure map) it would be great, but as slash said, i prefer be able to play the game that have a nice feature to show and not be able to play. So, for now, it all relays on fixing the graphics for our resolutions :unamused:

Sorry. I’m not good at explaining things. Look on image in attachment: This is one of that buttons. All blue area is transparent AND clickable. Placing buttons closer to fit 800x480 will result in clicking on several buttons at once.
Either resize buttons to make transparent area as small as possible (that red rectangle) or VCMI should check what we are clicking at - transparent blue area or actual button.

For rearranging buttons - yes, just to see buttons sizes and how it looks with this them - no.

Regarding transparency. This was mentioned several posts above already. What we have:

  • transparency in native for H3 format - def:

    • It has transparency levels but limited to total 256 colors (a lot of fading won’t work)
    • Some speed issues. (“Optimizing VCMI_client” thread)
  • some more common 32-bit format like png:

    • Take x4 memory compared to 8-bit defs
    • Single image but not animation - we need to implement some way to create animation from separate images.