Author
|
Topic: Ur-Quan Masters HD Mod (Read 123492 times)
|
Defender
Enlightened
 Offline
Gender: 
Posts: 817
|
ah good thank you!
|
|
|
|
|
Logged
|
|
|
|
superbutcherx
*Many bubbles*
Offline
Posts: 116
|
I too would also like to see this as an option in the main build. I don't see that it would be that difficult, once the bugs are ironed out and the non-HD-specific changes are removed. One additional graphics menu option I guess, plus the same commandline option. But far be it from me to judge - I think you've done great, and it's worthy of applause.
Me too. Trust me, I'd love to see my artwork in as many people's hands as possible. But, it's a volunteer army. If somebody doesn't feel like spending all those hours doing it, I can't make them. So, if any other programmer would like to volunteer their time, I'd love it. I'll make an alternative suggestion. Even if you guys don't have the time/manpower to prep patches to the main tree, it would be a really good idea to branch the UQM-HD repository, so that you've got a vanilla version (where new changes related to the HD resolution would go) and a strawberry version (where any new changes unrelated to the HD resolution would go). You could set up the strawberry version to always pull the vanilla changes, so it gets them all. I suggest this because otherwise, the UQM-HD code base will probably continue to diverge from the core line, and we risk it turning into a full fork, which I don't think is in the best interests of the UQM community.
Hi, Elestan!
You are more than welcome to come aboard and help us implement either making the "strawberry" changes a new option tree into the setup menu - or branching the repository.
We are seriously understaffed on the programming side. Without additional workforce improvements like these are sadly pushed to "some time in the future".
|
|
|
|
|
Logged
|
|
|
|
|
|
dczanik
*Smell* controller
Offline
Posts: 306
|
I'll be out on a business trip for 2 weeks in February so it probably will be in March.
|
|
|
|
|
Logged
|
|
|
|
Elestan
*Smell* controller
Offline
Posts: 431
|
You are more than welcome to come aboard and help us implement either making the "strawberry" changes a new option tree into the setup menu - or branching the repository.
We are seriously understaffed on the programming side. Without additional workforce improvements like these are sadly pushed to "some time in the future".
I'd love to, but I only have a little time to spend on UQM. My current project is helping the core team port to a newer Windows compiler, since the Visual C++ 6.0 that it currently uses is so old that you can't find it anymore. Then I hope to implement something to make it possible to mod ships without being a programmer. After that I might be able to put some time into merging the HD mod, but that's a fair distance (months or years) into the future, and if in the meantime UQM-HD isn't merging upstream changes from the core, and is mixing other non-HD changes and refactorings into the HD code, then it makes an already hard task even more daunting and less likely to happen.
This is a question (really, two questions) on project definition and goals for the UQM-HD team:
1) What are the goals for UQM-HD 1.0? Is this a single-purpose project to bring HD graphics to UQM, or is it intended to be some kind of "Extended Edition" that also adds a bunch of other stuff? These two options are actually in tension, because every non-HD feature added makes it harder to separate the HD changes needed for the core. If the project's goals aren't clearly defined, then it's unlikely to reach them very quickly.
2) Is the project a development branch, or a fork? If it's a branch, then it has a responsibility to merge the upstream changes from the core team, to keep the two projects in sync. Merging code isn't as fun as adding cool new features, but it's really important in open source projects to keep them from fragmenting. Forks are easier to do, because they don't require that ongoing maintenance work, but they run a higher risk of actually causing harm to the community from which they arose. Quicker, easier, is the dark side. :-)
My opinion is that the best course for the UQM community at large would be if UQM-HD stayed focused on perfecting the HD capabilities until they were complete, and made a 1.0 release of those features first, before opening up the door to other changes. Obviously, since I'm not working on the project, my opinion has only as much weight as Dczanik and his team choose to give it. But it's well-intended, and I hope that any UQM-HD developers that are considering spending time creating some new non-vanilla feature will take a moment and consider possibly doing some of the less glamorous but very important merge work instead.
|
|
|
|
|
Logged
|
|
|
|
superbutcherx
*Many bubbles*
Offline
Posts: 116
|
1) As the lead programmer, I've opted to go for Extended. There are several small annoyances in the vanilla game that I'm very happy to have fixed in UQM-HD.
Like:
showing the value of biologicals when picking them up. Or partially scavenged minerals' remainders staying on the planet surface. Or the monochrome white lightnings and earthquakes now having a proper fading to grey. Or nameable savegames. Or logging the QS-HS hole coordinates into the QS starmap. Or when exiting a system on autopilot, automatically exit facing in the correct direction in HS. Or asking the player's name when starting the game.
And I see nothing wrong in throwing in some extras like SC1-style ship info screens available in the supermelee menu.
2) I am getting very proficient in tweaking the UQM code. However, I am not at all proficient in pulling code from a different tree, say vanilla UQM, and trying to match it with ours without breaking anything.
So it saddens me to see that there are a lot of people even in these forums who most probably would be by far more capable than me in managing a source code project - merging and branching changes between two source code trees... and yet very few of those people are willing to put in even an hour or two into something that would take me weeks to accomplish, and probably only hours for them to do. Talk is cheap, labor is priceless.
So until someone actually steps up to actually offer us some help, a fork this is.
|
|
|
|
|
Logged
|
|
|
|
onpon4
Enlightened
Offline
Gender:
Posts: 709
Sharing is good.
|
Regarding nameable saves: I'm pretty sure that's something vanilla UQM is supposed to have in the future.
To be frank, relying on volunteers to come along is not very reliable. It's perfectly normal for projects to mostly be one-man shows; even entire operating systems remain like this in some cases. If you take the attitude that someone will need to volunteer for the UQM HD code to get merged with mainline UQM, either you'll get lucky, or it will never get done. The only way to be sure it will happen is to take it into your own hands somehow; either go past your comfort zone and do it yourself, or raise some funds to pay someone to do it.
|
|
|
|
|
Logged
|
|
|
|
|
|
Defender
Enlightened
Offline
Gender:
Posts: 817
|
You know the main ship seems kinda skinny compared with the old one. Any chance of making it a tiny bit wider?
New build, if you have the time.
|
|
|
|
« Last Edit: January 19, 2013, 02:01:27 am by Defender »
|
Logged
|
|
|
|
dczanik
*Smell* controller
Offline
Posts: 306
|
2) I am getting very proficient in tweaking the UQM code. However, I am not at all proficient in pulling code from a different tree, say vanilla UQM, and trying to match it with ours without breaking anything.
So it saddens me to see that there are a lot of people even in these forums who most probably would be by far more capable than me in managing a source code project - merging and branching changes between two source code trees... and yet very few of those people are willing to put in even an hour or two into something that would take me weeks to accomplish, and probably only hours for them to do. Talk is cheap, labor is priceless.
So until someone actually steps up to actually offer us some help, a fork this is.
I've been meaning to try and do some of this kind of thing sooner or later, in particular creating a branch of uqm-hd without all the extra added features which make merging with vanilla UQM problematic. One problem is that uqm-hd code is in SVN, which I'm not really all that familiar with (and is fairly bad at handling branching/merging in the first place). Sourceforge should make it quite easy to set up a DVCS mirror though.
Well, I can assist any way I can. I've added comments of 'strawberry' to anything extra. It's really not much. Unfortunately, Google doesn't seem to let you search the comments (you think GOOGLE would have a better search than that). There are some gray areas though. Technically a new feature added, but they don't really change the game IMO.
r966: Added old hyperspace map from 2135. Press F7 to view.
r961: Modules, jets and thrusters are now placed correctly in the ending anim instead of a generic ship image.
r952: Ship info screens added.
r787: Outfit screen now prints unaffordable prices in red with parentheses
r699: Implement a basic fuel warning system for lander
r676: Now also the regular + and - zoom the starmap in and out instead of just the keypad ones. This should help people playing on laptops without keypad.
r656: Added a very simplistic point of no return circle.
r619: Partially scavenged mineral deposits' graphics now change size upon collection.
Like 966: You're adding the starmap, that used to be a big printout in the original game. People downloading the game don't have the luxury of a giant star map.
Looking at our list of changes our biggest ones are the lunar rovers exploding, and you can find the ruined remains of a ZFP colony.
You know the main ship seems kinda skinny compared with the old one. Any chance of making it a tiny bit wider?
That's up to Zenzmurfy or another 3D Modeler. But, no, he has to completely re-model it. I'm quite aware of this problem, and the effects it has on gameplay. I've found it not a huge deal in the single player game, and in multi-player you don't fly it.
http://code.google.com/p/project6014/wiki/ShipSizes
I tried to get those dimensions to fit exactly on my ships. My Kohr-Ah has perfect dimensions, but my Chenjesu is 2 pixels wider. It's very difficult to make them the same in 3D.
|
|
|
|
|
Logged
|
|
|
|
|
|
onpon4
Enlightened
Offline
Gender:
Posts: 709
Sharing is good.
|
If UQM is not just incredibly deceptive and it really does use precise, pixel-perfect collision detection, there's no way you're going to get that perfect in the HD mod, unless you use the original graphics as a mask for collisions That actually might be a good idea as an option. Probably not too important, though.
One thing I have noted before: particularly noticeable on the flagship, with the original graphics, it has different sizes depending on its orientation. It's a lot longer when it's at 45 degrees, and quite a bit shorter when it's vertical. I guess partly because the original SC2 was intended for 320x200.
|
|
|
|
|
Logged
|
|
|
|
Defender
Enlightened
Offline
Gender:
Posts: 817
|
Fattening the ship is more of an aesthetic standpoint. it's much too narrow for me. just thought i'd voice my opinion.
|
|
|
|
|
Logged
|
|
|
|
dczanik
*Smell* controller
Offline
Posts: 306
|
Fattening the ship is more of an aesthetic standpoint. it's much too narrow for me. just thought i'd voice my opinion.
Aesthetics aside, that would still require re-modeling the entire ship. That's not even mentioning re-doing the intro, ending, modules screen, shipyard screen, orbit graphics, & melee graphics to match the wider ship.
That being said, I agree with you. It's just a huge amount of work, and even in the original game the ship varies a bit (it's silver in the intro, the modules go from 16 to 12, coverings, no coverings, etc.)
|
|
|
|
|
Logged
|
|
|
|
Defender
Enlightened
Offline
Gender:
Posts: 817
|
just the ship in the planet/system exploration. everything else seems a reasonable size.
|
|
|
|
|
Logged
|
|
|
|
|
