Leaderboard

This thread is for discussions and updates about the SpiderMonkey upgrade to ESR31 I've decided to create a new thread because getting the upgrade to ESR24 into SVN was an important milestone and the previous thread was already quite long. Ticket: 2462 Check it out from my github branch (read the readme!). Short summary what happened so far The upgrade from the old SpiderMonkey version v1.8.5 (released in March 2011) was quite a big task due to the API changes. The conceptual changes (like having a 1to1 releation between global objects and compartments) were the biggest problem. Another problem were inconsistencies and duplication in our own code. The smaller problem were simple API changes. These issues are sorted out now and we can continue with the upgrade to ESR31. Performance We expected a lot from the upgrade to ESR24 because most of the significant SpiderMonkey changes from v1.8.5 to v24 were solely to improve performance. There's a new baseline compiler, a new JIT compiler with enhanced optimization capabilities called Ion Monkey, improved type inference and a lot more. There was a whole team of programmers working on performance improvements over years. The commonly used benchmarks show a big improvement but unfortunately we figured out that this does not improve performance for us and the performance got a little worse with the upgrade. It's not a big secret that these benchmarks get "special care" from the developers of Javascript engines such as SpiderMonkey or V8. Browser market shares are the main factor deciding how much money these companies get from e.g. search providers for adding their search as default entry in the browser. Benchmark performance improvements seem to be important for marketing, which is where the term "benchmarketing" comes from. The benachmarks were originally desigend to be a good representation of real world application performance but now one could say they are not related to real world performance anymore because of all the tuning and benchmark specific optimizations. Still, I trust Mozilla that the fundamental engine changes will also improve performance for embedders like us at some point (and probably they already do). What they did first after integrating big changes like Ion Monkey or Baseline was making sure they don't decrease benchmark performance. Now that this goal is completed they can start fixing performance issues which don't show up in these benchmarks but are important for other applications. H4writer fixed some of these problems we reported during the upgrade to v24 and apparently they continued fixing others in the meantime. ESR31 schedule ESR31 is still in development. We have time until the end of the month to get changes in, so I'm starting early with the work on the upgrade (well, as early as I could). That should also help detecting performance regressions and ease the integration of API changes. The final version should be released in July and I'm aiming for Alpha 17. Exact rooting, moving GC and GGC While upgrading to v31 I'm also working on the transition to exact stack rooting and the support of a moving garbage collection (GC). V31 will probably be the last version supporting conservative stack scanning (the opposite of exact rooting). This change should bring some performance improvements, in theory, but we'll see what happens in practice. This transition will allow us to use features such as generational garbage collection (GGC) and compacting garbage collection in the future. The progress is tracked in #2415. Performance: current status V31 really brings some improvements compared to V24. Unfortunately I can't compare it to v1.8.5 easily anymore. I've used a non-visual replay with 4 aegis bots on the map Oasis 04 over around 15000 turns and measured how long the whole replay takes. This shows the difference more clearly than the graphs I've used before. I've found a bug with incremental GC causing problems with off-thread compilation of JIT code. I've reported the incremental GC problem on the JSAPI channel and they created bug 991820 for it. I've also confirmed once more that disabling garbage collection of JIT code makes a difference. Unfortunately there are currently only functions meant for testing purpose which allow us to do this and I'll ask for a proper solution soon. Here's the comparision with different variations concerning the problems mentioned above:

Okay, I started fixing some stuff. The first problem I encountered was that the Egyptians do not have a blacksmith, while the game expects it to have. Edit: as a temporary (unless there won't be blacksmiths ever) workaround I'll remove the Egyptian Blacksmith from the buildable building

The zebu model for the Ox cart is now rigged. Animators feel free to animate I also added vertex groups. Don't know if that will help. EDIT : This one is the right one : Zebu Rigged.7z

Sure.

Being able to create drop sites would be nice but I'm not sure it would have a game play influence. Maybe for mini factions.

Nice

Note that for lots of art stuff, the source files are not available publicly yet (or even completely lost). That means you won't find blender or photoshop files, but png and dae files. This is being fixed by adding a new art_source repo (http://trac.wildfiregames.com/browser/art_source). But it will take time to fill the repo. We currently also have an art repo that can't be made public because it also contains copyrighted reference material (which may not legally be spread publicly).

First of all, allow me to say that you are a talented 2D artist, sir. Your civ emblems show a high level of skill. I would love for my design doc output to be greater, but I am currently involved with academics for most of this month; by May, however, I should be freed up a great deal to concentrate more fully on Aristeia. As I stated in the Hittite topic, my plan is to (1) more or less finish the Assyrian civ doc, (2) revisit the Israelite civ doc and make some changes, (3) work on the Egyptians and Nubians, and (4) bring the basic civ docs for the Phoenicians and Sea Peoples up to speed. An idea to throw out there: would it not be better to have two separate documents for each civ? One for the written document itself, and another for the artist's illustration references? The two documents could cross-reference one another. What I've been doing so far is combining the two, which I think makes for a rather cumbersome, unwieldy, messy file. Just an offhand question: Is anyone besides myself currently involved with or interested in working on Aristeia design docs? Not that I necessarily wish to have a reduced role in the project, but a civ researcher/designer is one of the first links in the chain, and, as Romulus said, it would be good to get enough people working on each aspect of development that at any given time, at least one person would be perhaps semi-available to work on a task. It would be nice if I knew of any volunteers to establish contact with so that we could coordinate our efforts, and delegate design doc responsibilities. For the record, my main specialty is biblical Near Eastern civs (basically Israel and its neighbors): Israel, Israelite successor states (Ephraim and Judah), New Kingdom Egypt, Kush (aka Nubia), Sea Peoples (incl. Philistines), Phoenicians, Aramaic Syrian states, Assyrians, Babylonians, and perhaps Hittites. As far as European (such as Etruscan), Indian, and Proto-Greek civs I am more than willing to encourage anyone more familiar with them than I am to lend a hand. About the Egyptians: I had already begun work on my own Egyptian doc, which I posted in the New Kingdom Egypt topic. Lion.Kanzen, the Google Docs link to the Egyptian civ is basically the one created by Tyrannosaurus, who was last active on the forums over a year ago. I personally think that his design doc needs an overhaul. I can incorporate many of his concepts and ideas, but his timespan is a bit broad, and the unit names need revising, among other issues. Another point: Atenmeses52, one of the Aristeia co-founders, laid out a tentative list of proposed civs last December; I would like to revise the list, if I may; I have my own thoughts on the merits of including each civ. It would probably be a good idea to first get a more solid grasp on the civs Aristeia is actually going to include, and then proceed on to designing these civs, and then put 2D and 3D artists to work tranforming these concepts into a playable virtual reality.

Motivation maybe. Always remember to do what you like

Indeed looks better. Thanks for the support lion

No, it was about the local origin (of the mesh) that had to be set in the middle of the grip. Anyway, I somehow made it.

Hey. I realised that there is no real use of improving that blade texture, because for now texture is 1024x1024 ands it's gonna be something around 128x128 so losing five hours to fix it might not be the best idea.Anyway since I need to stop giving up I made some modification and added the variation. Viking.7z

Files in mods overwrite files in the public mod. So it won't change if the public file changes. But JS is very modular. The OO paradigm it uses is based on prototypes, which means you can extend the prototypes in other files too. F.e. if you want to have a separate attack function, you can just have a file with Attack.prototype.newFunction = function(a) { /* body */};You can use the above thing also to just redefine an existing function when needed. In this case, you don't have to copy the entire file from the public mod, and you'll automatically inherit changes from there, as it won't overwrite existing files, but only extend existing prototypes. When a change happens to a function you've redefined, you will have to update that manually. But there's nothing we can do against that. The only thing you have to watch out for is that your file is loaded after the file in public (else it would try to extend a prototype that doesn't exist yet, and crash badly). The files are loaded alphabetically. So you could either append something to it, like call the file "AttackMyMod.js" (the 'M' is sorted after the '.'), or use lowercase letters (lowercase is sorted after uppercase IIRC).

Pyrrhus of Epirus: He was a well respected ancient general, perhaps the greatest in history. Known for making the term Pyrrhic victory, he presented one of the greatest challenges to Roman hegemony in Italy as of yet.

Haha, the testudo looks a bit silly with the extraordinarius. Footage with silly animation and testudo fight (behavior is set at standground). The testudo gets beaten by a massive army of skirmishers. I think you should disable the victory animation while in testudo. And discovered a massive amount of bugs on the fly. (uploading right now) Edit: movie attached!

Sexy....

Have you seen the internet lately? Or have you checked out NPR? http://gawker.com/npr-pulled-a-brilliant-april-fools-prank-on-people-who-1557745710

Well uh, hello there. The story of my discovery is nowhere as captivating as this community. In short, I was browsing google for better screenshots of some old strategy game, guess one of the key words triggered an 0a.d. hellenistic units screenshot to pop up, so here I am, really. Guessing, this is the part I put some captivating introduction, but ehh, I haven't really got a thing on my mind right now. Well, wait, aside that I wish I wasn't a totally clueless geek when it came to programming, everything seems to neat around here. ;o

Wanted to share Millennium A.D.'s current theme song.

I just made some concepts. To the left there are 2 different sets for houses, a farmstead and a scout tower, and to the right different models for a civic centre.