Hard Light Productions Forums
Archived Boards => The Archive => FSO Overhaul Project => Topic started by: portej05 on January 23, 2010, 01:56:57 am
-
Welcome to the Rendering Engine Overhaul Project.
This project is intended to investigate as many potential options for continued development and overhaul of the rendering engine of FreeSpaceOpen (FSO) as possible.
This will involve researching existing engines, the requirements of FSO and the requests of people involved in modding or coding for FSO.
There are a number of goals of the Rendering Engine Overhaul Project:
- Generate documentation for the FSO engine and components thereof
- Investigate and evaluate rendering frameworks
- Investigate, evaluate, write, modify and collect tools to enable coders, modders and artists to work more efficiently
- Generate interest in the FSO engine and hopefully bring new artists, coders and modders into the fray
- Develop future planning, directions and libraries for the graphics components of the FSO engine
- Efficient use and provision of resources available
If you know of a graphics coder or a talented technical-artist (someone who is able to understand the needs and wishes of both the artists and coders), point them in our direction!
Whilst this project is officially examining the the rendering engine of FSO, we are open to discussing other components of the engine and how they inter-relate.
This is NOT a requests forum or a help forum - posts containing requests (where not clearly asked for by the team) or requests for help with modding will be moved into the appropriate forum boards.
We are expecting significant discussion on the HOW and the WHY of engine components. Keep the politics OUT and the technical reasoning IN.
We are currently recruiting team members falling into the following categories:
- Significant graphics or platform coding and documentation experience (C and C++ desired but if you have coding experience with other languages we will help to move you to that platform)
- Significant and established software architecture knowledge and/or experience
- Significant FSO modding experience
- Experience with other 3D engines
- Significant 3D math experience or knowledge
- Significant art experience
- Established research and report writing skills
- Established documentation preparation and production skills
This is an extremely ambitious project - we need people who are dedicated to the project and willing to come with an open mind and significant technical skills.
PM portej05 to join the project!
portej05
-
First question:
We've already had an ambitious project like this, Ferrium. What's the guarantee that this project will not die, just like Ferrium did? I see this is "an extremely ambitious" project. Extremely ambitious projects have a tendency to aim at heights that are impossible to reach with fan work - however dedicated it is.
Second question:
How will you release your work? Will it be one big SCP build that you release yearly, or is it something like the SCP nightlies?
-
The first requirement is clearly to document how the current engine works in detail.
Even if that's the only thing that comes of the project, it is most definitely worthwhile.
- There's a lot of very obtuse code in there, which is preventing or delaying a lot of useful work.
By documenting everything, it opens up the ability to refactor the existing code.
This is what I see this project as being - not a replacement engine, but a refactored one.
Once it is refactored, we have an engine that runs identically to the old but is much easier to maintain.
So by isolating the sections of the engine, it makes it possible to add features and apply bugfixes or other improvements to individual engine modules.
-
Documenting it is certainly one of the very first steps. After that, after we have gained a picture of just how interconnected the whole thing is, we can see about separating it into a more logical layout.
-
Comparing this project to Ferrium is probably a little unfair. Ferrium was intended to be a complete rewrite of the engine, whereas this is intended to be an overhaul of the engine. Just from that alone, we have a better chance of success. There are two bolded goals in the original post - those are the partial success criteria, although I'd hope that we can achieve a lot more.
This is not going to be a totally separate project from SCP. The large amount of research referenced is to acquaint the team members with current engine and design technology and methodology. It is intended that this project will replace the current rendering engine (read the FAQ for why the rendering engine is a focus at this time).
Additionally, this project will be driven by a technological focus. Whilst we have not lost sight of things like retail (data) compatibility, etc, we do have a lot more freedom than within the original engine.
-
The problem Ferrium had was that it was an attempt to build a completely new engine and game at the same time. One of the main reasons for keeping backwards compatibility in the FS2_Open engine is so that we always have something we can run on the engine. On the day the overhaul is done we'll have a wealth of mods and games as well as the original FS2 to run on it.
Ferrium didn't have this advantage and therefore couldn't pull in coders from the outside world anywhere near as easily.
-
i probably meet at least 4 of the requirements, namely theese:
# Significant FSO modding experience
# Experience with other 3D engines
# Significant 3D math experience or knowledge
# Significant art experience
unfortunately the downside is i have a reputation for being a lazy bum, and would probably just get in the way.
-
@Nuke: Jump on #hardlight or #scp at some point and we'll set up a quick interview (to determine your technical strengths and how best you can contribute!).
We'd love to have you on-board :)
-
i probably meet at least 4 of the requirements, namely theese:
# Significant FSO modding experience
# Experience with other 3D engines
# Significant 3D math experience or knowledge
# Significant art experience
unfortunately the downside is i have a reputation for being a lazy bum, and would probably just get in the way.
Heheh... I'm pretty much exactly the same. A tad less FSO modding and art though...
-
Just a thought, but would the coders be able to finish some of Volition's unfinished stuff, like planets?
-
..........
That is NOT THE POINT of this project. We are not talking about adding features like that, we are talking about making the process to add features easier by redesigning and documenting the engine.
-
I know what the point is, I'm just saying if that was being considered at all.
Hm. Had a retarded moment there. Seemed to me like you guys were trying to rewrite the entire engine.
-
That was another project.
-
That was another project.
Right, but I was thinking that these guys were trying to do the same. Drr on me.
-
So I'm noticing people are completely ignoring the instruction not to post broad "use XYZ" suggestions...
-
I just ran across one of my topics about upgrading the model format, as I've said a few times the graphics engine can't get much better than it is while we use the old model format.
http://www.hard-light.net/forums/index.php/topic,47751.0.html
-
Should I move that thread over here?
-
Hmmm. Sounds good to me, since the SLDC stuff is already implemented but we still need to have enhancements in the engine.
But then, even having that link above is sufficient.
-
I've left the SCP and associated projects as of last week.
Chief1983 is now leading this project.
-
Well there is that whole moderator status to take care of then.
-
Sorted.
-
I've left the SCP and associated projects as of last week.
Chief1983 is now leading this project.
What happened? Don't tell me acrimony on he internet has claimed another victim? :(
-
Catch someone on IRC sometime if you need to know. This is about the Speedwagon (REO? Get it?)
-
I just ran across one of my topics about upgrading the model format, as I've said a few times the graphics engine can't get much better than it is while we use the old model format.
http://www.hard-light.net/forums/index.php/topic,47751.0.html
i did a quick re-read through the thread. and was curious if we could have 4x4 transform matrices on a per subobject basis. subobjects would be stored in their local frame of reference and then transformed by the matrix for final positioning. this would also allow each subobject to be rendered and collided separately from the model. this matrix could be computed against the parents transform so that each subobject mey be handled as any other model, requiring only a single extra matrix multiply, which could be performed on the opengl matrix stack. this would solve problems with transparency on subobjects, speed up collision detection and would help make subobject animation much easier and allow translation.
another idea might be to embed idx files within the model format, so as to eliminate the need for freespace to generate them, as they would be pre-converted for the engine.
-
I've left the SCP and associated projects as of last week.
Chief1983 is now leading this project.
What happened? Don't tell me acrimony on he internet has claimed another victim? :(
Let's just say I've moved on to other projects and leave it at that.
-
i did a quick re-read through the thread. and was curious if we could have 4x4 transform matrices on a per subobject basis. unfortunately FS uses a 3X3 matrix with an additional offset vector, and there is not really a way to change this
another idea might be to embed idx files within the model format, so as to eliminate the need for freespace to generate them, as they would be pre-converted for the engine.OH YES, ****ING TRUTH!
I think there was a thread or two in the internal where I had some slightly more detailed specifications listed out, but I can't check that obviously.
-
I guess I can do maths and coding.
-
In response to some possibly sarcastic comments by chief1983 on IRC about me having been listed as a team member,
I have got a decent amount of programming experience, much of it with OpenGL. And although I can't dedicate much time, I can offer occasional 'freelance' stuff. And as much as people may be sick having me around as an ideas guy, I do know a thing or two about graphics programming and theory.
-
i did a quick re-read through the thread. and was curious if we could have 4x4 transform matrices on a per subobject basis. unfortunately FS uses a 3X3 matrix with an additional offset vector, and there is not really a way to change this
another idea might be to embed idx files within the model format, so as to eliminate the need for freespace to generate them, as they would be pre-converted for the engine.OH YES, ****ING TRUTH!
I think there was a thread or two in the internal where I had some slightly more detailed specifications listed out, but I can't check that obviously.
i think that the internal forum should at least be readable to everyone, even if only scp members are allowed to post. im sure there are some intresting reads in there.
-
Also some interesting flames, unfortunately. Probably why it's internal :)
-
Also some interesting flames, unfortunately. Probably why it's internal :)
Roger that.
-
I hope you guys do a good job with this product, but whatever you guys do, don't screw up anti-aliasing (*cough* post processing in 3.6.12 *cough*). There is no feature out there that is worth making the game an aliased, noisy mess to get, and if you're destroying a major image quality feature to implement a minor one, you're doing it wrong.
-
Well post-processing is a major feature, but it still shouldn't have broken AA.
-
_post processing_ dos NOT break AA.
Bloom on the other hand, breaks it quite happily. And that is one hell of an age old problem even for DX games. (Look at the chuck patch for Oblivion for ATI cards if you doubt).
However, there are ways to make bloom and AA somewhat co-operate with each other.
-
Ok good to know. I thought I'd heard something like that before, but also thought that for a while it actually had broken AA in other ways besides just having bloom enabled.
-
_post processing_ dos NOT break AA.
Bloom on the other hand, breaks it quite happily. And that is one hell of an age old problem even for DX games. (Look at the chuck patch for Oblivion for ATI cards if you doubt).
However, there are ways to make bloom and AA somewhat co-operate with each other.
That's good to hear. So how do I disable only bloom from the post processing effects?
Bloom breaking AA in commercial games used to be a problem a long time ago, nowadays pretty much all commercial games implement bloom in a way that doesn't break AA. That doesn't stop them from finding new features that do break AA (Unreal Engine 3 deferred shading is the biggie nowadays, although there are ways to code in workarounds (batman:AA), or do a more costly driver trick to get the same result). Nowadays many developers are going after consoles, where anti aliasing doesn't matter so much because of the greater distance away from the screen. On the PC though, aliasing and shimmering is very noticeable and is a huge factor. I try to use super sampling whenever I can.
-
Hery had working patch which allowed both PP/bloom and AA to be used together. Unfortunately Hery announced he is far too busy with his work and personal project to continue coding for FSO. However, we've sent a request he would at least send us diffs of the patches he worked on, including PP+AA patch.
This is not strictly a rendering engine related, but there should be increased focus to break the limits of being stuck to one CPU core. Every single new feature that gets added, slows the game down because not even the fastest CPU is enough for FSO as long as only one core is being utilized. To make things worse, GPU processing power is not used at all.
FSO would be incredible little beast if it could properly use GPU's and multi-threading. Of those two, GPU would give the largest performance boost I reckon.
-
Fury`: FSO can't be multithreaded without rewriting a fair portion of the engine.
The data structure just aren't right for multithreading, and it would not be a fun thing to debug.
-
A man(or woman)/robot/zod can dream, can he/she not?
-
Well... considering that even cell phones will have multicore processors, I'd say at one point we have to support them.
The per-core performance currently doesn't increase that much anymore, but the number of cores increases even more.
Intel will release a six core cpu this year. AMD already has a 12 core cpu. (http://vr-zone.com/articles/amd-begins-shipment-of-12-core-magny-cours-cpu/8463.html) (Yeah, I know it's for server.)
When Intel releases a 12 core cpu with HTT, it will have 24 threads...
-
and I thought I was on the edge with my 8 cores.
-
The problem is still that the engine was never designed for that kind of abuse (and the lack of documentation certainly doesn't help).
FSO relies heavily on global structures, and synchronising access to those is likely to be an extremely difficult task.
Just think about what would happen if you tried to call the dereference operator on a vector at the same time as another thread was doing an insert or push_back operation (yes, particles, looking at you). You'll crash straight away and not know why, and worse still, it'll be an intermittent crash that won't show up easily.
Not to mention that MT is just difficult to start with. SCP does not have anyone with sufficient experience to do MT reliably in FSO.
-
and I thought I was on the edge with my 8 cores.
Well... if you have the money, you can buy a system with 48 cores...
http://cgi.ebay.com/NEW-TYAN-AMD-OPTERON-6174-G34-48-CORE-MAGNY-COURS_W0QQitemZ270529337772QQcmdZViewItemQQptZCOMP_EN_Servers?hash=item3efcce19ac
I'd really like to see the render times on that monster. Though that's the only thing I can think of that might use all cores.
The problem is still that the engine was never designed for that kind of abuse (and the lack of documentation certainly doesn't help).
FSO relies heavily on global structures, and synchronising access to those is likely to be an extremely difficult task.
Just think about what would happen if you tried to call the dereference operator on a vector at the same time as another thread was doing an insert or push_back operation (yes, particles, looking at you). You'll crash straight away and not know why, and worse still, it'll be an intermittent crash that won't show up easily.
Not to mention that MT is just difficult to start with. SCP does not have anyone with sufficient experience to do MT reliably in FSO.
I know it won't happen, just because it needs to happen. It's not like I know what the solution is either...
All I'm saying is, that when I have slow-downs in FSO, most of the time is caused by the CPU limitation, which is a shame, because FSO only uses one of my four cores.
The real question is: Does FSO have a future without MT?
If it doesn't, what can we do? Is nobody here interested in learning MT coding?
From here on I doubt we'll see many non-MT games anymore, except for small freeware titles.
In fact I think more and more games will not only use MT (more and more cores), but also make use of GPGPUs (via OpenCL, CUDA, Stream, ect.).
-
From my layman point of view, there are only three possible coding approaches to improve FSO performance significantly.
1) Multi-threading
2) GPGPU
3) Find code blocks that uses most CPU time and rewrite them for better single-thread performance
None of the three solutions are exactly easy, but FSO is not getting any lighter as new features are added, on the contrary. It's a fact that something needs to be done about the CPU bottleneck as soon as possible. If this does not get any developer focus, FSO will eventually hit a large wall where adding wanted features simply can't be done because most people don't own a CPU capable of running FSO anymore.
-
if we havent already, soon the engine will reach a point where no new cpu-intensive features will possible to add, and we will just have to dig in and optimize what we have, then just focus on gameplay features for mods, and that will be it.
other option would be to rewrite core components of the engine with multithreading in mind (although not quite possible at the time), one at a time. when enough of those core components are modernized then you look again at the possiblility of multithreading, at which point you convert over all the data structures to multicore friendly equivalents. sounds like a lot of work to me. but in the longrun it would be worth it. otherwise wel have an engine that will kinda fizzle out and die as people start modding newer games.
-
For example: While we are using SSE/SSE2 compiler optimizations, there are no references in the code for those defines for areas that might benefit (3D Drawing and OpenGL, I'm looking at you) where actual SSE/SSE2 written code (based on #ifdef likely) could be used for further performance gains.
-
The problem is still that the engine was never designed for that kind of abuse (and the lack of documentation certainly doesn't help).
FSO relies heavily on global structures, and synchronising access to those is likely to be an extremely difficult task.
Just think about what would happen if you tried to call the dereference operator on a vector at the same time as another thread was doing an insert or push_back operation (yes, particles, looking at you). You'll crash straight away and not know why, and worse still, it'll be an intermittent crash that won't show up easily.
Not to mention that MT is just difficult to start with. SCP does not have anyone with sufficient experience to do MT reliably in FSO.
I was under the impression that documenting the engine so that we could do exactly this was the point of the Overhaul project?
I agree that multi-threading is currently impossible to do in FSO (and I have only had a detailed look into cfile, talk about race conditions), but I do not think we are unable to do it. Personally, I think the best way to start multi-threading FSO is to work toward removing the usage of global variables in the engine and finish FSO transformation into a strictly object orientated engine, if only to formalize the engine internals and complete the documentation.
On the topic of GPGPU, one advantage of reaching for this target, especially using OpenCL, is that it would allow the use of multiple CPU cores if the user does not have or want to use the graphics card to do the offloaded features. One of the many reasons for not doing the GPGPU work on the GPU could be from only having one GPU (and not enough spare time and/or bandwidth to actually speed up the game). As I think was stated before, the most obvious (in my opion, of course) would be the physics engine which I assume includes the collisions for weapons and ships.
-
I don't believe it's something beyond the coders here either. But it is a huge task and we can't expect the mods and TCs to wait for it.
My suggestion would be to do the same thing I suggested for the graphics overhaul. If you did want to add multi-threading to the engine, you'd split a branch off from trunk, get multi-threading working and then patch any features added to trunk in the intervening months (or years!) back into the new, improved code. That branch would now become the default FSO code and the old, single-threaded branch could be forgotten about.
The question is whether there is anyone willing to do all that? If there is I wish them luck. :yes:
-
My suggestion would be to do the same thing I suggested for the graphics overhaul.
Wouldn't that be in practice impossible to do? I mean, you have two or more branches in which people are overhauling major parts of the engine. Each branch would probably end up overhauling same code as well, for different purposes. Then you'd have to merge changes from not only main branch, but those off-branches too.
Sounds extremely hard to pull off.
-
You'd only do one at a time. Only an idiot would attempt both. :D
-
Indeed? I see several problems with that.
- Overhaul projects will probably end up taking years to complete.
- During these years, people and priorities change.
- We have no multi-threading experts on SCP right now, but the need for multi-threading is pretty much immediate due to performance issues we're having right now.
- With Hery gone to other projects we don't really have graphics experts right now either, but graphics overhaul seems to have larger momentum even though there is no quite as big need for it. Unless you can drastically reduce CPU usage with just overhauled graphics engine?
Anyway, I have my doubts sequential overhaul projects are going to really work because of the first two points.
-
Well you could try doing both using the same branch. What I mean is that only an idiot would try having a graphics branch and a multi-threading branch, as you said, too many things need to change in both branches.
Of course that means that the amount of planning you need to do goes way up.
-
It would be an interesting test of version control merging though. When is this going to turn into the "refactoring project"?
-
I already mentioned it earlier in this topic, but the fastest way of getting some results in breaking this CPU bottleneck would be concentrated effort in code optimization rather than new features. Might be worth giving it a short for 3.7.0? Only finish the features that couldn't be completed in time for 3.6.12, but focus only to bug fixes and code optimization? If this concentrated code optimization period is met with success, I believe there would be a lot of happy people.
I mean, higher and smoother framerates, what's not to like? :)
Edit: Hell, Darius gave his permission to give BP SVN access to any SCP coder who needs access to a mod that is stable, most of the time error-free and wastes plenty of system resources if that's what is needed to optimize code. :) *cough* carrot *cough* :D
-
Wouldn't that reinforce the obstacles to making major changes?
-
Edit: Hell, Darius gave his permission to give BP SVN access to any SCP coder who needs access to a mod that is stable, most of the time error-free and wastes plenty of system resources if that's what is needed to optimize code. :) *cough* carrot *cough* :D
Fury`: Carrot is all well and good, but there are other issues :) I will add that BPSVN is one of the best ways to performance test the engine.
karajorma: Your idea cannot work. What happens when an interface changes that mean that the 'features' can't be easily ported to new structures without a _LOT_ of work? (and that's the whole point of the branch you suggested)
-
Then that feature has to be reevaluated. If it cannot be made to work with the new architecture, it should be dropped, if only to ease the process of designing and switching over to the new architecture. If that feature is deemed critical (for whatever mod), then it should be put on the fast track toward reimplementation, but getting the engine on a surer footing has to have priority.
-
karajorma: Your idea cannot work. What happens when an interface changes that mean that the 'features' can't be easily ported to new structures without a _LOT_ of work? (and that's the whole point of the branch you suggested)
Well there you have the catch 22 which made me suggest that in the first place. Either you branch or you basically tell the mods that they won't get any new features for however long it takes to add multithreading or better graphics. Given that you are talking about years rather than months you're almost certainly going to lose the support of all the TCs and most of the mods if you try it.
The_E is spot on with the solution. You reimplement the feature as fast as you possibly can. And if for some reason you really, really, really can't reimplement it then it means someone ****ed up. Either the overhaul team cocked up the redesign of the engine cause any features that major should have been mentioned as part of the Hosted Projects Collaboration and they should have known it was coming or the mod/TC ****ed up by not having it on their list, in which case it's their problem.
-
Also seems to me that Portej05 suggested a similar approach on IRC yesterday but now is against it because it would require work.
-
At some point you're going to have to break something.
Look at the mess you're in with the cutscenes - one mod has done things one way, another mod wants things another way.
That's the kind of mess you get into when all you worry about is what mods think. You have to be more proactive - the mods need to use what you provide.
If the mods know about the changes that are coming, they can adapt.
-
And you have to realize that the mods are the clients of the SCP. Without them you would have an engine that no matter how good would sit on the shelf. That is why backward compatibility is one of the golden rules. You don't tell clients what to use you give them the product they want or you don't have clients.
This doesn't even get into the support nightmare removing a feature would cause. You would have years of post of why doesn't so and so work. I followed the install instructions but it wont run.
-
I don't see how letting every 'client' dictate how things should be done helps; especially when they apparently have different/conflicting visions of how it should work.
It doesn't seem that limiting to require any new non-trivial feature to have an upgrade path to the new version of the engine given say a design doc of how the new version will fit together.
And on the topic of missing features: why won't shadows work for me anymore?
-
I don't see how letting every 'client' dictate how things should be done helps; especially when they apparently have different/conflicting visions of how it should work.
There's a huge difference between letting clients dictate how things should work and actually asking them for suggestions on how things should work before trying to code a solution that pleases the greatest number though.
And both of those are very different from saying "**** the clients. I'm going to make it work how *I* want and they can learn to like it"
-
portej05 isn't advocating that either, but becoming incapable of finishing a feature because of a futile attempt to please everyone fully can't be allowed to happen.
-
Of course you can't please everyone. Which is why The_E's post mentions a fairly good compromise.
-
a major overhaul is gonna cause things to break, theres no way around it. theres only so much optimizations and bugfixes can do. its not about pissing off modders, its about preserving the engine's usefulness.
-
Archiving the subforum due to the departure of portej05 and Hery, and also due to the fact that current evidence strongly suggests any overhaul would be an epic failure.
-
Wouldn't want to talk that over with me first? I was left in charge after all.
-
Oh? I thought it was almost entirely portej05's and Hery's beast.
I'd be more than happy to talk it over with you though. I'll catch you next time on IRC or IM (can't run either at the moment).
-
Archiving the subforum due to the departure of portej05 and Hery, and also due to the fact that current evidence strongly suggests any overhaul would be an epic failure.
From this discussion, I did not get the impression that this project would be an epic failure. I got that it will be a long hard project, that could potentially piss people off.
To those that are worried about the Engine Overhaul Project (EOP) breaking things, and those that want the EOP to break things. An engine that does not have any content to run will never last.
The thing is, even if the project falls short of actually changing any code in the engine, the first step of the project, documenting the current behaviour, will still be useful to future work on the engine. I think karajorma and The_E have the best idea, when we get to the point of designing the route we are going to take (which will be a while yet as we have not really started to even document the engine), asking everyone, especially the TC's to list the features that they are currently using and would like to see would be the best way for the EOP to result in an engine that content makers will actually use.
Yes this project has drawn strong criticism from members, but this is because none of us want to see FS2Open, Freespace, and all of the mods and TC's just fall into obscurity after 10 years of going on.
Edit: Clairified, and added second paragraph.
-
Hmm. Goober5000 is:
An SCP Project Leader? Check.
A Hard-Light Administrator? Check.
God? Fail.
Not the best decision I've seen made.
-
An engine that does not have any content to run will never last.
News flash: The FSO engine has no shortage of content using it, and more is being created every day.
The thing is, even if the project falls short of actually changing any code in the engine, the first step of the project, documenting the current behaviour, will still be useful to future work on the engine.
Agree, but this does not require its own separate forum. Even if it did, using the "overhaul project" forum would be misleading.
Yes this project has drawn strong criticism from members, but this is because none of us want to see FS2Open, Freespace, and all of the mods and TC's just fall into obscurity after 10 years of going on.
Utterly false. This project has drawn strong criticism because of the way it has been conducted and the quality (or lack thereof) of the work that has been done so far.
God? Fail.
Hyperbole? Fail.
Basically, this project was starting to trend towards the old disasters of shoddy, unmaintained (and unmaintainable) code, and was already bearing rotten fruit. Based on what it has accomplished so far, the best solution is to isolate it and let it die off. Otherwise it would be like a parasite feeding off a host.
-
Perhaps we should start a Documentation Project though. That's something I could sink my teeth into.
-
Yes, as we have sort of agreed, any overhaul is dependant on building some documentation beforehand.
Having a separate subforum for that to coordinate matters might be a good idea. It's easy for threads to get lost.
-
An engine that does not have any content to run will never last.
News flash: The FSO engine has no shortage of content using it, and more is being created every day.
Thank you for taking me out of context, the comment was *not* directed at you Goober5000, but those that are worried about the project breaking the existing content or the engine being rendered unable to do anything. I guess unless you are one of the ones that is afraid of the engine being broken by the project. In which case, I reiterate, the goal of the overhaul project is not to break the engine, but to modernize it so that will be set for the next 10+ years.
I have also updated my quoted post to help clarify this, I admit the original version was not as clear.
The thing is, even if the project falls short of actually changing any code in the engine, the first step of the project, documenting the current behaviour, will still be useful to future work on the engine.
Agree, but this does not require its own separate forum. Even if it did, using the "overhaul project" forum would be misleading.
Misleading in what way? Yes, the documentation part, which is only the *first* part of the overhaul project, does not really require its own forum. But as the first stage of the larger project that does require a separate forum (if only for organization sake). There is no reason that all of the stages of the project use the same forum.
This is one of those "shoot for the moon, even if you miss you will land among the stars" type projects. Just because you (Goober5000) do not think the project will be successful or completed does not mean that this is what will actually happen. I know, I know, you have the experience with the SCP, but cutting it off before it has even failed? Really? Especially when there is some semitrance of consensus on the way forward?
Yes this project has drawn strong criticism from members, but this is because none of us want to see FS2Open, Freespace, and all of the mods and TC's just fall into obscurity after 10 years of going on.
Utterly false. This project has drawn strong criticism because of the way it has been conducted and the quality (or lack thereof) of the work that has been done so far.
So you don't care if FS2Open and its related content falls into obscurity because the engine slowly become useless on modern machines? As Nuke mentioned (http://www.hard-light.net/forums/index.php?topic=67715.msg1353263#msg1353263), "[The Overhaul Project is] not about pissing off modders, its about preserving the engine's usefulness."
Or is it that the overhaul project has not actually produced any concrete? If so, I address this below.
"... [T]he way it has been conducted..."? What is wrong with the way it has been conducted? I only see some passionate people arguing over the destiny of their favourite space game engine. Even within the arguing their was a semblance of consensus on how the Overhaul Project was to proceed, as mentioned above by me and by the The_E in the post he snuck in while I was typing.
On a related topic, you (Goober5000) wanted a Mailing list, because other serious open source projects have them. As we reminded you on IRC then, the forum of the discussion has nothing to do with the "seriousness" or the quality of the project. The "seriousness" of a project rests entirely on its ability to get things done and to have mature, logical, and open discussions about the future of the project in the so that all stakeholders (ie. the mods and TCs) have knowledge about and the ability to provide input on the changes.
"Serious" opensource projects do not have a site administrator shelve the project because he feels that a project has not done anything useful, when it still has a leader and in still in the planning stages with active discussion. It would be one thing to have the current project leader (http://www.hard-light.net/forums/index.php?topic=67715.msg1345239#msg1345239) request the archival, but based on his response to the archival, it was obviously not his idea.
God? Fail.
Hyperbole? Fail.
Basically, this project was starting to trend towards the old disasters of shoddy, unmaintained (and unmaintainable) code, and was already bearing rotten fruit. Based on what it has accomplished so far, the best solution is to isolate it and let it die off. Otherwise it would be like a parasite feeding off a host.
What code? As far as I know the only thing that has come out of this project thus far is the 70 some posts in this forum. This project was never intended to be a quick "fix" for the engine, it has always being a long term project. I don't think anyone that has participated in this discussion does not understand that this project will take time.
How can this project "trend towards the old disasters of shoddy, unmaintained, unmaintainable code" when no code has been written? Are you prophetic now? What rotten fruit has this project bared? A discussion about FSO's future? The idea that we can and should do something about the 1990's coding style? One of the original project leaders has left in a huff? Another has decided that his own projects would be a better use of his time? No code thus far? That the members cannot decide on how to go about implementing the big features that have been brought up?
Now, do not get me wrong, old code is not a bad thing, but FSO is turning into a mishmash of everything, every style and more hackish with every new feature and as a result is becoming more inconsistent and harder to read and pickup for new coders. Making the code accessible to new coders is what allows "serious" open source projects to grow, especially if they have chip on there shoulder like our licence.
-
I'm really sad it turned out this way.
I really thought the FSO might have a future thanks to this project. Maybe I was a bit too optimistic.
There is incredible much work to do and I don't think I can blame anyone for not being willing to do it. Especially considering I could have only been an advisor until later when new content might have been needed.
I think the most serious issues are:
-The collision system can't handle complex models (causes holes)
-The limitation to one core
-We can only use one shader depending on the maps on the model
-Mapping channel limitation
-Less than basic particle system, so we have to waste tons of memory on frame effects
On the other hand there are many nice things too:
-FSO is still very open for modding
-A huge feature set (sometimes people forget how many things can be done in FSO...)
-Pretty good tools
-The flight behaviour still feels great
-Powerful mission editor
-Wiki (hey, it's really not bad!)
-Great community
Is there anything we can do? I don't want to give up on FSO...
-
We lost the bulk of the manpower we currently had available at the time for this project, including the original leadership. There's virtually nothing that could be done right now to approach where we were going with it but there are some things we can do in the meantime. Like I said, we might as well get the documentation part going as that's going to be useful no matter what.
-
Color me really confused here, and as a non-technical person I most likely am, but where did this whole concept of "FSO has no future without this project" spring from in the first place? Exactly why would the engine just "fall off into obscurity"? Correct me if I'm wrong, but in today's gaming world, the space sim market is pretty much nonexistent, and the open-source space sim engine market even more so. This isn't the world of FPSes, where there are probably a good six or seven highly-moddable engines out there that would be idea for your average mod project along those lines. For anyone looking to put together a large-scale space-combat-based sort of mod, FS2_Open is pretty much the only ready-made option available out there; even without the Source Code Project, it has to be just about the most easily-moddable space sim ever released. The fact that we currently have active projects from multiple sci-fi universes utilizing the engine is a clear testament to that.
Now, am I saying that the engine isn't in need of significant improvements? Of course not. Actual members of the team know far better than I exactly what needs to be done, but even I could tell you that there are several areas where there's massive room for optimization and expansion. But at the same time, I don't see this as being some sort of do-or-die scenario. I hear people talk about terrible collision-detection and lack of multithreading, but what I've seen with my own eyes is my crappy old P4 machine be able to handle even Blue Planet's huge set-piece missions without slowing to an unplayable crawl...and that's with a video card that was low-tier even when it was created six years ago. Yes, certain things need fixing, but even as it stands, the engine responds pretty damn well when placed under duress.
You guys have already done an amazing job with this engine, and it's my belief that, even were all development to cease right here, the FS2_Open engine would continue to be relevant for some time to come. Don't sell yourselves short. :)
-
I'm going to lock this for now and I'll reopen it in 2-3 hours (after my class) when I've said my piece. It seems to me that both sides are needlessly annoying each other and creating animosity where none is needed.
-
OK time to make my position on the Overhaul Project clear because I suspect it's one that most of the SCP will agree with but this thread shows that if someone doesn't intervene everyone would take corners and bicker away about it.
Goober is obviously worried that the Overhaul Project will be another Ferrium. Bleeding coders away from the SCP for a project that is doomed to fail. I doubt that there is anyone here who would want that to happen. Yet it is also obvious that with Portej05 and Hery gone this project is already short-staffed (hell, it was short-staffed with them, let alone without them).
Others are worried that sooner or later major parts of the engine will need to be overhauled. If this isn't done, sooner or later the engine won't be able to compete with modern engines and will slowly bleed away as people get sick of its limitations and poor performance compared with other engines.
As I mentioned several times to Portej05, talk is cheap, it's action that speaks volumes. Designing the overhaul (no matter how much work is done on it) won't help us at all if no one is going to actually do it. So what I propose is this.
1) We shelve the Overhaul Project for six months
2) We make a concerted effort by the SCP to improve the documentation of FS2_Open and to profile and refactor the code which currently causes the greatest slowdowns. Goober mentioned having a list of some of the biggest bottlenecks provided by Taylor, I say we fix those now as they will give the code an immediate boost, something that is worth having. Even if we eventually do work on an overhaul this refactoring would keep FS2_Open performing well for quite some time and thus would allow mods and TCs to work with a powerful engine while whatever changes were made.
3) We make an effort to find and improve the worst code in the engine. The stuff that causes lots of bugs. Taylor has been doing this for a while with his pilot file change and I've taken a few steps of my own in this direction by getting rid of block variables and all the crap they caused. I intend to do more of this.
4) We reinstitute and this time enforce the rule that no coder can commit new features unless they have fixed a certain number of bugs or refactored a certain amount of crappy code.
5) In six months we see where we are. If we have good documentation and large sections of the code have been improved then we have proved we have a team capable of an overhaul and we can start discussing one. If on the other hand very little has changed then it would be stupid and egotistical to think we have team capable of taking on a task as major as overhauling graphics or adding multi-threading.
-
It is a solid plan. I like it.
-
Sounds like a plan.
[snip]
Goober mentioned having a list of some of the biggest bottlenecks provided by Taylor
[/snip]
Again this list as been brought up. Why has this not been posted publicly so that everyone can read it?
Also, if we are going to improve the code, we MUST have a coding style written down so that anyone that wants to contribute code to the engine knows beforehand what is acceptable code.
-
As usual, karajorma is the more diplomatic one. :) Chief1983 pointed out that I wasn't very tacftful, and for that I apologize.
For the record, when I saw that both portej05 and Hery had left the project, I figured that the project was abandoned and leaderless. I missed the post where portej05 handed it off to chief1983, and as soon as chief1983 corrected me I apologized to him. Even so, chief1983 agreed with me that the overhaul project in its current form is a dead end.
Again this list as been brought up. Why has this not been posted publicly so that everyone can read it?
Taylor has posted it in the past. But, scanning through his post history, these items come up:
model collision
model animation
sound
pilot file
dynamic limits for ships and weapons
a crapload of bugs that are currently in Mantis
Taylor posted a longer list at one point, but I can't find it right now.
-
21:08 portej05 karajorma: You still here>
21:08 NickServ Password accepted -- you are now recognized.
21:09 karajorma Yeah
21:10 portej05 Thank you for updating your post
21:10 portej05 I thought I'd share some of my thoughts
21:10 portej05 Especially before goober goes on a micro-optimisation witch hunt
21:11 portej05 Sound is already a fairly separate system with a not-badly defined interface
21:11 portej05 It can be threaded without much effort at all
21:12 portej05 Define a job queue which effectively represents an inter-thread communication structure
21:12 portej05 Define a sound thread which just loops around pulling jobs off and executing mixing
21:12 portej05 You suddenly remove 90% of the sound engine from the main execution thread
21:12 portej05 (with not a huge amount of effort, I might add)
21:12 portej05 You may not even have to update sound api calls throughout the engine - just redirect the current calls to something like mt_sound* through the thread interface
21:13 zookeeper yeah, looks like it's drawing all faces...meh.
21:13 karajorma The amount of time the game is spending in the sound code seems to change depending on which kind of profiling I use though
21:14 portej05 Still, it's one chunk demonstrating the concept for not a huge amount of work
21:14 karajorma Fair enough
21:14 portej05 Especially given that it's probably one of the better interfaces in the system
21:15 portej05 But can you see why you'd have to freeze development on the feature, even briefly to be able to do it?
21:15 karajorma Not really
21:15 portej05 The interface has to remain stable during the work
21:15 portej05 I don't think I communicated that well enough the other night
21:15 karajorma But that's an argument I've already had enough times
21:16 portej05 We haven't fought over stable interfaces....
21:16 karajorma We have over development freezes though
21:16 karajorma And I'm not doing it again
21:17 portej05 So how would you go about the above then?
21:17 karajorma We can worry about it when someone codes it
21:19 portej05 Who's saying that there isn't someone who has been thinking a lot about how to implement it?
21:21 karajorma Well Taylor is busy with the sound code now, you can always suggest this to him
21:23 portej05 The new sound code is headed for Antipodes - it's almost finished
21:23 karajorma All the more reason to PM him now
21:23 karajorma Best time to work on a new sound code feature is when you've just finished one
21:24 karajorma the code is still fresh in your mind
21:25 portej05 How about I just stick the above on the forum and you can PM him a link?
21:25 karajorma That would do
-
*_*
-
Take your FUD elsewhere, we don't want any :P
-
*_*
-
FSO is not going to die some swift, mysterious death without the full-scale implementation of multithreading. It may hit certain walls in terms of possible performance, but I hardly see how that automatically equates to the developer/modding community shriveling up and disappearing.
-
Like FSO was packed with such power hungry features that nothing else but multi threading helps anymore..
I'd like to hear about *one* feature that would be (realistically) relevant for FSO, but is not doable without multi-threading?
-
Oh, multithreading isn't mission-critical. However, there are aspects of the engine that can be threaded, which would free up resources to use by the main thread. The sound interface, for example. Or asset loading.
In the end, it's a bit of future proofing. If we extrapolate current trends, we can see that there will be only marginal improvements in single-thread performance in the future, as a result, if we want to use the power modern PCs give us efficiently, multithreading is something we should be thinking about.
That being said, as Goober pointed out, there are still areas of the code that can be improved for massive gain without altering the core concepts of the engine; since that is a more realistic goal, it's the one we're probably going to pursue.
-
FSO is not going to die some swift, mysterious death without the full-scale implementation of multithreading.
Nobody said that. We're just worried about the future of FSO. For now, it's still 'ok' to use only one core.
The CPU limitation of FSO is quite obvious though.
And no, the CPU load isn't that horrible, when you play FS2.
However, once you put some more complex content in there, some of the outdated parts of the engine really get in your way.
Imagine putting in a fairly complex model into FSO. A really big and important ship and lets say it has 160k polygons.
That's a lot, but really not that big of a deal for any gfx card that isn't completely outdated.
Instead of the graphic system, the collision code will drag the performance down a lot.
The game becomes unplayable when you put many of them into your mission.
Now imagine you have one of those new Intel 6 core CPUs with HTT and only one of the 12 availabe threads in your task manager is at 100%, while all the others are at ~0%.
I think the problem is less FS2, but the mod projects. They need to be able to get more out of the game.
Edit: I hope nobody sees this as a rant. I'm not blaming anybody there and I'm not telling the coders how to do their jobs.
I'm just concerned and I really know that this is not an issue that can be solved easily.
-
is the colision code realy that bad? I always thought it was fairly quick and would scale well to larger models.
-
From my experience I can tell the collision detection is currently one of the bottlenecks. Maybe even the worst one.
It also doesn't work very well for big objects.They tend to get holes in the collision.
Maybe PCS2 could fix that, but I fear it might be a limitation in the collision code.
There is a way to use simplified collision meshes, which boosts the performance a lot. (In a test with complex meshes I got from 25-30 fps to 120 fps)
However, it's more or less a workaround. There are still holes in the collision with the simplified meshes.
-
There is a way to use simplified collision meshes, which boosts the performance a lot. (In a test with complex meshes I got from 25-30 fps to 120 fps)
However, it's more or less a workaround. There are still holes in the collision with the simplified meshes.
Care to elaborate on this? How do you create simplified collision meshes? What are the disadvantages?
-
High poly models are good for viewing, but when you don't need the same complexity for collisions.
For example, a sphere with millions of polygons can be represented roughly as a dodecahedron - a massive saving (it's an exaggerated example, but that's the point). You just have to load one representation into the graphics system and the other representation into the collision code.
-
So basically, say, loading detail1 into the collision code instead of detail0?
-
What portej05 said. We only need the vague shape of the mesh for collsions.
It's a very common thing to do in games. In fact, I doubt there games out there that still use all draw meshes for collisons.
Here is an example from the Unreal Engine 2:
(http://udn.epicgames.com/Two/rsrc/Two/CollisionTutorial/show_karma_prims.jpg)
And this is an example from SoL.
(http://i32.tinypic.com/11iny2x.jpg])
We made collision meshes for our models. Like I said, the performance gain was incredible, but the holes in the collision remain and even though it's kind of hard to tell, I think they are bigger.
Sushi implemented a feature to turn off collision detection for submodels by simply putting these flag in them.
$nocollide_this_only: If this flag is set, then the submodel it is set on will NOT have collision detection. Put this flag on the high-poly "pretty" version of the mesh.
$collide_invisible: If this flag is set, than the submodel it is set on will allow collisions even for invisible textures. Give the collision model the invisible texture as well as this flag.
So basically, say, loading detail1 into the collision code instead of detail0?
Well, I wouldn't reccomend it.
Yes it would help a lot, but lods are ment to keep up the visual quality has high as possible with less polygons. In terms of collision detection they are still wasteful.
Also they often end up below parts of the lod0 mesh. Think about hit effects. You do not want that. In fact if your collision mesh is slightly above the draw mesh surface it can even improve the visuals, as the hit effects might not intersect with the draw mesh anymore.
-
Does FSU models use this method?
And why is this the first time I hear of this anyway? If this has such huge gains, why it is not used widely in FSO models?
-
No, FSU isn't using this yet. It's a little bit complicated to add collision meshes to existing POFs.
With a few tweaks in PCS2 that might not be an issue in the future. *
As long as we still have holes in the collision, I'd advice to stick to the current system.
* Importing another POF or even DAE works very well, but it's has to use the "invisible" material. You can add new materials/textures, but you can't assign them to a mesh... New textures won't be imported either.
-
If SoL is using this now, does this mean PCS2 and collision detection will be updated in the near future? Or why is SoL using it when you say it's not recommended yet?
-
We've created the models to see how well it works.
So far every model I imported the new mesh into had holes in the collision afterwards, so none of them is currently used in the game. We're just prepared to use them once this works better.
Preparing the models already is not a bad idea, but I don't know when and if the collision issues will be fixed.
-
This should probably be turned into a Mantis issue/feature request. (Unless it already is there, and I just missed it)
-
This might be reviving an old horse, but isn't that what's commonly called a hitbox in 2D games?
It's really easy to see how it would improve on performance, i hope this can be implemented correctly.
-
This might be reviving an old horse, but isn't that what's commonly called a hitbox in 2D games?
It's really easy to see how it would improve on performance, i hope this can be implemented correctly.
Yes, a hitbox is exactly what it is. Some 3D games still call them exactly that. Though it seems FSO has settled on calling them collision meshes.
Ya, the value of collision meshes is so strong that I am surprised that this was not already done.
-
Ya, the value of collision meshes is so strong that I am surprised that this was not already done.
This is almost certainly because the core of the engine appears to scare everybody.
There has been very little work done in the guts of engine recently - this isn't scientific, but the svn history of modelcollide.cpp has only 5 commits since 16th March 2008.
- The whole of the model folder has 64 commits, mostly animation, table and SEXP related.
Obviously, none of this gives any indication of how significant or difficult any of these changes was, but it is indicative of how little work has been done there recently.
(There aren't any valid metrics for importance or difficulty. A one-character bugfix could be amazingly hard and important, fifty lines of code could be trivial)
As to why - this is probably documentation.
A tiny change in the core of the engine is likely to affect almost everything - this makes it extremely dangerous to go in without knowing exactly what you're doing.
-
I would point out that DaBrains' method definitely needs more testing, by more people. It seems to be a workaround that would work in the engine as it is now; as such, it would behoove us to make it work right.
-
Suggestion: threadsplit so as not to keep bumping an archived board? That, or bring it back?
-
I don't think we have a good place for a discussion like that right now. I'd suggest renaming this forum to "Overhaul Planning/Discussion", or open a new board for it.
-
*_*
-
There is a dedicated thread in the SCP internal for overhauls such as documentation, collision code upgrade, etc. Active planning should go there.
If people merely want to talk about what sort of stuff would be involved, and what they would like to see, then this can probably be split off into the SCP public forum.
-
There is a dedicated thread in the SCP internal for overhauls such as documentation, collision code upgrade, etc. Active planning should go there.
If people merely want to talk about what sort of stuff would be involved, and what they would like to see, then this can probably be split off into the SCP public forum.
Having a thread in internal SCP forum is all well and good, but it is not much use to those of us that are not SCP members.
The problem with this being in the SCP public forum is that, as you mentioned when you moved this thread to the archive, most if not all of this will little to do with the SCP right now, everything thing here is for future planning and will just get buried in the SCP board. Which is arguably what what the SCP internal board is actually for, but again, part of the point of this project is to include the TC and Mod Makers in the process so that they get the engine that they want, not what the SCP coders think they want or need. The SCP internal board by definition excludes this type of discussion.
In this case I agree with DaBrain that this forum be reinstated or another created called the "FSO Documentation and Long Term Planning" with the tag line of "The place where we document the current engine and plan for the pie-in-the-sky features to be of FSO."
-
There is a dedicated thread in the SCP internal for overhauls such as documentation, collision code upgrade, etc. Active planning should go there.
If people merely want to talk about what sort of stuff would be involved, and what they would like to see, then this can probably be split off into the SCP public forum.
The last time I was on there, the internal board was about the quietest place on SCP (and still may be, for all I know).
This kind of discussion really should be public.
It's a case of what do the community think we should be doing, not what do 5 coders think we're doing.
Think community, not engine.
-
to be honest i dont see why it should matter if the nuts and bolts of the SCP are discussed on an internal board i mean to 90% of the members not on the SCP team that kind of stuff would be meaningless, lets face it i have done a little pascal, VB and C++ coding at college and if you posted a piece of the code it would be close meaningless to me.
if this thread was going to be maintained so the wider comunity can have a say and the SCP team keep us all updated on what is happening then i dont see a problem.
-
No. Input from people that are not on the team is necessary for this. Let's face it, there are guys like Nuke who certainly can provide some valuable insight, and not every left-field idea non-SCPers will throw around will be crap.
-
The problem with this being in the SCP public forum is that, as you mentioned when you moved this thread to the archive, most if not all of this will little to do with the SCP right now, everything thing here is for future planning and will just get buried in the SCP board. Which is arguably what what the SCP internal board is actually for, but again, part of the point of this project is to include the TC and Mod Makers in the process so that they get the engine that they want, not what the SCP coders think they want or need. The SCP internal board by definition excludes this type of discussion.
There is a board for that too: the Hosted Project Collaboration forum. That's the place where the SCP and the internal projects discuss what the projects need and what the SCP can offer.
The last time I was on there, the internal board was about the quietest place on SCP (and still may be, for all I know).
This kind of discussion really should be public.
It's a case of what do the community think we should be doing, not what do 5 coders think we're doing.
The SCP board has been quiet recently because people have been doing all their discussion on IRC. Much of that needs to be moved back to the internal forum.
And the discussion should be private, or semi-private (e.g. in Hosted Collaboration) because the SCP have a responsibility to the code as well as the community. The code needs to be kept stable and bug free, and it needs to be upgraded in a sensible manner. The SCP isn't a democracy any more than HLP is a democracy, because people who go in and get their hands dirty are more qualified to judge the state of the project (and this goes for both the SCP and for mods) than people who are merely spectating. For example, far too many people think the graphics engine is in the most need of improvement, when the graphics code has been continually and consistently upgraded throughout the entire life of the SCP. More attention needs to be paid to the collision code, the model animation code, and yes, the documentation.
No. Input from people that are not on the team is necessary for this. Let's face it, there are guys like Nuke who certainly can provide some valuable insight, and not every left-field idea non-SCPers will throw around will be crap.
I believe Nuke has access to HPC. If not, we can easily add him.
-
I would still prefer for discussions like this to be entirely in the open. People like Genghis, who come basically out of nowhere to provide fixes would probably be attracted to something like this.
-
It says something about the Hosted Project Collaboration board that I was not aware of its existence until right now.
Could I/other BP folk get access? Goodness knows we've made enough feature requests (mostly of the minor sort, I think, and hopefully not too irksome.)
-
No, HPO is designed for discussions between Project leaders and SCP staff only.
-
Okay.
-
I would still prefer for discussions like this to be entirely in the open. People like Genghis, who come basically out of nowhere to provide fixes would probably be attracted to something like this.
People like Genghis who come out of nowhere should start with providing basic fixes, as he did and is currently doing. Overhauling the engine requires a much more in-depth understanding of the codebase that a completely new coder would not have.
It says something about the Hosted Project Collaboration board that I was not aware of its existence until right now.
Indeed -- perhaps what it says is that HPC should be open to "senior project leadership" as opposed to "one project leader". For now at least, I've added you and Fury. (Though Fury should have already had access, being an admin.)
Could I/other BP folk get access? Goodness knows we've made enough feature requests (mostly of the minor sort, I think, and hopefully not too irksome.)
I confess to being slightly irked. :) It would be good if Blue Planet had its own thread in there, like WCS currently does.
-
I don't really like to use HPC board for feature requests, because once in a while someone like Spicious comes along and implements lion's share of code needed for the feature. Not everyone who can do that stuff once in a while have SCP badge.
-
HPC is meant to be a place where projects and the SCP can work closely together to make sure the SCP fulfills the project's needs and the project is aware of the SCP's features. There's a lot of traffic in the public SCP forum and I don't think it's a suitable place for feature requests. Generally the feature requests get buried beneath everything else, frustrating both the project and the coders. "Once in a while" does not seem to be often enough to balance that out.
-
Okay, what I think is needed is a subforum specifically for feature requests, accessible to the public (lest we forget, we have quite a few solo modders out there who have feature ideas that could be worthwhile, but who aren't members of any project). In addition, there are a number of projects that aren't hosted here, and those guy's feature requests should be treated just as seriously as those that come from the HLP projects.
I know this'll need strict moderating to keep the customary offtopicness to invade it, and I would volunteer for that.
-
What about a public version of that board, where non-SCP members can read but not post, to keep that clean.
Or maybe a sticky in the public SCP board, where all this could be updated on a regular basis ( weekly, 2 weeks...), and if someone wishes to comment, there's the option to start a thread.
Edit: The_E posted his suggestion before i could post mine
-
So far HPC has had very little to do with anything but total conversions, it doesn't live up to needs of other mods in its current form. If you ask me, it should be made publicly accessible and renamed to Feature Requests.
As for this board, it should be moved to child of SCP and renamed to Documentation & Long-term Planning.
-
Okay, what I think is needed is a subforum specifically for feature requests, accessible to the public (lest we forget, we have quite a few solo modders out there who have feature ideas that could be worthwhile, but who aren't members of any project). In addition, there are a number of projects that aren't hosted here, and those guy's feature requests should be treated just as seriously as those that come from the HLP projects.
I know this'll need strict moderating to keep the customary offtopicness to invade it, and I would volunteer for that.
I second this. As everyone keeps reminding me when I am developing features for wxLauncher, there is more to the FreeSpace community than just HLP and its large organized MODs and TCs.
I also volunteer to keep this new Feature Requests subforum strictly on topic.
-
No, HPO is designed for discussions between Project leaders and SCP staff only.
Yea I guess TBP and MULTI don't count as hosted projects either because I've never heard of it.
-
So far HPC has had very little to do with anything but total conversions, it doesn't live up to needs of other mods in its current form. If you ask me, it should be made publicly accessible and renamed to Feature Requests.
I thought the privacy was so private mod stuff could be posted.
-
Yep. That was the original idea but I also agree that most people don't seem to care about that so I'd be in favour of a better method to deal with feature requests. The Hosted Collaboration board was meant to be open to all projects but it's a PITA to maintain it and it's obvious that people like FUBAR who definitely should have access have been falling through the gaps.
The problem with more open feature requests is that the good requests tend to disappear below of a sea of less-good and fundamentally flawed ones. More access means more of those, so there does need to be some way of vetting which requests are good and adding them to some sort of database of requests so that the good ones don't get lost.
As for the future of the engine itself, I am in favour of a more open discussion of the future of the engine but so far attempts to do that have been handled spectacularly badly with numerous posts from people not qualified to actually give an opinion on what needs to be done. It's all very well to say that the general public should be allowed to post useful comments but a lot of their comments are a pointless distraction. As Goober pointed out, the community tends to have a very poor understanding of what actually needs to be done which means we waste large amounts of time discussing things like Multithreading instead of actually dealing with things that desperately need upgrading.
-
I'm all in favor of the concept of taking a hiatus of sorts so that the engine can get proper documentation under way. Seeing as the team has agreed upon this point (or seems to), that's great.
...Unfortunately, I'm not really qualified to make such commentary...
Which brings me to a new question/statement:
I do have a... seemingly unimpressive single semester of C++ under my belt. I really do love the language, but the level of coding involved in FSO is certainly over my head. What would be a proper way to better improve my skills with the language while potentially being of service to the SCP somewhere down the road?
...In other words, is there a platform/standard in place so new coders can get involved in the program or start learning the ropes of FSO?
-
The usual entry route is by going through Mantis and looking at the bugs there. While it's rather hard to find the really trivial ones still left, some of them may be solvable even by novice coders. And if the fix you've submitted is bad, well, I'd say that's a learning experience right there.
Other than that, I'd suggest having a language reference nearby, and to get comfortable with running FSO with the debugger attached.
Also, the "associated" projects, like PCS2 or the wxLauncher may be glad for some help.
-
So far HPC has had very little to do with anything but total conversions, it doesn't live up to needs of other mods in its current form.
That's deceptive. Most of the mods on HLP either 1) are happy with the state of the SCP, and are busy working on their project with current features; 2) have a coder already on staff, and therefore don't need to use the board; 3) inactive. Blue Planet is a rare exception in that it's an active project that requires new features, yet doesn't have a coder on staff; furthermore, the guy who is the project leader (Darius) leads behind the scenes.
The obvious solution is to add Battuta to the HPC forum because he interacts with the SCP to a much greater extent than Darius. (As for Fury, he's an admin so he already has access to that forum.)
Yea I guess TBP and MULTI don't count as hosted projects either because I've never heard of it.
Nobody added you to the Project Heads membergroup when you were made a Project Head. :doubt: You should see it now.
The Hosted Collaboration board was meant to be open to all projects but it's a PITA to maintain it and it's obvious that people like FUBAR who definitely should have access have been falling through the gaps.
It's only a PITA because SMF's permissions system is a PITA. :p It's only necessary to remember to a member to the Project Heads group whenever he becomes a Project Head. This controls access to Hosted Project Support as well as Hosted Project Collaboration. It's the same situation as remembering to add project membership as a secondary group rather than a primary group in order to avoid overriding custom titles.
The problem with more open feature requests is that the good requests tend to disappear below of a sea of less-good and fundamentally flawed ones. More access means more of those, so there does need to be some way of vetting which requests are good and adding them to some sort of database of requests so that the good ones don't get lost.
The problem with this is that it requires active organization on the part of the board moderators, and people are lazy. It's far better to make the process self-selecting, i.e. to prioritize feature requests from hosted project senior staff.
And yes, good requests definitely get lost beneath the sea of everything else. :sigh: For others reading the thread, this was discussed extensively when the HPC forum was first created. And some of these issues were even discussed back when the SCP internal forum was created. Take the "read-only" proposal for example: by the law of unintended consequences, that would only result in people complaining in the public forum about what they couldn't respond to in the "private" forum.
I would say that most of the problems on this subject can be solved immediately by expanding the definition of "Project Heads" to mean "Project Senior Staff", and by making sure the list is up-to-date. So for people like FUBAR and Battuta, that's already been taken care of. If anyone else is aware of a senior project member who should have access to Hosted Project Collaboration or Hosted Support and doesn't, feel free to say so and one of the admins will immediately add him.
-
This still does not address the issue that HPC board completely leaves solo modders and projects hosted elsewhere out of the loop. They should have as much of a voice around here as hosted projects. I honestly don't see much benefit in keeping HPC board private. In my opinion there would be more benefits of having it public, despite requiring little bit more moderation.
-
We can add solo project leaders and external project leaders to the membergroup if there's a solid rationale.
-
That won't help them if they have no idea it exists.
-
Why not do like you had it in The Padded Cell, during the brief period when that existed? Opt-in membership. Or possibly opt-in (with approval) to post, but visible to all?
-
If it's made entirely public, what purpose would it serve compared to the current public forum?
If feature requests are falling into obscurity, perhaps something like moderator (http://www.google.com/moderator/#0) could help.
-
Because having one place where feature requests are concentrated is easier to keep track of than the SCP board, where these things may be buried.