800x480 resolution

[slash]

Explained perfectly Thanks!

Is the attached image usable? Then I will create more of them. I’m afraid I can’t test it myself as the mentioned DefTool has very weird Russian letters in the menus.

I tried to be as close as possible to the original font, but getting rid of the image (for space reasons).

Could you try to convert it to .def and post or send me the result?

[Ivan]

H3 uses specific palette where 1st 10 colors are reserved for transparency and last 32 - for player coloring (if there is need for it). Try using palette from H3 files.

Could you try to convert it to .def and post or send me the result?

Sorry but fact that I know Russian letters doesn’t help me to manage with that DefTool (it has English version too AFAIK but don’t expect much)

I’ve already managed to open different formats like gif \ png in VCMI and it would be great to add possibility for some other formats for animation too, will open thread about this soon. Animated gif will not be easy to add though.

[slash]

H3 uses specific palette where 1st 10 colors are reserved for transparency and last 32 - for player coloring (if there is need for it). Try using palette from H3 files.

Hm, this is beyond my skills of graphic manipulation. I’ll try it though…

Sorry but fact that I know Russian letters doesn’t help me to manage with that DefTool (it has English version too AFAIK but don’t expect much)

I’ve already managed to open different formats like gif \ png in VCMI and it would be great to add possibility for some other formats for animation too, will open thread about this soon. Animated gif will not be easy to add though.

So I’ll have to wait until this is implemented, so that we can use .gif files. Or anyone else is able to convert .gif to .def? (Until .gif in VCMI is possible)

[Tow]

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

It is that way because thanks to it you can just blit unhighlighted button image to overdraw that glowing highlight.

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

I do have a counter-idea for scrolling. Instead of messing with global blitters and every place that touches screen, I’d rather realize scrolling as part of my GUI system and property of particular GUI objects. So we won’t be scrolling the whole screen but only single windows (like castle window or battle window). It is better, cause it’ll allow using 800x480 adventure map (and other windows when they’ll be adjusted) along with scrollable 800x600 windows. [And’ll be much cleaner in the code.]

Realising this idea would certainly need some work and I’m not promising anything now… but there is hope

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?

I don’t understand it. What would be a purpose of “minimal” or “double size” layouts, if everything was to be scaled to fit device resolution? [Besides, as I’ve written, dynamic scaling would be really troublesome from various reasons.]

I’m afraid I can’t test it myself as the mentioned DefTool has very weird Russian letters in the menus.

Try this version of DefTool: download.vcmi.eu/tools/H3DefTool.rar
It should be fully English, “Help” tab contains needed instructions.

[slash]

I do have a counter-idea for scrolling. Instead of messing with global blitters and every place that touches screen, I’d rather realize scrolling as part of my GUI system and property of particular GUI objects. So we won’t be scrolling the whole screen but only single windows (like castle window or battle window). It is better, cause it’ll allow using 800x480 adventure map (and other windows when they’ll be adjusted) along with scrollable 800x600 windows. [And’ll be much cleaner in the code.]

Would that still be a workaround until working 800x480 images for town/battle are implemented? I’m not in the position to, but I’d really dislike this being a final solution. Which does not mean I don’t like the idea itself! Quite the contrary, I’d be happy to have it as soon as possible!

Realising this idea would certainly need some work and I’m not promising anything now… but there is hope

There’s no need to rush!

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?

I don’t understand it. What would be a purpose of “minimal” or “double size” layouts, if everything was to be scaled to fit device resolution?

The purpose of those “classes” would be to have a customizable interface (adventure map button layout e.g.) like if you’d create a new one in those .pcx files and settings.txt. But more like defining various aspects like where to put the buttons, and in which size.

For example the “double-size” class could be there for people with bad eyes, and it would generate a normal AdvMap, but with all buttons in double size (scaled). The minimal config would remove some rarely used buttons and images to get more out of the actual map (for small screens probably).

If I did not misunderstand settings.txt it would be pretty much the same appart from the dependency on a resolution. Therefore the resolution is either picked from the native screen resolution or overwritten like it was done before in settings.txt. This does not affect the advMap and layout though.

Well, after reading my own words I guess it doesn’t make any difference from my previous post, so maybe this example is a better attempt. I removed irrelevant lines, to keep it clean.

[Besides, as I’ve written, dynamic scaling would be really troublesome from various reasons.]

Let magic happen! You’re the one that knows best what is possible. I guess there has to be a way? Maybe we need a totally different approach though.

Try this version of DefTool: download.vcmi.eu/tools/H3DefTool.rar
It should be fully English, “Help” tab contains needed instructions.

Thank you, will give it a try!

PS: vcmi.eu was down from ~ 1 AM to >= 3:30 AM…

EDIT: I tried the DefTool, and it’s not working. It says it imported the .def (which it created) into H3sprite.lod, but after starting VCMI the old logo is still present. DefPreview also showed me what I suspected. The transparency is dumb, and only fading for player colors. So can we get rid of .def, please?

[Tow]

PS: vcmi.eu was down from ~ 1 AM to >= 3:30 AM…

Server was down, ISP fixed it around 4:30. Sorry for trouble.

I tried the DefTool, and it’s not working. It says it imported the .def (which it created) into H3sprite.lod, but after starting VCMI the old logo is still present.

File should be named ZMENUNG.DEF, not ZMENNG.DEF.
Use DefTool only to pack images into the def, don’t fight with .lod archives. They are a pain to edit.
VCMI should recognize image (and use it instead of the standard one from the .lod) if you put the def file in /Sprites subfolder.

The transparency is dumb, and only fading for player colors.

Uhm… I don’t understand. Pregame buttons are not player-coloured, so you don’t have to worry about player colors. What do you neeed from transparency?

[slash]

File should be named ZMENUNG.DEF, not ZMENNG.DEF.]

O, thanks for the hint!

Use DefTool only to pack images into the def, don’t fight with .lod archives. They are a pain to edit.
VCMI should recognize image (and use it instead of the standard one from the .lod) if you put the def file in /Sprites subfolder.

It worked! Thanks!

The transparency is dumb, and only fading for player colors.

Uhm… I don’t understand. Pregame buttons are not player-coloured, so you don’t have to worry about player colors. What do you neeed from transparency?

Well, there are sprites that have a “player color” area that is replaced by the current players color. This kind of transparency is able to fade, so that even slightly different colors are semi-transparent. For the normal transparency it seems not to be possible, so you have to match the exact RGB values to get transparency at all. Maybe I just misunderstood DefTools explanation though.

My logo is not transparent at all. And the animation frames are mixed up somehow.

[Ivan]

As you can see H3-style palette is essential. Wrong color is used for transparency and as result picture is broken.
Try converting some stuff from archive in attachment - this is that buttons but with fixed sizes in gif format. I can’t convert into .def but they use correct palette and most possibly - correct frame order.
buttons.zip (183 KB)

[slash]

I have this huge file containing H3sprite.lod and H3bitmap.lod in .gif and .bmp format. I used the pipette tool to extract the turquoise color for transparency, so I assumed it was correct.

Given the fact that there is no smooth blending transparency for these menu buttons available, why don’t we just use your buttons? They are tiny and would easily fit on the 480 pixels height. I can’t make any better buttons without fading…

After you guys implemented .png images for animations I could create real transparent buttons, i guess?

[Tow]

I have this huge file containing H3sprite.lod and H3bitmap.lod in .gif and .bmp format. I used the pipette tool to extract the turquoise color for transparency, so I assumed it was correct.

The turquoise on screenshout you attached is (0,252,248). The default “transparent” colour should be (0,255,255). Maybe that’s an issue? In DefTool you can also set different colours for transparency, just click on the colour box in the Frames tab. But they must be same for all the frames and match exactly.

If that doesn’t solve the issue with transparency, please upload your frames and I’ll look why they don’t want to be assembled into a nice .def.

Well, there are sprites that have a “player color” area that is replaced by the current players color. This kind of transparency is able to fade, so that even slightly different colors are semi-transparent. For the normal transparency it seems not to be possible, so you have to match the exact RGB values to get transparency at all. Maybe I just misunderstood DefTools explanation though.

Sorry, I still can’t understand. You write as if player colours were some kind of transparency. Those things are unrelated.

H3 uses several first colours in palette as transparent “shadow” and - in some of the sprites - last 32 colours as players colours. Those colours are just replaced with predefined palette appropriate for given player. [H3 has a list of 32 colours for each player colour.]

[slash]

The turquoise on screenshout you attached is (0,252,248). The default “transparent” colour should be (0,255,255). Maybe that’s an issue? In DefTool you can also set different colours for transparency, just click on the colour box in the Frames tab. But they must be same for all the frames and match exactly.

That’s the problem, there is no tolerance. That way I can’t create a “fading transparency” (fading from color to transparency". But the pipette tool of GIMP still shows me 0,255,255 in the BMPs I use (I can’t check it for the .def).

If that doesn’t solve the issue with transparency, please upload your frames and I’ll look why they don’t want to be assembled into a nice .def.

Please find the 3 frames attached. Thanks!

Sorry, I still can’t understand. You write as if player colours were some kind of transparency. Those things are unrelated.

H3 uses several first colours in palette as transparent “shadow” and - in some of the sprites - last 32 colours as players colours. Those colours are just replaced with predefined palette appropriate for given player. [H3 has a list of 32 colours for each player colour.]

You’re right, player colors are no transparency, and yes, they are not used in spritedefs. But they are able to fade if I understood it right. And that is what is needed to create smooth blending buttons without background image pieces in it.

If you drew something with approximately player’s colors (i.e. you used anti-aliasing), click on the Player’s Colors icon and set the tolerance you need. The bigger tolerance is, the more pixels would be treated player’s. The tolerance varies from 0 to 442, unlike the most graphics editors. As an example of this, if you have two red colors with the red components of 140 and 150, you should set Tolerance to 10 (150-140=10) or more if you want these colors to be treated the same.

From here I understood, if the transparency would work the same way, it would be possible to create fading transparency. But it doesn’t. Bad.
ZMENUNG.zip (14.3 KB)

[sslmm]

So, any news on this?

[slash]

I don’t care for button styles, so I’d be happy to see the ones of Ivan implemented if possible? Please? They are smaller in height.

[slash]

Any progress or news regarding 800x480? Can we implement these buttons?

Thanks!

Daniel

[Tow_dragon]

I think 800x480 resolution should be considered as no longer in development. I really doubt it will be implemented before VCMI 1.0.

[Guitarzan]

I would think that VCMI being fully functional at 800x480 would be an important part of the development of VCMI. Many devices only support 800x480.

[Warmonger]

Well, certainly it’s more important to have the game complete before end of the world in 2012.
It’s getting closer to that state, as all of minor gameplay features seem to be more or less handled. But we need a really big jump to get through MP & AI.

I believe 800x480 may be the future of project as more and more mobile platforms can support it. However, the problem with graphics still exists. Things don’t get solved on their own.

[slash]

I don’t get the problem with supporting it. It’s almost there, we just need the smaller buttons working (and remove the scrolling as it crashes the game - or fix). The graphics could just be cropped and replaced one by one.

I don’t have a good view on how much work this means, it would be sad to drop it though. in the end it’s your decision…

[Warmonger]

The graphics could just be cropped and replaced one by one.

So crop it and replace one by one, there’s no better way than that

[Tow_dragon]

I don’t get the problem with supporting it.

Our GUI system is just not designed to handle resolutions smaller than 800x600. If you were a coder, you’d know that if a system is not designed to do something, very often it’s very, very, very hard to provide that feature. Of course it’s possible, but would you postpone MP support for many months to have 800x480 resolution? Currently I have no time to do anything with VCMI, even bugfixing and only Tow is able to add 800x480, but he is writing multiplayer mode.