Pre-release

[janso3]

Stuff to do:

• [x] Windows compatibility
• [x] Working main menu
• [x] Working user interface
• [ ] Correct cutscene rendering
• [ ] Sound effects (ADPCM)
• [ ] Loading / Saving
• [ ] Placing buildings
• [ ] Simple AI / path finding

[FilipJanitor]

I would like to help. I could play around with the menus for example to get some feel for the codebase. Also, I hope the task is independent enough to not block others who would depend on its results while I am working on it. What do you think? The AI looks interesting too, but it seems to depend on a lot of yet unimplemented parts - like tiles and units interfaces etc.

[janso3]

Yeah, there's a lot of unimplemented things ;-) Anyway, I would really appreciate any work on the UI code, since it's still pretty tedious to use (some helper classes would be nice!). I think it would help to create fairly small commits to make merging easier at this point.

[FilipJanitor]

Ok, I am sorry for polluting this thread but since I don't have any better idea on where to ask I will ask here - I started playing with the menus and got confused a bit. The question I want to ask is about the texture atlas. I think it would be faster if you could just shortly sketch the basic idea behind it instead of me trying to guess it. What I dont understand is the mapping from files to entries - how do I know which file from the data/ directory maps to some index? Currently I know which file does contain which picture. The next step for me is to map it to the entries - that means getting an entry index for some file. Thanks!

[janso3]

No worries asking here ;-). The texture atlas is just a way to merge multiple textures from a GM1 file into a single larger one, since there are some files containing as much as 1000 entries. The way the atlas works is that you give it a number of images and their dimensions, and it will give you the position of the image on the larger atlas texture (the first image will stay at index 0 for example).

[FilipJanitor]

Hi - so I am still fighting with the menus and element positioning and I have a few questions in order to write it in a future proof way. I checked both the original stronghold and the HD patch and I came to conclusion that there are 3 ways the menus are rendered

1. In 800x600 resolution the background is actually cropped and the menu is "zoomed in".
2. In 1024x768 resolution the menu is rendered according to the pictures available in the assets - that means the positions of the elements are different compared to the smaller resolution.
3. The HD menus are actually the second type of the menu surrounded by appropriate frame, the positions of buttons relative to the background picture don't change, but the positions relative to the whole screen change.

What we currently do by default is that we render it in the 1024x768 style, but in 800x600 window - that is the weirdest combination.

Now, I can imagine using this ratio based positioning for styles 2 and 3 if the third can be solved by using the picture part as a rendering target - not sure about it yet. However, the calculated ratios would not work for the basic resolutution. That also applies to the highlighting icons - they seem to be moved by one pixel and scaled differently.

Right now, the commandline options for resolution are pretty permissive and and I don't know where does the real stronghold persist the resolution configuration or how are we planning to do it in the future. My idea is - restrict the available resolutions to those used by HD patch (in case this project wwants to support its functionality). Have two styles of menus - the first one and the second one (I hope that the target idea for third could work and be incorporated into this one). What do you think?

Also, the HD patch seems to add a settings button to the main menu for all resolutions - I don't have it in the pre-patch installation. Do we want it there?

[janso3]

So, I actually thought of this a while back. When I started the project, I had dynamic resolution changes in mind, to support a better windowed mode or (maybe) even an Android version in the future. Now, I don't know if this would actually work when it comes to the UI, but maybe we could decide at runtime which of the 3 modes to use as a "base" and scale the UI accordingly. Let me know if this sounds dumb...

I guess adding the settings menu shouldn't be that hard as soon as we have a working menu system

[gloeyisk]

Stuff to do:

• [x] Windows compatibility
• [x] Working main menu
• [x] Working user interface
• [ ] Correct cutscene rendering
• [ ] Sound effects (ADPCM)
• [ ] Loading / Saving
• [ ] Placing buildings
• [ ] Simple AI / path finding

Will you add support for Stronghold Crusader?

[janso3]

Probably not. Maybe in a different repo when this one is playable.

[gloeyisk]

Probably not. Maybe in a different repo when this one is playable.

Great, will be waiting!