OpenDUNE Project News

[MrFlibble]

In a bit belated news, TrueBrain of the OpenDUNE development team has posted in the OpenDUNE Developer's Blog that the current stage of project development is nearing completion:

[P]rogress report:

 

Functions done: 1163 / 1229 (94%)

Functions named: 1180 / 1229 (96%)

 

That says most of it. We are nearly done converting all functions to real C (not my fake assembly-C). The functions that remain are related to sound, voice and music. It has little to do with OpenDUNE itself, so it slowly walks after us.

 

The rest of OpenDUNE is done. Including all the bugs, the weirdness and the exact identical behaviour Dune2 had. I am so proud When we started this project, I was hoping it would finish some day .. just never imagined it would. Makes me want to say HA! to all those pessimists who told us this was the wrong approach, that it would never be finished, that we should join (team up) with existing projects, ... Well .. for those I only have to say: HA!

 

There, I enjoyed doing that.

 

So, I am sure you now wonder: and now? Well .. a lot.

 

During our conversion, we kept the 16bit memory allocation. Its a pain. It does not allow for any extension in any way. So, the job that followed immediately after finishing conversion was: start moving the 16bit pointers to real pointers. This is not as easy as it sounds, as there are tons and tons of references in the 16bit world to structs and arrays. Simply moving them to the 32bit/64bit world causes many errors, because calls in the 16bit world can no longer see these objects.

 

A few days ago we managed to move out all UnitInfo, StructureInfo, TeamInfo and HouseInfo to the 32bit/64bit world, which was a HUGE milestone. Today we are very close to move Widgets out, which is around 80% of the work that has to be done for that. While at it we are also moving other variables and pointers from the 16bit world to 32bit/64bit when we feel like it, and the list of variables that needs doing is getting shorter and shorter.

 

The other thing we have been working on in parallel, as they kinda depend on each other, is dumping the information from Dune2.exe in a format we can work with, without needing Dune2.exe. In theory it would be possible to just read Dune2.exe on startup, read the information, and use it. But because there are many many pointers (which we would have to convert, which requires knowing where it used to point to), we decided to dump this information in plain C, in so called table-files. These are just files where you see endless variables defined for every entry. See for example:

 

http://svn.opendune.org/trunk/src/table/unitinfo.c?mode=view#filecontent

 

The content of the file is converted one-on-one from Dune2.exe 1.07EU. We simply parsed the information via a simple tool. So we start to depend less and less on Dune2.exe, which is only for the better

 

What else ... yeah, we named many more variables. And we also see a lot of unused variables. At least we know 100% sure they are unused now, as if not, we would have noticed by now (by the reason we converted everything Shall I say it again? We converted EVERYTHING).

The next public release of OpenDUNE is scheduled for August the 1st.

[Nyerguds]

...holy crap. That unitinfo file has stuff my editor doesn't have yet. They did an awesome job on this.

[Sonarpulse]

Wait, are they reverse engineering the entire program into C?

[Nyerguds]

Indeed. And succeeding too.

[Sonarpulse]

SHIIITTTT.  This is way cooler than openRA/freeRA/whateverRA in my book. go for the perfect clone, and then add new features.

 

How similar is the DUNE II engine to TD again? 

[Nyerguds]

C&C was completely rewritten, from the ground up. Some internal concepts are the same, and a few file types (WSA, CPS, and the Dune II SHP format used by C&C and RA's mouse cursor), but that's it.

[Sonarpulse]

Oh well, you're doing a great job with just debuggers+assembly, and the plethora of new features only doable with higher-level code are not needed for good old CnC

[Nyerguds]

Source would always be handy, but tbh, I don't know C++, and I DO know assembler

[Sonarpulse]

wow, you must be the only person left knowing assembly but not C++

[Nyerguds]

Meh. C# and Java are just so much easier.

[Sonarpulse]

true, but assembly's supposed to be the hardest of all

[Nyerguds]

I dunno. It's just, bytes. No rules, no conventions, just bytes

[pichorra]

For me Asm is pretty more easy than C++, i'm Studying Pascal, Delphi C# and ASM. i got a c++ book and i just "trow it away" =P

[Nyerguds]

Quite. I still don't quite get what those .h files are.

[Sonarpulse]

Ok, ok. I'd guess assembly is easy for stuff that works well with it--procedural programming or whatever. Then you hit a wall and everything else is terribly unintuitive.

[Nyerguds]

Well I'm not going to make any new function-containing object classes with this, no... but I don't need to, either. The object function calling system is confusing as hell when viewed in assembler (especially with subclasses). It basically takes the object, then takes the reference to its table of functions (which is always the start of the object), and then just says "execute function #12" or something by adding 4*12 to that table address (4 bytes = one 32-bit address for each function in the table).

 

What this boils down to is that all you see is "call [eax+30]" instead of having any real clue what function it goes to. The only way to find out for real is by debugging X_x

 

 

I don't need stuff like that for what I'm doing. If I have to call a function, I'll call the function directly. Not like I'll be making subclasses and stuff like that.

[ShadowDog]

Quite. I still don't quite get what those .h files are.

Basically, C/++ doesn't scan the .c files for functions. The following code isn't valid, IIRC:

 

void main()
{
stuff();
return 0;
}

void stuff()
{
//Lol
}

 

The compiler can't find stuff(). Yeah. So you have to specify that it exists. Technically, you could just go "void stuff();" above main(), but most people use header files. Even smarter people use C# instead, because A. you can put code pretty much anywhere once you find out about partial classes, and B. CLI/CLR is fast. Admittedly, programs running on it are generally slower, but that's because most graphical solutions involve C/++ wrappers.

 

Nyer, this has gotten me interested in that disassembler program I was talking about again. I'm seriously going to look into it now.

 

EDIT: The idea being that I could write a disassembler like the one OpenDUNE uses, only C# instead of C/++, x86 instead of... DOS stuff, and probably commented instead of working out of the box. Seriously, I know it's an unmanaged language, but HTF did they get that working? Fake X, Y, etc.?

 

EDIT2: Oh, emulated memory. Then how do they convert things to C while still having it interface w/emulated memory? I'll have to read the code in a few minutes.

[Nyerguds]

I'm seriously not getting into the DOS memory stuff

 

I don't think that description of the .h files is correct though... I got a small C program that's nothing but a single .c file. If I remember correctly the .h files are needed for making methods public to other classes, or something like that.

[Iran]

Well I'm not going to make any new function-containing object classes with this, no... but I don't need to, either. The object function calling system is confusing as hell when viewed in assembler (especially with subclasses). It basically takes the object, then takes the reference to its table of functions (which is always the start of the object), and then just says "execute function #12" or something by adding 4*12 to that table address (4 bytes = one 32-bit address for each function in the table).

 

What this boils down to is that all you see is "call [eax+30]" instead of having any real clue what function it goes to. The only way to find out for real is by debugging X_x

 

 

I don't need stuff like that for what I'm doing. If I have to call a function, I'll call the function directly. Not like I'll be making subclasses and stuff like that.

those are the wonders of virtual tables!

[Nyerguds]

well they're obviously a handy system for method overrides in subclassing... but still, annoying for researching an exe

[MrFlibble]

...holy crap. That unitinfo file has stuff my editor doesn't have yet. They did an awesome job on this.

TrueBrain mentioned immunity to deviation in his post, what else is there that we did not figure out? I haven't looked into the files yet.

[Nyerguds]

Well that was indeed the one that caught my eye.