MarkJ

Did you convert that code by hand, or did you generate it somehow? It's quite readable IMO.

I am guessing that this is something they will work on later, once they have the current version running. But nyerguds is right. I am guessing at least 95% of those jumps should be easily converted into high-level constructs. It doesn't look like the source was optimized too much flow-wise when it was compiled, so most of the structure is still fairly straight forward. If you want an example to see just how the compiler converted stuff, I suggest you grab a copy of the Wolfenstein 3D source code. That comes with a compiled version of the source which was compiled with the same compiler as Dune 2. So you have the compiled binary, a nice map file which tells you where everything is, and the source code itself.

This. Segra is pretty much the central intelligence of all things to do with Dune 2's internals.

Registered on your forum, and posted questions there :)

Fair enough about the legal issues. It's just that some developers seem kind of strict when people start poking around with their games, or making remakes, etc. It would be a shame to see the work and effort you have gone to halted by a 'cease and desist' order or somesuch. Yay for the age of litigation :). As for decompilation, I know what you are getting at. I am currently experimenting with decompilers (perhaps low-level to high-level translator is a better term) for c64 games :) My point was that most of the overlay segments in the Dune 2 executable seem to be just collections of functions like most other segments. So if you can decompile those, then why would it matter how the overlay manager works? As long as you can resolve function calls from non-overlayed segments to those in overlayed ones, then there wouldn't seem to be any real need to understand how exactly the overlay system does it's stuff. I suppose it's kind of like the C libraries. I am guessing that you didn't decompile those, and rather just identified where the functions were, and replaced calls to them accordingly. In regards to your generated source, it isn't really important how the C libraries were implemented in Dune 2, just that a call to the printf function actually does what printf is meant to do. I (and it seems everyone here) have no idea how overlays work, so my assumptions might be complete bollocks, but yeah, I would certainly be interested in seeing where the complications lie :).

Wouldn't decompiling then repackaging the generated source code open up a whole heap of legal issues in regards to the game? I am pretty sure the license agreements for most games specifically state that you are forbidden from reverse-engineering/decompiling the binaries. It's an ancient game, and to an extent, most of the work on these boards is based on the reverse engineering work of the community, but it seems different from decompiling the whole game, then releasing source. As for the overlays, I don't understand why that's even an issue. If you have generated the source code, why can't you just modify it and recompile it for a large or huge memory model instead of the resource limited DOS one. I would have thought that the overlay management code would have been fairly invisible (added by the compiler), or done through library calls.

Hey Nyerguds, I was wondering if it would be possible to implement a feature in your editor where you can compare a given field value for all structures/units at the same time. I have attached a screenshot from a dinky BASIC program I wrote quite a while ago to give you an idea of what I mean. Basically, lets say you have an unknown field, rather than having to go through all the units/structures to see how the value changes, you can just display that one field for all structures/units on the screen at once. It makes it easier to see patterns etc. Keep up the awesome work :)

What version of IDA do you happen to use segra? I would be interested in looking into the code myself :).

Hi, I have enjoyed playing dune 2 for quite some time, and I would like to have a stab at making some scenarios for it. I was wondering if there is any comprehensive document outlining the scenario format. Most of the format is fairly straight forward, and parts of the format are explained in the help files for some of the scenario editors that are available, but there doesn't seem to be any one place that covers everything. Anyway, I am still a little confused a number of things, so if no one can point out such a document, perhaps you could answer my questions. + What does the Choam section do? I know it controls availability of units from the starport, but I have no idea what the numbers do. + Have the win/lose flags been figured out at this point? + Any information on teams would be nice, as would reinforcements. + Any information on what undocumented features have been discovered (the extra reinforcement placement keywords for example). Also, I have noticed that there is an updated scenario pack available, which fixes a number of bugs within the scenario files (like the thopter misspelling). I was just wondering if there was any information about what specific fixes were made to the scenario files. Thanks in advance.