Added by Robert Wetzel, last edited by Robert Wetzel on Apr 22, 2008  (view change)

Labels:

Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.

Brain support list

  • Use FIXED, ADDED etc. as prefix for commit messages
  • Use Nel-# in commit messages which refer to a specific issue (number) tracked in JIRA
  • "agile" aka small fixes, when possible

Compiler support

In the wake of the gcc 4.3 patch provided by pocek, there was a short discussion about how far back we should provide compiler support for NeL. My Gentoo system (amd64 / 2007.0) currently has 3.4.6, 4.2.3 (default compiler atm) and 4.3.0 installed. The installation of 3.3.6 failed; I don't think going back any further will be of any use.

As far as I'm aware OpenBSD provides a 3.3.X version out of the box (however, it's modified in certain regards to the vanilla 3.3.X).

Platform support

I'm not so much into the Windows and MacOSX systems; however, there is a plethora of Unix systems available, and they may get used at least for the server part of an online game. Depending on OpenGL and/or sound support they may even end up as client platforms.

The main dependency to compile NeL on a Unix platform is gcc. We won't support any non-gcc compiler; not because it's too difficult to get things working, but because of the maintenance overhead afterwards.

To run NeL3D based client applications (which also includes non-networked / singleplayer games) you will need a decently fast OpenGL support.

OpenGL driver

The whole 3D engine will need some kind of cleanup, as it contains a good few bugs, aside of the "age" it shows in regard to support multipass rendering and free support for vertex & fragment programs, which are required for modern GPUs. As OpenGL 3.0 is "around the corner" it might be a good thing to start with a new driver once it hits the "shelves".

Open OpenGL bugs

  • Shadows are bugged in a similar way to the clouds from the looks of it.
    • After the cloud fix, there are no shadows visible at all anymore. What's going on there?
    • check out issue NEL-41 for more info, especially the comment from bf
  • ARB_fragment_program for water isn't handled natively on ATI cards, at least not on my HD 2600 XT. I haven't checked into the details, yet (what limit is actually causing this flag to be raised). However, in the long run we should offer GLSL/shader replacement for all the vertex and fragment programs (and keep the programs for all the older graphics cards / drivers).
    • "Handling natively" means, that the different hardware limits are not exceeded by the fragment program in question. Otherwise they have to get translated/compiled in a way that the hardware supports, down to complete software implementation (but I doubt that will happen, if everything around it happens in hardware). A first test has shown, that even though the fragment programs are not "native" on the HD 2600 XT, the result looks correct (if you disable the nativity check). This leaves the question, on what cards and drivers the whole thing goes bonkers (see ATI bugs on MacOSX machines).
    • Add support for ARB_fragment_shader and ARB_vertex_shader, with respective GLSL programs as described above.
  • Add native MacOSX GL-context support (Cocoa). Need hardware for this ...

OpenGL/ES 2.0

There is the idea of OpenGL/ES 2.0 driver. Mobile devices get more and more powerful, besides devices like the PS3 are supporting this standard (among a number of others) as well. Basically it's a copy of the existing OpenGL driver with all but the VertexAttribute, VertexProgram and FragmentProgram pathes removed, because OpenGL/ES 2.0 doesn't support anything related to the glBegin()/glEnd() programming paradigma.

X fullscreen

see VideoModeSetup

Input handling

see Backend decoupling

The X fullscreen change will include a change of the X event handling. As soon as this area is tackled, a more generic approach to support different input devices (not only keyboard and mouse) should be considered. Ideas coming to mind here: joysticks, gamepads, or even the Wii-mote controller as presented by ? on Youtube in combination with MTP-Target.

Sound driver

FModEx support in Linux

  • Check how the existing FMod driver needs to be changed to get things working with FModEx
  • Supposedly there is FModEx support in Windows already (done by ace)? Code doesn't give a hint about this, though.
  • Support in CMake build system.
  • I started a respective work, but aside of the CMake configuration nothing else worked, yet (configuration doesn't trickle down to the actual code and enables the FMod driver).

Generic interface to sound streams

  • Because OpenAL can't handle any sound formats aside of the ones it uses in it's interfaces (which is more less raw sound data), we will need some kind of sound file loader. Best would be a generic interface, which would allow us to plug other sound drivers to it (DSound?), but also gives NeL users a tool in the hands to fool around with
  • It's a new interface, which requires design and such things. Keep in mind that there are things like timed callbacks and such involved for proper data stream handling!
    • If it is generic, one could for example map a video to a texture and use that for whatever means, e.g. from movies to display parts of the storyline, over ingame screens displaying random junk, to billboard ads as you have them in Anarchy Online or Hellgate afaik.
  • GStreamer would be a perfect choice for Linux, especially now that it's pushed by KDE and updated more regulary again. I don't know how they want to solve that problem for non-Linux platforms; maybe we can "leech" their efforts into NeL (have to recheck the licenses). It would provide sound and video streaming via a common interface; the different codecs are handled via plugins to other libraries.

Tool support

The tool support for "content creators" is pretty much nonexistent in Linux. To give Linux users the chance to create data for NeL based games, we will have to write tools for them. Ideally, these tools are crossplatform and can be used by the Windows, MacOSX and non-Linux-Unix folks.

  • Choice of GUI platform
    Just to give a warning ahead: I'm used to Java Swing. Some like it, others don't, infact most of the arguments have been about the looks, which is part, but not the main focus of my opinion about possible frameworks. MVC is the key, because it keeps things cleaner and much more saner than all-in-one-packages.
    • wxWidgets, which I personally dislike for the fact it has started out as a MFC copy (and boy, have I bad memories about messing with MFC stuff!). If someone can find the MVC principle being used in wxWidgets, yell. Otherwise I'm more than willing to ignore this thing It seems crossplatform compatible.
    • GTK, which has MVC included, at least partially. I dunno about the C++ port gtkmm, because GTK as such is C based. What I have to figure out is how the support of non-Unix platforms is, especially Windows (and that NOT via MinGW or Cygwin, but by using Visual Studio).
      • There is a [GTKDisplayer] available already in the NeL libraries, at least for Unix/Linux users. It's currently an optional dependency for NeL.
      • Seems like at least gtkmm works together with Visual Studio. I would need to check the full stack, though, because all libraries (including GDK+GTK+additionals are needed for this).
    • Qt, which has MVC included. It's licensing is not fully open source, which could lead to problems eventually. As long as things follow the GPL, it should be fine, though. Offers crossplatform compatibility, especially with the latest versions you may not even need additional patching to do so My personal preferences slowly drift towards this framework.
      • ace preferes Qt, too, from the sounds of it. If we really go with Qt, I would suggest to get rid of the GTKdisplayer and convert it into a Qtdisplayer to remove an (optional) dependency from NeL.
      • The VideoModeSetup prototype is based on Qt to get a first look at the principles driving Qt.
      • Qt has the disadvantage that it provides it's own "STL" (i.e. QList and so on), which was maybe a good idea back in time, but becomes a growing pain in the rear end with increasing (working) support of the C++ STL. I haven't had the time to dive deeper into Qt; we may end up copying a lot of data around just because of this (NeL relies on C++ STL).
    • CEGUI, which is already included in NeL, if you enable it. Contrary to the other frameworks it has the huge advantage of the way it works together with NeL: There is no need to embed NeL into a "foreign" window, it all happens inside NeL / inside the rendering loop. It is not fully featured from the looks of it (in the meaning that it doesn't offer certain UI elements), and MVC seems to be rather foreign for CEGUI, too. I have to check into the layouter, still, as it failed to compile in the simple approach (probably versioning problems, 0.5.0 vs. trunk/HEAD).
  • Integration
    With all but CEGUI there is the problem of integrating NeL-OpenGL into the frameworks. They all have some kind of OpenGL-port, which handles creation and management of the OpenGL context, a thing NeL does as well. To work together, NeL has to be coerced in using the "foreign" OpenGL context, which seems only to work in a back-ass-wards way for Windows. A more generic approach is not only helpful for us, but also allows others to integrate NeL for their own projects.

Blender plugin

To free ourselfs from the chains of 3DSmax, Maya and the like, support of a free software 3D-software is required. Blender is probably the one which comes to mind first. For that we will need a plugin of some sort, which handles import and export of data from/to NeL.

  • Zerotacq said he is working on that, or at least getting a foothold there by first trying to import data from NeL into Blender. He follows a pure Python approach.

TODO list

After a compile run through NeL a good number of compiler warnings popped up. It turned out there are many warnings basicly saying the same, just on different parts of the code. The warnings have thus been grouped by their message and will be handled independently:

  • Compiler warning: pointer-casting & strict aliasing. See Article about strict aliasing of the things behind this "type punning".
    This is a more complicated matter and probably not always easy to solve.
  • Compiler warning: The singleton define results in a specific warning everywhere[?] such a singleton is used. Fix the define, if possible?
  • Compiler warning/error: signed<->unsigned mixups, comparison of unsigned against <0, type size problems on 64bit platform(s) etc. Some of these pose serious issues which can lead to crashes and other things if not fixed properly.
    Some of these warnings are probably not going to be fixed, as this also includes problems caused by template variables used in comparisons.
    • There are a number of "valid" casts, which actually seem to cause havoc, as it has been the case with trying to find and fix issues causing Snowballs to bail out / crash.
    • Tools/Samples need to be looked through for this kind of warning, there seem to be a few from the looks of it.
  • Compiler warning: possibly uninitialized variables. In the cases checked the variables will get initialized properly, but either it's hidden (e.g. via a function call) or done conditionally where the program flow will result in a proper initialization, but the compiler doesn't detect either (can't really, because it would need semantic information).
    • So far I have no idea how to tackle these without adding additional "overhead" by initialization, because most case s are valid code.

Further issues

  • (Unit-)Testing. From what I gathered the singleton handling is working differently on Linux and Windows thanks to the way how dynamic libraries are handled. As some tests rely on how this works the Windows-way either the tests need to be matched against Linux or some solution must be found to emulate this behaviour. Question is, if the Linux way leads to bugs (see Snowballs assertion failure, caused by something like this?).
  • Find out differences between CppTest (which is used currently?) and CppUnit. Latter one seems to be newer, the question is, if both projects are "finished" or "discontinued" and maybe other testing frameworks are in use nowadays.
    • sfb is probably going to transition the stuff to CppUnit, although CppTest had (finally) an update mid december 2007.

Ideas

  • Documentation. ace and sfb wrote a few number of rough outlines, but they are by far not enough to get started without having to dive deep (which is time consuming). See below for one way how to approach this issue.
  • Tool support. Many tools are aimed at the Windows folks, e.g. modelers like 3DS and so on. First off these don't come for free, secondly I dunno if they run natively on non-Windows machines. Blender comes to mind here and would need a respective plugin to work together with NeL.
    • sfb fixed a few issues with the 3DMax plugin his team was using for the Werewolf project. There is ongoing work by others to fix the plugin further.
    • Basicly the task splits into two: A big handy tool to view and (partially) manipulate the object and world data and plugins for the various 3D modeling tools.
  • Create a MIDIMaze/netmaze clone (exclusively) with NeL, write all the steps down for documentation (kinda a small HOWTO/Introduction). This will teach myself in the process and hopefully others using the resulting docs to get their way shown around NeL.
    • This requires a (halfway) working toolchain in Linux, so this will take a while still.