New resolutions

[Valery19]

I will maybe surprise everyone, but high resolutions are not always desired by those who play the game. I had a lot of feedback from MP long time players, and most if not all decided to ignore the so praised baratorch patch because the battle screen seems too small now, and everything important in Heroes occurs in.

Myself I enjoy the over detailed adventure map high resolution, but in combat I am annoyed about it, so I skip it as well. I know that would be impossible to have two resolutions running at once, therefore I don’t see how a compromise could be achieved. And resolutions over 1200 when coming to battlefield are just suicidal.

[Zamolxis]

You have a point about battles in high resolutions. Perhaps some motivated coders will provide a solution for that in the future.

[majaczek]

maybe an option to scale up windows twice (1 pixel will be replaced with 2x2pixels of same color - it should be fast)?
it will be nice for 1600x1200 and up

[Zamolxis]

Hi All,

I know there hasn’t been any new resolution added for more than a year already. That was partly because it wasn’t really needed (no new votes to this poll, or notable amount of requests coming from testers otherwise) and - from my part - partly because I didn’t manage to purchase that high resolution monitor yet, which I would need to properly test resolutions above my 1680x1050.

Luckily, someone else took the challenge of completing our “line-up” with the [size=117]1920x1080[/size] as the 10th in the list. Thanks to VCMI MantisBT member plush (see report #720), those with high res monitors who want to experiment H3-VCMI in the Full HD pixel ratio, can now do so by extracting the package I’m attaching to this post (VCMI 0.8x compatible) and placing the content in the corresponding folders.

As you know, you can select the game resolution by typing Resolution in the game console while in the Main Menu. For 1920x1080 you will need to select option 10. For those interested, I’m also attaching a version of the config/settings.txt file with 1920x1080 as default.

---

Not sure what the others think of new resolutions, but I suggest we still add this one to the official package from the next release, however I think this should be the last one (at least for a long while). We’ll have a nice line-up of 10 resolutions to choose from, with the Full HD 1920x1080 closing this line-up. I don’t imagine there’ll be many who would want higher resolutions soon. As for smaller resolutions (other than the custom ones which may still be developed for smartphones), if they didn’t become popular by now, they never will. We could of course have other resolutions built by whoever may want to give it a try (it’s a nice exercise)… but maybe they should probably be left for a secondary package with different types of extras.
1920x1080.7z (89.8 KB)
1920x1080default.7z (2.02 KB)

[plush]

I made the new resolution because my screen is 1920x1080… I had no idea there was a four page thread discussing resolutions. Wow.

Is there a specific reason for VCMI having hard-coded, manually made resolutions? When I saw how resolution support works in VCMI, my first thought was to implement a function that constructs the interface from individual elements at arbitrary resolution. I would still be up for coding that - but only if it is something that the project considers desirable. I do not want to waste my time working on something that will then be rejected anyway :).

[Boulie]

Yes, it is strange for me too. I’m not the programmer so I cannot say how it should be.
But VCMI team should consider more flexible and working solution - in HD mod for OH3. Ofc there should be implemented VCMI logo
More details on Polish forum HD mod desc in polish.
Interesting new feature is that you can adjust H3 in window.

http://www.forum.legendyheroes.pl/download/file.php?id=371&mode=view

[Warmonger]

The main problem with scalable interface is the lack of separate components to build a window from them. If you look at original H3 resource files, they are full of complete windows as one bitmap.
Still, I’d like to see it made by program. Not only it could be flexible, but also save space in package.

[plush]

When I looked at the mess that i the current GUI code, my instant feeling was “this should be replaced by a very simple toolkit that builds windows from elements”.

I would volunteer to program this.

However, note that the windows would never perfectly match the look of the original windows. I did some investigation in Gimp today: In the original windows, the background wood texture is not simply repeated. The artists seem to have copied and pasted it pretty randomly. If windows were to be generated programmatically, a single pattern would repeat.

[plush]

If you look at original H3 resource files, they are full of complete windows as one bitmap.

Speaking of which - is there some tool that can extract the images contained in these files? I can write my own… but my feeling is that there must be something out there already.

[Tow_dragon]

Is there a specific reason for VCMI having hard-coded, manually made resolutions?

The primary reason is scaling of screen background is not trivial to be performed automatically. You would have to cut the image, repeat to appropriate resolution and reassemble. Config file gives you more flexibility too - you can make longer lists of heroes and towns.

Anyway, I’d prefer a well-working automatic solution over what we have already.

I would still be up for coding that - but only if it is something that the project considers desirable. I do not want to waste my time working on something that will then be rejected anyway :).

If your changes won’t make the interface ugly in higher resolutions and take care of making hero/town lists longer, I’ll vote for commiting you changes to SVN.

When I looked at the mess that i the current GUI code, my instant feeling was “this should be replaced by a very simple toolkit that builds windows from elements”.

Actually that mess slowly converges to a simple toolkit that builds windows from elements. When we started writing VCMI we had no experience with GUI development. PreGame was rewritten recently and I think it’s quite acceptable.

I would volunteer to program this.

Recently beegee has expressed interest in improving GUI system so some coordination would be necessary.

However, note that the windows would never perfectly match the look of the original windows. I did some investigation in Gimp today: In the original windows, the background wood texture is not simply repeated. The artists seem to have copied and pasted it pretty randomly. If windows were to be generated programmatically, a single pattern would repeat.

I think it wouldn’t be a problem.

Speaking of which - is there some tool that can extract the images contained in these files? I can write my own… but my feeling is that there must be something out there already.

Of course there is, e.g. Resedit and defview from this site: heroesofmightandmagic.com/fo … t=download .

[plush]

You would have to cut the image, repeat to appropriate resolution and reassemble. Config file gives you more flexibility too - you can make longer lists of heroes and towns.

I would like to do that automatically. As you make the window bigger, the lists get longer. And yes, I would need to cut up the original images first.

If your changes won’t make the interface ugly in higher resolutions and take care of making hero/town lists longer, I’ll vote for commiting you changes to SVN.

I have a full HD screen myself - I want Heroes to look beautiful, not ugly on my screen :).

Actually that mess slowly converges to a simple toolkit that builds windows from elements. When we started writing VCMI we had no experience with GUI development. PreGame was rewritten recently and I think it’s quite acceptable.

Once code has reached a certain complexity and enough lessons have been learned while developing it, a complete rewrite is justified in my opinion. The pure virtual classes serving as interfaces, multiple inheritance and many undocumented things going on deep inside the GUI subsystem struck me as unnecessarily complex and difficult to untangle.

My GUI programming experience ranges from TurboVision for DOS through Delphi for Windows to Qt for Linux/FreeBSD. I think a solution based on the ideas behind these toolkits would work well for VCMI. I noticed that VCMI’s classes tend to expose almost everything as public members. I would go the exact opposite route, enforcing strict encapsulation. Once a solid toolkit is written, windows can be plugged together in a few lines of code.

Yes, what I am advocating is a complete rewrite of the GUI layer. This is probably a controversial proposition but in my opinion, is the best way forward.

Recently beegee has expressed interest in improving GUI system so some coordination would be necessary.

Thanks. I pinged him.

[Warmonger]

Well, current interface is a combination of many versions and it’s hard to figure out what is teh relation between its components.

I tried to make Creature Window based on Kingdom Overwiev by Ivan and everything worked fine until I decided to include nested components. Now it’s completely unclear why some of them are active, some are not and how is this process automated. I probably could copy a number of functions which activate / deactivate all, show all etc… but:

1. It doesn’t make much sense and appears to be excessive work,
2. It won’t help me understand the mechanics beyond it at all.

Not to mention every single window is written differently and contains different components, so it’s hard to spot a pattern.

[Ivan]

In the original windows, the background wood texture is not simply repeated. The artists seem to have copied and pasted it pretty randomly.

Are you sure? For example blue strips on adventure map ARE repeated (256 pixels size). Same size goes for most H3 windows.

I would like to do that automatically. As you make the window bigger, the lists get longer.

I remember screenshot of 1600x1200 resolution or something like that with 20-30 items in hero\town lists. Some limit to list size (around 10 items to leave place for one empty button) would be nice to have.

I noticed that VCMI’s classes tend to expose almost everything as public members. I would go the exact opposite route, enforcing strict encapsulation.

There are a lot of cases (especially in GUI code) where there is no access to class members from outside, so changing all members to private won’t broke anything. As already mentioned encapsulation is nice to have where it is needed - don’t see any point in creating one-lined setters and getters everywhere.

Once a solid toolkit is written, windows can be plugged together in a few lines of code.

It is already possible to generate some windows by creating several elements in the constructor and nothing more. Bigger problem is that some code is really ancient.

I tried to make Creature Window based on Kingdom Overwiev by Ivan and everything worked fine until I decided to include nested components.

Yeah… Lists and tabs management is quite tricky there
I already have classes for tabs\lists for this window but they are not finished yet.

[plush]

Not to mention every single window is written differently and contains different components, so it’s hard to spot a pattern.

This is why I am advocating a rewrite. I like the idea of more separation between GUI and game logic. Whenever some kind of functionality is needed in more than one place, write a control for it. A game window then consists of one method that arranges controls and a bunch of event handlers that fire when he user presses keys or clicks. The current system is kind of similar to this but often manually interferes with the inner workings of the GUI, breaking the clean separation.

Are you sure? For example blue strips on adventure map ARE repeated (256 pixels size). Same size goes for most H3 windows.

It differs between windows a lot. I was looking at the creature information window and at the load game window. Both of those use a background pattern that repeats - but not regularly. It looks like manual copy and paste where sometimes part of the pattern repeats, then the whole pattern again, then another part.

I remember screenshot of 1600x1200 resolution or something like that with 20-30 items in hero\town lists. Some limit to list size (around 10 items to leave place for one empty button) would be nice to have.

Absolutely. A list control could take a parameter “max size” and once it reaches that, the rest is filled by some kind of background pattern.

don’t see any point in creating one-lined setters and getters everywhere.

I like doing this from a consistency and code cleanliness point of view. My background is a formal education in computer science, so I am strongly in favor of clean, well-designed code.

It is already possible to generate some windows by creating several elements in the constructor and nothing more. Bigger problem is that some code is really ancient.

Yes, I saw that this is how most windows work: Create controls, handle events. But in the implementation of these two steps, the windows often interact with GUI controls at a lower level than I think is necessary. Whenever functionality is needed, a control should exist that exposes this via a clean interface.

I already have classes for tabs\lists for this window but they are not finished yet.

I do not want to interfere with any work you or others are doing. I discovered VCMI a couple of days ago, I would like to help - but I am proposing some radical changes. If my proposals happen to agree with what the current programmers want, I will implement them. If not, I will move on to other things. I will not at all be disappointed if you prefer not to change the GUI this much. It is your project after all, I am just an outsider with some ideas in his head.

[Tow_dragon]

Once code has reached a certain complexity and enough lessons have been learned while developing it, a complete rewrite is justified in my opinion.

Yes, what I am advocating is a complete rewrite of the GUI layer. This is probably a controversial proposition but in my opinion, is the best way forward.

Most of VCMI code is GUI handling so rewriting it from scratch would take a lot of time. Currently neither I nor Tow have enough time to significantly help doing it.

The current system is kind of similar to this but often manually interferes with the inner workings of the GUI, breaking the clean separation.

If the current system is kind of similar, why do you think we cannot change it gradually?

I like doing this from a consistency and code cleanliness point of view. My background is a formal education in computer science, so I am strongly in favor of clean, well-designed code.

I and Tow are currently studying applied CS. Interestingly, we didn’t experience not following certain good design habits taking revenge.

[Tow]

Chatting about how the code should be is always easy. You say it should be “clean”, “encapsualted”, “simple” and so on, while current GUI is “tangled mess”. And yet I’d say that current code is still better: it’s existent, not imaginatory. And it’s essentially working. Making a total rewrite of whole GUI code would require a huge amount of time (and even more to fix the bugs it’ll bring). In theory it’s possible. In practice, people get bored with project much, much faster. If you are really skilled and determined programmer — I think there are things that need some work much more than GUI system. [Or at least the current GUI can be gradually improved with much less effort.]

It’s not the first time, when newcomer, states that we did things wrong and we should start over. Some of your objections may be valid ones but that’s not a way of getting things done. I’m aware that our codebase has many flaws. Some needs fixing and some do not — fixing things that are not broken is sometimes only a waste of time. And I wouldn’t say that whole GUI system is broken. Of course, it’s unfinished (comparing what I planned and what I have done so far) and lacks some features but rewrite doesn’t seem to be a reasonable way of making it better.

Mind that GUI framework has been already largely rewritten on course of the years, but I’ve managed to keep it backwards-compatible. GUI system allows creating tree structure of controls, managing calling their (de)activation, showing, updating, destruction — but many GUI windows were created before it was possible. They are still working perfectly fine and that’s why I kept them in current shape (from time to time I adjust some of them to use new possibilities) but they should not be considered as representable how GUI code should look. I’d say that now pretty much functionality can be achieved with a little code (and, more importantly, without mindless glue-code). [And we should most certainly differ between GUI framework and various GUI objects that use it.]

If we want to make GUI system better, we should think what functionalities are missing and how to provide them. Think what functionalities now work badly, how they should be and how to achieve that. I can’t find in your messages any description of specific issues you’ve encountered when trying to do something in my GUI framework. [Well, the accurate thing is that current GUI framework lacks of documentation — that’s true, I somehow never forced myself to write a proper one — but I’m here willing to help and explain things, just ask.] Issues can be fixed without enormous rewrites.

You said that you’re willing to implement arbitrary resolution support. That’d be a nice addition to VCMI and I encourage you to give it a try. I have received graphics for arbitrary-resolution pregame (PM me, and I’ll send them to you) but adventure map will need new graphic pieces (or ask, if we can use ones from H3 HD mod). I’m pretty sure that whole thing can be done without rewriting the rest of GUI.

I like doing this from a consistency and code cleanliness point of view. My background is a formal education in computer science, so I am strongly in favor of clean, well-designed code.

I do strongly oppose implementing trivial accessors.
I believe there is only one fundamentally evil thing in programming: redundant code [and the worst form of it is duplicated code]. One-line setter/getter doesn’t introduce any logic, it’s just an additional place where you can make a mistake and additional function that needs maintenance (when adding/renaming/(re)moving variable). Code that’s not introducing any new logic shouldn’t be written.

[Zamolxis]

I would still be up for coding that - but only if it is something that the project considers desirable. I do not want to waste my time working on something that will then be rejected anyway :).

If your changes won’t make the interface ugly in higher resolutions and take care of making hero/town lists longer, I’ll vote for commiting you changes to SVN.

I’m not one of the programmers on this project, but I’ll give my 2 cents on the above.

Having no coding skills, I enjoyed (a lot!) the day I discovered that by just playing with numbers in a config txt file and playing a bit in GiMP with some pcx files, I can actually make a difference in this project by ‘creating’ something, rather than just testing.

That being said, we are at a point now where, at least as far as Adventure Map is concerned, we have a pretty good range of resolutions offered. It’ll probably take at least a couple of more years before people will ask for even higher resolutions. What we do already have, are requests for lower resolutions (for smartphones), but I’ll come back to that further below.

Therefore, in regards to the Adventure Map, I believe we are fine on the short to medium term with what we have. There are still minor errors here and there, but they are the kind non-coders like me could easily fix. And it’s small things like this that add to my motivation of keep being involved in the project: the fact that I can help with more than just testing. So for now, coding this into something only a programmer could control, I don’t see it as an added value (worth the effort), unless it can also serve for a good support to resolutions lower than 800x600 (see the 800x480 thread).

However, other than support for Adventure Map low resolutions, there are all the other game screens which are still stuck in 800x600. And the biggest problem seems to be the Main Menu, which really looks ugly now when going back from a high resolution, and I’m not sure if any good solutions for that are in sight. After the Main Menu, the 800x600 battlefield screen also starts to suffer in high resolutions (I can imagine as of 1920x1080 we may start wanting to wear glasses to see it better). And also, for the eye candy, it would be awesome if we could support the beautiful H3 town screens in higher resolutions. Now, if your code re-write would provide solutions for these, then I’m all for it, and I won’t suffer at all for losing the possibility to adjust or create new Adventure Map resolutions. It would be a tiny sacrifice, for the sake of making the rest of the game notably more enjoyable.

---

EDIT: I noticed Tow’s post above only after submitting mine. He makes a very good point about the risks of investing too much into re-writing from scratch something which is not like it’s fundamentally broken or anything. I would love a perfect GUI in VCMI, adjustable to all possible resolutions, for all the screens in the game. But there is something maybe a hundred times worse than having a less than perfect GUI: and that is more delays on this project.

Almost any Heroes project I’ve seen the last 10 years ended up dying before completion. Only WoG got pretty far (but is currently stuck, partly also because of the limitations which VCMI will remove). We already have less coders (with skills but also willingness to compromise for the sake of reaching a shared goal) than what we might like to have. Testers/fans come and go, partly because the project ends up taking longer than expected. Heroes VI is getting closer as well, and gives the feeling it won’t repeat some of the Heroes V mistakes. We’ll see if it doesn’t make new ones, but assuming it’ll be really better, the public for VCMI might become even more restricted (the better a sequel, the faster people leave behind older titles).

So coming back to the subject, I guess what I’m trying to say is:

• If the only way you would like to get involved in this project (else you’d move on) is writing a brand new GUI code, I wish you a lot of success and I will sincerely hope that you manage to get there, that you can provide something compatible with the rest of the game code which will be accepted by the lead programmers. But it should be something that can be achieved without asking too much involvement in terms of time from the devs, in answering questions and working on solving new compatibility bugs brought in by the new code.
• If on the other hand you believe you can help with bringing the project closer to a decent final product sooner rather than later, you would make a lot of people happier. It would be great if you felt you could work with the current code, but come up with a nice solution for a better Main Menu, battlefield, or any other GUI element which can still improve.

[Tow]

As for the main menu, I’m the one at the fault. Dru prepared a set of graphics to be used to make main menu work in any 800x600+ resolution. I haven’t programmed it cause there were still various more urgent issues and the whole thing would be tricky to be done neatly. [The buttons are sets of 32bit png files with alpha, obviously can’t be converted to .def.] The basic idea is to use high resolution graphics that will be downscaled (and cropped, if size ratio is different) to the required resolution.

[Zamolxis]

^ That sounds like an even better solution than what I had in mind for the Main Menu. I was thinking of suggesting something like a pop-up 800x600 window, centered on top of a grayed Adventure Map (kinda like the battle results window pops on top of the battlefield).

[plush]

I took my time with writing a reply as I wanted to see the resulting discussion first. Tow is right of course, many free software projects suffer from the problem that somebody shows up, tells them they did it all wrong, starts “doing it right” and then disappears halfway through the process. This is why I pointed out several times that I did not want to interfere with the project at large. I acknowledge the tremendous amount of work done on VCMI so far. What is there works - and works quite well. If the source to HOMM3 was ever released, I am sure an inspection would show that it is far more tangled and hacky. These are the realities of game programming.

My motivation, probably similarly to the other newcomers who jumped in with some big proposal, is not a practical one of making this or that work better in the short term. My idea is a theoretically sound basis to build things on in the longer term.

My proposal for a new GUI was not just based on the idea that what is there right now is “not right”. There are so many different ways to do things, so many different philosophies… it would be unfair for one programmer to judge another programmer’s approach as “wrong”. What I saw in VCMI’s code base and what I thought made it so difficult to follow was a collection of different coding styles. I knew this must be partially because of different people contributing parts of the code, each using their own style. I now see that another reason is the evolution of the underlying code base. The only way to unify this and make it more legible would be to rewrite it with a single philosophy behind all the code. But this would require one person to be in charge of that part of the project and would possibly alienate those with incompatible ideas.

I can see straight away that Tow’s and my concepts for how code should be designed and written differ. I wanted this discussion to see what might be wanted. Reading through the replies by VCMI’s coders, I do not think what I propose to do will be a good fit for VCMI. As I stated right at the start, I was aware of the potential misfit of my ideas, I did not want to be seen invading your project and telling you how to do it better. I offered to contribute a specific thing that I was interested in working on. Having read all the replies, I do not think VCMI is the right home for it.

Thanks for the discussion. It was very helpful for me. I hope nobody is unhappy about me dropping by the forums for a few days to check whether I can help and taking up some of your time. (If you feel your time was wasted by the questions I asked - I reimbursed the project a bit by fixing three bugs in return :).