31
Suggestions / Re: [GAME OPTIONS] Remove some "Advanced Options"
« on: May 02, 2014, 05:19:56 am »
I see no reason not to use "Inventory Extra Stats" at least. Why would you not want to know if you are overloading your soldier??
Welcome, Guest. Please login or register.
Did you miss your activation email? April 26, 2024, 03:50:41 am
Did you miss your activation email? April 26, 2024, 03:50:41 am
News: If you can't login, please contact us with your username and e-mail so we can fix it.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
32
Suggestions / Re: [GAME OPTIONS] Remove some "Advanced Options"
« on: May 01, 2014, 11:09:05 pm »
I think Airborne Transfers is fair to keep on. Force Craft launch and Alternate Movement do change the balance of the game however, so they should not be forced enabled. (The latter allows soldiers to move 50% farther each turn, as Ctrl-Moving enables a sprint mode that uses less TU but more Energy)
Things I think should be always enabled are things like "Inventory Extra Stats" (!!!), "Tilted Globe Lighting", "Enhanced Soldier Sprites", "Suppress Panic Messages for Aliens" and "Custom Initial Base"
Things I think should be always enabled are things like "Inventory Extra Stats" (!!!), "Tilted Globe Lighting", "Enhanced Soldier Sprites", "Suppress Panic Messages for Aliens" and "Custom Initial Base"
33
Offtopic / Re: the glitches with scrolling on the battlescape?
« on: May 01, 2014, 07:05:24 pm »
The thing is, there really is no accepted "speed" for Vanilla X-Com. It all depended on how fast your computer was. Every animation in the game relied on it. If you computer was faster, the explosions were faster, and vice-versa. My guess is you had one of the faster computers.
On the other hand, I wouldn't mind if they were sped up a little bit so that they weren't a lot longer than the explosion sound
On the other hand, I wouldn't mind if they were sped up a little bit so that they weren't a lot longer than the explosion sound
34
Suggestions / Re: A "kneeled" indicator
« on: May 01, 2014, 06:35:55 pm »
Only thing is...there isn't a pressed state for the Battlescape buttons. Click any button, they look the same throughout.
I suppose one can be made, of course. Or OpenXcom just simply darken it, that would eliminate the need for new assets
I suppose one can be made, of course. Or OpenXcom just simply darken it, that would eliminate the need for new assets
35
Translations / Re: Russian Translation
« on: April 30, 2014, 09:13:52 pm »Someone please stop volutar on GetLocalizationIt's part of an ongoing debate here.. Instead correct translation he sends total nonsense.
"1.5x" is "480x300", "1x" is "320x200", "Full Display" is "без увеличения" (without zoom) and so on. And he is not listen reasonable proposals, he think he always right. Now he just suggest me "shut up" and leave translation team...
I suggest holding off on this until SupSuper or Warboy can come to a final decision on how scaling should be presented.
36
Programming / Re: v1.0
« on: April 30, 2014, 07:59:50 pm »Another way is to abandon original basic resolution (only for software at least).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.
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.
Quote
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.
37
Programming / Re: v1.0
« on: April 29, 2014, 10:14:39 pm »Quote
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?? lolNo, 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.
Quote
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.
Quote
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"
Quote
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.
Quote
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.
38
Programming / Re: v1.0
« on: April 29, 2014, 09:03:18 pm »Frankly, neither of these explanations are understandable by me. What I understand is resolution - say, 800x600. This I can understand.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.
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.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.
If no scaling is used (e.g. Original) then the actual game resolution is 320x200, scaled up to whatever your output resolution is.
39
Suggestions / Re: Dedicated "Mods" folder, each mod can get its own folder to act as "data"
« on: April 29, 2014, 08:43:42 pm »
Yeah, Warboy already stated that that too is planned.
I think Name: and Description: will suffice, for now, at least for what's shown in-game
I think Name: and Description: will suffice, for now, at least for what's shown in-game
40
Programming / Re: v1.0
« on: April 29, 2014, 08:29:59 pm »Quote
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.
Quote
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)
Quote
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.
41
Released Mods / Re: [SOUND] Weapon Sound Variety
« on: April 29, 2014, 07:37:06 pm »
Yeah, I used CatPacker. I got it a long time ago, so I'm sorry to say I don't remember where. But it supports both the 1.0 and 1.4 file versions.
Just note that the 1.0 sounds are in a raw format, so you'll need to use something like Vox to convert them to wavs. They're also only 8-bit 8000kHz wavs, so trying to convert modern wavs down to that using modern tools is incredibly lossy. That's why I felt it best to load them via ruleset instead, since they can just use regular 32-bit wavs instead of having to cram them back down to 8-bit.
If I can find the original sound library that X-COM takes all its sounds from, I'd love to replace these with high-quality sounds.
Just note that the 1.0 sounds are in a raw format, so you'll need to use something like Vox to convert them to wavs. They're also only 8-bit 8000kHz wavs, so trying to convert modern wavs down to that using modern tools is incredibly lossy. That's why I felt it best to load them via ruleset instead, since they can just use regular 32-bit wavs instead of having to cram them back down to 8-bit.
If I can find the original sound library that X-COM takes all its sounds from, I'd love to replace these with high-quality sounds.
42
Suggestions / Re: Improved reserve for kneel, alien bleed out bug, and button change
« on: April 29, 2014, 07:32:55 pm »---New suggestion added:Grab a recent Git build. UI volume is on its own slider now.
For sound options it seems like the button select noise is much louder than every thing else. It would be awesome if I could reduce the volume just for that noise.
43
Open Feedback / Re: Officially Bundling With Steam?
« on: April 29, 2014, 07:18:46 pm »
Yeah, such a feature could be done by just having a button in the "New Game" screen. Of course, implementing this would take a lot of work and certainly wouldn't be ready by 1.0. That is, if it was an interactive tutorial and not just a few text screens explaining things. The former would be ideal, though.
But yeah, I could help plan out the actual tutorial when/if it comes time for it. I think the best way would be to have a simple prefab base (1 Skyranger hangar, 1 Interceptar hangar, the access lift, 1 barracks and 1 stores, and no soldiers/gear pre-owned.
Then, popup messages & greyed out menu options would direct the player to buy soldiers and weapons, then go back to the Geoscape to wait out time until they arrive. Then go through equipping them.
Then teach players about building facilities by having them build a lab and manufacturing plant, ordering scientists/engineers, and researching/building something simple like a Medkit.
After that, go back to the Geoscape and have a drone appear for teaching the player about Intercepting and shooting it down. After it's destroyed, have an "enemy base" appear that's just a prefab battlescape training course, and explain how to send soldiers there.
Then once landed, direct the player how to move/select units (by having one move to a specific tile) and then teach facing directions, opening doors, throwing grenades, shooting, things like that.
To keep it lore-friendly, it can all be set up as a training exercise, where no aliens are encountered yet. Targets are just wood targets or something similar. That way after completing the tutorial, your first real battles are still scary and stressful and you still get to have to figure a lot of things out on your own.
But yeah, I could help plan out the actual tutorial when/if it comes time for it. I think the best way would be to have a simple prefab base (1 Skyranger hangar, 1 Interceptar hangar, the access lift, 1 barracks and 1 stores, and no soldiers/gear pre-owned.
Then, popup messages & greyed out menu options would direct the player to buy soldiers and weapons, then go back to the Geoscape to wait out time until they arrive. Then go through equipping them.
Then teach players about building facilities by having them build a lab and manufacturing plant, ordering scientists/engineers, and researching/building something simple like a Medkit.
After that, go back to the Geoscape and have a drone appear for teaching the player about Intercepting and shooting it down. After it's destroyed, have an "enemy base" appear that's just a prefab battlescape training course, and explain how to send soldiers there.
Then once landed, direct the player how to move/select units (by having one move to a specific tile) and then teach facing directions, opening doors, throwing grenades, shooting, things like that.
To keep it lore-friendly, it can all be set up as a training exercise, where no aliens are encountered yet. Targets are just wood targets or something similar. That way after completing the tutorial, your first real battles are still scary and stressful and you still get to have to figure a lot of things out on your own.
44
Programming / Re: v1.0
« on: April 29, 2014, 06:43:05 pm »Quote
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)
45
Programming / Re: v1.0
« on: April 29, 2014, 07:31:20 am »
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.
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.