You'd probably get some high-quality responses from
[https://www.reddit.com/r/ReverseEngineering](https://www.reddit.com/r/ReverseEngineering)
You are completely correct @cumulonimbus (sorry for the long silence). I am a
complete beginner when it comes to assembly.
But I've played around with the DOS debugging (in DOSBox) and here are my
observations:
* the executable is DOS MZ 16-bit format
* the main executable seems to load
This is not code; This is data of some sort.
Even if you get the sprites they might be all jumbled up like this:
[http://www.gamasutra.com/db_area/images/news/253377/fig03.png](http://www.gamasutra.com/db_area/images/news/253377/fig03.png)
Older games tent to reuse/recolor spires. Even when you get spires it might be
really hard to put
> What's also possible, is that multiple pixels are stored in one byte. I don't
> know the exact specs, though it might be possible that if a sprite can only
> have four colors, each pixel is a palette color index stored in two bits
> therefore a byte holds four pixels and the palette selector
I'm not very familiar with MS-DOS games, but I have a bit of knowledge about
NES games.
It might be possible that the data you're looking for is compressed. Something
like RLE with small modifications wasn't uncommon on the NES, especially for
storing level data. What's also possible, is that
Getting sprites out old dos game can be hard. You will not find standard images
formats like png, jpg or dds. It can be stored in extremely convoluted way. One
game I ripped the sprites from (Panzer General) used a strange pen method where
it stored all images as move pen left, right, draw
Hi guys,
I have a couple resource files from an old MS-DOS game called `Zeliard`. The
files have a `.sar` extension, if that is of any help.
I would like to find out how the sprite information is stored in these files,
but I have no knowledge of how it is `packed`. Some data for the game text
