Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rosencrantz

Pages: 1 2 [3] 4
41
Bug Reports / Re: ODE INTERNAL ERROR 2: Bad argument(s) in dxSphere()
« on: September 07, 2006, 07:12:04 pm »
You can also try out doing "lsof -p <pid of precursors>" and seeing where the libraries are that it's pulling. Good way to make sure you don't have any lost libraries floating about somewhere unexpected.


42
Bug Reports / Re: ODE INTERNAL ERROR 2: Bad argument(s) in dxSphere()
« on: September 07, 2006, 05:34:21 am »
Recon, are you still having these issues?


43
That is exactly what we needed! Thanks a bunch!

Cplan, it's you job to go through those articles, and get really familiare with them. In about a week, I'd like to be able to get you and whitelynx to hash out a proposal for CS to add support for those features, or at the very least whatever framework is needed so we can add those features as plugins ourselves.

We're one step closer to where I want to see precursors get. :-D

I read through some of those articles and they've got alot of good things in them.
However, I think in the 1st or 2nd article he was using ROAM. I think there's a better alg out there than ROAM. I'll look around and see if I can find it.

44
Precursors / Notes on the journal of the main developer of Infinity
« on: August 30, 2006, 03:37:17 am »
I've been looking through this guys journal some just to get a feel for where he started and how he got there, and if any of it is useful to us.

First of all, can someone with more graphics background explain field of view?
Specifically I'm referring to his Aug 30, 2004 post.
Quote
I finally fixed the impostor bug. The formula i used was wrong, i was not calculating the frustum field of view angle correctly. It was a bit tricky to understand why, but revising my trigonometry helped a bit. For those interesting, the code looks like this: for a viewer position located at ViewPos, the impostored object being represented as its bounding sphere Center, Radius,

float d = distance(ViewPos, Center)
float fov = asin(Radius / d)
float l = d * tan(fov)
matrix4x4 viewMatrix = buildLookAtMatrix(ViewPos, Center)
viewMatrix = buildTranslateMatrix(-ViewPos) * viewMatrix.transpose()
matrix4x4 projMatrix = buildProjectionMatrix(fov, 1, znear, zfar)
matrix4x4 worldMatrix = buildIdentityMatrix()

Looking at what kind of triangle that math produces makes absolutely no sense physically. I'd expect something more like.

fov = atan(Radius/d)
l = Radius / sin(fov)

Is there something missing? (Probably the definition of field of view).


45
Bug Reports / Re: ODE INTERNAL ERROR 2: Bad argument(s) in dxSphere()
« on: August 29, 2006, 09:39:27 pm »
For now, try using revision 1021 of ODE (which is what I'm using and it still works). I'll see what I can verify and find as soon as things finish compiling.

EDIT: As far as migrating the game data, just cd into the gamedata directory and follow the instructions
listed here.

http://forums.g33xnexus.com/index.php/topic,589.0.html

EDIT2:

Also, currently working on getting an alternate testing box up so I don't keep overloading my main workstation when I compile CS.  :o

So it may be a bit before I verify this issue.

46
Precursors / Re: A game worth noting - possible huge competitor
« on: August 24, 2006, 07:42:10 pm »
Here's a copy of what I wrote in the IRC channel earlier:
Quote
<whitelynx> if someone can convince me that the engine is definitely better than CS, ok.
<whitelynx> but here's the thing...
<whitelynx> I haven't seen _anything_ that they've done that couldn't be done in CS
<whitelynx> yes, some of what they're doing hasn't been written yet in CS, but it can be done
<whitelynx> and we have to weigh the cost of implementing it within CS' framework to the cost of rewriting what amounts to 90% of our code
<whitelynx> one thing Rosencrantz didn't mention last night in his list of stuff we'd need to reimplement is the behaviour layer
<whitelynx> we'd need to rewrite the whole thing, since all of our BL classes make heavy use of CS-specific and CEL-specific functionality
<whitelynx> so basically, unless there's something in the underlying architecture of the infinity engine that makes it far superior to CS/CEL, it won't be easy convincing me that we need it at all :-P

As far as talking to their team, the thing I'd be most interested in hearing from them is how they went about getting seamless planet-to-space transitions. The procedural stuff would also be interesting, but I think our starfield mesh would go a long way toward that goal.

Yeah, whitelynx that's mostly the conclusion I'd come to. It looks really beautiful at first glance, but after playing with their combat prototype I don't see much differernce between that and what we can do in CS. And I agree on the seamless transitions, although I think I've got some ideas on how they do that.

I did forget to mention the behavior layer specifically though, thanks for catching that.


47
Precursors / Re: A game worth noting - possible huge competitor
« on: August 22, 2006, 01:52:40 am »
Also on this front I was browsing around and came across
http://video.google.com/videoplay?docid=8426566575107987989
and
http://video.google.com/videoplay?docid=-3744650885934024232.

They have higher res versions for download, but those are the easy ones to see some of the stuff they're doing.
Most notable seamless space-planet transions. They've also stated in the FAQ that they're using procedural functions to help generate content.




48
Actually I just thought of a method that could be used to find the center of gravity. It's a little heavy on the calculation side but might be able to be made into some sort of blender plugin (I have no idea how those works, so I'm just hoping  ;D  ) Also this will probably only work on regular polyhedral objects I need to figure out a more general way.

For every face on the mesh determine the center of the face and the area of the face. Then, sum all up all of those areas and divide the mass by that total area (to get the mass/unit area). Then use the non-integral form of the center of mass equation with the points as the center of each face and the masses for said points as the mass/area of that face.

EDIT: This might work for non regular polyhedral objects, but I'm not sure on that(perhaps just those that aren't *too* extreme).

49
Suggestions / Quasi-Dynamic Sky(Space) Box
« on: August 09, 2006, 06:15:12 pm »
Ok, I had an idea that's probably way in the future in terms of development, but I think it might add some extra "Hey that's cool!" factor.

How about a quasi-dynamic sky box. What I mean by this is that we figure out how each solar system is related to every other system in terms of distance and spatial orientation. Then we figure out what the universe looks like from that solar system. Same thing with other galactic entities.

for star in systems
  project [systems - star] onto star.unitsphere
  project [galactic_objects.nonstars] onto star.unitsphere

So say that you're going from one system to the next. When you arrive at the new system you can look behind you (or effectively behind you depending on how the new system is oriented w.r.t. the old system) and see the star you just came from.




50
Or, we could put the center of mass where it 'feels' right.

A dirty method for that is to find the biggest inner bounding circle, and the smallest outer bounding circle and then pick a nice spot between the two centers of those circles.

EDIT: Replace circle with spheres. That's what I meant anyway.

51
More specifics on what I was able to verify. I was able to verify this from within the game engine itself (not the menuing system).

Here is some info from the 967 build. (GDB stuff running on linux)

http://gne.pastebin.ca/112806 (With hitting the enter key)
http://gne.pastebin.ca/112809 (hitting the F10 key)

On the enter key one, the window was still open after the SIGSEGV. But the window was actually closed doing the F10 version.


52
I just verified the orbiting. Yeah, it's pretty weird. There some oddities in the mechanics of the way the asteroid was orbitting that I'll have to look at it and think about it some more. I'll post some more on it after that though.


53
Suggestions / Re: Non-standard spaceflight thrusting
« on: May 24, 2006, 08:37:48 pm »
I do want it to be toggle for coast. Thing is, coast simply ignores translational input. That's why rotation still works. It's to allow you to pick a direction, and then 'coast' so that you can turn your ship around, and fire at people behind you.

Now, what do you mean by 'more inertial'? Currently, we're doing everything with target velocities. We are using an accurate physics simulation, however, we're letting the game figure out what thrusts we need, given a desired velocity on a given axis. It's the most intuitive, and flyable thing we've been able to come up with.

Are you looking for something where once you srart movement, it keeps going? That would be interesting... setting the target velocity to the current one. then, toggle it back, and it acts like it currently does. Hmm... I think we could easily do this.

I guess the only real question is... what advantages do you have with this?

As far as the advantages, I'm not sure that most of them couldn't be simulated by just using coast. I'll think about it though.

And I suppose I'm using inertial because thats what I think I've heard it called before and I haven't thought of a succint way of describing the differences between the two different flight models. Although I think the current Precursors model is somewhere in the middle of what I've seen. I keep feeling like some of the other models don't take inertia into account very well, whereas precursors definetly does.

Also on the coast front, the way it works now is fine, I was just thinking it might be nicer to have it operate slightly different in terms of button mechanics. Right now you have to hold down the button, it would be nice for less finger gynamistics if you could just hit it once to turn it on, and then hit it again to turn it off.

--Rosencrantz

54
Suggestions / Non-standard spaceflight thrusting
« on: May 24, 2006, 04:13:18 am »
Is there any chance we could get a more inertial flight system working?

I know that there's coast, but A) You have to hold down a button for that,
and B) currently I can't get it to do anything but rotate while coasting.

Also on the coasting front, can we get it changed to a turn off/on instead of hold for coast?
Or perhaps an option to switch between the two.

For examples of some space based flightsim that mix inertial and "standard" flightsims look at
Babylon 5: I've found Her, and Vendetta Online.

Last time I played Vendetta's it was just a switch in an option menu. B5's you could switch on and off in mid-flight with spacebar (which made for some interesting dogfights).

--Rosencrantz

55
Bug Reports / Re: Probably not a bug but something on my side
« on: May 22, 2006, 09:21:08 pm »
Yeah we did, not an issue just old libraries hiding in places I forgot to check.

--Rosencrantz

56
Bug Reports / Probably not a bug but something on my side
« on: May 11, 2006, 05:44:26 am »
Ok, this is probably not a bug, but I can't for the life of me figure out what's causing it.

Here's the jam output.

http://g33xnexus.pastebin.com/711212

Here's the runtime output.

http://g33xnexus.pastebin.com/711217

At this point I think it's related to the DT_TEXREL warning message (as that's the only message around the networking stuff).

I've googled for it and all I can find is people suggesting using -fPIC, which it appears is being used. I've updated to gcc 3.4.5 and I still get the same problem. I've tried regetting the precursors source and raknet source and it still bombs out on me. The only wierd thing I have to do is symbolically link to the raknet headers in /usr/include. Oh, and it gets the undefined symbol whenever I try to start the server (same undefined symbol when trying to connect with the client as well).

Any suggestions?

57
Precursors / Re: Subspace Discussion
« on: April 12, 2006, 09:47:15 pm »
/nitpick

Technically it would be nicer to call it the 5th dimension instead of the 4th dimension because when you get down to it time really acts like the 4th spatial dimension.

On the quantum foam thing, I've heard about it before but never really looked into, although that description fits some of the stranger stuff that we've been discovering recently in the QM area.

I've got an old roomate from college who was into the whole quantum foam thing (I never really read much about it for some inexplicable reason). I'll see what I can find on the subject and see what I can throw in about it.


58
Precursors / Re: RolePlaying System
« on: March 08, 2006, 10:27:33 pm »
I've got a fair amount of experiece roleplaying. I think the important part is not the size of the dice that you are using to determine what happens, but the flexibility and balance of the system that you are working in.

From what I've seen the GURPS system has a lot of good stuff(well balanced and broad in genre), but there may be licensing issues with using that system in a closed enviornment such as this.

A d20 system may be good to look at for balance purposes.


59
Version: 0.3.3 build 696
Reproducability: Always.

Abstract: Collision causes gerber and ship to stick, afterwards hitting brings up the Cel window.


Description:
A collision between your ship and the gerber is a quasi inelastic collision. In addition to this after removing your ship from the flying gerber it continues to rotate. Eventually it stops rotating suddenly. At this point if your ship touches the gerber then you encounter the CEL error window mentioned in bug #82.

System:
Windows 98 SE
Athlon XP 2200+
512 MB Ram.
Geforce 4 MX440

--Rosencrantz

60
Bug Reports / Bug Report for 0.3.2
« on: March 01, 2006, 11:34:54 pm »
System information:

Motheboard: A7V333
Processor: Athlon XP 2200+
Memory: 512MB (PC2100 or PC2700 don't remember which)
Video Card: GeForce4 MX440 (AGP)

OS Information:
MS Windows 98 SE.

Precursors caused an illegal operation and was shutdown.
Details:
"Precursors caused an invalid page fault in module Kernel32.dll at 0187:bff858c."
The rest is just Register stuff.

3d Graphics appear to be running fine (Tested with World of Warcraft).

I tested to see if 0.3.1 works, and it does (although it took an uninstall of all precursors stuff and a reinstall of 0.3.1 to do that).

After a reinstall it still had the same error.

--Rosencrantz




Pages: 1 2 [3] 4