Address the DirectDraw deprecation

[rileyw]

DirectDraw has been deprecated; therefore, code needs to be refactored to use an active API. Developers may be more willing to contribute if they do not have to jump through hoops attempting to develop on deprecated technologies.

Which technology should replace our DirectDraw implementation? http://en.wikipedia.org/wiki/DirectDraw provides light on where the DirectDraw implementation has transitioned.

[Deceth]

I don't have an answer, I'd have to do some research to better understand all the available options. However, here are some guidelines to consider:

• Cross-platform: It would be nice if we could compile builds to run on systems other than Windows. We definitely want to run on all versions of Windows, but if Battle City could also run on Linux, I think there is an opportunity there, despite the significantly smaller user-base, because there isn't as much competition in the gaming space. There are also many developers in this niche area, with the same vision of promoting free open source software.
• Simple is better: Battle City doesn't need anything fancy or 3D. As much as possible, we want to keep the game running lean and consuming as little system resources as possible. This is important because we want to encourage players to leave Battle City running all-the-time (or at least, we don't want them to sign in, see nobody is on, then leave. We want them to sign-in, see nobody is on, then wait a little bit for someone else to join). We want players to open Battle City when they sit down at their PC, do whatever it is they do, and if they notice some other people logged onto Battle City, they can join-in.

[rileyw]

@Deceth I think we can start to list the available technologies to create a short list.

• Cross-platform is almost essential in today's market. I am definitely on board to see this to fruition
• I like simple as long as it has the capacity to address our problems and ideas.

[ndizazzo]

There are various technologies that make cross-platform code easily accessible to the project. Unfortunately, switching to this would be a bigger task than just the OS windowing / initialization. Quite a bit of the rendering and input (and sound, depending on what's chosen) will have to be retooled to accommodate a new API.

Some options are:

1. SDL
2. SFML
3. Unity3D

I put Unity on the list since it's an option, though switching to it pretty much warrants a rewrite of the game, so it's an unlikely choice in this situation.

[rileyw]

I'm in favor of the technology/framework that we can pick up and start transitioning the game. Perhaps a factor that could/should be considered is whether the technology supports mobile platforms. This definitely falls into the cross-platform umbrella but it may need more weight when calculating the decision.

Unity3D seems like a decent solution for delivering the game on multiple platforms as well as opening up the opportunity to introduce 3D components.

[ndizazzo]

It involves a complete rewrite and a "re-imagining" of the network model. Authoritative servers are slightly more challenging in Unity3D as the basic and built in implementation of networking is RPCs. There are, however, many 3rd party solutions like TNET and Photon that could be applicable here. We'd also need to have a Unity3D master instance per game server if we were to use the built in physics (as well as other stuff). Mixing and matching different physics engines WHILE maintaining synchronization is a complete nightmare, and has lead to numerous project failures in the past.

So, in the case we decide to keep an authoritative C++ server that serves individual game worlds and clients are Unity3D based: the server must then know how to calculate player positions / speeds / forces based on how the client's 3D physics engine is built. And on top of that, I'm fairly certain that the physics in Unity3D is NOT deterministic across platforms, meaning what rileyw sees on his linux box is not what sig_kill sees on his windows box during a simulation. A possible solution is then to use another 3rd party physics library that is used to do most of the physical simulation / collision. I think Unity3D now supports middleware libraries in this manner.

Given that this is an open source project and anybody who might contribute have day jobs, a large commitment like that seems like a step in a direction that makes the game much harder for people to contribute to. Don't get me wrong, if switching to a platform like that is in everybody's best interest, and we have C#/Unity3D programmers throwing themselves at us, I'm not opposed to the idea. I'm merely trying to state that we'll be taking a bite out of a large pie.

On the flip-side, switching to a much simpler multi-platform system like SMFL or SDL lets us keep everything that currently exists, and make incremental steps towards a better game.

[Deceth]

I just read: http://stackoverflow.com/questions/2842198/which-is-better-sdl-or-sfml

It sounds like you can get a little bit more performance out of SDL, but that SFML is more user-friendly/easier to develop with.

For an open-source project like this, my preference is for SFML if it facilitates understanding the code/keeping things simpler so anybody can keep carrying the torch forward over the years :)

I say this with no experience with either, so feel free to chime in with a different opinion!

[ndizazzo]

SDL is what we were using with the original Sourceforge project. SFML is coming along and has more frequent feature/bug updates, which is nice from a developer standpoint. SDL has a much larger user base, and is a more mature library; but releases are less frequent.

In the end, it always boils down to picking one that the person leading the tech direction determines will be good over the entire lifespan of the project.

Here are the factors I can see as important in weighing in for Battle City:

• Supported target platforms
• Sound management
• Unified Input handling
  • Would help with key remapping with issue 58
• Texture loading
  • BC uses low res, low colour textures - we can save memory usage by using a lesser pixel format
• Threading
• UTF-8 support (for issue 43)
• C interface (SDL) vs C++ interface (SFML).
  • Keeping a C++ interface would be better since BC is already primarily C++.

[rileyw]

Awesome comments. Unity3D seems to introduce more problems than it resolves based upon what @ndizazzo has highlighted. Unity3D Reference

• http://docs.unity3d.com/Documentation/Manual/Physics.html
• http://docs.unity3d.com/Documentation/Manual/NetworkedMultiplayer.html
• http://docs.unity3d.com/Documentation/Manual/LearningtheInterface.html

@Deceth, you're the person leading the technology direction, right?

I'm going to build a tech demo with SFML to see how much trouble I encounter before I vote on either one.

[rileyw]

Up and running with SFML in Xcode.

Up and running with SDL2 in Xcode.

Seems like SFML has spent more time preparing OS X resources which is a plus. I am going to do some builds in Linux and Windows.

[Deceth]

Deceth, you're the person leading the technology direction, right?

@rileyw I think this thread is a great example of you guys sharing your expertise and narrowing down the best options. If you need me to take a decision, I'm happy to do so, but keep in mind I'm not an expert. Any recommendations I make will be based on trying to keep things Cross-Platform and Simple.

[rileyw]

SFML and SDL on Linux was a bit more involved due to the distribution (CentOS), but both were easy to compile from command line once the libraries were in the correct location.

Windows is a similar experience as building on OS X.

[ndizazzo]

Nice work... I imagine any other Linux distro would be fairly easy to get it running on. The majority of desktop players are likely using Ubuntu, which will be dead simple to get things set up on.

Have you gone through the APIs for both frameworks? I've gone through SDL and SFML now, and they look fairly adequate for our needs with no real differences.

The one thing SFML is missing, was built-in support for loading textures with different pixel formats. That stuff is not hard to build though if we determine we need it. Anyway, there's more than enough here to get started to modernize the project. It's going to be a fairly large undertaking, but I think our high level goals should be to:

• Port the graphics to utilize rendering from the library
• Port the input system
• Port networking

Lastly, I don't think we should start changing the game logic around and fixing bugs while we are doing a port to utilize a new base library. We'll be able to keep the momentum going if it's a focused 1:1 copy of the game. From that point we'll have a better codebase and will be able to tackle the remaining issues.

[rileyw]

I agree that Ubuntu is the leader in the gaming category amongst Linux distributions¹. This can be our targeted Linux distribution.

I have skimmed through each framework's API, but I haven't dug much into the common hurdles and bugs/issues for each framework. SFML^{2 3} and SDL ⁴ are both working towards mobile platform support. I don't see any major concerns nor roadblocks with either framework at this time. Sorry that I don't have a stronger preference for one side or the other.

I agree with your suggestion to postpone game logic changes and bug fixes because trying to juggle those items and to refactor the project to use a new framework will only cause confusion and frustration.

[ndizazzo]

I don't have a preference in either language, so in the spirit of consistency of the codebase, I'd recommend SFML to stick with a C++ interface to help other contributors stay on the same page. It doesn't have mobile support yet, but it's not something we'd need at all in the near future.

[rileyw]

@Deceth What is your final verdict?

[Deceth]

@rileyw My preference is for SFML, unless someone brings up a good reason to go with SDL (For example, SDL 2.0 was just officially released).

I like that SFML is object oriented and is C++. Personally, I find it easier to read and understand. Overall, I think it will keep the codebase simpler, and thus have the long-term benefit of making it easier for new developers to join the project and get involved.

[rileyw]

I'm going to close this issue since we have a decision on how to handle the DirectDraw deprecation. Thank you for everyone's input in the conversation/decision.