1
Programming / Re: Holey supply ship
« on: June 01, 2015, 06:07:26 pm »
Well, I don't know what to tell you. hellrazor's modified map file is identical to the one in the universal patch.
Welcome, Guest. Please login or register.
Did you miss your activation email? April 25, 2024, 04:11:15 pm
Did you miss your activation email? April 25, 2024, 04:11:15 pm
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.
2
Programming / Re: Holey supply ship
« on: June 01, 2015, 05:37:28 pm »
It is fixed in the universal patch. 7saturn just didn't get the updated map because he loaded a savegame.
3
Programming / Re: Paletted 8bit -> 24bit shading.
« on: May 31, 2015, 10:03:17 pm »
I wasn't referring to the light sources, I meant how the graphics are actually darkened from lighting.
In EDGE, GZDoom, etc. you don't get reds turning into browns and such because it doesn't use the colormap for lighting. The map doesn't get darker further away from the player. The original software lighting shading is lost or only approximated. You can see an example here.
The same would happen for OpenXcom in 32-bit. That's the discussion; that allowing non-paletted sprites results in losing the paletted shading method.
If you go back and see the UFO TTS screenshot, you can see that darker tiles look a bit flatter and paler than they would with the 8-bit lighting.
It's not a really big deal, but just like Doom there is a certain charm to it that is lost.
In EDGE, GZDoom, etc. you don't get reds turning into browns and such because it doesn't use the colormap for lighting. The map doesn't get darker further away from the player. The original software lighting shading is lost or only approximated. You can see an example here.
The same would happen for OpenXcom in 32-bit. That's the discussion; that allowing non-paletted sprites results in losing the paletted shading method.
If you go back and see the UFO TTS screenshot, you can see that darker tiles look a bit flatter and paler than they would with the 8-bit lighting.
It's not a really big deal, but just like Doom there is a certain charm to it that is lost.
4
Programming / Re: Paletted 8bit -> 24bit shading.
« on: May 31, 2015, 08:12:28 pm »Employing something like the COLORMAP used in IDEngine1 for palette entries except with full RGB support for the different light levels of the respective palette entry* would likely be a good solution to this problem.X-COM already uses a similar palette method. That's the gradients you see in earlier posts.
* - the actual COLORMAP implementation uses palette entries that would visually look like a grayscale image with the pixel brightness indicating the palette entry number. This means we can't do anything we want since ultimately we're dictated by the palette. :^(
And I'm bringing this up because it seems like a way to do what you're looking for, while also providing a funky tool for modding.
The idea is to not have to use the palette. This is analogous to Doom's GL ports allowing 32-bit PNGs, with the same pitfall that in GL renderer you lose the original shading look, since they don't use the colormap at all.
As for my opinion, this is a question that almost every palette based game engine upgrade project reaches at some point (Doom, Quake, Duke 3D, and so on). There simply is no way to perfectly replicate the original shading while taking non-paletted sprites into account. The best you can do is approximate it with shaders or curves or forcing darker shades to certain step intervals.
I think there should simply be a video option for choosing yourself. 8-bit, which uses the vanilla lighting and makes 24/32-bit graphics map to the nearest palette color, or 24/32-bit which allows any color despite a less authentic lighting method. This is what most other projects do.
5
Programming / Re: Upgrading to the nightly
« on: May 31, 2015, 06:53:23 am »
I guess it's a bit late now, but would it be better for OpenXcom to look for UFO's files in the 'XCOM' folder instead? This would make OpenXcom work right out of the box by installing it into the directory of the Steam version, for example, without having to rename it. Of course it's still trivial.
Perhaps it could check either one?
Perhaps it could check either one?
6
Open Feedback / Re: What will happen in OpenXcom in 2015?
« on: February 12, 2015, 04:00:10 am »
Don't get me wrong, I love mods and I love that they add so much longevity to the game. That being said, a very large proportion of them tend to be crap, and in many cases things much of the community see as "must haves" completely alter the feel of the game such that I don't like the idea of "must have mods" in general (see Brutal Doom and all of its controversy within the Doom community if you want an example)
Everyone always has their own idea of what "the ideal (game name) experience" is. That's part of why mods exist in the first place
Everyone always has their own idea of what "the ideal (game name) experience" is. That's part of why mods exist in the first place
7
Open Feedback / Re: What will happen in OpenXcom in 2015?
« on: February 12, 2015, 03:51:10 am »Comunity edition mod? What that would be ?If my experience in other modding communities is any indication, a huge bundle of hundreds of different mods, many of them buggy or obsolete, with little consideration to how well they work together, often making the game even clunkier and less appealing than before
Personally, even today I think the only "Must Have" mod is Luke's UFO pack, and MAYBE the Cover Aliens since they are so well made and adhere perfectly to the game's original style.
8
Programming / Re: OpenXcom 1.1
« on: February 12, 2015, 03:37:18 am »Having the nightly gives some people the false impression that they have something stableI don't really understand this. It says on the download page for the nightlies that they are prone to having the latest bugs. Plus this is true of any other programming project out there.
If anything, I think it's mostly the fault of modders. I understand the need to use the biggest and best features, but it's the modders and not the devs in this case that push people to keep up with the nightlies rather than for testing purposes. In most other modding communities, people generally are reluctant to officially release mods using features unavailable in latest stable versions. If they do, they also make clear what build the mod is intended to work with. This prevents all the confusion you mention.
The other thing is: I have no idea where to get the info about what's new in a nightly and how to cope with it. Sometimes the XCom1Ruleset.rul changes and you can guess at what's needed, other times you can't. Is there a resource somewhere with informative content as to what was committed for those who can't read the OpenXCom code?Yeah, the changelog on the nightly download page describes changes, and so does the commit tracker on Github
I'm still not seeing the "adding features before fixing bugs" tendency that some of you mention the devs have. Look at the commits yourself. Almost every other commit is a bugfix. Much of the time the reason the bugs don't get fixed until later is that it is a while before they are even found, and usually are in fact uncovered by the addition of new features. Looking over code relentlessly does not yield anywhere near the amount of discovered bugs that users and testers are able to find.
9
Programming / Re: OpenXcom 1.1
« on: February 09, 2015, 11:52:30 pm »
The way I see it, adding TFTD support changes the internal structure enough that exclusively fixing bugs might end up being a waste of time since many areas end up getting rewritten anyways.
Besides, it's not like SupSuper is the only coder only working on TFTD. There is also bugfixing at the same time; they just merely don't warrant an official release.
The same justification applies to mod compatibility - the quest for TFTD also will alter the mod code, so going from a theoretical stable release between now and the TFTD release would just offset the compatibility complaints further down the line as more TFTD features get added to the nightlies. But once TFTD support is more or less finished, there isn't much more in the way of significant new features to add, so mod support will be less prone to breaking changes in future versions.
Besides, it's not like SupSuper is the only coder only working on TFTD. There is also bugfixing at the same time; they just merely don't warrant an official release.
The same justification applies to mod compatibility - the quest for TFTD also will alter the mod code, so going from a theoretical stable release between now and the TFTD release would just offset the compatibility complaints further down the line as more TFTD features get added to the nightlies. But once TFTD support is more or less finished, there isn't much more in the way of significant new features to add, so mod support will be less prone to breaking changes in future versions.
10
Open Feedback / Re: Sound is actualy very annoying
« on: August 29, 2014, 06:13:58 pm »
Your post isn't very specific. Maybe you should record it so we can know if there's a problem with it or not.
Otherwise, there were 2 versions of sounds. The 1.0 release and the later 1.4/Windows release had two different sound sets. You may just be remembering the other one.
You also could just have rose-tinted, uh, earbuds. The original DOS version was anything but high quality, the sounds were only 8-bit 8KHz, and the 1.4 sounds weren't much better (11KHz)
Otherwise, there were 2 versions of sounds. The 1.0 release and the later 1.4/Windows release had two different sound sets. You may just be remembering the other one.
You also could just have rose-tinted, uh, earbuds. The original DOS version was anything but high quality, the sounds were only 8-bit 8KHz, and the 1.4 sounds weren't much better (11KHz)
11
Suggestions / Re: HWP options
« on: August 04, 2014, 01:17:08 am »
It would be pretty cool to be able to rename HWPs just like you can with SHIVs in XCOM 2012. Though I'm not sure the best way to do that other than listing them in the SOLDIERS screen...
12
Work In Progress / Re: [SOUND] High Quality Sound Replacement Pack (44KHz/Stereo)
« on: August 04, 2014, 01:00:43 am »
Oh, my bad, I didn't see that you'd already started on this. There's been such an influx of new mods since 1.0 hit that I haven't kept up with what's new.
But yeah, that'd be fine. The main sounds I'm having trouble finding are the male deaths. I think the Plasma firing sound is a modified Laser Gun, Single Shot.
But yeah, that'd be fine. The main sounds I'm having trouble finding are the male deaths. I think the Plasma firing sound is a modified Laser Gun, Single Shot.
13
Work In Progress / [SOUND] High Quality Sound Replacement Pack (44KHz/Stereo)
« on: August 03, 2014, 10:17:22 pm »
X-COM's sounds are between 8000KHz and 11,000KHz, which just don't sound very good at all on modern sound equipment. But what to do, other than replace them with completely different sounds from other games?
I've talked about it before, and now I'm actually doing it. I found the sound library where all of X-COM's original sounds were pulled from, so that a 44KHz Stereo replacement pack could be made.
It'll take some time to scour through them all to replace each one.
Here is a preview of some I have found so far (however currently this is not setup to work in-game just yet) separated into 1.0 sounds and 1.4 sounds
Once I find them all, I'll get it useable ingame
I'm not sure how I should distribute this when it's done. Should I have two different versions for the 1.0 and 1.4 sounds, or should I do like one of my old mods and mix them so that things like pistols, rifles, and heavies use their own unique sounds? I think I'm going to go for the latter.
I've talked about it before, and now I'm actually doing it. I found the sound library where all of X-COM's original sounds were pulled from, so that a 44KHz Stereo replacement pack could be made.
It'll take some time to scour through them all to replace each one.
Here is a preview of some I have found so far (however currently this is not setup to work in-game just yet) separated into 1.0 sounds and 1.4 sounds
Once I find them all, I'll get it useable ingame
I'm not sure how I should distribute this when it's done. Should I have two different versions for the 1.0 and 1.4 sounds, or should I do like one of my old mods and mix them so that things like pistols, rifles, and heavies use their own unique sounds? I think I'm going to go for the latter.
14
Work In Progress / Re: [Request][UI] Open door button
« on: July 24, 2014, 10:50:24 pm »So the idea was to make an additional button for this. I think it's not bad if PC version will have this UI button, tooQuite frankly, I think the Android version just needs a new UI entirely. The buttons are entirely too small for a finger on 4 or 5 inch screens. There's been a few mockups in the old Android port thread.
I think the best place to start though would be if UI layouts and such were externalized. Then they could simply be handled by mods.
15
Troubleshooting / Re: Soldiers pass through the door..
« on: July 12, 2014, 08:53:36 pm »
Another fix would be the Universal Patch from OpenXcom's download extras page, because the original assets also have plenty of bugs besides that one