Tools: C++ || Java || C#

[silnarm]

I've been thinking about modding tools a bit.  In hacking the G3d viewer a bit I got somewhat familiar with wxWidgets, it wasn't long before I started looking for alternatives...

The contenders:

C++ with wxWidgets
Pro: Is what the existing tools were written with.
Pro: No need to port any code to a new language.
Con: Looks suspiciously like a multi-platform version of MFC.
Con: system for specifying callbacks is really clumsy.

Java
Pro: Top of the class for platform neutrality, and a very popular programming language in general.
Con?: Unsure of the status of OpenGL bindings (and have no intention of supporting a second 3D api)
Con: No delegates

C# with OpenTK and Winforms
Pro: The Visual Studio forms designer (don't underestimate this!).
Con: mono.winforms has some quirks

C# with OpenTK and Gtk# + Glade
Pro: Top notch platform neutrality.
Con: Gtk (noun): world's largest collection of deprecated and obsolete functions

C++ with FLTK2 + FLUID
Pro: Is C++, no porting of the shared lib would be needed
Pro/Con?: Contains a very simple and interesting looking system for callbacks, maybe somewhat limiting, or maybe a stroke a genius.
Con: ?? Haven't actually played with this yet, it looks ok, but there are bound to be an issue or two.

So, those are my thoughts on the contenders thus far.  I'm leaning toward C# with OpenTK & Gtk#, I like C# as a programming language, and OpenTK gives gives us access to OpenGL + OpenAL, and seems to work well.  I've already converted a fair portion of what is needed from the shared lib into C# with OpenTK while playing with OpenTK.

Gtk I have only started messing with a couple of days ago.  Using online references if incredibly painful, there seems to be more deprecated functions than not, and the proper way to do things now is to use Pango for the layout and rendering of text, and Cairo for drawing.  This leads to weird and ugly kludges to pass information around, ie, your Gtk widget's area is given in a Gdk.Rectangle (all ints), but when drawing you need to know this as a Cairo.Rectangle (all doubles).  Colours are similarly cumbersome (Gdk.Color has byte components 0-255, Cairo.Color uses doubles with values from 0 - 1).

So, I'm somewhat torn... hopefully Gtk will seem less like a kludgey pile of crap with time...

Anyway, enough of that little digression, if anyone would like to suggest other contenders, or add pros/cons to existing contenders, or just argue with some of the pros/cons I listed... fire away!

[assassin]

Well, personally I'd avoid c# (microsoft! boo!), and I'd stay with c++. I'd look into FLTK2 + FLUID some more, and if it sucks, then use wxWidgets.

[hailstone]

Another option to look into could be a scripting language such as python.

It has quite a few bindings, IDEs and WYSIWYG tools for GUI development. The opengl speed is hopefully sufficient for tools. Also might not need to rewrite parts of C++.
http://wiki.python.org/moin/GuiProgramming
http://pyopengl.sourceforge.net/
http://wiki.python.org/moin/IntegratingPythonWithOtherLanguages

[Yggdrasil]

So your main problem with the current tools is the used toolkit, wxWidgets? And there mainly the callbacks?

I would rather stick with it and certainly not switch the programming language. That's not worth it.

Regarding the callbacks: wxWidgets supports two "systems". Atm we use the macro event_table, but there's also a Qt-like connect-function:
http://wiki.wxwidgets.org/Events#Using_Connect.28.29

FLTK callbacks are just plain function pointers with one void* as argument. Need to cast your way to get the actually arguments which can be quite error prone. The library is really small, good for static linking.

If i have to do gui stuff i use mostly Qt which is quite nice. It has all the tools you need: Designer for drag&drop your layout, Linguist for helping you translating all the strings and even an IDE QtCreator.
The callbacks there are called signals and slots, and they're easy to use. Be aware that it is using non-standard c++ and therefore needs a special precompiler called moc (meta object compiler). Not a big deal to setup (e.g. cmake provides a macro).

[silnarm]

Well, personally I'd avoid c# (microsoft! boo!), and I'd stay with c++....

C# is a programming language, invented by the folks in Redmond, yes, but just a programming language.

Another option to look into could be a scripting language such as python.

Python as a programming language is an option, but we'd still need to chose a GUI toolkit.... there seem to be quite a few...

Regarding the callbacks: wxWidgets supports two "systems". Atm we use the macro event_table, but there's also a Qt-like connect-function:
http://wiki.wxwidgets.org/Events#Using_Connect.28.29

AHH! That's more like it... I indeed was not aware of this...

I would rather stick with it and certainly not switch the programming language. That's not worth it.

Well, I'd have to disagree somewhat.  C++ is not ideal for tools, and the existing tools are not exactly anything to write home about, I'm certainly not concerned about ditching them and rewriting them in Java or C#, and either C# or Java would be a much better choice in my opinion (I want good tools, but I'd rather spend as little time as possible making them).

That said, I'll certainly be playing with wxWidgets again, without all that crappy EVENT_TABLE nonsense, and I'll probably at least experiment with FLTK2 some.  I was avoiding mention of Qt, it's another C++ solution which I don't like, wxWidgets I'm considering for obvious reasons, and FLTK because it's small and looks like it might be very easy to use.  Qt's signals and slots is nice, although the method by which they added them does suck somewhat (the C++ extensions & the pre-compile compile).

[titi]

If you want to write tools in another non C-based programming language you will face some serious problems with reading/converting data.
Glests formats are all C-structs or types written directly to a file. Reading these data is really hard ( alignment ... )!
I had these problems too when I started with jglest. I decided to write C-based native c-converters to create xml-formats for all the things I use. C# will have the same problems and by the way, I don't like it too ( microsoft .... )!
I would stay with wxwidget too.

[silnarm]

Glests formats are all C-structs or types written directly to a file. Reading these data is really hard ( alignment ... )!

Just read (or write) them one by one into your Java/C# structure.

C# will have the same problems ...

I extended System.IO.BinaryReader, adding a few convenience functions, the Java equiv is (I think) DataIputStream

Code: [Select]

public class BinaryStream : BinaryReader {
public BinaryStream(Stream s) : base(s) {}

public Vector2 ReadVector2() {
Vector2 res;
res.X = ReadSingle();
res.Y = ReadSingle();
return res;
}

public Vector3 ReadVector3() {
Vector3 res;
res.X = ReadSingle();
res.Y = ReadSingle();
res.Z = ReadSingle();
return res;
}

public void Skip(int n) {
if (n > 0) {
ReadBytes(n);
}
}

public void ReadVector3Array(uint n, out Vector3[] array) {
array = new Vector3[n];
for (int i = 0; i < n; ++i) {
array[i] = ReadVector3();
}
}

public void ReadVector2Array(uint n, out Vector2[] array) {
array = new Vector2[n];
for (int i = 0; i < n; ++i) {
array[i] = ReadVector2();
}
}

public void ReadUInt32Array(uint n, out UInt32[] array) {
array = new UInt32[n];
for (int i = 0; i < n; ++i) {
array[i] = ReadUInt32();
}
}

public string ReadFixedString(int n) {
byte[] raw = ReadBytes(n);
string str = "";
for (int i = 0; i < n && raw[i] != 0; ++i) {
str += (char)raw[i];
}
return str;
}
}

I don't even attempt to have my model/mesh headers aligned properly, you just have to read them in order..

Code: [Select]

struct MeshHeaderV3 { // version 3
// property flags
public const int PropNoTexture = 1;
public const int PropTwoSided = 2;
public const int PropTeamColour = 4;

// data
public UInt32 vertexFrameCount;
public UInt32 normalFrameCount;
public UInt32 texCoordFrameCount;
public UInt32 colorFrameCount;
public UInt32 pointCount;
public UInt32 indexCount;
public UInt32 properties;
public string texName;

// read header
public void Read(BinaryStream stream) {
vertexFrameCount = stream.ReadUInt32();
normalFrameCount = stream.ReadUInt32();
texCoordFrameCount = stream.ReadUInt32();
colorFrameCount = stream.ReadUInt32();
pointCount = stream.ReadUInt32();
indexCount = stream.ReadUInt32();
properties = stream.ReadUInt32();
texName = stream.ReadFixedString(64);
}
};

I'd recommend you do the same for jglest.  You don't want to be loading models from xml.

I know it's trendy to bag microsoft, and I can assure you I'm not their biggest fan either, but I'm not going to ignore a potential tool because microsoft invented it, C# has been standardised, that's good enough for me.

[Omega]

I'd prefer C++ (though I don't really know java or c# much, though c++ is supposedly slightly faster). I'd definately recommend wxWidgets, having tried it a few times, and it's simple enough to use (the challenge was configuring it for windows).

[titi]

I think binary reading is only possible with native code...

there are problems like:
http://en.wikipedia.org/wiki/Endian
and alignment problems:
http://en.wikipedia.org/wiki/Data_structure_alignment

Maybe the C# thinks can work around some of these problems, but they cannot fix everything. Its simply a very bad idea to store binary data this way. Xml is something that can be read by everyone/everything but its a bit big :/ and has a lot of overhead.
XDR-encoding might be a better way:
http://en.wikipedia.org/wiki/External_Data_Representation  ( by the way, why it is not mentioned in the english wikipedia, that this was invented by sun microsystems ? ? ? ? ? ? )

And for the MS bashing :   C# may be well described and standardised but they do everything they can do (software patents!) to keep it on windows only. See the problems the Mono project has, sometimes they are not allowed to implement something .... 

[silnarm]

I think binary reading is only possible with native code...

This is not even remotely true.

That model was loaded direct from the g3d file.

there are problems like:
http://en.wikipedia.org/wiki/Endian
and alignment problems:
http://en.wikipedia.org/wiki/Data_structure_alignment

These are non-problems, they are very easily overcome.  If you are going to continue with jglest, you are going to have to bash bits at some point, get used to the idea.

Maybe the C# thinks can work around some of these problems, but they cannot fix everything. Its simply a very bad idea to store binary data this way. Xml is something that can be read by everyone/everything but its a bit big :/ and has a lot of overhead.

Yeah, the overhead is going to kill if you are loading 3d models from text files.  Load one whole faction that way, you'll soon be looking at loading the binary files.

XDR-encoding might be a better way:
http://en.wikipedia.org/wiki/External_Data_Representation  ( by the way, why it is not mentioned in the english wikipedia, that this was invented by sun microsystems ? ? ? ? ? ? )

If you wanted to be completely platform neutral this does indeed look promising.  Given that the only port to mac is, apparently, buggy and the author seems uninterested/unwilling to fix it, I wont be bothering just now.

And for the MS bashing :   C# may be well described and standardised but they do everything they can do (software patents!) to keep it on windows only. See the problems the Mono project has, sometimes they are not allowed to implement something ....

Probably stuff related to that passport crap, none of which is of any interest to me...

Do you fear that Microsoft will change the spec and render Mono useless?

No. Microsoft proved with the CLI and the C# language that it was possible to create a powerful foundation for many languages to inter-operate. We will always have that.

Even if changes happened in the platform which were undocumented, the existing platform would have value on its own

The solution of C# + Gtk# is in absolutely no way tied to microsoft. It would even have the Gnome look and feel!

[Loronal]

Well, personally I'd avoid c# (microsoft! boo!)

you took that out of my mouth