Messages

41

RaptorNL / Re: Questions about the RUDP headers

« on: November 02, 2006, 07:06:32 pm »

First off, I'd like to note that I moved the Enhanced UDP information off of the Features page into its own page.

Do we really need header length?

If we look further down the spec, we can see that every segment except EAK has a fixed length in bytes (which is the unit of the value in header length). About half of the segments (ACK, RST, NUL) have header lengths of 6. SYN has the longest length at 28, and TCS has 12. Only EAK has a variable-length header, since the header contains the list of segments received out of sequence. "Its minimum value is seven and its maximum value depends on the maximum receive queue length." Thus, we need the header length to know how long the segment header is.

I suppose we can make an argument that if we know the type of segment (based on the flags at the start) that we know the size of the segment, meaning that the size is not needed. However, I'd still think the size would be necessary for determining whether additional data was included in the segment (which is expressly forbidden for certain segment types - SYN, RST, NUL - meaning that an error would be thrown), and for determining whether the whole packet made it (especially important for EAK, since we can't know the full header length).

I can agree with leaving the header length, now that I've read more of the spec. I just wanted to make sure it got discussed so we're sure what we're doing.

It is worth noting that the spec refers to the data as "segments," not "packets." I think this is due to RUDP being implemented on top of the UDP protocol - the whole thing, UDP header + RUDP header + data (if any) is the whole packet. However, to UDP's standpoint, the RUDP header is simply regular data in binary form, to be interpreted in any way so chosen by the recipient. Thus, I think the spec is thinking of the RUDP headers as simply "segments" in the packet as a whole. Just an observation I thought I'd share.

Ok, we can change our terminology to match, if we want to. The reason I'm using the term "packet" stems more from my experience with RakNet.

Do we need all those flag bits?

As described above, the flag bits are necessary to know what kind of packet we're dealing with, so I'll take this question as "Do we have to send all of the types of packets described in the spec?" Initially, I'd say yes - they're in the spec, so we should probably use them. The only one we may not end up using is the NUL packet, which is basically the equivalent of a "ping," which the Gamdev.net forum post says can easily be accomplished (in games) by just watching the traffic going back and forth. However, I would still rather include it for completeness's sake, rather than leaving it out to save a bit and a minor bit of logic to handle it.

The reason I asked that is because I want to add two flag types to the original spec: one for reliable/unreliable and one for ordered/unordered.

Where does channel number fit in here?

I modified the page to include that today.

These headers are both for sending ordered data packets? Is that why we have the 7th bit 0 for reliable and 1 for unreliable (which I would reverse, personally)?

Yes. I have actually changed the meaning of that bit in the latest version on there, using the ACK bit instead for reliable/unreliable (since ACK is only used when you're doing reliable packet transmission) and used that bit instead to signify ordered/unordered receipt.

42

Precursors / Re: Precursors, Open Source, GPL and community?

« on: October 29, 2006, 02:27:50 pm »

<whitelynx> as far as GPL vs. LGPL, keep in mind that GNE effectively is a 'proprietary software developer' even though we tend to do a lot of our stuff with open-source licenses whenever possible
<whitelynx> our end goal is to end up selling something in some form, so that we can make money to eat and maybe not need other jobs on the side
<whitelynx> personally i'd still like to be able to use any of our code in our proprietary products if/when needed
<whitelynx> for Precursors itself the current model we have in mind is for the code to be freely available (under LGPL) and then license the content and the use of our servers to the end users
<whitelynx> if we licensed the precursors source under GPL instead of LGPL it would effectively prevent us from using _any_ of that code in _any_ proprietary project down the road, even if we kept the original code (the GPL stuff) open-sourced

As far as the Stallman article... I'm not sure I agree with forcing people to open-source their code to be able to use a library. I'm all for open-source development, but I'm not really pat of the GNU community, just the open source community. I'd rather not start a flame war over GNU's tactics, but personally I prefer LGPL simply because it allows more freedom for everyone involved.

43

RaptorNL / Re: Developers' Journal

« on: October 27, 2006, 04:32:51 am »

Ok, we've been doing some massive work on RaptorNL as of late. The next really big thing we'll be needing to do as far as design is concerned deals with how to handle what used to be HawkNL's 'driver' struct. Please take a look at https://kashmir.g33xnexus.com/projects/raptornl/wiki/Design/Refactoring and let us know if you have any thoughts.

44

RaptorNL / Re: [OT] Interesting programming articles

« on: October 22, 2006, 04:40:17 am »

Just browsing through the Boost docs, and I came across a very interesting type, boost::any. It is basically a variant type that's a hell of a lot safer than a union. (and more flexible i believe) On the examples page, they also have an example of a key/value pair class with boost::any as the 'value' type, allowing you to set arbitrarily-typed values.

45

RaptorNL / Re: Developers' Journal

« on: October 22, 2006, 03:00:22 am »

In HawkNL, (as far as I can tell) groups are basically ersatz sockets that can be written to and read from just like any standard socket that allow you to effectively do software multicasting. They're an interesting concept, and something definitely worth retaining for RaptorNL. The question is, however, how should we go about doing this? I'm not entirely sure how HawkNL went about implementing them, but they used file descriptors to represent groups, same as for sockets. Personally I think this could be done as a class instead, one which inherits from Socket. I'll have to take a closer look at HawkNL's implementation to be sure, but I think that'd be the way to go for this.

46

RaptorNL / Re: [OT] Interesting programming articles

« on: October 21, 2006, 04:07:59 pm »

Another very useful site I just came across is one which lists all the predefined macros in almost any compiler you can think of. This is very useful for telling what architecture, compiler, or environment you're using. It can be found at http://predef.sourceforge.net/.

47

RaptorNL / Re: Developers' Journal

« on: October 21, 2006, 03:20:34 pm »

I've been looking at the different address families available in HawkNL, and it got me thinking that it might be useful to have two things: subclasses of Address for each address family, and a convenience function to create an instance of the correct Address subclass, given a valid address in string form. Basically it'd parse the address to determine what address family it is using, and create the appropriate Address object.

Also, if we combine the address family into the Address class and subclasses, then we may not need to manually specify the address family when creating a ConnectSocket from and Address. We'd still have to specify it for ListenSocket, but that's fine.

48

RaptorNL / [OT] Interesting programming articles

« on: October 21, 2006, 12:50:32 pm »

A very interesting thing I just came across is something called "the Named Parameter Idiom". Basically, it allows C++ to have something similar to Python's keyword arguments. (things like func(foo="boo!", bar=3) in Python) The article can be found at http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.18.

49

RaptorNL / Re: Developers' Journal

« on: October 21, 2006, 12:41:26 pm »

First, some questions I've already posed to contingencyplan and others in the Precursors IRC channel, just in case any forumites have thoughts on them:

• Where should we use references vs. pointers? So far the consensus seems to be that we should use references for the Address class at least so that we can test for equality without dereferencing pointers. Otherwise you get ugliness: ((*add1) == (*add2)) See the articles at http://www.embedded.com/story/OEG20010311S0024 and http://www.parashift.com/c++-faq-lite/references.html for more information on the subject.
• Should a Buffer class be made to encapsulate all the read/write macros in raptornl.h? Currently we have HawkNL's read and write macros for every data type, made for working with packet buffers. (arrays of bytes) I think it'd make sense to use a class for this so that the user doesn't need to work with raw buffers.
• Where should endian-swapping go? I think it'd make sense to put it in the Buffer class, but then you're required to use it for all data... on the other hand, this isn't necessarily a bad thing. (we'd just use a Buffer* or Buffer& in all our send/receive functions)
• Should we make a class for the overall network layer options? There are some "global" options like whether or not to collect socket statistics, big vs. little endian data, and allowing multiple drivers to be selected... I'm not sure how many of these options will stick around once we've finished the conversion, but it might still be nice to have a central place to manage the various sockets and other things in the system.

50

RaptorNL / Developers' Journal

« on: October 21, 2006, 12:26:55 pm »

I'm starting this thread as a collection of random thoughts and questions I come up with as I go through the process of converting the old HawkNL code into RaptorNL's new structure. Anyone should feel free to reply if they have any thoughts on what I say here. (also, contingencplan, feel free to post your own thoughts and questions here as well) I'd like to turn this into a running discussion of the structure of RaptorNL. If any one question in this thread grows beyond a couple of posts, it will get moved to its own thread.

51

Precursors / Re: RE: Models, screenshots, etc... in Developers' Discussion

« on: October 20, 2006, 02:55:13 am »

They don't even understand double? Honestly, I don't think adding the ability to consider coordinate systems as doubles would be very hard; just have an #ifdef to switch between them.

They have support for double in certain classes (see http://crystalspace3d.org/docs/online/api/group__geom__utils.php) but those classes aren't used in most of the engine proper, and we'd probably have a tough time convincing them that there was a need for #defines like that... There doesn't seem to be an option in configure to enable it currently.

After talking to the devs, they agree that there should be some work put into getting a better coord system into CS, but thebolt says that double probably isn't the way to go... Even if we did use double, it wouldn't solve much... it is still as non-linear as float is, as far as precision; it just wouldn't start to show the jitter as soon. (see http://home.comcast.net/~tom_forsyth/blog.wiki.html#%5B%5BA%20matter%20of%20precision%5D%5D for more info, and check out the OffendOMatic while you're there)

Ah, missed that part, sorry. Yeah, that should work then. Like I said, my main other concern is speed of conversion between these formats, especially if we're doing such conversions frequently (I'd suspect we'd be doing them numerous times per second, especially when there's a BUNCH of stuff on the screen [e.g., major battles]).

That is a valid concern... I'm tempted to simply go for a fixed-point implementation where the rightmost n digits of the RBI are beyond the decimal point (multiply the RBI by 10^-n) since it would simplify calculations and still give us a usable infinite coordinate system. (as long as we ignore the performance impact of extremely large numbers)

Of course, there's still other solutions we can explore... we could go with a paged memory-influenced algorithm, where we have a "sector" we specify with an int 3-vector, (so we basically have a 3D grid of sectors, kinda like a rubiks cube) and then float coords within that. The size of the sectors would depend on how much distance we can squeeze out before it gets jittery. Of course, this then brings up the question of what to do when we approach boundaries... my instinctual solution in this case would be to simply use sectors and portals, since that's what they're made for. :P

Edit: After reading up on that Tom Forsyth page, I'm starting to think a straight 64-bit int might be the best way to go... as he says, using a 64-bit int as a fixed-point number "gets you to the furthest distance of Pluto from the Sun (7.4 billion km) with sub-micrometer precision." That should be enough for in-system coords at least...

What do you guys think?

52

Precursors / Re: RE: Models, screenshots, etc... in Developers' Discussion

« on: October 19, 2006, 04:56:25 pm »

Hrm. This sounds good, but I still want to see the implementation on the RBI / RBF before I can sign off on this. I think this will work, thinking about it, but we'll have to see it in action. And we still have to consider the cost of converting it to a float / double / long double. Likely the latter two - if we convert it to float, we'll still be running into the jitter issue, methinks: the jitter is caused by rounding and lack of precision. It doesn't matter how much precision we have when storing the value in the RBF. What matters is how much precision we have after storing it in memory as a floating point value (not necessarily a float).

The issue with floats only arises when the values are relatively far from 0; ie. really big positive or negative numbers. If we're converting into a localized coordinate system (such as one centered around the player) the stuff that's far away doesn't matter because it'd be so small on the screen, so we don't care if it jitters. If it's closer, then it has good precision. Besides, float is all that CS and the hardware understand.

Oh, and if we only have 8 bits, then we have a precision of 10 ^ -128 to 10 ^ 127, since we need to account for positve exponents too. But we'll see. I still think doing something of a fixed point implementation might be a better way to go about it, since we can guarantee to have a certain precision about what we're doing.

Actually, as I said above, we don't need positive exponents at all. RBI will handle that, since we have an effectively infinite range for the mantissa. The only thing we can't do with RBI currently is non-integral values, which is what the exponent would be for.

53

Precursors / Re: Precursors, Open Source, GPL and community?

« on: October 19, 2006, 03:24:09 pm »

Well, the big thing we're actually selling (other than the content) is the usage of our servers.

54

Precursors / Re: RE: Models, screenshots, etc... in Developers' Discussion

« on: October 19, 2006, 03:17:30 pm »

Ok, as far as really big numbers...

First off, there's next to no chance of us getting CS to change the coordinate system used in the base libraries. (especially the renderer) If nothing else, it would require hardware support on the video card end, and that's something that just won't happen.

However, if we took my second suggestion (the rendered area of the world being centered around the player or camera) and then used an RBI/RBF implementation as our "universal" coordinates but converted back into float when doing rendering and localized stuff like physics, then it would probably work pretty well.

Now... as far as getting decimals out of RBI. I think the best way might be to store an exponent, which should only need 8 bits or so (that's all that's used in float) and then use RBI as the mantissa. (or, technically, "significand") If we use all 8 bits of the exponent as denoting a negative exponent, this gives us quite a bit of precision, and since RBI is the mantissa we won't need the exponent to make bigger numbers. (only smaller) To compute the actual value of a number of this type (let's call it RBF for simplicity) you use the following formula:

Code: [Select]

mantissa * 10^(-exponent)
This gives us a precision of about 10^-256, which means about 0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001

If that isn't enough precision, then you're too damn picky.

55

Precursors / Re: RE: Models, screenshots, etc... in Developers' Discussion

« on: October 16, 2006, 08:50:11 pm »

Hard to believe none of us have replied to this post yet... we've been talking about it a lot. :P

It would be great to see you working on a solar system generator, since that's one of the big parts missing from a playability standpoint right now.

As far as scale, that is an inherent problem with Crystal Space. It uses the C++ 'float' type for coordinates, which becomes extremely inaccurate past a certain point. (at something a good bit less than 1000000000, you lose all decimal places and have to deal with integer precision or worse) There are two ways to solve this in CS, each of which has some pros and some cons.

The first way involves splitting the space up into sectors. This works fine on a small scale, but sectors are a technique that is generally more geared toward "indoor" scenes. Basically, you'd have a cube (the current sector) with 6 faces, each of which would be a "portal" to another sector. The reason that this fixes the float issue is that each sector would be based around the origin (0,0,0) and each portal would "warp" back to the other side of the next sector so that you never get further away from the origin than the size of a sector.

The problem with the first solution is that we have to split up space into a large number of sectors, and it gets rather difficult to track what is in which sector. Also, either we have to have a huge amount of separate sectors (so the size is relatively small) or else we'll still run into some jitter near the edges of a sector.

The second solution is to put the player's ship (or character, or whatever) at the origin and translate the rest of the world to be correctly positioned around it. This is a great solution and lends itself well to deep space scenes, because once something is far enough away to cause jitter, the jitter will be small enough and far enough away that you won't notice it.

The problem with this solution is physics. ODE (and the CS physics system in general) tries to move each object around... somehow we have to then translate everything into ship-space coordinates for the renderer. It would be good to do some tests to see how well this method works with physics and whether we can adapt it to work on a large scale. If we can get past the problems with physics integration, this may well be our best solution.

As far as your ideas on seed-based system generation, that looks pretty promising! I'm not sure about using the stuff from Celestia (we'll have to check their license before you commit any of that to the repository) I have some mixed feelings as far as doing the calculations client-side. I think they should definitely be done on the client to improve speed and response, but the server needs to send updates to the clients every once in a while, and even more often if the given object goes outside of its "predicted" path for some reason. (like being rammed by a large ship or something) Keep in mind that regardless of how much of the calculation is done on the client, the server will need to have the final say on anything that affects actual gameplay.

I'd like to set up an account for you on our subversion repository so that you can commit your code there and we can help you out with it. We'll give you a sandbox directory in the repository, and I'll contact you over PM on the forums to get your login information.

Thanks for working on this! It's encouraging to see some other people getting interested in coding for Precursors.

56

RaptorNL / Re: Idea: Socket class

« on: October 10, 2006, 02:08:23 pm »

For now, I'm not too worried about the statistics stuff... I think it clutters up the interface, but I can see why it's in Socket. Other than that, since there seems to be no argument about the other two points, I'm going to start implementing them.

57

RaptorNL / Idea: Socket class

« on: October 05, 2006, 06:18:34 pm »

Right now we're making a thin class to wrap socket functionality, called Socket. I have some ideas for making it a bit more than a strict thin wrapper that I think might make it easier to use.

• Socket subclasses - create two smaller subclasses of Socket, ListenSocket and ConnectSocket, to handle the functionality for incoming and outgoing sockets, respectively. (if you're wondering about the names, take a look at any classic BSD sockets implementation) This makes all of the individual Socket files a bit easier to read through, as the read/write functionality is common to all sockets, but a listening socket can't connect, and a connecting socket can't listen.
• Move some functionality to the constructor - open() should only need to be called once during the lifetime of a socket, and it must be called before anything else can be done, so I think it makes sense to put that into the constructor. Similarly, either listen() or connect() must be called on a socket before anything except open(), so it would make sense to put those in the constructors of their respective socket types. (or, if we don't split Socket into subclasses, simply have convenience constructors that take care of the listen/connect functionality.)
• Move statistics functionality out of Socket - Statistics are nice, but I don't think their functionality logically belongs inside Socket... it may make more sense to move it to its own Statistics class that all Sockets register with, and they don't record statistics unless there is an attached Statistics object. (see my comments on the wiki for more thoughts)

58

Requiem for Innocence / Re: Download?

« on: October 03, 2006, 07:31:52 pm »

This has been fixed. It was actually a problem in the site's code that kept it from sending the right headers for IE, which doesn't support XHTML. (so the site has to be billed as straight HTML, which it actually isn't) Anyways, it should work in IE now.

59

Bug Reports / Re: ODE INTERNAL ERROR 2: Bad argument(s) in dxSphere()

« on: September 21, 2006, 11:07:35 pm »

That's very strange... I always compile ODE with double precision... did Jorrit have any idea as to why that was causing a problem?

60

RaptorNL / Re: Start of the RaptorNL project

« on: September 19, 2006, 12:18:02 pm »

<idiocy>
We should have 2 main classes in the library: Tube and Message. Every time you connect to another computer, a new Tube is created, and then you can create Messages and call Tube.suck(message) to send it.
</idiocy>