feature freeze time

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

klauss wrote:
safemode wrote:While, ray collisions isn't fully done ..it's fairly close and the diff between my branch and trunk is growing to probably 50 files now. Maintaining a clean merge over the course of another month may easily get very ugly if code cleanups persist and we start micro-optimizing.
Isn't it mergeable right now?
it is, it just isn't fully complete, and i can't complete it until i know what the hell is wrong with rays and bolts drawing through what they obviously register a collision with. It's likely that i'll need to provide a means of returning data about where on a ship that a ray or bolt hit, but until i know what format and what information is needed, all i can do is say "we hit something this frame, stop advancing" but I can't tell the Beam Or Bolt where on it's line segment it should stop, so technically it should stop at it's endpoint for it's movement that frame. But i dont think this even occurs.

safemode wrote:Even if we documented things up, I really dont see us being ready for an actual release soon. The artwork needs time to catch up to the shader work. The beam/bolt drawing issue needs to get resolved. The Removal of the Nebula unit should be done. Our background generator should be finished. The release should be something we can stand behind, not kicked out in an incomplete state just so we can get onto more exciting things. I'm not saying we should rewrite entire subsystems to correct the ugliness there, but
Perhaps you're putting too many features for the release. I believe bug squashing is the most important thing for the release. The most important graphical bugs have been squashed, namely those cubemap issues.

The release can be made with ad-hoc auto shininess, which looks rather nice. SVN isn't using it to motivate artists, but if no artist is motivated by release time I'd release anyway.

The beam/bolt drawing issue was deemed unimportant already, or that I thought.
Well, it was deemed to be not a regression, but it's a glaringly obvious artifact.
The removal of the nebula unit should be made into a ticket and prioritized - I don't believe it's important enough to block the release for it.
yea, it can wait until after release.
The background generator idea was explicitly stated for after the release. For the release, the idea was simple foggy systems as you explained, with radar interference and that kind of stuff.
by background generator, i was thinking of the cubemap generator so artists would have tools provided by the release to start working on our current setup, instead of having to pull svn (which most people dont do).

As for nebular systems, that's after release and after the removal of nebular units.

as far as fog goes, if we can define the position and volumetric dimensions of the fog, it might be an excellent means of showing gas venting around a damaged ship. Especially if we dont have to track and do all the moving of such an effect like we do with particles. (star streaks and particles are surprisingly time hogs).
safemode wrote:I'm not ready to merge the ray collider to trunk yet, but it isn't going to be long before it's finalized
Why isn't it ready? I recall reading you had it working. Working is ready enough... isn't it?

Anyway, it's cleanup. If it isn't ready, don't merge, lets release without it. Although it removes duplication of functionality and the need for bsp files, so it's important, it still is invisible to users except perhaps a performance increase.
It'll do the exact same job the current setup is doing. By ready, i was talking about providing actual impact data so we can stop our rays and beams at the exact point of impact. But that's extra i suppose compared to what we currently do. I could merge it today and pretty much nobody would notice :)

I recommend deleting the generatedbsp directory in your homedir .vegastrike dir when it does go in. The directory will just be ignored from then on.
safemode wrote: ...and then i'm sure we wont be any closer to a release than we are now especially with the lack of artists active anymore. Chuck can't do everything by himself and i'm afraid i'm useless at anything art related.
About the artsy stuff, I believe I could produce shininess maps for units. That's about as artsy as I get, though. Lack of artists is real, and troublesome.

There's a technical aspect though that I could affront, and that's mesh quality. Some meshes are simply lacking LODs or proper smoothing - perhaps I could address that, but I certainly won't be fast in that department. It may take a week or more per unit, that's a lot.
apparently before my ray collider work, we supported up to 8 LOD's at the mesh and collider level. each lod gets it's own collider. I'm not sure if we scale automatically or what...but from the look of the code it seems like we do, at least for the collider LOD's. We retrieve the correct collider by sending the correct scale to our collider tree array.
safemode wrote:0.5.1 is basically done. Has been for a while. 0.5.2 and 0.5.3 is where i think we're at now. generally. Maybe we should aim for 0.5.3 to be the next release and go that route, or modify the roadmap and aim for 0.5.2. i dont know. All i do know is that the /data side is seriously behind the engine side and we really can't release while it's like that.
What's more important than features for the release is being able to build in the three supported platforms. Linux, is ok. Windows, is on its way, but slow. Mac... no clue whatsoever.
I really dont care much about the mac setup. It's so mindnumbingly annoying to develop across mac OS versions since they are fixed to certain versions of libs. We probably have as many amiga OS users as we have Mac users.
We need testing just as well. We should release a beta, test, fix serious bugs, then re-release. A branch has to be kept with source and data for the release so bugfixing can happen on that proven branch while development for the next release continues.
it's easy to do that on svn. We can easily tag the next release, than backport any bugfix-only changes to that tag and eventually make a patch release (would not require a data update, only replacing the bins).
So we need a plan. We had a feature plan, now we need a release plan.

BTW: good thing you mentioned that roadmap, it had left my mind. Release 0.5.1 is very close, which is ever so good.

Lets squash all the serious bugs and release a beta as soon as there's a release plan, that will give us quick feedback on the bugs that need fixing. Lets also make it clear: the release is the first release in a faster release cycle, it may not be a huge change from 0.5.0 in terms of gameplay, it may or may not, I forgot already how 0.5.0 was, but it's not the point. The point is to release more often, get more feedback, and actually fix the bugs reported.
it's only been almost 2 years since 0.5.0 just about :) so i guess that's faster than the 0.4.3 -> 0.5.0 release. heh.

anyway, we'll probably end up using Cpack from cmake to build our installers.
http://www.itk.org/Wiki/CMake:CPackPackageGenerators

which was part of the entire point of moving to cmake. A single setup file that can allow us to build and package on every supported OS we handle.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

safemode wrote:I really dont care much about the mac setup. It's so mindnumbingly annoying to develop across mac OS versions since they are fixed to certain versions of libs. We probably have as many amiga OS users as we have Mac users.
We have two PU users with mac's. I agree it's a pain though; but we should at least post asking for help from mac users to help get the engine compiling and the game running, and the whole thing documented in terms of installation process.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: feature freeze time

Post by charlieg »

I think making models without shininess maps look crap is a really, really, terribly, awfully bad idea.

You are punishing players to motivate artists. That doesn't really make sense.

Crippling the release is just a dreadful idea. Perhaps your worst, chuck.

By all means make the game complain loudly to log output, or at the very worst make shininess maps mandatory in SVN, but don't cut off the nose to spite the face. That'll just cause the project harm, make people think bad things about VS, and - worst of all - turn off new players who'll not go to any length to understand the politics of it and just drop the game quickly.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

chuck_starchaser wrote:I thought you agreed to my plan. If we keep postponing the requiring of shininess maps, we are NEVER going to have them. It's not "just for the release", because artists, by definition, will get the downloadable release, rather than svn, and will test their ships on that.
We have to, sooner or later, make models without shininess maps look bad. Do you agree? If that time is not now, would you tell me why, and when would be a better time?
I do agree. I just don't see movement in that department, and postponing the release until all specmaps are fixed could mean postponing it for a long time (not indefinite, I'd tackle that eventually).
Are we ok with that?
chuck_starchaser wrote:I agree, but without cheating in the shaders. And that cheating looks like shit, anyways. To cheat right you need to compare diffuse and specular saturations, and determine whether you have a dielectric. Dielectrics should look shiny even with low specular values.
How about we write a python program to generate the shininess map?
My problem is getting started with it. Just write a python program that does anything, like add textures A and B and write to C; and then I'll write the real algorithm.
Deal?
I wanted to avoid automatically producing shininess maps because it risks falling into similar issues than that of a shader hack. Albeit that's arguable, since a python program would be orders of magnitude smarter.
So it might work, especially with your guidance and approval, you've proven more than wise in this field, so even if I argue a lot I value your opinion even above mine ;)
So... ticketize and prioritize?

Unrelated, a task I'd add to the release is updating vssetup graphical presets to really make it playable in legacy hardware. I have a GF6200, an ATI9800 running on Windows (yep, revived my windows machine, but it can't build, it's full of virus), a GF9800 and I can probably get my hands on an onboard GPU somewhere.

It's a nice mix for testing, and I'd like (when I get the time) to get that nailed down - players should choose their GPU class and the game should work well and acceptably fast. Note that I've been running VS on the 6200 with a decent FPS, stuttering was mostly CPU/memory-related, and not graphics-related.

In essence, the task is producing hardware profiles and making vssetup show those choices rather than the current outdated and miscalibrated ones. I believe poor performance and poor configurability is what kills the experience for many many users, as evidenced by all the help posts out there.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

charlieg wrote:By all means make the game complain loudly to log output
People don't read VS logs. Mostly because they're full of garbage, but I doubt they would if they weren't. It's not a powerful enough motivation.
charlieg wrote:or at the very worst make shininess maps mandatory in SVN
That's the entire idea of making models look like shiny crap without explicit shininess maps. I always gave for granted that any release would revert that setting, but SVN will always look like crap to remind artists that we need those.

Chuck's only opposed to the idea of hacking that in the shader... he'd rather hack it offline, with an ad-hoc yet smarter script. Or that's the idea I got... right chuck? It would work better than hacking the shader. It would be far slower though, and distracting if the results aren't of high enough quality to consider them permanent.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

klauss wrote:That's the entire idea of making models look like shiny crap without explicit shininess maps. I always gave for granted that any release would revert that setting, but SVN will always look like crap to remind artists that we need those.
The problem with that is that artists are allergic to svn and compilers. They will target for the release version.
Chuck's only opposed to the idea of hacking that in the shader... he'd rather hack it offline, with an ad-hoc yet smarter script. Or that's the idea I got... right chuck? It would work better than hacking the shader. It would be far slower though, and distracting if the results aren't of high enough quality to consider them permanent.
Yes, but why would it be slower? Au contraire, to hack the shader means more shader instructions than reading the shininess off alpha. Unless you mean slower for us to get a release?
I wanted to avoid automatically producing shininess maps because it risks falling into similar issues than that of a shader hack. Albeit that's arguable, since a python program would be orders of magnitude smarter.
Not sure what you mean about similar issues... That artists would not produce shininess maps because they can use this tool? I think they WILL use this tool, but just to produce a starting point for their manual work; and why not?
If you're talking about the lack of intelligence in producing shininess, that's true; but the results I got with the UberShader.fp were a lot better than a simple specularity -> shininess hack. Far better. But that was terribly expensive to do in the shader. My 8800 was running at like 5 FPS!!! And doing it off-line I could put A LOT more intelligence in it. The shininess map I got on the Tarsus, in PU, I generated it offline with a Blender noodle, by the way. I was in a hurry and never took the time to finish it manually, but it looks quite decent.

I posted the shininess generator idea to a new thread:
http://vegastrike.sourceforge.net/forum ... 27&t=15266
But I'll ticketize it as well.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

chuck_starchaser wrote:Yes, but why would it be slower? Au contraire, to hack the shader means more shader instructions than reading the shininess off alpha. Unless you mean slower for us to get a release?
I mean slower for us to get a release.
chuck_starchaser wrote:Not sure what you mean about similar issues... That artists would not produce shininess maps because they can use this tool? I think they WILL use this tool, but just to produce a starting point for their manual work; and why not?
Hey... that's true!
Artists can grab the generated shininess map and use the AI-computed values and copy/paste and tweak with their knowledge of materials.
Hadn't thought of that.
chuck_starchaser wrote:If you're talking about the lack of intelligence in producing shininess, that's true; but the results I got with the UberShader.fp were a lot better than a simple specularity -> shininess hack.
Yap, besides, I like your idea of having humans review the output and refine it.
chuck_starchaser wrote:I posted the shininess generator idea to a new thread:
http://vegastrike.sourceforge.net/forum ... 27&t=15266
But I'll ticketize it as well.
PIL (Python Imaging Library) can open images in a window, create histograms, and tricks like that. So a lot of the functionality can be done with PIL, but it won't be so pretty. To get a pretty interface we'd need Qt or GTK or some heavier library, and I've never done GUI applications at that level.
But I'll try to get the basic commandline framework done... eventually. Remember my constrained schedule... so be patient.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

klauss wrote:Yap, besides, I like your idea of having humans review the output and refine it.
Exactly; and the refining would be quick and easy. You get a color-coded map of materials, and all you have to do is pick the color in gimp and paint over the noise. Probably two minutes of work, compared to two days or so to produce a shininess map from scratch.
We could also have the program save a text file for how it plans to represent each material; which file you could also review and edit.
This is not to mean that we'd over-sanitize the artist's work. As I mentioned in the ticket, the differences between the original and sanitized version would be re-introduced at a later stage, but re-interpreted. A reddish shade on metal could be rust, and represented by a reddening of diffuse and darkening of specular. Most other noise could be either dirt or scratches, separated and represented appropriately. Dirt would darken specular sharply, even if it wasn't so in the original. This stems from the fact that most specular textures currently in-game were produced by desaturating diffuse, and are therefore suspect. This could actually be ascertained at the start of the program by looking at diffuse/specular correlation.
But I'll try to get the basic commandline framework done... eventually. Remember my constrained schedule... so be patient.
Eventually... as in before or after release? Would be nice to clean up all the texturings for the release. Other than the release consideration, I'm in no rush; I need to finish the shader harmonization and organization; and that's going to take a few days.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

This evening i'll be merging my branch back to trunk. Functionality wise in the game, you shouldn't notice any changes
In the source side of things, the vc guys will have to update their projects to note the removal of some files so their builds dont complain about them being missing.


Once it's committed, i dont want to do anything more than simple cleanups to it until after our release. Not because i dont really want to, but because i want to get CPack up and functional on the linux side of things and attempt to get cmake to properly interface with VC on the win32 side of things (along with nsis output in CPack).
Ed Sweetman endorses this message.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: feature freeze time

Post by charlieg »

chuck, I think you should go on the shininess texturing crusade after a release. That way it can be dealt with in a timely fashion - so textures can be done to a higher standard etc - and the release can be uploaded as soon as the build process is finalized.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

Well, this shouldn't take too long, really. If Klauss finds the time to put together the basic python infrastructure, I think the algorithm would take a day or two; and then processing the textures for all the units another day or two.

Klauss: If this would make it simpler, it could be split into 3 python programs:

1) Material analysis -- writes a color-coded materials texture and a text file with the keys, and suggested material representations.

User touches up the texture and edits the file.

2) Masters production -- program reads the touched up materials index and text file, produces the representations, then blends in removed data from the originals, and writes png masters (e.g.: shininess is a separate black and white png).

Visual inspection and possible touch-up.

3) Packer -- Takes the masters and packs shininess in spec alpha, etceteras, then calls nvcompress.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

It would be easier that way.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

Good. So just tackle the first, when you can; and don't worry about the others.
Once materials detection is working, the rest is easy.
What would be good is if the first py writes filepaths to a file, so the second and third py's just
read it from there, so it doesn't take horribly many data entries to get a job done (I'm worrying
in advance about how much typing it will take to do about 100 or 200 units.)
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

My Itinerary if everything goes according to plan:
1.merge my branch in after a small tidy up.
2. Setup cpack with cmake on linux. Get a functional .sh installer going.
3. Using my uber cool windows 2000 installation in vmware, install whatever free msvc variant that's available from microsoft.
4. Get cmake to create a build file for it
5. compile VS under it.
6. setup cpack to use nsis and create an installer for win32


I dont know what happened to our two intrepid win32 porters that were around a month or so ago, but apparently they gave up.

I dont think it's much of a secret that I hate developing on windows (and mac). I hate it so much that i hate how much work is needed to get things going come release time on those archs, and that's why i want to see the whole cmake system come together. When it does, it will be zero effort for a single developer (who has access to the different OS's) to use different compilers even to build VS on each platform and package it up using a central configuration used by all. I'm sick of the having to play catchup on the other archs or needing to deal with new project files for a new version of Visual studio or whatever MS calls their compiler ide setup these days. cmake can handle that crap and all we need to do is handle cmake. Less time wasted in that area is a win for everyone.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

r12731 compiled and run no problems; good job!; and I think works a little better; no freezes like I had before, though the freezes are sometimes on sometimes off, so I have to test more.
The clipping of the bolts is a bit too agressive, I think; shooting at the agri base from 3.5 kilometers away I don't see my shots; but shooting at an angle, at free space I see them.

Idea: How about we get rid of those spheres around units?
I guess they represent the shields, but they don't look like the proverbial shields; and they don't even look like spheres; more like octagons; very polygonated. Not sure how else we could represent shields; but this way simply sucks. Maybe we could create temporary spheres at the points of bolt impacts and light them up? When I shoot at something I want to see where my shots are hitting, rather than a huge polygon lighting up. I also don't know why the screen turns red when you get shot at. Does it represent blood in your eyes?, or what? These kinds of gimmicks make the whole game feel cartoonish and cheap, which was the intent in doom and duke nukem; but I don't think it's the intent in vegastrike.

The removed files removed many of the remaining warnings. For the record, there are two warnings left under gcc 4.4.1:

Code: Select all

Building CXX object CMakeFiles/engine_com.dir/src/gfx/mesh_xml.o
/home/d/vs/repo/trunk/vegastrike/src/gfx/mesh_xml.cpp: In member function ‘void Mesh::PostProcessLoading(MeshXML*, const std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)’:
/home/d/vs/repo/trunk/vegastrike/src/gfx/mesh_xml.cpp:2005: warning: ‘<anonymous>’ may be used uninitialized in this function
which I've no idea what it means or how to fix; and...

Code: Select all

Building CXX object CMakeFiles/vegastrike.dir/src/gfx/quadsquare.o
/home/d/vs/repo/trunk/vegastrike/src/gfx/quadsquare.cpp: In member function ‘float quadsquare::GetHeight(const quadcornerdata&, float, float, Vector&)’:
/home/d/vs/repo/trunk/vegastrike/src/gfx/quadsquare.cpp:220: warning: suggest parentheses around arithmetic in operand of ‘^’
This function is probably not being used.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

I think shields should be tightly bound to the surface of the ship... like reactive armor only via a plasma charging of the outter hull

This doubles as hiding the fact that we dont register weapon collision until it hits the actual ship, so shields are activated in large vessels after we see the weapon fire pass by them. Very noticable on bases.

It would also fix the issue of getting stuck to another ship's shields when moving very slow.

Then, we can play some sort of GL effect across the ship's mesh when shields are hit. etc etc.


edit: It would make dealing with shelds so much easier. They become simply a factor in applyDamage and a GL eye candy effect, nothing more. No mesh, no collision issues. no visual artifacts that shouldn't exist.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

-ftree-parallelize-loops= What did i ever do without you? You are like porn for gcc optimizations. Really good stuff :)

I set it to 2 since that would be the most common smp config setup around. Game loading time is drastically reduced with this option. Seriously, it's almost as good as having true threaded subsystems now, with no code changes.

You likely wont fully benefit unless you use the whole set of gcc opts i'm enabling in cmake for cpu archs if you plan on porting this into autoconf's setup, but try it out in cmake and see if you like it.

loading the game uses >170% cpu ...other aspects will also make use of your smp setup.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

No SMP here; one chip; one core.

Perhaps we could use a particle trick to simulate shields that are invisible normally but light up momentarily around a weapon hit.
I can write a fragment shader to produce something like an expanding shockwave around where weapons hit; but there's a catch: I need geometry to apply the shader to --just like we need a ring around planets onto which to paint "halo's".

Now, we could have a second mesh surrounding ships; but this would be EXTREMELY expensive in terms of overdraw, even when the shield is completely transparent.

What I'm thinking we could do is create a temporary billboard where a weapon hits; with like a 1-second time to live, and paint an alpha-blended luminous but quickly fading animation on it.

But we'd need a couple of datas:

Position of the hit, x,y,z
Velocity vector of the ship that got hit x,y,z, so that the billboard moves with the ship that got hit.
And the position of the ship that fired the shot, x,y,z, so we can move the billboard a few feet in the direction of where the shot came from, so that it doesn't get clipped by the surface of the ship, --and so that it looks like the shield has thickness.

Admittedly, though, this runs contrary to the general idea of a "feature freeze"... :roll:
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: feature freeze time

Post by klauss »

safemode wrote:I think shields should be tightly bound to the surface of the ship... like reactive armor only via a plasma charging of the outter hull
If you specify a shield mesh in units.csv you get that.
The mule is the only ship that has such a mesh, I believe. Oh... and the clydesdale.
We need more meshes.

About the lighting effect being too big... that can be fixed. It's implemented with a fading light at the point of impact - the initial radius could be smaller. Should be smaller.

Shield meshes that are different from unit meshes are an important feature of the game, consider vegatrek and PU. If you check the original WC games, I seem to recall they did have that effect (shielded units were easier to hit because the shield bubble was somewhat bigger, but once the shield was gone, hitting the ships was harder).
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

Ok, i changed the cmake setup to allow you to choose how many threads you want 1, 2, 3, 4 etc.

It's only used when you select a cpu arch.

I'll commit those changes in a while..



as for shields, I wasn't saying to remove a feature that other mods depend on, but to create a new one that VS can use that just bypasses the entire mess. No meshes, no crappy sphere. Just a special effect that plays over the surface of the regular ship mesh. ApplyDamage need not even really be modified, it'll still work as if we did have a shield.

So our geometry is the ship mesh.

edit: I really dont like profiling. it's not very intuitive as to what is actually hogging time vs what's simply using the most due to being called the most often. The vast majority of functions register 0.00 self seconds. which is useless info to me.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: feature freeze time

Post by chuck_starchaser »

But Klauss, this is horribly inefficient! Or am I missing something? What about overdraw? You're suggesting we cover every mesh with a second mesh using alpha-blending? !!! We need to invest on dual videocards in SLI just to see stupid shields?
How about my idea of faking a shield by showing billboard effects around the points of impact?

EDIT:
Even where a spherical shield is desired it can be faked by showing temporary billboards that appear at a fixed radius from the ship's center.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: feature freeze time

Post by safemode »

hrm.. getting rid of the sphere mesh is easy. I've been unable to trick it into re-using the regular mesh to make the shields though... not sure why but the special FX code keeps causing it to segfault. oh well.

There should be an easy way to apply a special effect (via the shader or whatever) to the standard textures on the mesh ...and skip creating the sphere mesh, set some special code to deal with a shield of radius == radius of unit (rather than 0 which may signify that shields are down)


edit: some of the cpu_opts i'm using in cmake may cause bugs to rear up. let me know if anything strange is happening when you use them vs when you dont. I may have to switch off some of the unsafe math options. For instance, i notice on my machine sometimes certain ships are missing textures (they're all black)... weird things like that.
Ed Sweetman endorses this message.
Neskiairti
Confed Special Operative
Confed Special Operative
Posts: 334
Joined: Thu Jan 11, 2007 4:10 am

Re: feature freeze time

Post by Neskiairti »

you could always add a flag to runtime something like -artist
which would turn off the shiny mapping stuff. And if some one submits a piece of art without the shiny shit, tell them to display it in their game with -artist :P
reject it until they make it look good.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: feature freeze time

Post by charlieg »

Why not just release as-is, then release an update with the better shields, planets etc.

Feature creep, the enemy of a release cycle.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
Post Reply