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!
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?
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.
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)
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.
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
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.
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?
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.
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.
Hm, this is beyond my skills of graphic manipulation. I’ll try it 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)
It is that way because thanks to it you can just blit unhighlighted button image to overdraw that glowing highlight.
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
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.]
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!
There’s no need to rush!
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.
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.
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?
Server was down, ISP fixed it around 4:30. Sorry for trouble.
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.
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.
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)
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?
Thanks!
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.
