Last visit was: It is currently Thu Mar 28, 2024 3:30 am


All times are UTC-05:00




Post new topic Reply to topic  [12 posts ] 
    Author Message
     Post subject:Onlink v0.1.1 Progress Report
    PostPosted:Tue Jul 31, 2007 3:46 am 
    Literally Nine
    User avatar
     

    Joined:Sat Apr 02, 2005 3:31 pm
    Posts:1171
    Location:The vicinity of an area adjacent to a location.
    Some people have asked about when we're releasing v0.1.1. We're planning on a "soon as it's ready" release, but please don't take this to mean "never" or "long from now". We in fact believe we can safely make a release within the next couple weeks, but we're doing some testing and code additions first.

    Developers out there may be interested to know that Onlink v0.1.1 will use an open source CrissCross backend for various functions. We've used it internally for a long time, and we've decided it's time to use it in a practical program. CrissCross provides very nice stack traces too, and has memory leak detection (both Windows-only features for now). The CrissCross backend has taken some time to implement, but it'll be worth it. It actually contains the data structures (RedBlackTree, LList, DArray) we use, and we've had a couple years now to optimize them properly. We'll be continually developing it, and making the CrissCross component our open source contribution. We want people to be able to take advantage of the same capabilities we do.

    We would also be interested to hear if there are any developers in the Onlink community who believe they can contribute in some way. If so, please let us know, we may be interested in taking on an additional developer.

    And finally, we are really hoping for a site redesign sometime soon. If there are any web developers (especially skilled in PHP/XHTML/CSS and phpBB modding) out there, please give us a shout. This also includes graphics designers, of course. The main part of the look is not just the positioning of the images and the code underneath, but the images themselves.

    So to summarize, we need:
    1. C++ Developers
    2. Web Developers (CSS, PHP, XHTML, phpBB theming and modding)
    3. Graphics Designers
    If interested, apply within (email us or send us a private message on the forums).

    Thank you all for your support!

    _________________
    - Tycho

    Image


    Last edited by Tycho on Fri Aug 03, 2007 1:15 pm, edited 1 time in total.

    Top
    Offline  
     Post subject:
    PostPosted:Tue Jul 31, 2007 2:00 pm 
    Literally Nine
    User avatar
     

    Joined:Tue Mar 01, 2005 9:00 am
    Posts:1263
    It needs mention that we also need graphic artists to make new OSs for us.

    As it stands, we have one completed, two in dev, and two slated. It bears mentioning that the guideline for Onlink OS modding are very much different from Uplink graphical modding, with much fewer restrictions: you may resize, replace, and reformat the entire layout if you see fit.

    Also inquire within.


    Top
    Offline  
     Post subject:
    PostPosted:Wed Aug 01, 2007 3:20 pm 
    User avatar
     

    Joined:Fri May 25, 2007 7:49 pm
    Posts:200
    Location:Argentina
    Congratulations on the progress. :)


    Top
    Offline  
     Post subject:
    PostPosted:Thu Aug 02, 2007 12:24 pm 
    User avatar
     

    Joined:Sun Feb 12, 2006 8:56 pm
    Posts:1019
    Website:http://eddieringle.com
    Location:Detroit, MI
    Well now you got me excited. I was thinking of getting back to learning C++ so I can do something on my computer besides play games. :P If I ever get to the point where I think I could be of help, I'll give you a shout.

    Btw, what are the key parts of C++ I should be focusing on? Just to give me an idea of what I should work hardest on.

    _________________
    -- Eddie Ringle

    Check out Elysian Shadows and consider backing us on Kickstarter!

    ====================================

    Image


    Top
    Offline  
     Post subject:
    PostPosted:Thu Aug 02, 2007 1:01 pm 
    Literally Nine
    User avatar
     

    Joined:Sat Apr 02, 2005 3:31 pm
    Posts:1171
    Location:The vicinity of an area adjacent to a location.
    Quote:
    Btw, what are the key parts of C++ I should be focusing on? Just to give me an idea of what I should work hardest on.
    There's no real magic part to focus on, but I would suggest you focus heavily on a few areas.

    First, proper object-oriented design. If you have a class Pen and class Pencil, they should inherit class WritingImplement, since they both can Write(), but only a Pencil can Erase(), and so forth. Probably doesn't make a ton of sense right now, but once you start thinking in object-oriented design, you'll see it everywhere in the real world.

    Second, you really need to learn the pitfalls in C++. Many computer science majors will wrongly tell you how wonderful recursive functions are. Recursive functions solve problems with less effort from the programmer but with much more effort for the machine. It also is dangerous because you can get infinite recursion (or something close to it which has just as bad results) if you're not careful. There's a function in the Uplink code which is called TraceLog(). It's unfortunately recursive, and it wasn't able to recognize that it had entered an infinite recursion, so one of our forum users experienced a crash when the in-game computer's log said "Two computers. Computer A and computer B. Computer A has connected to itself." The connection to itself made it trace back to itself over and over and over, and eventually caused a crash.

    Third, optimization. I'm not listing these in order of importance, because I actually think optimization comes first, and the computer engineering side of programming is extremely important. Why? Computer science works in the theoretical plane. Stuff that you have to run for months on end on a supercomputer or not even solve for years. Engineering is about making things work with what you have to meet a set of constraints, and deals in milliseconds or microseconds. In game programming, you have a CPU, a GPU, memory that has a certain latency, a disk with a certain seek time, etc. You need to accomplish so much every 60th of a second given those hardware constraints or else the game will suck.

    Put another way, computer science is about exploring new ideas and not having to worry about the practical implementation, which is the engineering portion. Prime numbers for example. Computer scientists love to talk about ridiculously large prime numbers and all you can do with such things, like unbreakable encryption and such. Engineering is taking that abstract algorithm and making it work on, say, a 200MHz ARM processor running on your battery-powered MP3 player, where things like battery life and response time matter.

    What I?ve found is that computer science majors write really shitty code. Not code that doesn?t work, but code that?s slow. They don?t know how to optimize. They can?t tell you the difference between an AMD Athlon XP and an Intel Pentium 4. They can?t explain why the new Core 2 is such a good thing. In their little abstract world of trees and lists and Java, they don?t need to understand the low level hardware. Many of them can?t ever read an x86 disassembly or tell me the first thing about how many registers in a Pentium processor or what the registers are for.

    Parallelization is the big thing right now. The Xbox 360, for example, has a 6-way processor. How does one write video games when you can have 6 concurrent pieces of code running at the same time? How does that change your rendering engine? Your game logic? Memory allocation? The Playstation 3 has nine hardware threads. This totally changes the way one writes video games from now on.

    Computer Science has a long standing solution to concurrency - the concept of a lock. Which in Linux and Windows are synchronization objects known as locks, mutexes, semaphores, and other names. They?re used in every operating system and just about every shipping Windows and Linux application today. Even calling malloc() is a seralizing operation on the memory heap that causes a lock. Have multiple threads calling malloc() and they basically get to stand in line (a queue data structure) and execute serially. That?s not very parallel. So once again, computer science has given us something that doesn?t translate well into real-world performance.

    My point of this is that you should NOT go pure computer science when you program. You?ll rot your head with abstract ideas and end up writing very poor code. If you can?t visualize an algorithm or a piece of code and understand what that touches in the microprocessor, in the memory, on the disk, and what the costs and delays of all the steps are, you?re going to write shitty code.

    _________________
    - Tycho

    Image


    Top
    Offline  
     Post subject:
    PostPosted:Thu Aug 02, 2007 2:24 pm 
    Sagely Amphibian
    User avatar
     

    Joined:Sun Jun 18, 2006 3:06 pm
    Posts:69
    Offtopic:
    Quote:
    Btw, what are the key parts of C++ I should be focusing on? Just to give me an idea of what I should work hardest on.
    Quick ideas:

    - Learn to code in modular ways, it makes code easier to maintains, understand and reuse.
    - Learn C++ language constructs/_libraries_, they are harder to use at first then C language constructs/_libraries_ but the gain is there.
    EDIT:
    - Learn good memory management and error handling technique.
    - Learn Data Structures (advance one too), their benefits and drawbacks, when to use them.

    ----------------

    Tycho comments, for the fun of argumenting, no war is declared here ;)
    Quote:
    Second, you really need to learn the pitfalls in C++. Many computer science majors will wrongly tell you how wonderful recursive functions are. Recursive functions solve problems with less effort from the programmer but with much more effort for the machine. It also is dangerous because you can get infinite recursion (or something close to it which has just as bad results) if you're not careful. There's a function in the Uplink code which is called TraceLog(). It's unfortunately recursive, and it wasn't able to recognize that it had entered an infinite recursion, so one of our forum users experienced a crash when the in-game computer's log said "Two computers. Computer A and computer B. Computer A has connected to itself." The connection to itself made it trace back to itself over and over and over, and eventually caused a crash.
    The problem here is not the use of recursion, it's the algorithm. An infinite loop wouldn't have been better ;) (People need to verify that their algorithms meets their termination conditions)
    Quote:
    Third, optimization. I'm not listing these in order of importance, because I actually think optimization comes first, and the computer engineering side of programming is extremely important. Why? Computer science works in the theoretical plane. Stuff that you have to run for months on end on a supercomputer or not even solve for years. Engineering is about making things work with what you have to meet a set of constraints, and deals in milliseconds or microseconds. In game programming, you have a CPU, a GPU, memory that has a certain latency, a disk with a certain seek time, etc. You need to accomplish so much every 60th of a second given those hardware constraints or else the game will suck.
    Optimization is good, algorithm first (the gain can be in order of magnitude), code second. A lot of time optimizations makes things ugly/hard to maintain and introduce new bugs. Optimization should be made in critical sections where there is proof the optimization as tangible benefits.
    Quote:
    What I?ve found is that computer science majors write really shitty code. Not code that doesn?t work, but code that?s slow. They don?t know how to optimize. They can?t tell you the difference between an AMD Athlon XP and an Intel Pentium 4. They can?t explain why the new Core 2 is such a good thing. In their little abstract world of trees and lists and Java, they don?t need to understand the low level hardware. Many of them can?t ever read an x86 disassembly or tell me the first thing about how many registers in a Pentium processor or what the registers are for.
    I do agree that most computer science majors write shitty code and not only speed/resource wize, code is badly structured, error handling is very poor. Having an idea of the inner working of the hardware and low level libraries is indeed a good thing, it helps evaluate the cost of a given piece of code. But once again, I would say that knowing the cost of your algorithms is as important (if not more important), how many time I saw O(n2) algorithms where a O(n) algorithm could have been used. EDIT: Same goes for Data Structures, how many times I saw arrays/lists when hashtables/sets/trees would have been much better.
    Quote:
    Computer Science has a long standing solution to concurrency - the concept of a lock. Which in Linux and Windows are synchronization objects known as locks, mutexes, semaphores, and other names. They?re used in every operating system and just about every shipping Windows and Linux application today. Even calling malloc() is a seralizing operation on the memory heap that causes a lock. Have multiple threads calling malloc() and they basically get to stand in line (a queue data structure) and execute serially. That?s not very parallel. So once again, computer science has given us something that doesn?t translate well into real-world performance.
    I don't get why you blame the locks problems on Computer Science, if some piece of code relays heavily on locks I guess the code is badly written, the problem is not the locks but their utilization. On the malloc problem, malloc is a generalized memory manager, fit all but don't do anything very well, you could code your own memory manager (and some have done it) or utilize other methods to reduce the number of calls to malloc.

    EDIT: I would add that C is not designed with parallelisms in mind. Which doesn't mean that some programming languages don't fair better in that domain.
    Quote:
    My point of this is that you should NOT go pure computer science when you program. You?ll rot your head with abstract ideas and end up writing very poor code. If you can?t visualize an algorithm or a piece of code and understand what that touches in the microprocessor, in the memory, on the disk, and what the costs and delays of all the steps are, you?re going to write shitty code.
    Keeping an idea on how it works in the inside is good to keep the things down to earth, realistic. But I think one of the first thing to keep in mind is the structure of your program, easy to maintain, easy to read/modify, easy to spot/correct errors/bugs.


    Top
    Offline  
     Post subject:
    PostPosted:Thu Aug 02, 2007 5:31 pm 
    User avatar
     

    Joined:Sun Feb 12, 2006 8:56 pm
    Posts:1019
    Website:http://eddieringle.com
    Location:Detroit, MI
    Alright, thanks for all the info, first though I think I'll go over the basics again (haven't played with C++ for awhile)... But I do know lots about OOP (I learned a good deal of it while reading a Java book, of course, Java isn't C++, but they both share OOP).

    Oh yeah, the post above was my 100th! :D

    _________________
    -- Eddie Ringle

    Check out Elysian Shadows and consider backing us on Kickstarter!

    ====================================

    Image


    Top
    Offline  
     Post subject:
    PostPosted:Thu Aug 02, 2007 6:55 pm 
    Literally Nine
    User avatar
     

    Joined:Sat Apr 02, 2005 3:31 pm
    Posts:1171
    Location:The vicinity of an area adjacent to a location.
    Quote:
    The problem here is not the use of recursion, it's the algorithm. An infinite loop wouldn't have been better ;) (People need to verify that their algorithms meets their termination conditions)
    Sure, an infinite loop wouldn't have been much better, but consider the fact that the crash was caused by a call stack overflow. This is one of the reasons that the original Tosser BTree was so slow. Not just the fact that it was unbalanced, but it caused crashes if there were enough items to overflow the call stack.
    Quote:
    Optimization is good, algorithm first (the gain can be in order of magnitude), code second. A lot of time optimizations makes things ugly/hard to maintain and introduce new bugs. Optimization should be made in critical sections where there is proof the optimization as tangible benefits.
    I certainly agree. Finding the right algorithm is the biggest part of optimization. You can save a few milliseconds by using inline assembler, but that's tedious and excessive.
    Quote:
    I do agree that most computer science majors write shitty code and not only speed/resource wize, code is badly structured, error handling is very poor. Having an idea of the inner working of the hardware and low level libraries is indeed a good thing, it helps evaluate the cost of a given piece of code. But once again, I would say that knowing the cost of your algorithms is as important (if not more important), how many time I saw O(n2) algorithms where a O(n) algorithm could have been used. EDIT: Same goes for Data Structures, how many times I saw arrays/lists when hashtables/sets/trees would have been much better.
    I suppose what I suggested sounds like I'm hoping that people learn to program in assembly. I mean to insinuate that if you don't know how the hardware reacts to code, you won't be able to write fast code for it.
    Quote:
    I don't get why you blame the locks problems on Computer Science, if some piece of code relays heavily on locks I guess the code is badly written, the problem is not the locks but their utilization. On the malloc problem, malloc is a generalized memory manager, fit all but don't do anything very well, you could code your own memory manager (and some have done it) or utilize other methods to reduce the number of calls to malloc.
    I blame computer science for locks because instead of finding a way to make their code parallel, they avoid the problem altogether and serialize the threading.
    Quote:
    EDIT: I would add that C is not designed with parallelisms in mind. Which doesn't mean that some programming languages don't fair better in that domain.
    I suppose this is true, because C was made before parallelism was designed. But things like OpenMP greatly help the move towards parallel code. It's at least something to research and be working on understanding before writing purely serialized code. Know when it's safe to parallelize, and when it's not, etc.
    Quote:
    Keeping an idea on how it works in the inside is good to keep the things down to earth, realistic. But I think one of the first thing to keep in mind is the structure of your program, easy to maintain, easy to read/modify, easy to spot/correct errors/bugs.
    Structure of the program was one of my points too, but I erased it in favour of points I thought more critical. Still, I agree with this, certainly. Finding a proper coding style and structure is a major point.

    _________________
    - Tycho

    Image


    Top
    Offline  
     Post subject:
    PostPosted:Fri Aug 03, 2007 10:59 am 
    User avatar
     

    Joined:Sun Feb 12, 2006 8:56 pm
    Posts:1019
    Website:http://eddieringle.com
    Location:Detroit, MI
    Can you give a real life example of what I'd be doing?

    _________________
    -- Eddie Ringle

    Check out Elysian Shadows and consider backing us on Kickstarter!

    ====================================

    Image


    Top
    Offline  
     Post subject:Re: Onlink v0.1.1 Progress Report
    PostPosted:Mon Jan 10, 2011 10:19 pm 
    User avatar
     

    Joined:Sat Jun 06, 2009 1:21 am
    Posts:581
    WHEN DID WE LET THIS HAPPEN???

    _________________
    I'll see you on the dark side of the (ferrous) moon.


    Last edited by sentinel on Sun Jan 16, 2011 7:55 pm, edited 1 time in total.

    Top
    Offline  
     Post subject:Re: Onlink v0.1.1 Progress Report
    PostPosted:Mon Jan 10, 2011 10:54 pm 
    User avatar
     

    Joined:Sat Jun 03, 2006 3:51 am
    Posts:1186
    Website:http://griffinhart.livejournal.com/
    Yahoo Messenger:Squall591
    AOL:FinalWarrior591
    Location:Look at my horse, my horse is amazing!
    sentinel:

    Posting replies to spam does not help. Next time, report the post so that I, or one of the administrators, gets an email about it so we can clean it up.

    Also, to reply to your question about "where are the mods": I and mc2m are the only moderators on these boards; I don't know about mc2m, but as much as I lurk the boards, I do not have them on a constant watch (i.e., I do not get notified every time a post is made); hence the necessity that spam posts are reported.

    -- Griffinhart

    _________________
    "My word is my honor. My honor is my life."
    -- Demonchild, Angelkin, the Blackest Seraph, the Final Warrior

    Image


    Top
    Offline  
     Post subject:Re: Onlink v0.1.1 Progress Report
    PostPosted:Sun Jan 16, 2011 7:56 pm 
    User avatar
     

    Joined:Sat Jun 06, 2009 1:21 am
    Posts:581
    Got it, chief! Sorry about that! :classy:

    _________________
    I'll see you on the dark side of the (ferrous) moon.


    Top
    Offline  
    Display posts from previous: Sort by 
    Post new topic Reply to topic

      All times are UTC-05:00


      Who is online

      Users browsing this forum: No registered users and 17 guests


      You cannot post new topics in this forum
      You cannot reply to topics in this forum
      You cannot edit your posts in this forum
      You cannot delete your posts in this forum
      You cannot post attachments in this forum

      Search for:
      Jump to:  
      cron
      Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
      Theme created by Miah with assistance from hyprnova