There goes maybe a stupid question:) Is there any project o make spring.exe directx?, directx is very powerfull

Or perhaps it could use diesel engine, thats very powerful too! :)

Lame joke is lame.
I had ask this before and it requires a rewrite on the rendering part of the engine.( To be honest it needs a rewrite anyway, but these spring dev do this during their spare time, so I won't be harsh on them.)

why should the spring engine need a rewrite? they just added roam.. speeding up mapdisplay we have splatmaps.. we have features.. we are building on the suicide_commit_bot, that will transfer idle boardtalk into powerfull feature commits

Before I begin, thanks for taking the time to answer my barrage of questions :)
Obvious question 2: As far as I understand, this is build time dependency, right?
(In case it hasn't been done) Will it be possible to simply stuff a local copy of it and integrate it into the makefiles?
If its only build-time dependency that's included in the tar-ball it'll be far easier for me to get it included w/o having to go through the long review process... *

- Gilboa
* Obviously, being undecided and all, once pygccxml gets included in Fedora I'll ask for a build switch to use the system copy instead of the included one. Downstream packagers, gah!

Yes, pygccxml is a build time dependency and yes, it should be possible to integrate it, at least temporarily. This wouldn't even clutter the engine repository since the bindings are already a submodule: https://github.com/spring/pyunitsync
I won't be able to check out the feasibility of this for at least a week though.

Thanks!
No rush, for now, I'll release 86 for testing without it; let me know when there's a patch / updated tar-ball and I'll issue a new build.

Gilboa

Something appears to be slightly wrong with shield rendering.
Its more opaque and not smoothed?

unfinished shield
http://i52.tinypic.com/ojp3s5.jpg

finished one
http://i55.tinypic.com/1z30bc9.jpg

Looks very different from 85.0

Senna..Please do some research before you post the first thing on your mind. People will take you more seriously.


Why don't you lend them a hand then?

The main reason is that Spring is an Open Source game, and because of this the devs will not use a proprietary, Windows-only API.

Fix'd, and it IS possible to simultaneously use directx/opengl for rendering part of the engine engine, but that shit requires more work on rewriting/maintenance and debugging. As spring devlopment is slow at it is, it requires more man effort. The chances of getting new devs are slim. Very slim.

I Like to help out with the project, but I do not have the necessarily knowledge to help out without consistently breaking things.

i can not speak for others, but i personally would not want directX support in the spring repo (and i qoudl assume other devs neither). it just adds maintenence hell, without any actual benefit, except maybe at best, marginal performance/stability gains for windows users with certain graphic cards. even if i coudl push a button and get near perfect directX rendering impl for spring, i would not want it. if for nothing else, then for hte maintenence work it creates.
if it would come with a very clean rewrite and redesign of the whole renderin process (and in practise this means.. also msot of hte rest of spring), thne i woudl push the button. but ... i might still remove directx support again after that.

Shield drawing is very broken. shieldAlpha no longer does anything which is preventing a workaround.

Was the gadget handler updated at all? I have heard about new callins but they are not in springcontent.sdz.

There is also rendering bug with sniper bullets in ZK - similar to shields, no alpha, very opaque.

As for DirectX umad? Lots of rendering is now done in the games (lua) using opengl and shaders - you would need to expose some other api to games to shield them from platform specifics..

Its just crazy proposal for project in this stage..

OGL is more powerful anyway.

Is there going to be an 87.0 reasonably soon with the few bugs from 86.0 fixed? It would be nice to have before more bugs are added to develop.

Yup, 86.0 is dropped and there will be a 87.0

Well, OpenGL is 2D/3D API, but DirectX (as someone said this abbrev) is a general purpose API which can be successfully used (rly) even in commercial non-entertainment software. With open source solutions you need to be very carefull to stick all things to work as you expect, even with latest library versions. For example try to effectively debug bullet and boost libraries

From my point of view DirectX provides better image quality than OpenGL, especially on proffesional screens (Wide CRTs and S-IPS).

And btw DirectCompute came before OpenCL. Well, not exactly but came with enough features :)

This is good! Just keep community informed. I mean it is better to edit news page and say that 87.0 will be soon instead.