OpenXcom Forum
Contributions => Programming => Topic started by: hszp on February 13, 2014, 03:01:10 pm
-
"When will v1.0 be released?" - I'm sure I'm not the only one interested.
Could SupSuper or someone else sum up what is between now and the much expected release?
What features do you want to complete, how many bugs need to be fixed?
-
It will be released no sooner than "when it's done".
However, the roadmap is something I would like to know too.
-
I'm not to bothered personally. version numbers are just numbers, I just look forward to the new updates and hopefully mod merges (mainly Shoes stats/medals)
-
Warboy recently updated the changelog, https://github.com/SupSuper/OpenXcom/blob/master/CHANGELOG.txt
Some things may have been missed, due to him being human.
I'm not to bothered personally. version numbers are just numbers, I just look forward to the new updates and hopefully mod merges (mainly Shoes stats/medals)
:3 I also look forward to publishing my mod in an accessible way!
-
It's true that the version number does not represent much to those who follow the project closely and upgrade often.
To everyone else however, a nice round version number means that the project is in a state not just worth trying but worth using.
He can start a game without worrying about savegame compatibility breaking tomorrow and the fix to yesterdays bug arriving the day after tomorrow.
-
It's mostly usability stuff to reduce the typical problems whenever someone new tries a release for the first time.
- New Options GUI to bring popular "hidden" options to the front.
- Revise option descriptions/defaults based on user feedback.
- Make Windows installer automatically patch old UFO data and support Adlib music (gets around SDL_Mixer issue).
- Check on palette bugs.
- Check on music / volume bugs.
- Add common failure scenarios to Loading screen and make error messages more informative.
- Review any pending UI / usability issues that might be worth including.
- Final check for serious bugs / crashes.
- Final localization inspection.
- Final changelog update.
- Trailer?
- Ship it.
-
Oh snap a trailer too?!
Start with slow music, showing off the newest features on the geoscape.
It gets faster and louder showing off new features on the battlescape.
Epic climax symphony playing while showing 2 second video clips of tense battlescape situations and showing off weapon mods.
Then at last the music goes down again softly showing off how easy it'll be to mod the game, then the URL to the official modding website and how easy it is to upload mods, and other reasons you need to be part of the OXC community.
The last 5 seconds will be for the OpenXcom clothing-line and coffee mugs.
Miss anything?
-
Great, thanks SupSuper!
-
yeah i can't give you anything concrete, mostly i watch let's plays in languages i don't understand and keep an eye out for inconsistencies and usability issues.
i've kinda run out of personal landmarks at this stage so i'm just tidying up and double checking everything to make sure it's all as vanilla as possible.
there are still a handful of issues i'd like to deal with, like the missing/wrong frames on the muton animations, explosion propegation in bigwalls, some grenade AI stuff maybe...
when i'm not doing that i'm working on my own mod.
-
then the URL to the official modding website and how easy it is to upload mods
The wizard cave ninja is making great progress in this area.
-
But when v1.0 is done, you`re going to TFTD, don`t you? ;)
-
- Scrollbars (proper scrollbars for lists and dropdown menus)
- Proper indentation for multilined lists
- Dropdown menu size (currently it's hardcoded to 7).
- Geoscape/battlescape/basescape resolutions
- Naming of base resolutions like: original, 480x300, 640x400, x1:XXXxYYY, x2:XXXxYYY, x3:XXXxYYY, x4:XXXxYYY (xN mean pixel zoom, and XXXxYYY is resolution for autoresized screen contents, considering zoom level). In sake of making translation hell less hellish (it's not possible to translate "to window" that short) - numbers don't need to be translated at all.
- Proper basescape menu rearranging, fitting whole screen (at least vertically) - it is possible
+ Making window contents automatically rearranged without getting into "options" each time after window resize
+ Adlib music emulator embedding (as custom sdl music player), without need to download 35mb of non quite legal data.
- Soldier position "helper" for craft crew list. Also in equipment screen (including pre-battle) - somethinglike in attachment.
Gentlemen! "1.0" traditionally means "complete", and without those frankly it won't be complete, and I doubt - deserves that name.
Perhaps, "0.99"?.. Seeing 1.0 with lots of unfinished things (like scrollbars, or intuitive, bug-free scaling) personally for me, it will be... a shame, to say the least. That hurrying tells me, that most probably it will be exactly that. And I simply don't wish openxcom release to be such a flaw. Thus I'm calling for a wisdom. I see how project is crying for next milestone release, but I believe it better not to be called "1.0".
Thank you.
-
Tough.
-
and unfair. One of the goals of this project is to be faithful to the original Xcom UI. Many of these "requirements" are expressly counter to that goal. 1.0 should be whatever the devs deem worthy of that title.
Edit: I realized I may have interpreted "tough" incorrectly. If it is the other meaning, +1
-
Many of these "requirements" are expressly counter to that goal.
Lies. I was one of developers, and without me this project wouldn't get to that level of faithfulness. Ask Warboy.
1.0 should be whatever the devs deem worthy of that title.
Sure, and that will show the level if their wisdom I'm calling for, or in opposite - the level of shame.
It's like making graduation party without passing exams, or without even finishing all needed tests. I wouldn't wish that for anyone.
-
for the record i believe volutar only has the purest of intentions here, and i can see the point he's trying to make, but i don't think ALL of these features are necessarily required for a 1.0 release.
we'll see what we can do, and i'm sure most of this will make it in, but i don't see how naming the option "x2:563x355" is more user friendly than "1/2 display" or how that is particularly shameful.
-
we'll see what we can do, and i'm sure most of this will make it in, but i don't see how naming the option "x2:563x355" is more user friendly than "1/2 display" or how that is particularly shameful.
Because it tells you it's zoom x2, and internal resolution is 563x355. And if you resize your window - it will change it into "x2:550x315", and you will be known of what exactly inner resolution it is. And what pixel size it has. "Display/2" tells nothing without proper explanation and documenting.
1. "Display/2" doesn't mean pixels are x2 sized
2. Not everyone knows that "original" is 320x200, and 1.5x original means "480x300". Are you expecting people will take calculator and estimate proper Display resolution to make square and uniform pixels?
3. "Original" and "Display/2" is hardly translatable, and most probably won't fit that button, in the same time numbers don't need to be translated at all.
-
True, less technical = more fun. Having to fiddle/search for some numbers that seem like random background noise to get the game display properly is not fun at all.
Volutar, you're the man with the criticism :) What would the solution be? :D
-
kkmic, i already told solution - to show fixed resolution (for stretchable mode (320x200,480x300,640x400) ) and calculated baseresolution for zoom mode (x1,x2,x3,x4). And these baseresolution numbers should be updated with each window resize - because they've changed. You won't need to calc real base resolution - it simply shown, plus you don't need to make 100 translations of these short and weird terms like 1.5xOriginal and Display/3
I have another issue to point to. Drag scrolling in battlescape.
1. Mouse cursor is locked inside window, even for dragscrolling, which is dumb. Dragging mode (when you're holding drag button) should capture mouse even if it's out of window, and should allow to drag-pan battle on distances larger than window size (currently you are unable to scroll by amount more than window size).
2. Minimap mode dragging scroll has a glitch, when you hold mmb (dragscroll) and pan away so mouse cursor happens beyond MAP square - it stops dragging, and even disable drag state, while MMB is still held. You have to release, and hold it back to reinitialize drag mode. Plus it also limits dragging distance with this small square.
Fixing those is also essential before 1.0.
-
I'm going to side with Warboy here. Seeing a big list of resolutions is not very intuitive, especially if context is stripped (like your proposed x2: XXXX x YYYY -- "x2 of what?" a user could wonder.) But seeing a scalar of Display, a word they see at the top of the screen right above the display resolution they picked, should be intuitively apparent to mean the resolution that's listed up there. And it shouldn't require much extra translating work - "display" is already translated at the top.
I suppose listing the ORIGINAL resolutions as "x1: 320 x 200" and "x2: 640 x 400" and so on would not be very bad, but I don't see much point in listing out the display-scaled ones. I'm not sure what you mean by pixels being "square" (there's an aspect ratio letterboxing option for that) and "evenly distributed" (do you mean so every pixel in SDL or Raw mode is the same size as any other? If so, the "display" scalar options do just that, as well)
I agree the display scalar sizes should update on window resize. EDIT: I just tried it, and it seems to already do so.
In all honesty, the options menu is already fairly cluttered, so having a seemingly arbitrary list of resolutions in it would not help.
As for the scrolling issues you mentioned, those are bugs and should be reported.
I hope you do not have the impression that the devs are outright ignoring issues like what you mentioned in your list for the 1.0 release. That's not true. Warboy's list is a list of long-term goals, not absolutes. Your issues would be a part of "review any pending UI/usability issues" in that case.
-
1. "Display resolution (https://en.wikipedia.org/wiki/Display_resolution)" for me is 1920x1200. Always. I can change only WINDOW size. Thus Display/2 means nothing.
2. In most of languages this "resolution" menu isn't even translated, because people don't understand what it is. Or translate them the way so user won't get what it is.
3. No need to add lots spaces("x2: 540 x 350" -> "x2:540x350").
4. Fixed resolutions (320x200,480x300,640x400) don't need of any extra "x2" specifications. "x2" means ZOOM, not resolution resize. And always means ZOOM. And these fixed resolutions imply STRETCH resize technique. While ZOOM can't change size of any pixel.
5. These x2:XXXXxYYYY are for information only, it meant to be "zoom x2", AND information about actual game resolution considering zoom/aspect mode.
I'm not sure what you mean by pixels being "square" (there's an aspect ratio letterboxing option for that) and "evenly distributed" (do you mean so every pixel in SDL or Raw mode is the same size as any other? If so, the "display" scalar options do just that, as well)
In attachment - letterboxed display. Do you see lots of real square pixels? And it's the "letterbox" (or better to call that "keep aspect" because "letterbox" doesn't have proper translation to other languages). Problem is - it doesn' t care on actual pixel size, it simply stretches image (in 1.5 times), having them look that ugly. Any resolution/size which adds such a shame should be forbidden. That's what these 2x, 3x zoom mode are for - to guarantee fixed pixel size.
My suggestion (assuming you have window size 1366x800):
Game resolution:
[320x200]
[480x300]
[640x400]
[x1:1366x800]
[x2:683x400]
[x3:455x200]
after you resize window to 720x400 - list items will be changed to:
[320x200]
[480x300]
[640x400]
[x1:720x400]
[x2:360x200]
---- NO x3 zoom, because game resolution will be less than minimum 320x200.
As for different resolutions for different modes (battlescape/basescape) - it's optional, and by default - greyed out, with enabling checkbox next to it. Most of people (and myself) are okay with single zooming/stretching option and resolution for every mode. Those 3.5 people who want to change resolution in different modes will be allowed to enable them.
Main concept is not to overcomplicate and increase possibilities, because people in 80% of cases will use them wrong.
-
2. In most of languages this "resolution" menu isn't even translated, because people don't understand what it is. Or translate them the way so user won't get what it is.
Then report these cases so that someone who knows the language can fix it.
Fine then, would Window/2 be preferable then? I honestly have not seen anybody else be confused by this.
I'm afraid your screenshot is just how Nearest Neighbor scaling will always be by nature. No monitor out there today (save 1280x800 laptops) can do a perfect clean scale of the original 320x200 game without letterboxing completely like, say, Chocolate Doom does (and I don't think that's preferable, nobody wants black bars on all sides of their monitor. But if it was made this way, to make things simple, I vote that such a feature is always enabled, and only enabled, for Non-GL modes and any GL shaders where linear: false)
I prefer Quilez shader because of this, it preserves the classic blocky look without looking uneven and jagged. (It's essentially Nearest 2x and then Linear the rest of the way)
-
Then report these cases so that someone who knows the language can fix it.
Are you kidding?
Fine then, would Window/2 be preferable then? I honestly have not seen anybody else be confused by this.
original pixel size, 2x pixel size, 3x pixel size - are preferrable. 2x zoom, 3x zoom - shorter version.
But "Display/2" is some weird notation, looking like a formula, with which users are offered to make their own calculations? Is it obvious that 1.5 original is 480x300? I guess users are suggested to: 1. Find out original values, 2. take calculator, and multiply them. 3. Calculate best "display resolution" to avoid those non uniform pixels. Lame.
I'm afraid your screenshot is just how Nearest Neighbor scaling will always be by nature.
Thus it's important to keep pixels fixed, square and integer sized- 1x1, 2x2, 3x3 or 4x4.
-
Are you kidding?
No. The devs cannot possibly know every language OpenXcom runs on, and if a bad translation changes the meaning of something from what was originally intended, then that is a problem that should be rectified.
Thus it's important to keep pixels fixed, square and integer sized- 1x1, 2x2, 3x3 or 4x4.
In that case, I agree, as 1.5x scaling on Nearest looks utterly awful. But as I said, it should apply only for the SDL modes and GL shaders where "linear: false" is set, as there is no reason to preserve pixel uniformity in filtered shaders (see attached, which uses 1.5x pixel size and looks fine)
But "Display/2" is some weird notation, looking like a formula, with which users are offered to make their own calculations? Is it obvious that 1.5 original is 480x300? I guess users are suggested to: 1. Find out original values, 2. take calculator, and multiply them. 3. Calculate best "display resolution" to avoid those non uniform pixels. Lame.
No, they are not suggested to calculate anything. The options themselves do the calculating for the user. That's what they do. "Display" guarantees 1x1 pixel size, "1/2 Display" guarantees 2x2 pixel size, and so on.
I know it makes sense to name those opeions "Pixel Size: 1" or 2 or so on for windowed mode, but what about fullscreen? Unlike Windowed mode, using different display resolutions would result in different physical dimensions from using the same scaling option. This doesn't really make sense unless it is clear that it is in reference to the selected output resolution.
-
Frankly, neither of these explanations are understandable by me. What I understand is resolution - say, 800x600. This I can understand.
The rest... Well, I don't even know what it's for. Back in my days, we had MS-DOS, there was resolution, and if the game ran at all it was already good. :P All these bazillion display modes are just some sort of techie wankery to me. I tried various display modes in Openxcom, they all look the same to me, so why even bother? All I care about is to not have black stripes near the borders.
-
Frankly, neither of these explanations are understandable by me. What I understand is resolution - say, 800x600. This I can understand.
The rest... Well, I don't even know what it's for. Back in my days, we had MS-DOS, there was resolution, and if the game ran at all it was already good. :P All these bazillion display modes are just some sort of techie wankery to me. I tried various display modes in Openxcom, they all look the same to me, so why even bother? All I care about is to not have black stripes near the borders.
Basically, "1/2 Display" sets the actual game resolution to half of the output resolution, this lets the battlescape use all of your 16:9 widescreen monitor (no black stripes) instead of only the 16:10 portion in the middle. The "Original x#" modes just scale up the original game, and will always be a 16:10 aspect ratio.
If no scaling is used (e.g. Original) then the actual game resolution is 320x200, scaled up to whatever your output resolution is.
-
Basically, "1/2 Display" sets the actual game resolution to half of the output resolution, this lets the battlescape use all of your 16:9 widescreen monitor (no black stripes) instead of only the 16:10 portion in the middle. The "Original x#" modes just scale up the original game, and will always be a 16:10 aspect ratio.
If no scaling is used (e.g. Original) then the actual game resolution is 320x200, scaled up to whatever your output resolution is.
Well, okay; still, what I wanted to say is that aspect ratio is something you actually notice, while all those fancy settings... not so much. At least I can't.
Therefore, I suppose choosing the aspect ratio should be enough, unless other users feel differently.
-
No. The devs cannot possibly know every language OpenXcom runs on, and if a bad translation changes the meaning of something from what was originally intended, then that is a problem that should be rectified.
And i'm suggested to find a people, call them or write emails, so they urgently will think on how to translate that better way and do that as soon as possible?? lol
In that case, I agree, as 1.5x scaling on Nearest looks utterly awful. But as I said, it should apply only for the SDL modes and GL shaders where "linear: false" is set, as there is no reason to preserve pixel uniformity in filtered shaders (see attached, which uses 1.5x pixel size and looks fine)
Not fine. Blurred.
No, they are not suggested to calculate anything. The options themselves do the calculating for the user.
What calculation? "x1.5 Original" doesn't make any calculation. It's static value - 480x300, which is much more clear, as for "640x400" instead of "x2 Original".
That's what they do. "Display" guarantees 1x1 pixel size, "1/2 Display" guarantees 2x2 pixel size, and so on.
I simply can't get how "Display/2" means it has fixed pixel size 2x2? By trying it? It's obviously unclear, and Solarius Scorch demonstrated that. If this forum had a polling, it would show real picture.
I know it makes sense to name those opeions "Pixel Size: 1" or 2 or so on for windowed mode, but what about fullscreen? Unlike Windowed mode, using different display resolutions would result in different physical dimensions from using the same scaling option. This doesn't really make sense unless it is clear that it is in reference to the selected output resolution.
Fullscreen is totally another story. But even in fullscreen - either "keep aspect ratio"(letterbox), or pixel-stable zooming.
Having non integer zoom levels is bad.
Every single emulator has option resembling Zoom: 100%/200%/300%, and no free scaling with stretching, and no 150% or 250%.
Basically, "1/2 Display" sets the actual game resolution to half of the output resolution, this lets the battlescape use all of your 16:9 widescreen monitor (no black stripes) instead of only the 16:10 portion in the middle. The "Original x#" modes just scale up the original game, and will always be a 16:10 aspect ratio.
See? you have to explain that "term" as "1.5 original" - also needs of explanation. List items with exact game resolutions would be 300% clearer, specially if you compare them with translated.
-
And i'm suggested to find a people, call them or write emails, so they urgently will think on how to translate that better way and do that as soon as possible?? lol
No, but you could leave a post in the Translations forum about it and if someone has the time they'll eventually get around to clearing it up.
Therefore, I suppose choosing the aspect ratio should be enough, unless other users feel differently.
That just removes the feature entirely. The feature being a hi-res game, which many users (myself included) have wanted for a long time.
Not fine. Blurred.
This is how the linear filter looks. There is nothing wrong with it, per se. It is a personal preference. I understand you prefer the classic blocky look. The point is, a 2x Linear scale looks no better or worse than 1.5x, unlike with Nearest scale where only integer looks good.
What calculation? "x1.5 Original" doesn't make any calculation. It's static value - 480x300, which is much more clear, as for "640x400" instead of "x2 Original".
I thought you were referring to the Screen options. Anyway, to me it makes sense because I see "2x Original - that must mean twice as much area as what I remember for 20 years"
Having non integer zoom levels is bad.
Only for nearest-neighbor scaling, which I imagine the majority of the userbase is not using. It should still be accommodated, however.
Every single emulator has option resembling Zoom: 100%/200%/300%, and no free scaling with stretching, and no 150% or 250%.
The difference is, emulators can't expand the actual game view like OpenXcom can. That's the entire reason the scaling features in OpenXcom exist at all. The "1/# Display" options were likely added so that it could take advantage of extra widescreen space. Clean pixel doubling was never the goal, even if it should have been one. This is an important difference. Also, most emulators DO allow free scaling as an option. This is because it looks fine if you aren't using nearest neighbor scaling.
But you're all right, it's not very intuitive if you're a novice. Most importantly in this regard: Frankly, all the average user will care to want is to "make it hi-res" and then be overwhelmed by the 6 different choices. For one, I think the fixed non-320x200 ones should go. The main reason to stick with 320x200 is that it's what all the assets were designed for - menus in particular. 640x400 and so on have no such benefit, so any user would probably want to use a mode that fills their entire screen instead.
I think a far more elegant (from the UI perspective at least) would to have "Original" and "Expanded", and Expanded would enable a Zoom scalar value (that goes up/down in increments of .5 for Linear). This will set the pixel multiplier.
Volutar's problem is that nearest scaling looks like shit for any non-integer multiplier (which unfortunately is any modern resolution) therefore I propose that when the game is scaling using nearest neighbor (in any SDL mode, or any GL filter where "linear: false" is set) the Letterbox option also letterboxes the game to the closest clean integer multiplication. Modes where "linear: true" is set have no need for this, so there's no reason to sacrifice aspect-ratio correction for using the entire screen space in their cases.
Original: Base resolution 320x200. If nearest: letterboxed to closest integer scale. For example, window size 1920x1080 would use a 5x scale since 1600x1000 is the largest integer multiple of 320x200 that fits. Black bars on all sides. See Chocolate Doom for example of this.
Expanded (Zoom 1x): The base resolution becomes the output resolution.
Expanded (Zoom 2x): Halves the base resolution so that it is pixel-doubled (2x2 pixels)
Expanded (Zoom 3x): and so on...
Essentially, it just dumps the Original 1.5x and 2x options and renames the "1/# Display" options to something more meaningful. I think the Expanded term makes clear that the purpose of scaling is for showing more of the battlescape. With "1/# Display" or "2x: 960x540" this isn't very clear.
-
I thought you were referring to the Screen options. Anyway, to me it makes sense because I see "2x Original - that must mean twice as much area as what I remember for 20 years"
Good for you, if you remember, others might not. Nevertheless these terms meant to be friendly and meaningful for everyone.
I think a far more elegant (from the UI perspective at least) would to have "Original" and "Expanded", and Expanded would enable a Zoom scalar value (that goes up/down in increments of .5 for Linear). This will set the pixel multiplier.
Thing is - "original" doesn't mean much. 320x200/480x300/640x400 means exact and fixed resolution, and "scaling" using stretching algorithm. "Expanded" - meaningful term, but it makes this line too long. And we're short on space.
Volutar's problem is that nearest scaling looks like shit for any non-integer multiplier
It's not my problem, it's the ugly fact i'm not willing to ignore.
Essentially, it just dumps the Original 1.5x and 2x options and renames the "1/# Display" options to something more meaningful. I think the Expanded term makes clear that the purpose of scaling is for showing more of the battlescape. With "1/# Display" or "2x: 960x540" this isn't very clear.
Proposal is simple - make these terms more meaningful and more translation-friendly.
"Original" makes sense not to everyone, as "x1.5 Original". Only few people will understand that from first sight.
While "320x200", "480x300", "640x400", AND (if we don't care on length - which is bad, so we care)- "Zoom 3x Expanded", "Zoom 2x Expanded", "Zoom 1x Expanded" - are more clear. Maybe use something shorter, like "Zoom 2x", or "Expand 2x" (2x already means it's a zoom).
-
Another way is to abandon original basic resolution (only for software at least).
Will be only two options, resolution and pixel size. Pixel size can be any number that is divisor of both screen sizes.
Basic resolution will be screen size divided by pixel size.
-
Abandon is not an option. Long term isn't an option. Unclear terms with formulas referenced to other values are also not an option.
Clear, simple, and easily translatable short terms - that's an option.
-
Another way is to abandon original basic resolution (only for software at least).
Will be only two options, resolution and pixel size. Pixel size can be any number that is divisor of both screen sizes.
Basic resolution will be screen size divided by pixel size.
The problem with that is that many areas (such as the Geoscape) look terrible with expanded view because the menus and assets are made for 320x200. (See attached) The battlescape is more or less the only place where an expanded view looks fine. The game is made for 320x200 - that should not be abandoned.
Thing is - "original" doesn't mean much. 320x200/480x300/640x400 means exact and fixed resolution, and "scaling" using stretching algorithm. "Expanded" - meaningful term, but it makes this line too long. And we're short on space.
My view is that the end user doesn't need to know that Original is 320x200. All they need to know is that it's the default, unaltered view of the game, and that Expanded lets them view more than that.
Also, in my case, I said that "Zoom 2x" would be stripped from the title in the dropdown menu and put into its own slider. That way there's room for "Expanded" alone.
-
The problem with that is that many areas (such as the Geoscape) look terrible with expanded view because the menus and assets are made for 320x200. (See attached) The battlescape is more or less the only place where an expanded view looks fine. The game is made for 320x200 - that should not be abandoned.
Disagree. Geoscape looks perfect in 480x300 (The only thing is unstretched space background - but it's not too hard to stretch it). Though Basescape is indeed, too spacey. And I'd prefer Basescape to have it's own resolution.
My view is that the end user doesn't need to know that Original is 320x200. All they need to know is that it's the default, unaltered view of the game, and that Expanded lets them view more than that.
Unaltered?? SO why are we bothered with all these options? Let it be 640x400 zoom x2 like in version 0.3.
End user doesn't know what's ORIGINAL. He knows what's 320x200. It's the lowest possible.
Also, in my case, I said that "Zoom 2x" would be stripped from the title in the dropdown menu and put into its own slider. That way there's room for "Expanded" alone.
No you can't do that, because there's no space for anything else, even Basescape selector can't be fit.
-
Locking this as it's gone way off track and quite heated.
Feel free to start a new thread if you want to discuss screen scaling, and I do mean discuss, not argue.