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 - whitelynx

Pages: 1 [2] 3 4 ... 9
21
General Discussion / Re: New to the forums
« on: June 18, 2007, 01:31:32 pm »
cplan: There's a DeVry near Buffalo, so I'm guessing there's multiple campuses around the country.

cara: Welcome to the forums! I need to keep an eye on things around here better. -.- Have you heard the most recent announcements concerning our projects? (if not, check the General Announcements board)

22
Developers Journal / Some thoughts, or at least words...
« on: June 11, 2007, 10:53:34 am »
Well, I figure this board hasn't gotten much love in the past year. We've all been busy as hell with school, jobs, women, existential crises, and the like.

Now that we've finally decided what we'll be doing from here on out, I'm sure some of you (ok, probably a LOT of you) are disappointed that we've decided to put Precursors on hold. I know I'm somewhat disappointed myself, but at this point it really is the best thing we could do for the project. We've been working on Precursors on and off for almost 3 years now, and we've gone through so many design changes, different versions of CS, and cycles of forgetting and then re-learning everything we knew about game design that it really is time to take an official break from it.

I do hope, however, that you all realize that this project is FAR from over. We have plans to work on Alluvion Storm for the next 2 years and get it to a publisher by then, which seems to be a much more realistic goal than any goal we've set for Precursors. Once we've gotten Alluvion to a beta-testing stage, (which should be well before a publisher gets their grubby hands on anything) there won't be much more work for the Dev team to do on Alluvion, because all that will be left is content and art. When we get to that point, we plan on throwing all our development resources at Precursors, starting the codebase over (mostly) from scratch, and coding up a good, solid foundation for a game.

The time spent on Precursors so far has been an amazing learning experience for us, and we have come a long way since banging out the first few lines of code in Chris's dorm room my freshman year. I'm very grateful for all of you who have noticed our project and gotten involved, by making models, volunteering code, or even just joining our forums and chatting; it's been a rewarding experience working on a project that captured your imaginations like it did ours!

I hope at least some of you are able to see the same kind of potential in Alluvion Storm; we definitely do. Even if you don't like Alluvion at all, check back in a year or two, and things should be starting back up for Precursors. It's been a great ride so far; here's hoping it gets even better!

23
The Wallth Are Thoundproof / Re: Things you just can't say....
« on: June 03, 2007, 09:20:57 pm »
"I think I left it in my pants..." (a key?)

24
Precursors / Re: Ideas for a Character Generator...
« on: June 02, 2007, 03:06:06 pm »
The question of storing models client-side basically feeds into the whole caching idea, and I'm pretty sure CS has at least basic facilities for that... on the other hand, it could probably use some optimization for use in an MMO.

25
Precursors / Re: CS/CEL Revisions
« on: June 02, 2007, 02:59:32 pm »
I'm actually thinking that this would be a great use for branching; have a branch that follows the head CS and CEL revisions, but keep trunk synced to a specific revision; then, when we want to upgrade to a given CS/CEL revision, just merge in the branch changes up until that point. My reason for this is that I generally need the latest CS/CEL revisions because I do development on them as well, and I hate having 2 checkouts if I can help it. (CS is huge)

26
Bug Reports / Re: Rev 1154 , runtime segfault
« on: April 19, 2007, 10:30:22 am »
Well, there seem to be a few problems here... First, of course, is that you can't build the CEGUI plugin... that's rather important since our main menu and HUD both use that. Second, it's saying it can't find the service manager plugin, which is a bit strange; I don't have the service manager built as a separate plugin here either, and last I knew my copy worked fine. I'm now in the process of distcleaning and rebuilding CS, CEL, and Precursors, since I recently removed my Python 2.5 install in favor of 2.4. I'll let you know how it goes.

27
Wallpapers / Re: star and planets
« on: April 11, 2007, 11:33:05 pm »
Kickass, looking great. ;D

28
Bug Reports / Re: More compile problems
« on: April 06, 2007, 10:37:37 am »
IIRC, we require an svn more recent than 1.0 for both CS and CEL. I've made some changes that didn't make it into the 1.0 releases.

I'm currently trying to check everything out on my desktop and get it compiling with the latest svn of CS and CEL, because I just reinstalled linux a week ago.

29
Precursors / Re: just some screen shots of what i been doing!
« on: April 06, 2007, 10:34:34 am »
Looking great! Like everyone else has been pointing out, we're really busy this semester; I've gotten involved with a few different projects that are more closely related to school, so I've needed to focus on them, but hopefully this summer I'll get a chance to put some work back into Precursors.

We would almost definitely be able to host kiolakin's plugin, but he'd probably be best off trying to contact us via email or these forums, since none of us except cplan have been very active on IRC lately. (sorry for that)

Looking forward to seeing this in Precursors!

30
Precursors Artwork / Re: Photoshop tutorials for making planets and stars
« on: February 11, 2007, 12:32:42 am »
I really like a lot of the work that came out of this thread... what I'd like to see is someone doing some new skybox art for the game using these techniques. When doing skybox art, there's a few things to keep in mind:
  • There should be 6 individual square images, each representing one side of the cube. (i'd suggest 512x512 or 1024x1024 as the size of each image)
  • Each image has to line up with the images that border on it; we don't want nebulas that suddenly cut off at the edges of the cube. (keep in mind, you're creating images for the inside of the cube, so make sure they line up right)
  • Stuff at the edges of each image is going to take up less screen space than in the middle, since it is further from the camera and tilted away from it; therefore, stuff in the corners should be "stretched" a bit to make up for the strangeness in perspective. (you can try doing a "pinch" on the finished images, and it might have the desired effect. The image at the bottom of this post is an example of that.)
  • Don't make it overly flashy; space may be full of interesting things, but that doesn't mean that there's alway 30 psychedelic-colored nebulas with weird shapes visible from any given point. Something along the lines of ryguy's first image would be great for a skybox.

Think you guys can come up with something? If so, it'll probably make it into the game's test levels. ;D

31
Precursors / Re: Out of the Loop
« on: December 29, 2006, 01:07:56 pm »
Yay for sinus infections! :P

The semester was rough on me as well, so I didn't get much done, other than a good bit of work on RaptorNL earlier in the semester... right now I'm in the process of finishing up some tickets so we can get the next Precursors release out next week... we should finally have some Python behaviours (including damage, projectiles, and systems) and some better input stuff, like being able to press enter and use the numpad in CEGUI windows... hopefully.

Anyways... back to work.

32
Precursors / Re: Need help with linker/Autoconfig, Stuck!!
« on: December 17, 2006, 07:23:45 pm »
Well, I appear to be stuck.
Being trying to dynamical link some exteranl apps to my planet generator for the last week and have failed utterly to make any headway. the libs in question are

ImageMagicK and RT

RT is the realtime clock and I need it for moving my moons, Second intervals are just to long.
Please don't use an external library for this; CS includes a virtual clock that should be used for all game timing things... otherwise, things will keep running even if the game is paused. (I know, online games normally don't get paused, but we're planning on making a single-player version of this eventually) iVirtualClock provides methods to get the number of ticks elapsed since the last call, which should be perfect for what you're working on. (you can't really do stuff faster than the framerate anyways, so just go on a per-frame basis) Ticks in CS are milliseconds. (1/1000 second)

Quote
I need ImageMagick to create materials that are bigger that the screen. I have being trying to get them to dynamicaly link when I build my project by changing configure.ac but have had no success. I have looked and asked for help everywhere I can think of but getting nowhere.

revision 1082 of my sandbox is compilable and working copy of what I have done so far with the offending bits commented out. The revision description gives the line numbers of the offending bits of code. so if any of you can try get those librarys to link I would be most greatful. Send me the modified configure.ac file :)
I'll see if i can take a look at the configure.ac as far as ImageMagick goes. I'll let you know if I'm able to get it working.

33
RaptorNL / Re: Questions about the RUDP headers
« on: December 04, 2006, 09:37:09 pm »
Yeah, the original idea was to simply put a reliability layer on top of UDP, and personally I never cared much if it matched up with the RUDP spec. ;)

I wasn't aware that UDP already included a checksum, or I would have left that out. We'll make sure we take that into account when we get around to working on the protocol some more. Thanks for the input!

34
Bug Reports / Re: On the CS_Assert (n < count)
« on: December 04, 2006, 09:32:53 pm »
I figured it out using my Amazing Powers of ObservationTM.

Actually, it was #1 and #3 at the same time. ;) The array in question was the array of sectors that the camera was currently "in", and it was empty because the way they name regions in CEL changed, and we hadn't fixed our code to take that into account yet. So now it's fixed. :)

35
Precursors / Re: Galaxy Generator.
« on: November 13, 2006, 06:18:21 pm »
Actually, even skyboxes have to be done in rectangular coordinates. _Everything_ that goes on the screen is rendered by Crystal Space, including the skybox, so no matter what, everything needs to be converted to rect coords before we give it to the engine. Even if we're rendering stuff to a texture, that should be done through CS, as it is many times more optimized and well-tested than any way we could come up with to do the same thing. ;)

36
Precursors / Re: A possible solution to our scale issue
« on: November 13, 2006, 06:15:20 pm »
well, I have been trying to work out how to get large objects and small objects on the screen at the same time. we where discussing splatting images of far objects on the skybox. but after thinking about this I spotted several large issues with this approach. these where

Generating the image, as the planets will be rotating the image would have to be generated again and again so it would present the correct face to the camera

lighting would affect how that face appeared, and would also have to be calculated 

these seemed like big coding issues that would require lots of work
then i had an idea,

If we could create 2 sectors, one for the solar system with a large scale (1 unit CS = 30,000km) and then a small scale sector ( 1 unit = 10cm ). now if we could get CS to render the large scale sector first, then render the small scale sector over it we would have both scales on screen looking right with minimal coding. Now we would have to do a bit of trickery to move objects out of the large scale sector to the small scale sector as the got close but this seem easy compared to skybox issues we would have to solve.
Actually, this is closer to what I originally had in mind... the splatting thing was something you mentioned, and I didn't see a problem with it at the time. ;)

How about this... do 2 sectors as you say, but make the large-scale one the skybox. Simply make it camera-centered, and have it render with "sky" priority. (so it renders behind everything else) Everything in the skybox sector should be rendered as billboard impostors instead of rendering the whole model each time, to save poly counts. (otherwise we'd be rendering tons of polys every frame) I'm not sure how far along CS's LOD impostors are yet, but you can ask in the CS channel... basically what we'd need to do is render each object to a texture (the "impostor") and render that as a billboard in place of the actual object when rendering the skybox. Then, we wouldn't put anything in the skybox that would fit in the solar system's sector, and we can even move the contents of the skybox sector around a bit if you get too far to one side of the solar system's sector.

I'm not sure how clearly I'm explaining this... feel free to ask me to rephrase. ;)

37
Precursors / Re: Galaxy Generator.
« on: November 09, 2006, 03:57:37 pm »
Well, CS could very well break with that unless the object was at 0,0,0. Keep in mind, float is much more accurate near 0 than anywhere else; at 0, you may be able to accurately represent the number 0.00000001, but make that 1000.00000001 and all of a sudden it will drop the trailing digits.

I agree with Recon's proposed coordinate systems, except I don't think coordinate system number 2 is necessary... Moving things around in RA/Dec/Dist space is a bit more complicated than I'd like, and doesn't give us much advantage... we need rectangular coords for rendering (even to the skybox) so it'd be easier to convert to the galactic scale (number 2) and manipulate the numbers there. I'd personally rather change all of the stars' coordinates in the data files to be rectangular coords, centered around the galactic core, so that we have a relatively even distribution across the coordinate system, and use the int-based fixed-point data type discussed earlier to work with that in code. We can use fixed-point math to calculate the size of the impostor that needs to be rendered and to calculate its coordinates on the skybox, and then convert those numbers to float for the actual rendering. Shouldn't be too difficult, and lets us keep track of coordinates on a galactic scale relatively easily.

A system like this will give us a very nice way of splitting things up across different servers. (each node server handles one solar system)

38
Precursors / Re: Galaxy Generator.
« on: November 07, 2006, 04:39:21 pm »
Well, let's just choose the radius of an arbitrary, yet well-known star... maybe Betelgeuse, Antares, or Aldebaran... maybe Morgul can come up with a good star for this, seeing as he's familiar with all the different races and where they are located in the galaxy.

39
Precursors / Re: Galaxy Generator.
« on: November 07, 2006, 01:38:47 pm »
Well, got a good bit of stage 2 done, I got Stargen working and it's producing planet data, here is a example of some output ( note this is a subset of the info generated )
First off, great work so far! It's starting to really look like a solar system! :)

Quote
Now, I have been trying to not do any development on rendering these planets and the brings us the the whole GLP/LGPL issue. I went ahead and used stargen as it saves me a lot of time doing work that has already been done in the GPL community.

The question now is, is precursors interested in using any of this? as precursors is LGPL including the code is out, but it should be possible to use the data generated. I am going to look into getting it to create world files. The idea being that it can generate world files that can be used in precursors ( this is why I am trying not to do any work on rendering as the code would not be useful later.). The world files should be quite small, as they should only contain text. then if we code a loader/Render in CEL it would seem like a nice solution. I would appreciate some feedback on this.
I'm not yet sure which method I'd prefer... whatever happens, we can't include GPL code in Precursors, but aside from that, we're free to do pretty much whatever works best. I'm still not entirely sure which one to suggest, although generating world files and storing them does seem to be the preferable method, since then we can edit the resulting world files to add buildings and other such features. One thing we really need to think about, though, is how we're going to handle LOD and landing on planets. I know there's been some other discussion on this, but the dev team needs to make a final decision as to how we're going to implement things so that we know what data we'll need.

Quote
On a side note, I have already run into scale problems ( lighting appears to stop working at 100,000 units from the origin, 3 of my planets are past this even in my seriously squashed up model . This is still a hard technical problem we need to over come. and the discussion of it has seemed to miss the point, the problem is not storing large numbers, it is rendering objects that are far apart in crystal-space.
Actually, large numbers are the problem, since that's what CS has a problem with. :P The trick as far as solar systems go is simply to use a different coordinate system. We don't need to use 1 unit = 1 meter or even 1 unit = 1 km; we can use 1 unit = 1 au if we want. Try to find units that work well for the solar systems. We can worry later about how we're going to fit ships into it. (right now, my guess is that we'll end up having to use render-to-texture for the solar system and plaster that on a skybox or something... we'll see)

40
RaptorNL / Re: Defining Reliable / Unreliable and Ordered / Unordered
« on: November 02, 2006, 07:42:36 pm »
Here is my current understanding of Reliable vs. Unreliable and Ordered vs Unordered. I'm hoping whitelynx can correct any misunderstandings I have on the subject.

Reliable vs. Unreliable: This refers to whether the packet must arrive at the destination. If a packet marked as "reliable" fails to arrive at the destination, then we must request that the packet be resent.
Almost... It just means that we have to try to provide a guarantee that it will get there. (with reasonable limits) There are two ways of doing this: requesting resends of missing packets, (perfect for ordered reliable packets because you know that one's missing when a sequence number is skipped) or resending any packet after a given timeout, unless an ACK for that packet has been received. (which could be useful for unordered reliable sending, but which may need to be discussed first.)

Quote
Ordered vs. Unordered: This refers to whether the packets must arrive (or at least be interpreted) in a specific order.
Exactly.

Quote
TCP is an ordered, reliable protocol, to the point that it will outright block (i.e., stop receiving data and just keep sending resend requests) if it misses something. RUDP is ordered reliable as well (I think), but it won't block if it misses a packet. Rather, it collects the numbers that it didn't receive in the past N time units and send a resend request all at once (in the EAK segment).
Actually, from my understanding, they both work the way that you described RUDP. TCP will queue up out-of-order packets until the previous packets arrive, and then pass them all to the application once they do. The biggest difference between TCP and RUDP is that RUDP cuts out a lot of the unused "features" of TCP.

Quote
So assuming the above info is right (I honestly expect it to be wrong, personally, but whatever), how would an ordered, unreliable or unordered, reliable packet behave? Can we have such a thing as an unordered, reliable packet, since we have to know which packets actually made it to the destination?
Yes, we can, using the second technique for making reliable packets that I described above. We could also rely on sequence numbers, but simply pass all packets up to the application when they come in instead of waiting for older packets when an out-of-order one arrives. I'm not sure which approach would be best for us.

Quote
Okay, so for unordered, unreliable, we'd use straight UDP, and for ordered reliable, we'd use TCP?
Actually, no, on both counts. We wouldn't use straight UDP because we need some sort of header in there so we can figure out what type of packet it's supposed to be. (since we can have multiple packet types on each socket... take a look at the channel/socket thoughts in the IRC log on that page) For the same reason, we can't use TCP at all for this; we'd have to create a new Socket to be able to do that. Instead, I'd like all 4 of these sub-protocols to be usable on the same socket at the same time, by opening a channel for each.

Pages: 1 [2] 3 4 ... 9