k776

The <object> approach was YouTube's older video embed syntax. The <iframe> is YouTube's newer one. If we're using <object> it's because they didn't use <iframe> at the time this forum was set up. A quick glance looks like the code that parses the youtube urls/media tags here on this forum is contained within admin/sources/classes/bbcode/custom/defaults.php. In theory it's possible to make changes, but I'd recommend not doing it because it'll complicate upgrading the forum.

I've gone ahead and changed the topic and tagged it with "[Resolved]"

I made some tweaks a few hours ago which may take between 4-24 hours to take effect for everyone. Initial reports indicate the changes fixed the issue, so this whole thing can be put behind us now.

@wraitii: I think being able to enable disable different settings would be wiser than a high/medium low. The GUI might do high/med/low, but underneath, it would just be settings these: renderer.water.fancy = true # colour based on depth renderer.water.waves = true renderer.water.foam = true renderer.water.reflections = true renderer.water.refractions = true renderer.water.shadows = true

As am I. The last thing we want is something to work like magic, because it's confusing. We might want a soft sound when zoomed out for example, and if it's based on gain, we can't do that. So please add the extra XML value and run a script which updates all the existing sound files.

@wraitii Good work. Go ahead and commit this, and we'll soon find any issues that need fixing. @myconid If you can spare some time, after wraitii has committed his code, to review it, that'd be good. It's alway good to have two pairs of eyes on large code changes.

Yes, I mean in graphics.0 A.D. need a bit to catch up to other games in terms of gameplay. For one thing, we don't have a complete multiplayer experience yet :-( Diplomacy only just got implemented and needs refinement to make it perfect. But we're getting there :-)

Well deserved. Great changes over the last few release cycles. Artists are slowly making better use of all your changes. It's looking good :-) 0 A.D. already leads within open source, but with deferred lighting, better shadow code, better water rendering (coming from wraitii soon), 0 A.D. will start rivaling some of the commercial games :-) Keep the changes coming :-)

Well, if it affects ARB(?), probably best to post a patch for review. GLSL is slightly different in that it is opt in, so we don't need to worry about it temporarily breaking. But with ARB, we need to make sure it works on most devices. However, we're still a little while from release so if you feel it's stable, and you'll be online in IRC for a few hours after you commit to fix issues, then maybe it would be alright. Of course, make sure you code is as clean as possible, complies with coding conventions, etc etc. When you look at the code, you should be able to say "This is clean, simple, and optimized.". We don't want a whole lot of code and complexity for little gain.

I haven't look thoroughly, but quickly, I found this in the XML (for example, in binaries/data/mods/public/art/actors/units/athenians/cavalry_javelinist_a_r.xml): <prop actor="props/units/weapons/jav_projectile.xml" attachpoint="projectile"/> I'm guessing the game uses the prop at the "projectile" attachpoint to determine what to throw.

Correction: The optimisation made it take only 20% of it's original time. That's an 80% speed boost, but those numbers weren't verified, just estimates, so probably best alter that to:"he was able to lower the CPU usage of the CCmpRangeManager so that in theory it can be up to 80% faster." Also, this optimisation hasn't been committed yet, he's working on it.

An open source bounty is probably the way to go, but we would need to ensure the code is clean, not something someone has put together quickly. Everything runs on one core, one thread at the moment. The reason for this is so we can easily see speed bottlenecks (like pathfinding and the AI). Once the bottlenecks are improved, then we can split parts out into their own threads. This is still a while off though. Philip is working on the pathfinding, and wraitii (last I heard) is working on an AI rewrite to make it more efficient. So we're making progress toward speeding up the game.

The distance fog is look pretty nice. Can we get this implemented as the default for maps please and apply it to all current maps. Leave HDR/Bloom to the artists to tweak per maps, but fog seems a pretty generic thing all maps could have applied now.

Hey mimo. Thanks for your patch. Can you please file a new ticket and attach your patch here: http://trac.wildfire...s.com/newticket Edit: Opps. Nevermind me :-) Looks like you already did (http://trac.wildfiregames.com/ticket/1691). Thank you.

serveurix, you are correct. CPU is the bottleneck, but it's not the CPUs fault. There are many parts of the app that aren't as effecient as they could be. In particular, the AI and the Pathfinding. Work is being done in both areas to make them faster. Eventually too we'll split things like AI and PAth finding into threads, so CPU's with multiple cores can split the processing. But that's still a few releases away.

Can you can build on top of rubble (it doesn't have an obstruction)? And if so, does it make the entire rubble disappear or just the part you build over?

Did a very quick test on my Mac. Seems to work nicely. Can't notice any of the sudden music start issues I could before. The source code looks a bit cludgy though, with a massive whitespace gap. Remember to format according to coding conventions before you commit to SVN.

This has been discussed many times. The idea is yes, the main thing we want is to split the AI and pathfinding from the main thread into their own threads, and send info back to the main thread. This would help a lot. Before we do that though, we want to make sure that each part of the system is already fast'ish. For example, at the moment, each AI is keeping a copy of their own unit collections and terrain data, rather than sharing it. wraitii was last seen working on a new AI that shares it's data, which is the first step before then splitting the AI into it's own thread. So progress is being made, but it is slow. If you're experienced enough to help, pop on IRC, irc.quakenet.org #0ad-dev and have a chat with a few of the developers if they're online. If you plan to help, make sure that everyone agrees with your solution before you start. Nothing worse than many man hours for a solution that won't fit into system neatly.

@myconid You checked in a binaries/data/mods/public/maps/scenarios/reservoir.xml file, but not the actual map cause when I load it says no terrain file? I'm eager to try it out but I don't have Atlas on my Mac, so a working map I can load and test would be awesome.

No alternative formats! Stick with <textures><texture> and throw an error when unmatching data is found, and keep it simple. if actor->textures.size() == 0 throw "internal/art/actors/iber_spearman_e.xml contains invalid texture data" end

@myconid: We seem to have wound up with dozens of materials doing nearly the same thing, minus one feature. e.g. basic_trans_ao_parallax_spec.xml does the same as basic_trans_ao_spec.xml, just without the Parallax. How hard would it be to make a system like this instead? The conditionals are right in the file. The conditional_define tag is combined with <define /> to make it look nicer too. (this is just my thoughts, you'll want to check with others first before implementing it if the idea is possible) Edit: Tweaked based on feedback. Removing the quality level stuff in favour of different options in default.cfg instead. Doing so should make it easier to test things too (e.g. disable specular but have AO enabled) Edit 2: Further tweaking. Actors define what effects they should use. e.g. on the roman civ center: <effects enable="normal specular ao parallax"/> would pass EFFECT_NORMAL, EFFECT_AO, etc as true constants. (you can find better naming I'm sure). Then the material would become: <?xml version="1.0" encoding="utf-8"?> <material> <alpha_blending/> <shader effect="model_transparent"/> <define name="USE_TRANSPARENT" value="1"/> <define name="USE_ALPHATEST" value="1" if="CFG_FORCE_ALPHATEST"/> <define name="USE_NORMAL_MAP" value="1" if="CFG_USE_NORMAL_MAP & EFFECT_NORMAL"/> <define name="USE_SPECULAR_MAP" value="1" if="CFG_USE_SPECULAR_MAP & EFFECT_SPECULAR"/> <define name="USE_AO" value="1" if="CFG_USE_AO & EFFECT_AO"/> <conditional if="CFG_USE_PARALLAX_MAP & EFFECT_PARALLAX"> <define name="USE_PARALLAX_MAP" value="1" type="draw_range" conf="PARALLAX_DIST"/> <define name="USE_HQ_PARALLAX" value="1" type="draw_range" conf="PARALLAX_HQ_DIST"/> <define name="USE_VHQ_PARALLAX" value="1" type="draw_range" conf="PARALLAX_VHQ_DIST"/> </conditional> <uniform name="effectSettings" value="1.0 50.0 0.0075 0.85"/> </material>

If not already done, please make sure you post this patch to the Trac under a new ticket if one doesn't exist already. Posting on forum for feedback is fine, but you must have a corresponding ticket, else the patch could be forgotten/lost.

Bottom line, kickstarter is too limited. It needs a USA bank account, which just won't work for us. However, I'm looking at alternatives. http://www.indiegogo.com looks like the second choice. I'll post back when I have something useful to say about it.

If we did a kickstarter, we'd need someone in the US that would be happy to lend their bank account (which is not likely given tax issues). We'd also need someone willing to work full time. We'd probably want to get 2 years worth to make it worth it (~$100,000 USD).

There have been some recent changes that require a new pyrogenesis.exe rebuild. If you can't build it yourself, you'll have to wait for ben to.