To clarify my last commit message. I _do_ work with unprocessed files.
Just I happened to have one demo with resource fork stripped from game binary.
It was told that sometimes Mac conversion programs on intel platform silently
strip it down. Now I fail with error message, but we may use some fallback.
At least we need to know a standard way of copying binary files with resources
unstripped and describe it in Mac HOWTO.
svn-id: r16714
TODO:
o Allow reading from non-processed game executable. Now you need to get
.bin file out of it
o Use color versions of cursors
o Combine MacResExtractor with Win32ResExtractor. Now I just stupidly
create 2 objects and do not use new cursor caching code.
svn-id: r16713
Committed for review/criticize. No further support by the engine, i.e.
detected games will not run, but most complex task is done. Will finish
it tomorrow unless some nasty bugs will pop up.
svn-id: r16686
In this first step, I have moved all opcode functions into functions.cpp,
instead of having them scattered all over the place.
To get things to compile again, I had to rewrite the overly complicated
sound effects handling. It's much simpler now.
The next step will be to move any non-trivial code out of the opcode
functions and into the appropriate object. This, I hope, will make it
easier to create well-separated objects, instead of the current mess.
I also want to tear down the artificial boundary between the main directory
and the "driver" directory. We already have a cross-platform layer; there's
no need to have yet another one. (Actually, the rewriting of the sound
effects code took one first step in this direction.)
At the final stage, I'd like to get rid of the "drivers" directory
completely, but I'll probably need some help with that if I want to
preserve the CVS history of the code.
Things will probably be a bit bumpy along the way, but I seem to have
reached a point of relative stability again, which is why I'm commiting
this now.
svn-id: r16668