Jump to content

k776

WFG Retired
 View Profile  See their activity

  • Posts

    721

  • Joined

  • Last visited

  • Days Won

    6

 Content Type 

Posts posted by k776

  1. Shader-Based Rendering

    in Game Development & Technical Discussion

    Posted

    Here's my info. Hope I did it right.

    I manually set the shader in local.cfg before starting the game, to get as accurate info as possible:

    Shader: 15 FPS, 62-65 msec/frame, 170-200 msec/turn (fairly stable)

    VertexShader: 11 FPS, 85-87 msec/frame, 171-250 msec/turn (constant jumping between high and low)

    Fixed: 13 FPS, 76-78 msec/frame, 155-230 msec/turn (constant jumping between high and low)

    So shader has a better FPS and msec/frame, but it is beaten by fixed when it comes to msec/turn.

  2. How Did You Come Up With Your Username?

    in Introductions & Off-Topic Discussion

    Posted

    Mine started off as kieran776, and that's still used for my emails.

    But I shortend it for two reasons:

    1) back then (I was 13 y/o), I didn't want people knowing my real name right away

    2) no one could remember how to spell my name :-P

    k776 was a lot easier for people to remember.

    So I use k776 all the time now, with the exceptions of my email (which I kept longer to prevent spam) and forums/games that require a username longer than 4 characters

  3. Compile Errors

    in Help & Feedback

    Posted

    Additionally, if you've done an 'svn update', you must also rerun ./update-workspaces in build/workspaces, and recompile the game.

    Simply doing an svn update and this trying to play the game without recompiling will not work.

  4. What Does Everyone Think Of Switching To Git/github?

    in Game Development & Technical Discussion

    Posted

    Far more active projects have made the switch from SVN to Git, like Ruby on Rails (https://github.com/rails/rails) and JQuery (https://github.com/jquery/jquery), and they coped with the work required to get people up to speed. So compared to them, the effort for us to switch to Git is minimal. We only have about 5-6 people committing at the moment.

    there is still the risk of alienating users (Git being quite a different model)

    Not if we amend the documentation. The only change for someone who just pulls the code to play would be changing from a 'svn update' command to an 'git pull'.

    this particular situation and others foreseeable in the near future don't require DVCS

    But wouldn't it be best to do that now, when the need isn't great and the amount to people who need to swtich are few, than wait till we have 2x/3x devs (maybe) and make it nearly impossible to switch? At least by doing it now, those who haven't used Git will have time to get used to it, and those new to the project won't have to worry that we ever used SVN. And I'm always available to help on the IRC if someone is lost.

    Would the significant effort of completely switching over

    Significant? The mirror exists, I can commit to it right now if I needed to. All someone has to do is clone it, and they can commit too! At most, you spend 45 minutes downloading the source again, but then you're good to go. It's not significant effort at all.

  5. What Does Everyone Think Of Switching To Git/github?

    in Game Development & Technical Discussion

    Posted

    I've been hosting a mirror of the 0 A.D. source code for some time now on the popular Git hosting website, Github. See https://github.com/0ad/0ad

    With Philips recent graphics proposal, it got me thinking that it might be a good time to migrate to using Git as our code management system.

    Philips changes are going to affect every player (for the better or for the worse), and I'm a strong believer that the main branch of a project (trunk/master) should always remain stable, and working, in case a user grabs a copy of that code to try. We don't want them to have a first time bad experience because of some in progress code.

    As Philips changes are implemented, it could be some time before all kinks in the new system are worked out. Even if Philip completes the work locally first, he won't know if it works for others until he commits it, at which point, it could then break for users when it should be working.

    So I proposed using a branch to keep the changes in until they were stable and tested. However, SVN is notorious for having poor branch/merge support. We need something better if we're going to do that. This is where Git comes in.

    The biggest issues I've heard on the switch to Git are these:

    * Windows users cant use it - This used to be a problem. When git first gained popularity, you needed a command line on windows to use it. However, there are a few decent tools now that work on Windows (including a TortoiseSVN clone called TortoiseGit - http://code.google.com/p/tortoisegit/). So you don't need to worry about alienating users.

    * Git downloads the whole history - Yes, but that can be a good thing. Taking a look at old commits or the commit log is much much quicker than it is with SVN. And at the end of the day, you only end up downloading about 20% more IIRC (last time I checked). It's not several GB to download, only about 500mb. IT also downloads quicker. From our current SVN, it takes 6 hours to do a full checkout. With git, 45 minutes. Not too shabby!

    * Autobuilds can't commit to the repo - This is true, and while it could be fixed, Git's 'download all history' nature would mean each autobuild would be committed and downloaded each time. Not ideal. Instead, we can easily create the binaries and upload them to Github's download page. Users simply download the latest binaries and put them in the right directory. Not difficult at all.

    * There is a learning curve - Sure, there always is with new stuff, but it's not by much. And I'm very familiar with Git, so I'd be here and on IRC to help with any queries.

    What we gain by switching to Git/Github:

    * Excellent branching and merging support which will be very handy for multiple devs to support multiple branches of work, and easily pull in changes made by other devs. No more time consuming patches or single person development! Multiple people could work together on the same thing!

    * Ultra efficient history packing (20% more, you get all 8 years of 0 A.D. commits). Getting new commits after that is super small/fast too.

    * Github.com is an excellent Git hosting solution. The socialness of it makes contributions extremely easy to do. An interested person simply 'forks' (github uses the term for duplicating the codebase to your own account) the code, makes the change, commits and pushes it (unlike SVN, a commit doesn't go online until you push the code) and sends us a 'pull request', a Github feature which has file change view (per file), code change view (per line) and comments (for discussion, really good for feedback on things that need improving). Overall, it'll make the contribution process for interested devs more streamlines (no more trac or tickets to have to manage, just make the code).

    What does everyone think? Is there any solid reason why can't at least try use Git, maybe for a week? If it doesn't work out, it should be fairly simple to make a patch of all the changes in Git and apply them to the SVN if we decide to go back to that.

  12. Graphics Features

    in Game Development & Technical Discussion

    Posted

    To me, the most important thing would be getting to a point where doing these things is easier.

    From what I've read, we have like 3 different renderes for shadows, 3 for water, and more.... ideally there would be just one well written one, which scales on older hardware by downscaling the quality of things.

    So getting something brand new to build upon would be great! I'd be happy if performance just stayed the same for the moment, though utilizing new features in graphics cards should make things faster?

    Then, from there I think the important ones are (in order):

    * Hiding changes in FOW, but using a "last known" state to display, which is updated when they next go there (#599)

    * Showing units hiding behind buildings (#144)

    * Gradual FOW peel back (#732)

    * Particle system in place, so that we can have:

    * Ground effects (flowing grass as units walk through, fires, flowing water, water falls)

    * Sky effects (clouds, rains, lightning, wind)

  16. Hey!

    in Introductions & Off-Topic Discussion

    Posted

    Hey,

    Thanks for your interest in the game.

    The best thing to do is just jump in and start coding. There is some info here: http://trac.wildfiregames.com/wiki/GettingStartedProgrammers (may be outdated)

    Just checkout the 0 A.D. source code, and then choose a ticket that isn't already being worked on, and go for it. Once you're done, submit a patch, and one of the devs will review it.

    Depending on the quantity and quality of your contributed work code, you may, in time, be asked to join our development team.

    If you have any questions, there is a Development and Technical discussion forum, where one of our devs would be glad to point you in the right direction if you get stuck.

    Regards

    Kieran

  17. AI

    in Game Development & Technical Discussion

    Posted

    The implementation is already fundamentally event-based (since that's necessary for performance). The data that the engine sends to the AI scripts every turn looks like:

    That information certainly looks like it'd work, so there won't be a need for a callbacks system inside the C++ code, but it's still a low level interface for JS API.So now it needs JS to parse that info and send out events as needed.

    I expect you don't want to send your whole army rushing after a single enemy archer who pinged one of your outpost towers - you probably want to do some kind of threat calculation based on the rate of damage and the concentration of enemy forces, so you're forced back to looping over lists of entities

    You just pass the relevant information through the events system. For example, if you want to test a unit was killed really quickly, for the above information you posted (+some more info would be needed), and with a decent event system, this'd work:

    on('unit.attacked', function(info) {
      if (info.unit.health_last_turn == info.unit.max_health && info.unit.health == 0) {
        // unit was killed so quickly! serious threat?
        Chat.post("Grr!", info.attacker);
      }
    });

    It's still a pretty basic example, but basically, they should be able to have access to inspect anything related to the event (so a unit who is attack send who attacked them, where they got attacked, their old health, their new health as shown in the code example above).

  19. AI

    in Game Development & Technical Discussion

    Posted

    So, are there any progress on the AI event system idea?
    Hopefully soon. The AI is on hold at the moment. There are a few other things that need finishing off before the AI system is worked on again.
    IS good way to change difficult of AI.
    There is no difficulty setting in game. But AI will be made that are harder. They won't be in the next release though.

  20. Mac Osx Install Of 0Ad

    in General Discussion

    Posted

    WOOO! It works on Mac again. Hopefully with these instructions, it'll make compiling for Mac users a lot easier :-) http://trac.wildfiregames.com/wiki/MacBuildInstructions

    Edit 1: Aww, so close. I can load the game and submit my user details, but when I go to play a map, I get this: http://pastie.org/1599061

    Here is the profile I got from the Mac. http://feedback.wildfiregames.com/report/user/2af9e2ea0a3e9dd5ffee421a14999d79e76e7f3e

    Any ideas?

    Edit 2: Talked with Philip on IRC and it turns out the error came from toggling from full screen to windows mode. A new ticket was made to handle it later on.

  22. Suggestions for 0 A.D.

    in General Discussion

    Posted

    Hey, thanks for your comments.

    - faster building: What do you mean by this? Do you mean the speed of which things are built? If so, the values are subject to tweaking before the final release. I would not worry about these for now.

    - new nations: There will eventually be 6 nations. The next nation will likely make it into the Alpha 5 release.

    - campaign: yup, it'd be nice. Likely to happen further down the track though. We need a decent AI first, and then the actual campaign system.

    - easy modification of settings: Also would be good. But we need to get to a point where the settings are set in stone, else we'd just be changing them too often

  24. Mac Osx Install Of 0Ad

    in General Discussion

    Posted

    I just tried to compile the game myself, got as far as opening up the game executable, and the same thing happened. The game had no GUI, it just printed some LC_* messages and did nothing.

    Compiling threw no errors, only heaps of warnings from spidermonkey. I also remove atlas from the update workspaces script to it could compile. Not sure what's going on here.

    Here is the backtrace from GDB: http://pastie.org/1597119 . It seems to hang in timer.cpp:152 (the 'fin' command never eturns to another gdb prompt).

    A quick search shows this file was changes since Alpha 3. http://trac.wildfiregames.com/changeset/8515 and http://trac.wildfiregames.com/changeset/8516 .

    All changes since revision 8000: http://trac.wildfiregames.com/changeset?old_path=ps%2Ftrunk%2Fsource%2Flib%2Ftimer.cpp&old=8000&new_path=ps%2Ftrunk%2Fsource%2Flib%2Ftimer.cpp&new=8973

    However, if I revert those changes, update workspaces, and recompile, it still doesn't work, so there looks to be multiple regressions :-(

    P.S.  I've written up a guide with some very simple and quick instructions for Mac users. http://trac.wildfiregames.com/wiki/MacBuildInstructions

×
×
  • Create New...