afritz1 / opentesarena Goto Github PK

OpenMW has a very useful command line argument to start the game in such a way that skips the menus and drops you straight into a default cell with a default character. This is a pretty useful tool and would be helpful for OpenMW as well to quickly test new gameplay functionality, and would be a welcome addition as well.

I decided to test the behavior of Arena's XMI music files in the program's current state. I tested them all as the opening music on program startup. Below are notes for each one. See issue #29 for related discussion.

I used freepats.zip and wildmidi.cfg for the MIDI patches and config file. wildmidi.cfg seems identical to freepats.cfg, though. WildMIDI version is 0.4.0.

Here are music files that play fine:

• ARABCITY.XMI
• ARABTOWN.XMI
• ARAB_VLG.XMI
• CITY.XMI
• COMBAT.XMI
• CREDITS.XMI
• EQUIPMNT.XMI
• EVIL.XMI
• EVLINTRO.XMI
• MAGIC_2.XMI
• OVERCAST.XMI
• PALACE.XMI
• PERCNTRO.XMI
• RAINING.XMI
• SHEET.XMI
• SNEAKING.XMI
• SQUARE.XMI
• TAVERN.XMI
• TOWN.XMI
• VILLAGE.XMI
• WINGAME.XMI

Here are music files missing at least one instrument (usually choir and/or xylophone):

• DUNGEON1.XMI
• DUNGEON2.XMI
• DUNGEON3.XMI
• DUNGEON4.XMI
• DUNGEON5.XMI
• NIGHT.XMI
• SNOWING.XMI
• SWIMMING.XMI
• TEMPLE.XMI
• VISION.XMI

Here are music files with a long pause at the end:

• OVERSNOW.XMI (~4-5 minute pause)
• SUNNYDAY.XMI (several hour pause)

Nearly all of the music files have some kind of trouble at the end for a split second; either getting cut off, playing white noise, or playing clicks before starting over. Is this caused by the original XMI files, or how they're being interpreted? I would understand if the original files are just plain incorrect at some parts to begin with.

Why are some instruments missing? Is it because the freepats indices are incorrect? Or because WildMIDI is not reading XMI properly (I thought 0.4 fixed this)?

@kcat and @psi29a, your thoughts?

Edit: The missing instruments are because freepats lacks them. Using eawpats instead with gravis.cfg seems to be satisfactory for Arena.

This project currently has Windows and Linux builds for each release. I'd like to see macOS releases as well so that I can run OpenTESArena on my preferred platform.

The code seems to be littered with constructs like
auto var = type();
and
auto var = static_cast<type>(value);
These serve no functional or practical benefit, and actually just result in obfuscating what's going on (and in some cases, can actually impact performance since it's constructing a temporary of the given object type then copy-constructing the real object with it, rather than constructing the object in-place). The same thing can be written as
type var;
and
type var = value; or type var{value};
which is just as type-safe, and is more clear, with what it's doing, along with being shorter.

I'm not suggesting to go through and change them all right away, but I would suggest changing them as you work on code around where they appear.

I've also noticed a number of redundant pointer checks, where you new an object into a unique_ptr container, then assert that the unique_ptr has a non-null pointer. By default, new will never give back a null pointer and will only fail by throwing an exception, so the pointer is never set. It can give back null if you use new(nothrow) type, but that's not (and generally shouldn't be) used. Again, I'm not suggesting to go through and change it right away, but I would suggest removing such checks as you work on code around where they appear.

Mostly a suggestion as projects can easily get to a point where inline documentation would be vastly helpful, and the commenting format Doxygen requires is pretty natural so there's the added side benefit of being able to generate HTML documentation from your programming.

This issue can basically just be summed up as "header documentation", really. At the least, requiring the use of Doxygen compatible comments standardizes the code a little bit more. I'm also just personally obsessed with documenting the crap out of everything I write.

Here's a pretty decent example of it in action.

A quirk of the original game, along with a number of other games from the same era, is that even though they used a 320x200 (16:10) video mode, it was intended for fullscreen display on 4:3 monitors. This resulted in the scene being viewed with non-square/"stretched" pixels. For modern systems which use square-pixel video modes (framebuffer aspect ratio matching the monitor aspect ratio), this requires screen elements to be stretched vertically by a multiplier of 1.2. Both UI elements and the world projection matrix need to include this stretching to appear as they originally did, on top of any letterboxing or pillarboxing.

See here for more information (for the original Doom, but the same applies to Arena as they both used stretched 320x200 on a 4:3 display).

If I run the game with MIDI active, it crashes when I click "Start New Game."

Specifically, if I have eawpats.zip extracted into the Data folder, the game starts and plays MIDI, but crashes when I click Start New Game. If I don't have eawpats in the Data folder, the game doesn't crash.

assert(mSource != 0) in OpenALStream::init() fails when GameState::tick() is called the first time.

The mSongStream.reset(new OpenALStream(this, mCurrentSong.get())) function right before if (mSongStream->init(mFreeSources.front(), mMusicVolume)) in AudioManagerImpl::playMusic() seems to be the problem. It causes mSource to always be set to 0 in the OpenALStream() initialization list.

Could it just be that the mSongStream.reset() unintentionally sets mSource to 0?

In vanilla Arena, clicking on a land to choose a race gives you a choice asking if you're sure you want that race, and then several messages about your chosen race and class.

These do not currently appear in OpenTESArena. As soon as you click on a land, you go straight to the stat allocation screen without any messages.

The built-in palette in AUTOMAP.IMG is supposedly the intended palette for the quill cursor POINTER.IMG, but it causes the cursor's pixels to all be black (treated as transparent by SDL). Other built-in palettes like in BLAKMRSH.IMG and BUYSPELL.IMG don't make the cursor invisible (though they're far from the correct colors), so I have a feeling that the palette in AUTOMAP.IMG is somehow a special case.

See these for some relevant code:
AutomapPanel.cpp#L128
IMGFile.cpp#L226
TextureManager.cpp#L168

The default palette PAL.COL is used with the quill cursor for now as a placeholder.

I gave a fast look into the .DAT files listed as todo in the Projects page. Those are basically lists of zero-terminated ASCII strings.
Sadly I didn't really play the original game a lot, so I can't tell exactly what part of the game they are related to.
All files seem to use the BEL character (0x0A) as a sort of line separator.
I'm attaching text files of the dumped strings, you can find the simple script i used at https://gist.github.com/andreaukk/e5fe01d61d9e38887e18328da19e8dda

ARTIFACT1/2.DAT files contains in some points the byte sequence 0x21 0x00 0x21 0x00 (which i guess is a separator between chunks of strings) and appears in text files as two consecutive strings consisting in a single exclamation mark.

Similarly MUGUILD.DAT uses the byte sequence 0x3F 0x00 0x3F 0x00 0x3F 0x00 0x3F 0x00 0x3F 0x00 0x3F 0x00, which appears as six consecutive strings consisting in a single question mark in the text dump.

NAMECHNK.DAT is different from the other files (also contains non-ascii bytes), and needs further investigation.

Guess I will need to play the game a bit to be able to gather more info.

ARTFACT1.DAT.txt
ARTFACT2.DAT.txt
EQUIP.DAT.txt
MUGUILD.DAT.txt
SELLING.DAT.txt
TAVERN.DAT.txt

A small portion of IMG files, like LABRINTH.IMG, have some black pixels scattered around where they should not be. Could this be from char overflow?

OpenTESArena writes warning messages, error reports, and other information to the console via the Debug class. This has several major downsides:

• Console output is not visible when running as a macOS app
• The information is not recoverable if the app is shut down before the user is finished reading it
• It is more difficult for end users to submit information about what was happening before a bug was encountered

I recommend that we write all of this console output to a log file in order to solve these problems. We can still write to the console as well if desired.

Unfortunately, there isn't an SDL_GetLogPath() or anything. The recommended log locations for each platform are:

• macOS: ~/Library/Logs
• Linux: /var/logs/
• Windows: AppData*\MyCompany\MyApp (where * is Roaming, Local, or LocalLow.

We would need to determine the proper location based on the platform.

I have some data on the MIF/RMD formats; are you interested?

At some point in the future, the 3D rendering API should be switched from OpenCL to Vulkan. This is because the OpenCL API does not provide a link to any display device by itself, so the resulting color buffer must either be sent back to main memory for updating the SDL_Texture frame buffer with each frame (which is slow), or shared with another API like OpenGL through interop and drawn as a quad.

Vulkan is a more interesting choice than OpenGL interop in my opinion, and I believe it provides a kind of future-proofing as well. Since Vulkan is both a graphics and compute API, the ray tracing can occur on the render device and the results can be sent straight to the screen without any interaction with main memory, which would be a big plus for performance.

Problem:
When compiling under Windows (7 and 8.1) with MSYS2 the following error occurs:

.../OpenTESArena/OpenTESArena/src/Media/AudioManager.cpp: In member function 'void OpenALStream::play()':
.../OpenTESArena/OpenTESArena/src/Media/AudioManager.cpp:235:30: error: 'mem_fn' is not a member of 'std'
   mThread = std::thread(std::mem_fn(&OpenALStream::backgroundProc), this);
                              ^~~~~~
.../OpenTESArena/OpenTESArena/src/Media/AudioManager.cpp:235:30: note: suggested alternative: 'mem_fun'
   mThread = std::thread(std::mem_fn(&OpenALStream::backgroundProc), this);
                              ^~~~~~
                              mem_fun
mingw32-make[2]: *** [OpenTESArena/CMakeFiles/TESArena.dir/build.make:2614: OpenTESArena/CMakeFiles/TESArena.dir/src/Media/AudioManager.obj] Error 1
mingw32-make[1]: *** [CMakeFiles/Makefile2:141: OpenTESArena/CMakeFiles/TESArena.dir/all] Error 2
mingw32-make: *** [Makefile:84: all] Error 2

Current solution found:
This was easily fixed adding #include <functional> to the file.
Some googling suggests this is normal and the error only occurs on some compilers.
After that, the game compiles and runs correctly.

env:

• Toolchain: mingw-w64-x86_64-gcc 7.1.0-2
• OpenAL: 1.18.0
• SDL2: 2.0.5
• WildMidi: 0.4.1

For the program's icon, I've just been using the one that comes with the CD version, but I think it'd be neat to have a new custom-made icon instead. If anyone's a particularly good artist, maybe we could have a couple different designs done and then we'd choose the best one. I imagine most artists don't have a GitHub account, so I'll ask around.

The final icon would be submitted somewhere (like Dropbox?) in .png and .ico format. The dimensions should be something like 48x48 or 64x64.

Here's the current one for reference. It's from the CD version, just a clip of the front cover. The new one could be something completely different if we wanted.

Some initial thoughts I had (just to ballpark it):

• A remake of the mage on the front cover
• A remake of the helmet on the world map
• A remake of something iconic from one of the main quest dungeon splashes (like Fang Lair or the Crypt of Hearts)
• Maybe transparency in the background

The default cursor scale in the Options.txt file is 2.0, which makes a pretty small cursor. I found that a value of 3.6 seems to recreate the size of the cursor in the original game. Personally I like this size because it fits with the pixel size of the rest of the graphics. You might want to make this the default or at least comment on it in the file, like you do for how to recreate a 4:3 aspect ratio.

As per commit 309ee0d, I added a fallback to software rasterization in the SDL initialization. This is because on my machine here, I couldn't initialize with the hardware rasterizer for one reason or another and it was a general fix in the meantime until the reason why could be investigated.

This is more or less a note so that I don't forget or for someone else to look into the issue if I don't get to it in the meantime.

The affected machine is:
OS: Linux Mint 17.3 AMD64 (using KDE4)
Compiler: GCC 4.8.4
GPU: Radeon R7 360 w/ fglrx

If your machine is afflicted, you'll see this in your stdout output when running the game:

Renderer: Failed to initialize with hardware accelerated renderer, trying software.

That machine actually no longer quite exists, it is now running an NVidia GTX 750Ti with blackbox NVidia drivers in place of the Radeon, I need to try running the project on that when I can to see what the results are.

Edit The initialization issue also exists with the NVidia drivers here. At the least, the project shouldn't be terribly CPU heavy given that the only rasterization its actually doing is GUI and rendering the output from the OpenCL rasterizer as a texture underneath but it would be nice to work out why it might not be using hardware acceleration on a machine that clearly can provide it.

It also fails to actually spool up the OpenCL renderer, but that's another issue totally unrelated, likely mostly due to my switch from AMD to NVidia and still using the AMD OpenCL libraries.

The PERCNTRO.XMI music can be heard on startup, but upon clicking "Start New Game", "Exit", or the "X" to close the application, Visual Studio breaks in the ~WildMidiSong() destructor.

Could this be a WildMIDI issue with closing .xmi files? I am using WildMIDI 0.4.

I've linked my project with Travis CI, and all I need now is the .travis.yml file, but the examples I've seen so far have more scripts and extra things in them than I currently need, and it's a bit confusing.

Could someone give an example below? I'm looking for something along the lines of:

language: cpp
os: linux
compiler: gcc
before_install:
- sudo apt-get install libsdl2-dev
- sudo apt-get install libsdl2-image-dev
- sudo apt-get install libopenal-dev
- sudo apt-get install libopencl-dev
- sudo apt-get install wildmidi

or

language: cpp
os: linux
compiler: gcc
script: cmake ...

I'm not sure what all is needed, though.

Sound triggers don't always fire in original Arena, but they do in OpenTESArena. I tested with the drip sounds in the starting prison cell.

OpenTESArena assumes that options/options.txt will be in the same directory as the executable. This will not be a long term solution. On Windows if we install this app in C:/Program Files, users may be unable to edit this file without administrator rights. Furthermore, Mac applications in .app format cannot edit files contained within themselves, and non-admin users generally cannot edit them at all. And of course, if two users on the same computer want different settings, they would be overwriting each other's changes.

Every user has a preferences location that they are guaranteed to be able to write to. I suggest that we bundle a copy of options.txt, then the app copies it to the user's preferences location (if it doesn't already exist there), then reads from that location. This is exactly what projects like OpenMW use for their preferences.

The preferences location can be found with SDL_GetPrefPath(), which takes the organization name and game name as parameters. On macOS, it points to ~/Library/Application Support/OrganizationName/AppName/. As with SDL_GetBasePath(), we should be calling SDL_free() when we are done.

If we don't want to use an organization name, I suppose we could use "OpenTESArena" as the organization and "AppName" as whatever subdirectory we want to use. So SDL_GetPrefPath("OpenTESArena", "options") for instance.

The two LIBWILDMIDI_VERSION branches in WildMidiSong::read() seem to do the same thing. Are they intended to be different in the future?

The cinematic sequences (opening scroll, Ria Silmane, etc.) are currently black because the FLIC frame decoding is not complete. I took a shot at it, but if someone else knows more about FLIC files, then please take a look.

The public methods for the FLCFile class have been defined, so only FLCFile.cpp needs to be worked on. Each unique_ptr in the pixels member is created after decoding each frame, and each should point to a complete frame of the video.

Refer to any of the other image classes (.CIF, .IMG, .SET, etc.) for general style guidelines.

As the title says, FMOD will never be included into Debian (nor Ubuntu and most FOSS distros) because it closed source library. This makes things harder for the end user:
https://wiki.debian.org/FMOD

Why not use OpenAL-Soft instead?
http://kcat.strangesoft.net/openal.html

It is what OpenMW and others use and cross platform.

My game path is C:/Games/OpenTESArena and there is the installed 1.06 ARENA folder in the data folder as well as the eatpaws. The path seems to be the same as written in the options txt file too.

Console:
Game: Initializing (Platform: Windows).
KVP Text Map error: Boolean "false" must be either True or False.

Pressing enter closes the console so it doesn't seem like I could type anything.

I found that Debian and Ubuntu don't include FMOD as it is actually a closed-source library, so I will be moving in the direction of OpenAL-Soft soon instead.

For MIDI support, I'll use either WildMIDI or FluidSynth. I don't know if there will be any significant changes to the project's Ogg support when using OpenAL-Soft. In the worst case, all of the .ogg sound files would be converted to another (hopefully lossless) format.

How should I approach turning the components files into a static .lib in a portable manner? Should it be part of the CMake file so a Windows developer can build it automatically?

Edit: It looks like the static library instructions are already in CMakeLists.txt, but my CMake doesn't know where to find OpenAL at. Is there a standard "FindOpenAL.cmake" that should be added to the repository?

It was recommended on /r/linux_gaming here that I add a COPYING.txt file to the project to account for the GPL2 code in components/misc/fnmatch.{h,c} and MIT code in components/vfs/dirent.h.

@psi29a, could you offer some advice on this? I didn't know I needed to provide extra copyright information for people wanting to distribute binaries (I thought my releases page would be the only place for binaries).

This may already be in your longer-term plans, but I think it would be very useful for testing and reverse-engineering the original game data to be able to import native save game files from original Arena, as Daggerfall Unity can do with saved games from original Daggerfall.

There are some saved game editors on UESP for Arena, and these are useful for finding out how data is stored in the save files.

I don't have a Linux computer handy, and I'm not sure how much of an issue this is for Linux users, but the download link on the Bethesda website provides an install file named Arena106.exe, which is (clearly) a Windows executable.

This is essentially how the process is done on Windows:

• Download the Full Game
• Extract Arena106Setup.zip
• Run Arena106.exe
• Pick a destination folder (anywhere)
• Install

Is there an easy way for Linux users to use that file to install everything into a new ARENA folder? Maybe with DOSBox? What about Wine? I'm not familiar with Wine, so anyway I'm just looking for suggestions of things I could add to the install instructions in the Readme that would streamline this part for Linux users.

I've noticed that the project is keeping very clean compile logs in Travis-CI GCC builds, and also when building in Visual Studio. I decided to test running it with clang enabled, and quite a few warnings popped up.

https://travis-ci.org/Allofich/OpenTESArena/jobs/323518887

It may be worthwhile to double as a light review of your code, maybe you'll see some other things you'd like to fix up while addressing these.

If you want to add clang as a compiler from here on, you can simply add it to the "compiler" option in the travis.yml file.

I also looked at adding OS-X builds, but it looks like a little work would be required to figure out how to get the dependencies correctly. Just adding OS-X to the travis.yml file, it will fail due to OS-X lacking the apt-get command.

On https://docs.travis-ci.com/user/installing-dependencies/, it explains how to set this up by OS. The example is:
`install:

• if [ $TRAVIS_OS_NAME = linux ]; then sudo apt-get install foo; else brew install bar; fi`

and I was able to get past the error using this. But then, it still failed to download the dependencies. so we'd need to set it up to get appropriate OS-X dependencies. If it was all set up, in addition to adding another layer of checks on the code, it would be a step toward closing #74.

I've been fighting this a lot. The player classes dialog will sometimes show up with no classes to select, this includes if you navigate back (hitting escape) and going back to new game when it already worked.

The castle graphic in the Imperial City is incorrect.

The MIDI tracks PERCNTRO.XMI and SHEET.XMI loop over and over, but SUNNYDAY.XMI (in the game world) only plays once.

I appreciate your effort here, however I have some problems with your goals.

You're not remaking Arena, you're building something similar. But in doing so, you're missing some of the classic feel and design elements in the game itself. I am just going through the readme and would like to point these out. This isn't an attack on the project, which I love - but just pointing out that I would like to be able to play Arena and not an Arena-like.

I think you need to actually recreate Arena before you begin to add features from Daggerfall, since by not doing that you aren't creating an alternative to the original game but something different. The interface and combat for example, this is classic Arena/Daggerfall and a lot of people absolutely love it - WSAD and click to attack may be typical today, but the mouse movement and drag to attack is part of the charm of the games.

As well, altering the magic and class system defeats the purpose of them. Arena wasn't designed to give each class an equal chance of finishing the game, but was a way of creating more or less difficulty. Bethesda never intended the Healer or Burglar classes to be as easy as the Mage or Knight.

My point is that if you're going to be recreating the game, you should recreate the game before altering it, because a lot of those historic or archaic features that need to be 'modernized' are either there for a reason, or fan favourites.

In the Elden Grove (accessible from the main menu by selecting 40852494.MIF and pressing 'F'), there are some garbage voxels at the bottom of the map. If they are rendered by the camera, it causes an out-of-bounds texture access and the game crashes. I'm not sure why there is garbage since this is the only main quest dungeon that has it, and its dimensions are correct (100x100), so perhaps there is some exception in the .MIF file's FLOR or MAP1 data that the program isn't checking for.

I open this issue to request an ebuild (Package manager file) for Gentoo Linux

My intention is, if I have the time, to write such a file myself.

However, it's possible others may have the same desire as I do, so this issue can serve as a coordination area for doing that.

Ebuilds are different from a "normal" package file for Linux, such as Debian .debs, or Fedora RPMs, in the sense that an ebuild is a file that describes the process to download the code for a project, and compile it right then and there, and then install the result of compiling.

I noticed the left wall right at the entrance of the Fortress of Ice doesn't reach all the way to the ceiling in OpenTESArena. I went and checked in the original and the wall seems to go up all the way to the ceiling.

I would like to move the repository over to CMake so there's no more Visual Studio clutter lying around, and so other Windows programmers don't have to mess with my project files for their own computer.

I've been kind of avoiding CMake because it wasn't producing desirable Visual Studio files (i.e., just plopping all source files into one folder), so the CMakeLists files in the repo will need to have some more configuration done so they produce pretty VS project files in addition to Linux Makefiles, etc..

Maybe we could take some hints from the OpenMW or freeablo repositories. I'm not an expert on CMake, so help is appreciated!

Here's the general structure I'm envisioning. The new apps folder is there in case the repo ever has something else added, such as an Arena image viewer.

master:
  apps
    OpenTESArena
      Assets
      Entities
      Game
      ...
      Main.cpp
  cmake
  components
  data
  docs
  options
  samples
  .gitattributes
  .gitignore
  ...
  CMakeLists.txt
  icon.ico
  ...

The results of CMake would go in a new build folder, and that's also where the executable would go, along with a copy of data and options.

.travis.yml will also need to be updated with the new directories, etc..

Some general requirements for build rules:

• C++11, SDL2, OpenAL Soft, OpenCL, WildMIDI
• Some minimum required CMake version
• Preprocessor definitions (HAVE_WILDMIDI, _SCL_SECURE_NO_WARNINGS)
• Debug and release modes, x86 and x64
• Put solution/makefile in generated build folder
• Build "OpenTESArena" executable using code in apps/OpenTESArena and components (no more "TESArena" on Linux)
• Use icon.ico when building executable
• Copy data and options to build

Hi there, today I installed your 0.4.0 release and found that the game is going to be really nice!
So I would like to ask you (all devs.) if it is possible to build in some features /modifications in the future.

• Better movement: A and D keys will move the player to the direction instead of rotating the camera
• Camera improvements: possibility to move the camera using the mouse but also the keys Q and E.
  Also a optional possibility to move the camera 45 ° up and down -> this would add some immersion and make some things a bit easier. e.g. you can pickup this looking at the floor instead of standing meters away of them and have a better view on loot in general as well as the sky.
• Translation support: there is already a full translation for ARENA into the Russian language, but there are some fails concerning the generated dialogs of NPCs (The story-line scenes are fine). I think this is caused by the NPC-related texts, which are generated using ASCI-numbers. And because Russian uses the cyrillic-letters it cause a lot of bugs in the official game. Maybe this issue would be fix-able in OpenTESArena?
• Quicksave / Quickload using F5 and F9
• Toggle fullscreen using F10

In trying to replace my PNGs for the new game cinematic, I found that the intro images INTRO01.IMG, INTRO02.IMG, etc. aren't using any of the color palettes correctly. Note the 0 in the filenames; a similarly named set of INTRO images are junk.

The fact that INTRO01.IMG, et al. can be loaded by TextureManager::loadIMG() says that their header flags are recognized, but perhaps there is something else missing. Maybe the red and blue bytes are switched around for certain IMG files? Or perhaps there should be another level of indirection with the palette indices? I don't know, but it appears that some IMG files are an exception.

Looking at tool-extracted PNGs of the palettes, it looks like the most correct candidate is PAL.COL, but in that case, it should be using the second-to-last row of palette pixels, not the first row. I could be wrong, though. @kcat?

I only noticed this during trying to check into #26 on my Linux machine here. Probably caused by my rapid clicking through the menus, but that apparently caused the game to be unable to capture my keyboard input (at least for the name entry after you select your class).

I'll have to see if its easily reproducible.

Edit So far I haven't been able to reproduce, it is possible that it was just a bug in my desktop environment as my input just really wasn't shifting from CLion to OpenTESArena.

WinArena is able to print out (among several other things) a list of all the files contained within GLOBAL.BSA, shown with their byte offset from the beginning as well as their size in bytes.

I removed the line numbers here for brevity, but the last entry (ZOMBIE6.CFA) is at index 2440, so there are 2441 items contained in GLOBAL.BSA using a variety of formats:

--- Offset ---- Size ---- Filename -----
0x000002 0x02E1 01AXE.CFA
0x0002E3 0x14D7 01BARATT.CFA
0x0017BA 0x2AE0 01BARWLK.CFA
0x00429A 0x04AD 01BAXE.CFA
...
0xFF1273 0x2BA4 ZOMBIE3.CFA
0xFF3E17 0x3266 ZOMBIE4.CFA
0xFF707D 0x37CD ZOMBIE5.CFA
0xFFA84A 0x0D6C ZOMBIE6.CFA

Perhaps the virtual file system can use this information to load chunks of GLOBAL.BSA into the program. I can also put the actual list into a parse-able format at some point.

In a recent commit I added some CL defines in CLProgram.h for restricting the program to OpenCL 1.2 compatibility. The <CL/cl2.hpp> header is still in use for now, but it could be switched to <CL/cl.hpp> if need be.

This change is because of issues with Nvidia support for OpenCL 2.0.

There's a one pixel gap between the fists and the interface when you ready the fists. It isn't there in the original game.

XXX@XXX ~/XXX/OpenTESArena-master/build $ ./TESArenaGame: Initializing (Platform: Linux).
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::at: __n (which is 0) >= this->size() (which is 0)
Abgebrochen
XXX@XXX ~/XXX/OpenTESArena-master/build $ ^C

Linux Mint 18 - 64bit

The x-executable do not start :/

There are several useful strings in the A.EXE file, but they cannot be read in at runtime directly because the executable is compressed with PKLite v1.12. There are tools like UNP and The Executables' Unpacker which can uncompress A.EXE into a readable state, but they are DOS programs and their source code is either unavailable or in assembly.

Some options that have been discussed:

1. Distribute DOSBox and the UNP executable with OpenTESArena.
2. Write a PKLite decompressor using code from the disassembled UNP executable.

There's a lot of references to data types being returned and passed as arguments where there's no real benefit to actually using a reference. For example, the int:

Entities/DerivedAttribute.h: const int &getMaximum() const; // Might be a calculated value instead of a member in the future.
Entities/Entity.cpp:const int &Entity::getID() const
Entities/CharacterClass.cpp:const int &CharacterClass::getStartingHealth() const
Entities/CharacterClass.cpp:const int &CharacterClass::getHealthDice() const
Entities/DerivedAttribute.cpp:const int &DerivedAttribute::getMaximum() const
Entities/Entity.h: const int &getID() const;
Entities/PrimaryAttribute.cpp:const int &PrimaryAttribute::get() const
Entities/PrimaryAttribute.h: const int &get() const;
Entities/Player.h: const int &getPortraitID() const;
Entities/Player.cpp:const int &Player::getPortraitID() const
Entities/CharacterClass.h: const int &getStartingHealth() const;
Entities/CharacterClass.h: const int &getHealthDice() const;
Interface/ListBox.cpp:const int &ListBox::getScrollIndex()
Interface/ListBox.h: const int &getScrollIndex();
Game/Year.cpp:const int &Year::getEraNumber() const
Game/Year.cpp:const int &Year::getYearNumber() const
Game/Options.cpp:const int &Options::getScreenWidth() const
Game/Options.cpp:const int &Options::getScreenHeight() const
Game/Options.cpp:const int &Options::getSoundChannelCount() const
Game/Date.cpp:const int &Date::getDayNumber() const
Game/Year.h: const int &getEraNumber() const;
Game/Year.h: const int &getYearNumber() const;
Game/Options.h: const int &getScreenWidth() const;
Game/Options.h: const int &getScreenHeight() const;
Game/Options.h: const int &getSoundChannelCount() const;
Game/Date.h: const int &getDayNumber() const;
Rendering/Texture.cpp:const int &Texture::getWidth() const
Rendering/Texture.cpp:const int &Texture::getHeight() const
Rendering/Texture.h: const int &getWidth() const;
Rendering/Texture.h: const int &getHeight() const;
Rendering/TextureReference.cpp:const int &TextureReference::getOffset() const
Rendering/TextureReference.cpp:const int &TextureReference::getWidth() const
Rendering/TextureReference.cpp:const int &TextureReference::getHeight() const
Rendering/TextureReference.h: const int &getOffset() const;
Rendering/TextureReference.h: const int &getWidth() const;
Rendering/TextureReference.h: const int &getHeight() const;
World/VoxelReference.h: const int &getOffset() const;
World/VoxelReference.h: const int &getTriangleCount() const;
World/VoxelReference.cpp:const int &VoxelReference::getOffset() const
World/VoxelReference.cpp:const int &VoxelReference::getTriangleCount() const

There's no gain on 32bit machines because internally these will be passed as a 32bit pointer anyway. On 64bit machines there's actually a 4 byte loss since we'd be passing a 8byte value around to reference a 4byte value that we never actually want to modify (as explicitly declared by its const-ness). In both of these cases we have the slight performance detriment of an extra pointer deference, so overall its worthwhile to just pass these types around as regular values on x86 and x86_64.