afritz1 / OpenTESArena

Open-source re-implementation of The Elder Scrolls: Arena.
MIT License
988 stars 68 forks source link

Other open-source project to check #138

Closed Nodepad closed 5 years ago

Nodepad commented 5 years ago

Hello, several years ago I was working on translation of TES: Arena and make two open-source libraries based on my findings. Most of the stuff is already implemented here. But I thought you'll be interested in LZSS-based and DEFLATE-like algorithms of image compression (I couldn't find it in this repo) and text relocation table of EXE file v.1.6. Also I could find some of my ASM listings of executable v.1.6 if you're interested.

TESA EXE Translator TESA Resource Lib

afritz1 commented 5 years ago

Thanks for stopping by. It's interesting that you have several algorithms for reading Arena's data. I wonder how many other people out there have also done similar work? (at least a few I know of, like for WinArena, BSATool, etc.).

I believe my engine is able to load all of Arena's image formats now, so the image decompression methods should be fine as they are. The person who implemented support for type 8 images did leave a comment here though about it seeming like a DEFLATE algorithm.

So the text relocation table is for translating the text in the executable to another language? I saw in your EXE translator project that it reads the text then sends it out to an XML file where it's then translated and put back into the executable? Is that right? My ExeData class is essentially the same as your exe.xml file; it reads in most of A.EXE's text and constant data into memory at runtime. I make sure to do it this way so I don't distribute any of Bethesda's intellectual property in releases. I still need to add support for the CD version's executable.

By ASM listings, do you mean decompiled code? I tried looking into it a couple years ago with a decompiler but it was mostly gibberish and I couldn't make any sense of it. Since then I've been following clean-room implementations with other people and just trying to load Arena's data "the right way" when implementing features. Again, that's mostly to avoid IP issues.

Nodepad commented 5 years ago

Thanks for pointing out on algorithm implementation. I've missed it because was looking into Compression.cpp.

About EXE translator, I've created a patch which allows to draw fonts in range of 0x21-0xFF instead of 0x21-0x7F, which helped me with translation. The exe.xml contains strings and pointers to them, so it allows me to relocate all strings within executable and change their length.

Yeah, I've some decompiled and decrypted code, which helped me with translation. Maybe the main thing you could be interested in is player struct description which is used in save files.

afritz1 commented 5 years ago

The save data implementation is partially complete, and much of the current progress is thanks to @Carmina16's documentation work in the wiki. There's a treasure trove of information in there and I'm working through implementing each piece of it as I have time. If you think anything in the save data formats (or anywhere else you're interested in looking) is incorrect or out of place, feel free to mention it here and I'll revise it. One example would be anything called "unknown" in ArenaTypes.h.

Nodepad commented 5 years ago

I've checked wiki. And it seems that you've done a remarkable job in unwrapping Arena's data structure. 😀 There isn't much things which I could help you with. But still I found some missing data which you might find interesting.

NPCDATA

WORD Mana, MaxMana;
BYTE misc2;
BYTE face; // face index in appropriate CIF file
BYTE misc3[2];
INVENTORYITEM Inventory[40];
...
WORD StatusFlags;
// 0x01 - diseased
// 0x02 - poisoned
// 0x04 - cursed
// 0x08 - blessed
// 0x10 - fortified
// 0x20 - drunk
// 0x40 - paralyzed
// 0x80 - regenerating
// 0x200 - being drained
...
WORD ActiveEffects;
// 0x01 - invisible
// 0x02 - a non-target
// 0x04 - resistant to fire
// 0x08 - resistant to cold
// 0x10 - resistant to shock
// 0x20 - resistant to acid
// 0x40 - resistant to poison
// 0x80 - levitating
// 0x0200 - silenced
// 0x0400 - able to absorb spells
// 0x0800 - able to reflect spells
// 0x1000 - resistant to spells

SPELLDATA Not quite sure about those ones, just old notes. Probably depends on spell type.

WORD Param0[3]; // Spell damage range start (chance)
WORD Param1[3]; // Spell damage range end (chance)
WORD Param2[3]; // Spell damage increase range start
WORD Param3[3]; // Spell damage increase range end
WORD Param4[3]; // Number of levels to spell damage increase (chance)
WORD Param5[3]; // Number of uses to spell damage increase
BYTE TargetType;
Nodepad commented 5 years ago

INVENTORYITEM

...
BYTE Hands; // Also # of charges left (could be wrong because there is `Health` field)
...
WORD Health; // Also amount of money left for King Orgnum's coffer
WORD MaxHealth; // Also # of max charges
DWORD Price; // Repair cost * Repair time is related to this field.
...
afritz1 commented 5 years ago

Thank you for adding these here. I'll try to get to them soon. I've been distracted with my renderer improvements for the past few days.

afritz1 commented 5 years ago

Added.

afritz1 commented 5 years ago

Looks like this issue can be closed.