Warzone 2100 Forums

There are certain things I feel would be better spent (purely from a time perspective), if we can just pool all the talent together, and do the things that need to be done. The issue here is, that everyone has to agree what the 'base line' is, and go from there, and of course we all have to be looking at the same direction as well.
As I said, there were many mistakes on the road to what we have now, and some of those things keep coming back to bite us.
Shame we don't have a rewind button, but we live & hopefully learn.

However, doing a fork doesn't automatically mean we lose manpower, if that person never would have joined in the first place.
If they can do something better in their version, then good projects would merge the code in question in, and continue on.

History...
Warzone's codebase is still incredibly complex and intertwined in lots of (unexpected) areas.
The road to determinism has been rough, but the end result should provide a more stable environment, since everything happens at the same time, and the same thing happens on all machines.
One of the main changes made was to split logic from rendering, so that can happen. That touched lots of code.
Pretty much all floats that could affect game state are now ints.
Switching away from SDL to Qt seemed to be the correct move at the time, and now we are back with SDL.
3.1 is still using wzscript for all of campaign, with a touch of JS thrown in, and the default AI is still using wzscript.
While JS is arguably a improvement over wzscript in some areas, in other areas, it pretty much is the same thing.
Game still uses brute force for pretty much all rendering of things.
Where does this all leave us now ?

Well, you are looking at the upcoming release of 3.1, I still think it is one of the better versions of Warzone out there, and, it is far more "stable" than any version of 2.3 ever was in multiplayer, and while not perfect, it is slowly getting into a better shape.

While personally, I feel that we need to find alternative libs for some of the things we are using now, it really isn't as clear cut as it could be to some, and again, time is the big enemy of this (and pretty much all) non-paid projects. Right now, it is whomever can get the job done gets dibs so to speak.

Hmm, don't know how this fits in this thread, since I kinda went off on a tangent.

It fits, even though its not related to DX. I was hoping to get people debating this and the current problems with the codebase.

@Rman

What happened in 2004-05 is clearly documented in the rts.net forum archives which are still extant.

Where is that archive? I've got a lot of catching up to do any way I can...

Overall I would say WZ is being updated/fixed at a far better pace than Vega Strike. More coding and bug fixes from here. It makes sense to be leary of a major change like adding DX back in but it could be worthwhile. So we work with what we have and with what we can. If it ends up being like adding Qt into the game then so be. Good goal and idea, just didn't work out. So we shall see how things go.

So with the debate mostly out of the way lets get down to the nitty gritty and see how we should go about doing this. Is all the game logic moved out of the rendering files? Does portions of the codebase need to be refactored before we can begin? Does the code need refactoring at all? Does the windows side of things have a working Visual Studio solution? Things to dicuss and more to debate.

Sidenote. It is easy to see how cross-platform open source projects become lost. Far more developers in said projects are using non windows machines and as such if not careful the windows side of the code tends to get neglected. Thankfully windows is a bit of a cludge and can run even on the most unfriendly of code (though with 64bit windows this has become more of an issue).

Kids are distracting me so I may not make as much sense this go round. Till they sleep...

What happened in 2004-05 is clearly documented in the rts.net forum archives which are still extant.

Lord Apocalypse wrote:@Rman.....Where is that archive? I've got a lot of catching up to do any way I can...

Sab, Lav, Cowboy, Grim.... maybe Kevin.

.

About forks, I wouldn't say that those needs to result in loosing manpower, especially if those who forks are most often not interested in working on things that are goal for upstream. The main issue is that they can lead to splitting community, if they end up incompatible.

So for current situation I would opt now only for cleaning up source and refactoring code so it could be easier to go one of those possible paths since it's a good thing for all of them. When that work will be done then we can return to discussion which path should be used for upstream and if we really need to have forks.

About Qt, well that was weird choice for the exact task for which it was chosen but it is possible to create a rendering engine with it (especially easy with upcoming version, though that will require OpenGL (ES) 2.0 for GUI part...) and using it only for non GUI parts (especially networking, scripting, strings handling) also makes sense and really makes development easy. If someone would decide to go for even more gargantuan task of rewriting game nearly from scratch (reusing assets and maybe some parts of code) then I would consider using it for that (Qt5 with QML2), maybe paired with some library for physics calculations.

For ifdef vs library / plugin, I would like to go for library, make it fully abstract to let to create even more third party paths taking advantage of OpenGL 3.x and 4.x (maybe also 1.4) or DirectX 10 / 11. Also in next month we will probably end up with OpenGL ES 3.0 and maybe OpenGL 4.3.

So for conclusion, I would suggest for now improving code of current master branch, identifying places which needs reworking to make whatever will be ultimately chosen (including sticking with OpenGL ES 2.0) easier.

I can second the call to not divert manpower. As OpenGL is already working and will also work for e.g. Linux, I would not put too much effort into a DirectX renderer, unless someone is really passionate.

A simple interim solution would be to build a blacklist of bad drivers, and ask users to upgrade.

After all, it should be easy to detect old Intel graphics drivers. Intel has been putting a lot of effort into improving their drivers (at least under Linux, but I figure for their sandybridge+ generations for all platforms - better graphics drivers can help improving battery life for "ultrabooks").

As for me, I won't be buying a powerful graphics board anytime soon (currently: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)). And once my current laptop is dead, I will definitely go for an Ultrabook with Intel graphics. I'm playing just once a month, so a high-end graphics doesn't pay off for me, battery life is much more important. So don't forget about the low-end users, please! These may actually be a key audience for warzone, as it is not up to par with current commercial game screen goodness - but it actually works for users of older hardware that are not willing to buy the latest most powerful graphics all the time.

I'm happy that warzone 3 at least somewhat works for me (intel graphics driver 2.19.0), but I'm seeing some nasty screen corruption in heavy fighting situations. maybe it is particular weapons / effects causing this. I will try --noshaders --novbos next.

@Lord Apocalypse - http://www.raspberrypi.org/
@vexed - OpenGL ES 2 should be capable of running everything we need, I think. ES 3 is soon going to be published, but I do not know what hardware will support it.

Per, yeah, OpenGL ES 3.0 will be probably published in coming weeks, probably it will require OpenGL 4.x capable hardware...

Lord Apocalypse wrote:If it ends up being like adding Qt into the game then so be. Good goal and idea, just didn't work out. So we shall see how things go.

Qt ending up adding many kludges into the system, if directx is to be added I want this to be done using as much refactoring as reasonable.

Lord Apocalypse wrote:So with the debate mostly out of the way lets get down to the nitty gritty and see how we should go about doing this. Is all the game logic moved out of the rendering files?

Not completely, but the situation isn't so bad either.

Lord Apocalypse wrote:Does portions of the codebase need to be refactored before we can begin? Does the code need refactoring at all?

Yes.

I read through the above posts and I don't see where the discussion is over, but this is how I suggest we proceed:
The rendering code needs significant refactoring, I suggest that we refactor it such that the entire rendering operation is modularized. This would make it easier to do the following:

• Trying 3rd party engines
• Maintain a renderer which supports older hardware (e.g. runtime opengl renderer swapping, without complicating individual code paths)
• Directx

Etc.

Everybody wins in this scenario: Directx evangelists get their DirectX and we have a more modular code base to work with (not to mention more developers.) If it flunks there is still a net benefit to everyone.

This being said, other parts of warzone will likely also need some love in the process, e.g. the resource loader.

I completely agree with Safety0ff (maybe except Qt parts, it was used in wrong way here, for backend ).

Safety0ff wrote:other parts of warzone will likely also need some love in the process, e.g. the resource loader.

It doesn't need love, it needs

Emdek wrote:I completely agree with Safety0ff (maybe except Qt parts, it was used in wrong way here, for backend ).

Too be clear, it was a comment about the end result and process, not so much a reflection about Qt.

Safety0ff wrote: I read through the above posts and I don't see where the discussion is over, but this is how I suggest we proceed:
The rendering code needs significant refactoring, I suggest that we refactor it such that the entire rendering operation is modularized. This would make it easier to do the following:

• Trying 3rd party engines
• Maintain a renderer which supports older hardware (e.g. runtime opengl renderer swapping, without complicating individual code paths)
• Directx

Etc.

If there is a way to check what the hardware can handle you can always check the users hardware capabilities at first runtime and save it to the config file. Internally you woulc probably want to clump some features together in various blocks of more advanced features and only allow the calls if config value x = whatever. Do it using an enum I guess.

Everybody wins in this scenario: Directx evangelists get their DirectX and we have a more modular code base to work with (not to mention more developers.) If it flunks there is still a net benefit to everyone.

Long run, adding DirectX helps with bad OpenGL drivers.. I could care less about what DX evangelists think, at least for an open source project.

This being said, other parts of warzone will likely also need some love in the process, e.g. the resource loader.

Anything on trac about resource loader issues?

I still haven't started updating to DX 9 in Redemption yet, having some issues over at Vega Strike I'm trying to clear up...

I think the more everyone looks at this the more its a win-win even if the reintegration is a failure. Well, perhaps not a win for those with flaky opengl drivers.. but thats not our fault anyway.

Lord Apocalypse wrote:If there is a way to check what the hardware can handle you can always check the users hardware capabilities at first runtime and save it to the config file. Internally you woulc probably want to clump some features together in various blocks of more advanced features and only allow the calls if config value x = whatever. Do it using an enum I guess.

We already do something like this, but there are advantages to multiple simplified independent code paths instead of one grand unified one.
E.g. Each renderer has fixed requirements which are checked once then assumed from there on.

Lord Apocalypse wrote:Long run, adding DirectX helps with bad OpenGL drivers...

How many people have issues with this? How many people with issues have hardware which is no longer support by the OEMs?

Lord Apocalypse wrote: Anything on trac about resource loader issues?

No, you'll see once you look at it, it should be ripped out and redone like per implied.

How many people have issues with this? How many people with issues have hardware which is no longer support by the OEMs?

Intel is the worst. Even with supported cards there are still ogl related issues.

I just came up with a new reason to use directX (9). Given that warzone doesn't have advanced lighting effects due to how old the game is, one could use the ENB series mod, which is completely FREE, and works for all directX 9 games. It features amongst others bloom, screen space ambient occlusion (SSAO) and high dynamic range (HDR) lighting. I post links to the developers' website as well as to galleries of before and after comparisons on various games. The effects are less dramatic on older games (such as this) but it still may be well worth reintegrating DirectX, given the advances in graphics the game is undergoing. There are around 100 parameters you can modify so we shouldn't (i shouldn't if you guys prefer) have trouble adjusting the mod to the game. DX9 compatibility is a different issue entirely though.

dev's website: http://enbdev.com/index_en.html
before and after comparisons:
http://enbdev.com/ss_deusex_en.htm
http://enbdev.com/ss_re401_en.htm (page 2 as well)
http://enbdev.com/ss_deusex3_en.htm
http://enbdev.com/ss_crysis_en.htm