Posted: Tue Dec 06, 2016 2:22 am
A user on another forum asked about a place for general Phoenix discussion, so I decided to open such a thread here.
All about and for EFS
TKComposition wrote:I found Phoenix to be inspirational as well and have been slowly coding a clone and keeping a log of what I've learned so far... Someone once encouraged me to keep pressing on to getting to something playable,
mastnosis wrote:Is there still any interest in this project. I've tried contacting the developers of both Phoenix and the EFS Editor direct via email with no responses.
mastnosis wrote:I'm creating a JavaFX interface for the game. I've created a utility for reading in the Galaxy.gal file based on the source code, but there are definitely questions I have about some of the variables. I would prefer to have documentation that describes the byte format in detail. For instance why is the planet map info 44x65 instead of 44(width) x 32 (height). Especially the 65, at least 64 would be twice the height. In the source code it appears half the data is thrown away and the 65th row is discarded entirely. In the half that is thrown away, while most of it is zero some of it is not, so there must be some information encoded there that is being ignored.
Has anyone else viewed the source?
mastnosis wrote:Ok, I fully decoded the planet terrain data. The format is 4bits terrain (16 possible 10 used), 5 bits graphics index (32 possible, number available depends on terrain). These can be stacked up to 3 deep. Top terrain is in the lowest bits, bottom terrain is in the high bits.
The programmer on Phoenix had to hand craft the map data rather than using the index which must have required a herculean effort.
mastnosis wrote:Another oddity related to the above is that resource information is stored in the following hex. What I mean by this is that if you see a "fertile" or "metal" icon, in a hex, the resource data is in the following hex RES:TERRAIN pair.
mastnosis wrote:I have to admit myself, I'm quite conflicted on Phoenix. On the one hand I'm quite impressed with what it has accomplished so far, but it is clear by reading the code that the author is a self taught coder (which I applaud). The design violates practically every 'best practice' I know which makes it hard to jump into and contribute.
mastnosis wrote:For now I'm just focused on creating a functional UI in JavaFx with no game logic attached. I can read the GALAXY.GAL file and load PCX and BIN image formats. I'll decide later if it is quicker to tack it on Phoenix or rewrite from scratch. I'm more likely to help with Phoenix if I can get hold of the developer but both email addresses I found bounced and no longer seem valid.
I don't recall receiving such email recently, but this would not be the first time the internet has eaten emails. When I collaborated with Richard Wein three years ago no emails he sent from his address arrived at gmail.com and I had to use another address ... also, I've been distracted IRL recently and am slowly returning to work on the project.
It seems that the data is stored so that when viewed as 44x65 table it appears somewhat like in a hex map, every even numbered column (starting from zero) is offset downwards by one position like in the following picture where X is hex data and O unused/garbage bytes and 65th row is unused.
There is also some strangeness with the x,y positions of the units and cities, the y position ranges from 0 to 63 (instead of 0 to 31 as expected) with even rows having odd column numbers and odd rows having even column numbers (in Phoenix the y's are converted to 0-31.) It's been 3.5 years since I took a serious look at the planet maps on a bit-level, so the correctness of my memories may be in question ...