Jump to content

Alpha 14 Preview


Mythos_Ruler
 Share

Recommended Posts

It's been a long Summer. Old team members go inactive, new team members fill the void. Ups and Downs. Lots of work and preparation. Alpha 14 is nearly upon us and with it will come a huge announcement regarding Wildfire Games' future.

But in the meantime, how about we preview the next release for you?

The art department is busy making the game's buildings look the best they can be. But that's not all that is happening. We'll preview more in the days ahead, but for now check out some of the building updates in store for Alpha 14:

JzKKqZH.jpg

In this in-game screenshot you see:

Environment

  • Distance Fog (editable in Atlas).
  • A small amount of Bloom (editable in Atlas).
  • Some HDR contrast (editable in Atlas).
  • Some Saturation (editable in Atlas).

The Building Model

  • Diffuse Maps
  • Ambient Occlusion Maps
  • Normal Maps
  • Parallax Maps
  • Specular Maps

Link to comment
Share on other sites

TO ENABLE "WHIZBANG GRAPHICS"

*WARNING: REQUIRES A NEWISH (NO MORE THAN 3 or 4 YEARS OLD) DEDICATED GRAPHICS CARD, AND SOME BASIC UNDERSTANDING OF CONFIG SETTINGS*

Navigate to this folder in your 0 A.D. directory:

\binaries\data\config

Next, create a text file in Notepad or Notepad++ or your favorite text editor. Save it to the above address with the name local.cfg.*

*not local.cfg.txt.

With this file you can add configuration options without overwriting the game's default settings.

Next, add these lines in the local.cfg file:


; System settings:

waternormals = true
waterbinormals = true
waterrealdepth = true
waterfoam = true
watercoastalwaves = true
waterrefraction = true
waterreflection = true
watershadows = true
showsky = false
postproc = true

; Replace alpha-blending with alpha-testing, for performance experiments
forcealphatest = false

; Quality level of shader effects (set to 10 to display effects)
materialmgr.quality = 10

; Prefer GLSL shaders over ARB shaders (not recommended). REQUIRES gentangents=true.
preferglsl = true

; Experimental probably-non-working GPU skinning support; requires preferglsl; use at own risk
gpuskinning = true

; Generate tangents for normal and parallax mapping. REQUIRES preferglsl=true. Incompatible with gpuskinning.
gentangents = true

; Use smooth LOS interpolation; REQUIRES preferglsl=true.
smoothlos = true

These are my local settings. They override the game's default settings, but don't overwrite them. I also have:


; Local Configuration Settings

xres = 1600
yres = 900

But it is not necessary. I only have that bit to switch quickly switch to 720p for creating videos.

If you follow these instructions, then all of the WBG features should be enabled and looking good. If you get errors, then you can adjust the settings in the local.cfg file or just delete the file and no harm will come to the game or your computer.

If you don't want to mess with any of this, then you'll just have to wait for Alpha 15 or Alpha 16. :)

And to clarify: The game has been able to do all of the above for quite some time now, but we haven't gotten around to making a settings menu yet. It's in the planning stages though.

Link to comment
Share on other sites

Is there any automated build to test this alpha 14 ? without grabbing all the SVN, getting all the tools, etc...

There is an automated build ... in SVN: http://trac.wildfire...binaries/system But the executables aren't enough. To have the newest version of the game, you also need the data, which is only in SVN (it's the biggest part of the repo anyway), and the game won't run without it.

Is there a Jenkins server or something like this for 0.a.d ? if not, and if it's planned, i can give you some help, if wanted... :)

Philip is moving the repo to git, and that change would go together with having a better autobuild tool, probably jenkins. But as it's a bit of a boring task for a programmer, it takes a while ;)

Link to comment
Share on other sites

There is an automated build ... in SVN: http://trac.wildfire...binaries/system But the executables aren't enough. To have the newest version of the game, you also need the data, which is only in SVN (it's the biggest part of the repo anyway), and the game won't run without it.

I've grabbed the SVN content, it works fine. Despite this, I think that putting a setup with an automated build up to date would have been a good idea (a very good idea if link will be available on the website... ^_^ ), because testing the new functionnalities coming out with alpha 14 is not easy for all (example : perform a checkout for my wife... :unknw: )

Philip is moving the repo to git, and that change would go together with having a better autobuild tool, probably jenkins. But as it's a bit of a boring task for a programmer, it takes a while ;)

If some help is needed, I can spend some hours to make it "real" !!! :bye:

Link to comment
Share on other sites

It's not the cost of the server we're worried about (I think), it's just the maintenance. Btw, if you have experience in the field, I guess you can always contact Philip (always online on the #0ad IRC channel, though not always active). But some of the problems are passwords that shouldn't get shared etc. So only contact him if you have experience in the field (as Philip also has a lot of experience, so he normally knows what to do).

Link to comment
Share on other sites

Way to go with Alpha 14!!! Works really well in ubuntu 13.04 (compiled it from source). Much faster than A13 and even more fun! Have played it briefly multiplayer too and didn't have any issues over internet with a windows client and ubuntu host.

(retracted the GC sucks comment). :)

Edited by cheesyweasel
  • Like 1
Link to comment
Share on other sites

The garbage collector still sucks for javascript. It pauses the game horribly when playing against the AI over time. Why is it so necessary to write it in javascript and not C? Is the existing garbage collector efficient or could it be rewritten in something like C#?

The garbage collector is the one from the JS library we use, Spidermonkey. That doesn't cause a lot of lag normally, spidermonkey is quite clever with it. Are you sure it's not the AI itself you're experiencing? When the AI makes a plan (f.e. around turn 1000, it plans to launch an attack), it takes a lot of time, and can cause a lag pike.

The goal is to only have our non-speed important parts written in JS, the rest is in C++. Consequently, it wouldn't need a lot of garbage collecting as it contains highly static things. Writing the entire game in C++ (let allone C) would cause us to program a lot slower.

Link to comment
Share on other sites

Whenever it happens, the GC count goes up by 30 or so immediately after the lag. I can make some more detailed notes for you next time I play if that's helpful? :)

The garbage collector is the one from the JS library we use, Spidermonkey. That doesn't cause a lot of lag normally, spidermonkey is quite clever with it. Are you sure it's not the AI itself you're experiencing? When the AI makes a plan (f.e. around turn 1000, it plans to launch an attack), it takes a lot of time, and can cause a lag pike.

The goal is to only have our non-speed important parts written in JS, the rest is in C++. Consequently, it wouldn't need a lot of garbage collecting as it contains highly static things. Writing the entire game in C++ (let allone C) would cause us to program a lot slower.

Link to comment
Share on other sites

I see what you're saying. The attack plan runs which takes forever and the GC at certain points (30 times). So an attack plan pauses the game temporarily? And its probably the attack plan and not the GC thats taking the time. And the attack plan can't be threaded? Like at turn 1000 take a snapshot and send it to the attack plan worker thread.. when done the plan is put into action by checking each turn for done jobs? I see that in other threads on the forum that multithreading for the AI is possible with the new spidermonkey. Well... nothing more to discuss, really. Keep up the good work!

Edited by cheesyweasel
Link to comment
Share on other sites

I see what you're saying. The attack plan runs which takes forever and the GC at certain points (30 times). So an attack plan pauses the game temporarily? And its probably the attack plan and not the GC thats taking the time. And the attack plan can't be threaded? Like at turn 1000 take a snapshot and send it to the attack plan worker thread.. when done the plan is put into action by checking each turn for done jobs? I see that in other threads on the forum that multithreading for the AI is possible with the new spidermonkey. Well... nothing more to discuss, really. Keep up the good work!

The AI can, and should be in a separate thread. But for developing purposes (which is still rather important, since it's an alpha), it's better to have it in one thread (easier profiling, less problems with multithreading ...) the release (and maybe the beta versions) should have it in multiple threads.

I have still had problems with retina support. Please fix it. You don't know how hard it is to go through withdrawal from the game.

Even for those who should be able to solve it, it's a very hard task as nobody on the team owns a mac with a retina display. It's very hard to develop for something you don't own.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...