Code reformatting project [DONE]

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project

Post by chuck_starchaser »

Part 1 of 3 committed. r12643.
Now...

Code: Select all

d@kar:~/vs/repo/trunk/vegastrike$ svn merge -r 12628:12640 ../../branches/refactor/vegastrike
--- Merging r12629 through r12640 into '.':
...............
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project

Post by chuck_starchaser »

klauss wrote:
chuck_starchaser wrote:
This will then pull the diff of your current working dir and your branch, giving you a set of changes to trunk that you will then commit to the trunk, with a message such as "merging reformat branch, r-whatever"

So, you basically have the url's wrong. Your working dir should be trunk, your url's should be pointing to your branch.
Okay, but ditto; I think I'll have to do the merges locally onto my trunk pull, and then commit them from my local trunk.
I always do it like that. I have two local working directories: one with the branch, one with trunk. When I'm merging, I go to trunk, do svn up, then svn merge -r<revs> <path-to-local-branch> . --dry-run, if all's ok, svn merge -r<revs> <path-to-local-branch>, svn diff | less (inspect diff - in your case it may be too big for that), and if all's ok svn commit.
Cool! I thought I had invented this method; --someone beat me to it :D
That process works perfectly every time.
Of course if you have conflicts at some point you may have to resolve them. It's not hard at all, if svn merge says C <file>, you open up <file> and look for "<<<< mine" (or similar - I always search "<<<") - you have your side of things and their side of things, pick one, or mix and match, remove the conflict markers (the <<< mine and stuff like that), and svn resolved <file>.
Gottcha.
In this case, theirs (branch) when merging, and mine when committing, for simplicity. This undid your premul alpha commit momentarily, but will put it back in when I commit part 2 of 3.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: Code reformatting project

Post by charlieg »

After this is complete, I suggest somebody [who knows what they are talking about] instigates a 'Next Release Tasks' thread where the fastest possible path to an updated release is worked out.

Release early, release often

-- Free Gamer guy ;)
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: Code reformatting project

Post by chuck_starchaser »

Indeed.
After this is done, I'll take a break from the engine and get back to shaders, by the way; as the first
part of cleanup work (comment headers in files) is something I can't help with, at all, anyways.
Shaders, and integration of art currently stopped in the pipeline that should be in the next release.

Part 2 of 3 committed. Doing the third merge now. I'm late; gotta leave like 5 minutes ago already,
got a meeting at work in less than an hour. I'll try to finish this part three merge/commit, but won't
have time to inspect it. Hope it works.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Code reformatting project

Post by klauss »

Once was a time where there were milestones.
Releases were often rolled out when milestones were met.
Once was a time where updates were common.
Users reported bugs, updates corrected them.

Once was a time where new milestones were set
But find them I cannot... lost are they.

Anyone know where they went?

Really.

Like, I remember someone had made up a plan and release points and all...
...where did that go?
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: Code reformatting project

Post by charlieg »

klauss wrote:Once was a time where there were milestones.
Releases were often rolled out when milestones were met.
Once was a time where updates were common.
Users reported bugs, updates corrected them.

Once was a time where new milestones were set
But find them I cannot... lost are they.

Anyone know where they went?

Really.

Like, I remember someone had made up a plan and release points and all...
...where did that go?
Milestones are very poor ways to organise open source projects who do not have a large pool of regular contributors. How can you plan 3 months, 6 months, or a few years into the future when a contributor who is needed to do feature X might not be around then or may prefer to work on something else?

In my opinion, based on a lot of observing and some participating in open source projects, the best way to be organised is to have 3 categories of features: short term [next release], medium term [can be done, if somebody picks it up], and long term [needs other features working on first] where long term is representative of the final '1.0' vision of a project.

Importantly, to really help a project stay alive and interesting to new contributors, there should always be a plan for the next release [the "short term" plan]. The next release is fresh meat to the community and really helps to generate interest in a project.

Roadmaps on the other hand, are always inaccurate, constantly change, and are never adhered to. Goals are good but roadmaps are usually not worth the pixels used to display them.
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: Code reformatting project

Post by klauss »

Just this: Milestones don't have to be long-term.

A milestone could read: Externalize content authoring. Move to OpenCTM/Ogre/Insert your library for mesh format to inherit its production pipeline.

Ie: it's not a ticket, the task is big enough on itself to be called a milestone, it is a milestone for the project's purposes since it represents a whole new (better) way of doing things, it can be divided into separate tickets for people to work on, for devs to grab as they please, and it gives direction to the project.

A release is made when the milestone is met. That is, when there is substantial new functionality.

A milestone can also read: Have critical bugs 1, 2, 3, 4, 5, 6, 7, 8 fixed.

A release is made when the milestone is met. That is, when the game functions substantially better.

How is that bad? Of course, you don't use the same milestones in an open source, all-volunteer project as you'd use on a commercial project.

And you have to plan several branches too, for those devs that just want to work on something else.

But milestones, IMHO, are a way to tell the developer comunity, what is indeed important and what is just a bonus. Because, you know, devs like I tend to work on what is fun working on, and forget (or don't even know) what users really want.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: Code reformatting project

Post by charlieg »

You say milestone, I say feature. Milestones are just a measurement, but they are not a roadmap. Too many metaphors.

I disagree on 'milestone=>release'. Releases can be made for only minor (e.g. content) additions. X.Y.Z
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: Code reformatting project

Post by chuck_starchaser »

Added ticket
http://vegastrike.wcjunction.com/trac/timeline

Roadmaps are changeable, just like plans are, in general. That doesn't mean they are worthless. It's always
better to work with a plan than without one; but it's good also to change the plan as necessary or as
convenient, or as new and better ideas come along. Of course, milestones are more set in stone, but may
be delayed, or new priorities may come up.
Case in point, we've got plans for major code clean-up, refactoring and multi-threading. But we also got
many ideas for improvements, new features, etceteras. These are two parallel tracks, each having its own
sequence of milestones; but it's hard to plan in advance how much work to devote to one track or the
other far in advance; so we can make a "tentative plan", which is a redundant term, as all plans are; and
then play it by ear.
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: Code reformatting project

Post by pheonixstorm »

The real problem with this project is its only being actively maintained by what... 3 coders, 1 sound, 1 gfx, and 1 win32 nut case (oh wait.. thats me).

I would love to see a new patch release every few weeks for testing... I would love to see a lot more people working on getting features into the game or helping to clean up the menues.. ships... code w/e but its not feasible.. nor is releaseing often w/o some type of update/patch feature to make things easier (since no one is working on packaging anything including data changes).

I like this project but its on life support as is, it can't be treated as an active fully supported OS project such as Ogre, Freeorion, GiGi etc

Anyway, Chuck is everything done? If so do you want to tag this as done or wip in the main subject?
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project

Post by chuck_starchaser »

Yep, it's done, and out of my hands, AFAIK.
What's to "wip in the main subject"? (English is a second language around here.)
What charlieg is trying to say is not to start releasing every Friday; he just wants to see "a" release, for a
frigging change, and he's right: Having a release would generate excitement, and would probably bring in
more helping hands. I think there's enough new features for releasing soon. Cube-maps alone warrant it.
There's basically two problems that I know of that need addressing before a release: One is a graphical
glitch introduced with cube-maps: Planets flickering, and ox'es looking bright yellow, and some other
ships white. I'll write a ticket about it.
The other is, of course... Windows...
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: Code reformatting project

Post by pheonixstorm »

chuck_starchaser wrote:Yep, it's done, and out of my hands, AFAIK.
What's to "wip in the main subject"? (English is a second language around here.)
What charlieg is trying to say is not to start releasing every Friday; he just wants to see "a" release, for a
frigging change, and he's right: ...
W.I.P. Work In Progress. If the reformat project is complete, why not label the subject as done (edit first post if your unsure of what im getting at)

As for charlie.. yeah I know he wants a real release, but he keeps bringing up the other bit as releasing often. A release soon I like, but releasing often with so few of us doing work I dont like.

I shall update my head directory. Also, when I update the win32 libraries/dlls can you add them to the svn for me? I don't know how long till I get svn access.... :roll:
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Code reformatting project

Post by klauss »

I agree with charlieg about the release.

And I agree the white ships bug must be addressed for such a release.

I think we can set that as a goal: release - whatever there is, it should be released in a packaged form for those that can't or won't build.

However, chuck, I'm not sure the bug comes from cubemaps. I didn't have that bug until your last update to shaders, where there was a marked downgrade in quality - a bug, he'll fix it surely I thought. So take a look at your last commit to shaders:

data$ svn diff -rPREV:HEAD programs

should do the trick.

It will be a busy weekend for me, we're moving to a new office at work and they require my services during the weekend for that :( - however, when I get a chance I'll take a look at everything done, particularly that yellow bug.

I've seen quite a lot of content added, and that alone (when big bugs are solved) merits a release, IMHO. I'd like to be able to deliver the new sound system (which hopefully will be a lot less quirky and a lot more maintainable and extensible) for the next release after that.
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: Code reformatting project

Post by chuck_starchaser »

pheonixstorm wrote:
chuck_starchaser wrote:Yep, it's done, and out of my hands, AFAIK.
What's to "wip in the main subject"? (English is a second language around here.)
What charlieg is trying to say is not to start releasing every Friday; he just wants to see "a" release, for a
frigging change, and he's right: ...
W.I.P. Work In Progress. If the reformat project is complete, why not label the subject as done (edit first post if your unsure of what im getting at)
DONE :)
As for charlie.. yeah I know he wants a real release, but he keeps bringing up the other bit as releasing often. A release soon I like, but releasing often with so few of us doing work I dont like.
He's no pusher, though; don't get confused; charlieg has one of the most popular websites about FOSS and gaming, FreeGamer; and he's a friend of all FOSS game projects, and tries to inspire progress wherever he goes. He's like a frequently visiting angel helping us keep the FOSS spirit and focus; and he often quotes The Cathedral and the Bazaar.
I shall update my head directory. Also, when I update the win32 libraries/dlls can you add them to the svn for me? I don't know how long till I get svn access.... :roll:
Ouch; we've got to do something about that. I'll send a PM to www2.
klauss wrote:I agree with charlieg about the release.

And I agree the white ships bug must be addressed for such a release.

I think we can set that as a goal: release - whatever there is, it should be released in a packaged form for those that can't or won't build.

However, chuck, I'm not sure the bug comes from cubemaps. I didn't have that bug until your last update to shaders, where there was a marked downgrade in quality - a bug, he'll fix it surely I thought. So take a look at your last commit to shaders:

data$ svn diff -rPREV:HEAD programs

should do the trick.
I will. I wasn't sure it was the cubemaps; just an assumption. My thinking was, and is, that planets and oxes probably don't use the
newer shaders; but I think I did make some changes to the default shaders; probably not much, but perhaps the problem is there.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

Klauss, I could use your feedback on the changes I made to default.vp; I seem to have made extensive changes, and the thing is, I don't really grasp
all that's going on in vertex shaders.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Code reformatting project [DONE]

Post by klauss »

I think it's that you messed with lightPositionAndAttenuation in a bad way:

Code: Select all

// before
rv.xyz    = normalize(lpos.xyz*vertex.w - vertex.xyz*lpos.w);
rv.w      = 1.0;

// after
rv.xyz    = lpos.xyz - vertex.xyz*lpos.w;
rv.w      = SUNS_SOLID_ANGLE; // const ~0.0002
First badness: you took out the normalize() call... later code in the vertex program needs xyz normalized, for lighting calculations (lights 2-6 are done per-vertex rather than per-pixel). So even if you normalize in the fragment shader, when there are extra (more than two) lights, things would go bad.

Then you modified rv.w, which makes light attenuation go bonkers. See line 47 in the same file. The fragment shader seems to be ok with those changes though, but if you take a look at the yellowness, it does look interpolated, as if it were per-vertex.
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: Code reformatting project [DONE]

Post by chuck_starchaser »

klauss wrote:(lights 2-6 are done per-vertex rather than per-pixel)
DOH!
See line 47 in the same file.
(DOH^2)!

Thanks!
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

Klauss, I hope you don't mind; I think I'm going to get rid of ALL macros in vertex shaders.
It's just impossible for me to figure out the code the way it is. I have to remember that
parameter N of macro Y is the name of a function that I can't look at because it is
created from the expansion of macro X, and so on... It's a head-banger.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: Code reformatting project [DONE]

Post by klauss »

Macros were there to appease ATI drivers.

I think we can fork shaders into ati/nvidia versions with the new foldering scheme rather easily (whenever we have such versions), and make users make their pick.

So go ahead, those macros are a pain in the ass.
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: Code reformatting project [DONE]

Post by chuck_starchaser »

Yeah, I know; but I haven't replaced them with loops; I just expanded them manually and used copy/paste.

Code: Select all

uniform int light_enabled[gl_MaxLights];
uniform int max_light_enabled;
uniform vec4 detail0Plane;
uniform vec4 detail1Plane;

//temporarily using the Sun's solid angle, as seen from Earth, for the solid
//angle of all light sources, until this parameter can be passed as a uniform
//for each light.
#define SUNS_SOLID_ANGLE (0.000263759)

/* varyings:
 *   gl_TexCoord[...]
 *    0 - tex coord
 *    1 - ws normal
 *    2 - ws tangent
 *    3 - ws binormal
 *    4 - vertex-to-eye direction
 *    5 - vertex-to-light0@xyz, light_size@z
 *    6 - vertex-to-light1@xyz, light_size@z
 *    7 - untransformed vertex position
 **/

//float selfshadowStep(float VNdotL) { return step(0.0,VNdotL); } // fast but hard selfshadow function
float selfshadowStep(float VNdotL) { return smoothstep(0.0,0.25,VNdotL); } // costly but soft and nice selfshadow function

vec4 lightPosAndSize0(in vec4 vertex)
{
  vec4 lpos = gl_LightSource[0].position;
  vec4 rv;
  rv.xyz    = lpos.xyz - vertex.xyz*lpos.w;
  rv.w      = SUNS_SOLID_ANGLE;
  return rv;
}
vec4 lightPosAndSize1(in vec4 vertex)
{
  vec4 lpos = gl_LightSource[1].position;
  vec4 rv;
  rv.xyz    = lpos.xyz - vertex.xyz*lpos.w;
  rv.w      = SUNS_SOLID_ANGLE;
  return rv;
}
vec4 lightPosAndSize2(in vec4 vertex)
{
  vec4 lpos = gl_LightSource[2].position;
  vec4 rv;
  rv.xyz    = lpos.xyz - vertex.xyz*lpos.w;
  rv.w      = SUNS_SOLID_ANGLE;
  return rv;
}
vec4 lightPosAndSize3(in vec4 vertex)
{
  vec4 lpos = gl_LightSource[3].position;
  vec4 rv;
  rv.xyz    = lpos.xyz - vertex.xyz*lpos.w;
  rv.w      = SUNS_SOLID_ANGLE;
  return rv;
}
vec4 lightPosAndSize4(in vec4 vertex)
{
  vec4 lpos = gl_LightSource[4].position;
  vec4 rv;
  rv.xyz    = lpos.xyz - vertex.xyz*lpos.w;
  rv.w      = SUNS_SOLID_ANGLE;
  return rv;
}
vec4 lightPosAndSize5(in vec4 vertex)
{
  vec4 lpos = gl_LightSource[5].position;
  vec4 rv;
  rv.xyz    = lpos.xyz - vertex.xyz*lpos.w;
  rv.w      = SUNS_SOLID_ANGLE;
  return rv;
}
vec4 lightPosAndSize6(in vec4 vertex)
{
  vec4 lpos = gl_LightSource[6].position;
  vec4 rv;
  rv.xyz    = lpos.xyz - vertex.xyz*lpos.w;
  rv.w      = SUNS_SOLID_ANGLE;
  return rv;
}
vec4 lightPosAndSize7(in vec4 vertex)
{
  vec4 lpos = gl_LightSource[7].position;
  vec4 rv;
  rv.xyz    = lpos.xyz - vertex.xyz*lpos.w;
  rv.w      = SUNS_SOLID_ANGLE;
  return rv;
}

void lighting2(in vec4 vertex, in vec3 refl, in vec3 normal, inout vec4 pc, inout vec4 sc)
{
  vec4  lpatt  = lightPosAndSize2(vertex);
  float NdotL = dot( lpatt.xyz, normal );
  float RdotL = dot( lpatt.xyz, refl );
  pc += lpatt.w*(  gl_FrontMaterial.ambient * gl_LightSource[2].ambient
                 + max(0.0, NdotL) * gl_LightSource[2].diffuse * gl_FrontMaterial.diffuse );
  sc += lpatt.w*(  pow( max(0.0, RdotL) , max(1.0,gl_FrontMaterial.shininess) ) * selfshadowStep(NdotL)
                 * gl_LightSource[2].specular * gl_FrontMaterial.specular );
}
void lighting3(in vec4 vertex, in vec3 refl, in vec3 normal, inout vec4 pc, inout vec4 sc)
{
  vec4  lpatt  = lightPosAndSize3(vertex);
  float NdotL = dot( lpatt.xyz, normal );
  float RdotL = dot( lpatt.xyz, refl );
  pc += lpatt.w*(  gl_FrontMaterial.ambient * gl_LightSource[3].ambient
                 + max(0.0, NdotL) * gl_LightSource[3].diffuse * gl_FrontMaterial.diffuse );
  sc += lpatt.w*(  pow( max(0.0, RdotL) , max(1.0,gl_FrontMaterial.shininess) ) * selfshadowStep(NdotL)
                 * gl_LightSource[3].specular * gl_FrontMaterial.specular );
}
void lighting4(in vec4 vertex, in vec3 refl, in vec3 normal, inout vec4 pc, inout vec4 sc)
{
  vec4  lpatt  = lightPosAndSize4(vertex);
  float NdotL = dot( lpatt.xyz, normal );
  float RdotL = dot( lpatt.xyz, refl );
  pc += lpatt.w*(  gl_FrontMaterial.ambient * gl_LightSource[4].ambient
                 + max(0.0, NdotL) * gl_LightSource[4].diffuse * gl_FrontMaterial.diffuse );
  sc += lpatt.w*(  pow( max(0.0, RdotL) , max(1.0,gl_FrontMaterial.shininess) ) * selfshadowStep(NdotL)
                 * gl_LightSource[4].specular * gl_FrontMaterial.specular );
}
void lighting5(in vec4 vertex, in vec3 refl, in vec3 normal, inout vec4 pc, inout vec4 sc)
{
  vec4  lpatt  = lightPosAndSize5(vertex);
  float NdotL = dot( lpatt.xyz, normal );
  float RdotL = dot( lpatt.xyz, refl );
  pc += lpatt.w*(  gl_FrontMaterial.ambient * gl_LightSource[5].ambient
                 + max(0.0, NdotL) * gl_LightSource[5].diffuse * gl_FrontMaterial.diffuse );
  sc += lpatt.w*(  pow( max(0.0, RdotL) , max(1.0,gl_FrontMaterial.shininess) ) * selfshadowStep(NdotL)
                 * gl_LightSource[5].specular * gl_FrontMaterial.specular );
}

void main() 
{
  // Compute position, eye-to-object direction and normalized world-space normal
  vec4 position = gl_ModelViewMatrix * gl_Vertex;
  vec3 eyetopos = normalize(position.xyz);
  vec3 normal   = normalize(gl_NormalMatrix * gl_Normal);
  vec3 tangent  = normalize(gl_NormalMatrix * gl_MultiTexCoord2.xyz);
  vec3 binormal = cross(tangent, normal) * sign(gl_MultiTexCoord2.w);
  // Load varyings
  gl_TexCoord[0] = gl_MultiTexCoord0;
  gl_TexCoord[1].xyz = normal;
  gl_TexCoord[2].xyz = tangent;
  gl_TexCoord[3].xyz = binormal;
  gl_TexCoord[4].xyz = -eyetopos;
  gl_TexCoord[5] = lightPosAndSize0(position);
  gl_TexCoord[6] = lightPosAndSize1(position);
  gl_TexCoord[1].w =
  gl_TexCoord[2].w =
  gl_TexCoord[3].w =
  gl_TexCoord[4].w = 0.0;
  gl_TexCoord[7] = position;
  // set primary color to the emissive material properties
  vec4 pc = gl_FrontMaterial.emission;
  vec4 sc = vec4(0.0);
  vec3 refl     = reflect( eyetopos, normal );
  if (max_light_enabled >= 2)
  {
    if (light_enabled[2] != 0) lighting2(position, refl, normal, pc, sc);
    if (light_enabled[3] != 0) lighting3(position, refl, normal, pc, sc);
    if (light_enabled[4] != 0) lighting4(position, refl, normal, pc, sc);
    if (light_enabled[5] != 0) lighting5(position, refl, normal, pc, sc);
  }
  // Need this instead of ftransform() for invariance
  gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
  gl_FrontColor = gl_BackColor = pc;
  gl_FrontSecondaryColor = gl_BackSecondaryColor = sc;
}
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

Something very strange happened...

I rearranged my svn folders, a few days ago. I have a folder repo, with folders trunk and branches under it.
Under trunk I have a folder vegastrike, which was/is? a checkout of vegastrike/trunk/vegastrike.
And my original vegastrike folder, which I had svn switch'ed to the reformat branch, moved under
trunk/branches/reformat/vegastrike in my disk.
Due to that rearrangement, my symbolic links from data/bin no longer work.
So, I wanted to create new links; and since the branch is merged already, I decided to create links to
trunk/vegastrike.
I found that there were no binaries there. Of course! I never compiled in that folder. BUT...
When I try to compile there, there seems to be no Makefile.am.
Now, how is this possible? Not only there should have been a Makefile.am from the trunk checkout, but
I even merged my new Makefile.am into it. How can it be missing?
I tried svn status, but it only mentions boost; no other files.
But svn info shows the full path to trunk/vegastrike in sourceforge.

I'm totally confused.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

Ahh, never mind; I'd never run ./bootstrap-sh and ./configure.

EDIT:
By the way, my room-mate was saying we should be using the boost libraries that come with Ubuntu,
when they are available, as Ubuntu patch them to get rid of warnings and stuff.
And, speaking of the devil, any reason why we can't switch to boost 1.40?
It's supposed to be a more stable release than 1.35, long term support; and my room-mate switched
from 1.35 to 1.40 at his project where he works; said the change was simple and transparent.
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: Code reformatting project [DONE]

Post by pheonixstorm »

Can always add the latest boost to /boost and depreciate 1_28 (keep 1_35 in case something breaks). At least then we can keep the last 2 boost versions (but should we update 1.35 to 1.39?)
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Code reformatting project [DONE]

Post by chuck_starchaser »

Fixed gfx/technique.cpp, which seems to have got corrupted during merge, and would not compile.
r12646
Post Reply