Jump to content

Matei

WFG Retired
  • Content Count

    1.753
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Matei

  • Rank
    Primus Pilus

Previous Fields

  • First Name
    Matei
  • Last Name
    Zaharia

Contact Methods

  • Website URL
    http://www.matei.ca
  • ICQ
    421040084

Profile Information

  • Gender
    Male
  • Location
    Canada
  • Badges
    Donator Indiegogo

Recent Profile Visitors

575 profile views
  1. BTW, I'm also curious to see if other ways of doing map generation would work better. I went with the TileClass design (where a TileClass is just an arbitrary set of tiles) because it was simple and fairly fast (RangeOp is pretty cheap in both memory and access time). My guess is that a quadtree would perform similarly, but maybe this changes when you implement it in JS.
  2. Sorry for the late reply, it took me a bit of time to page this back in. RangeOp is actually a data structure that is meant to store an array of counts in an efficient manner. In particular, suppose you had the following problem: * You have an array A of integers of size N. * You need to quickly query it for sums of the values on ranges of the form i..j (so you want A + ... + A[j]). * You want to be able to add or subtract from the values at any spot in the array. RangeOp lets you do this in O(log N) time for each operation. In particular, RangeOp maintains a number of smaller arrays: the big
  3. I should add: the best way to contact me is to email me at matei@eecs.berkeley.edu, but you can remind me to post here as well.
  4. Hi Bruno, Jason forwarded me this link. I wrote the old rmgen (in source/tools/rmgen), so I'd be glad to answer any questions you have about it. I like the idea of integrating it with the main game engine. Right now there are some parts that are C++, but the system is intended to let you write scripts in JS. The parts that are in C++ are mostly that way for performance (e.g. Perlin noise is fairly computationally intensive). However, performance might be good enough with pure JS code, in which case it would certainly be nice to move everything to JS.
  5. I think this is a great idea, Philip, sidestepping a lot of issues associated with building our own GUI that we'd have to address as we go on. (Even if we started with a very simple GUI, inevitably, people would want more from it, and would have to hack it in somehow.) Defining GUI pages using standards (HTML, CSS, etc) is also a big win for modding. The only question is whether Webkit embedding is really as easy as advertised. Seeing EVE use Webkit is very promising. I also know that a lot of apps on Mac OS use it (beyond the browser), and it claims to be designed for embedding.
  6. I had the same problem with Atlas on OS X before - it would load but then freeze. I assumed it was a problem in the wxWidgets configuration. Using gdb or dtrace on it might also help.
  7. I'm curious whether Atlas works on Mac when compiled with gcc 4.3. It used to have problems caused by wxwidgets. If you run pyrogenesis_dbg -editor, does it start up and can you interact with it? My guess is that the problem on the mac mini would be the lack of a GPU, but you can also try the gcc 4.3 version there to see if it works.
  8. Arn, what were some of the errors you got under gcc 4.0.1? I was able to build Collada according to the instructions on the wiki and then to go into build/workspaces and make pyrogenesis. There were some errors compiling AtlasUI (if I just type make), were those the ones you saw?
  9. I can confirm that I've managed to build the game on OS X with Collada based on the instructions on Trac. I just used Apple's GCC (4.0.1) and I didn't have to modify the OpenAL header.
  10. I definitely get speedups from make -j 3 on my dual core machine, so I think keeping the option for parallel build would be nice. If SCons really doesn't scale to the size of 0AD though, we can drop it. Many developers will have the option of working in Visual C++, which does parallel builds.
  11. That's hilarious! Good catch by you guys. Poor Ross .
  12. This is great, congratulations! Very well-written article too . I've always enjoyed reading your articles (and those of other historians) for 0 A.D., especially since I don't know too many details about the history of the time period, and it's very nice to get an article in print too. Good luck with other writing in the future!
  13. Achilles, I think I understand your point, but I think that your form of fandom really can't apply to our project. Your attitude is closer to that of a loyal consumer or a sports-fan - you make a commitment to an organization, but you want something back. What we mean by a "fan" is just a friend or supporter. Like it or not, our project really *is* volunteers working on something in their spare time, and if you think it's possible to have people to do that at the same rate and with the same level of commitment as a company, I think you've got yourself a very nice business plan . I don't know,
  14. Just another thing, please keep in mind which posters are members of the development team and which aren't. I don't think anyone on the team meant to be disrespectful. I'm sorry if we were that way. Here are my thoughts on your points: - If you wish to see daily progress, look at the Revision Log on the left side of http://www.wildfiregames.com/0ad/. This shows a summary of the changes we make to the game each day. (Highly technical changes aren't listed.) It's updated in real-time as we make them. It's not very detailed and doesn't explain much, but at least it gives an idea of the things we
×
×
  • Create New...