dvalin

eastwood supports them as well ;)

when you decode graphic using eastwood, you can specify that you like to scale it to bigger sizes using scale2x (http://scale2x.sourceforge.net/) to get nicer looking graphics than you'd otherwise would when scaling it. Same goes for sound, which you can resample it to higher frequencies and make it sound better using libsamplerate (http://www.mega-nerd.com/SRC/). here you can see some examples of these options for eastwood: [peroyvind@localhost tmp]$ eastwood --cps --help Usage: eastwood --cps [options] arg Options: -h, --help show this help message and exit -o OUTPUT, --output=OUTPUT save to OUTPUT -p PALFILE, --pal=PALFILE PAL --scale=SCALE Scale graphics using either '2x', '2x3', '2x4', '3x' or '4x' --cps=CPSFILE CPS [peroyvind@localhost tmp]$ eastwood --voc --help Usage: eastwood --voc [options] arg Options: -h, --help show this help message and exit -o OUTPUT, --output=OUTPUT save to OUTPUT --voc=VOCFILE VOC Resampling options: --resample=RESAMPLE Resample sound using either 'linear', 'zero_order_hold', 'sinc_fastest', 'sinc_medium_quality', or 'sinc_best_quality' -f FREQUENCY, --frequency=FREQUENCY Resample to FREQUENCY hz -c CHANNELS, --channels=CHANNELS Resample to CHANNELS channels -F FORMAT, --format=FORMAT Resample to FORMAT format, either u8, s16be or s16le

you forgot to mention EMC (basically a merge of segra's DST;) & text strings :P Also it supports graphics scaling (scale2x, scale2x3, scale2x4, scale3x & scale4x) and sound sample rate conversion (aka interpolation) to enhance your output result! ;)

see http://forum.dune2k.com/index.php?topic=22082.0 ;) The eastwood tool implements most of the functionality provided by the library API (as listed in the post referred to), currently with the exception of midi (ADL & OPL), FNT font files, reading DUNE2.EXE structures, reading/writing of INI files. More functionality in progress. :)

https://launchpad.net/libeastwood It comes as part of the python bindings shipped with the library. :)

you're still missing libeastwood (and it's 'eastwood' tool using it) on yer list! ;)

If you're getting nostalgic about the Dune RE days, you might just wanna take a quick look on how I've made use of and developed your OD 2 code further. I'd like to think that you'll be happy to see that your code was made actual use of and to great benefit for others directly, rather than being left behind abandoned and unused (worst fate I can think of for my code to suffer, I'm such a sentimental when it comes to it;)! :D Have nice weekend! :)

I figured that I'd just provide some status update report on the progress of mine: I removed the last remaining piece of code getting the original data structures from DUNE2.EXE the OD2 engine last night, introducing replacements for these in libeastwood with code resembling more the original c++ code in implemented in more generic fashion now. The more I refactorize and clean up the disassembly code in C, I'm getting a much better understanding of the remaining code as well, it's quite interesting to see in how similar fashion much of this code was implemented compared to much of our older in dune legacy/doon lunacy. Not only do I think the code will be easier to fit into my own engine when I'm done decompiling it, but I think it should be quite easy for others with their own engines to integrate. All the data structures are easily available from the library, with the OD2 implementation using it, both aiming at (and progressively succeeding in;) being written in a very generic fashion, making it relatively easy to implement in different languages from as well. Myself I'm thinking about implementing python classes for my Dune2File class in libeastwood, then reimplement the c++ code decompiled from Dune 2 in python using them for use in doon lunacy, eventually separating libeastwood from the engine completely (ie. no linking or use of it's c++ API), making use of python interfaces that'll be easier to figure out and play with and the engine less tied into it, making it more generic (buzz word/fetish of the day;) for supporting other games as well eventually.. So yeah, that's kinda describes some of my thoughts and efforts on the subject, you can follow my progress in more detail in my branches (as you'll see, they've been quite active lately :O): https://code.launchpad.net/~doonlunacy/libeastwood/trunk https://code.launchpad.net/~proyvind/doonlunacy/od2 News of my progress might not be that interesting to gamers at this moment, I haven't really added any new functionality visible for people only playing the game, nor made any new discoveries to share on these things interesting to most either (the OpenDune guys does a lot better job on this;), but at least people will notice that my project(s) are still alive and making progress. Hopefully it will look a bit more interesting to other devels with similar projects of theirs, perhaps even being of some use to them, and if I'm lucky, getting a bit help, feedback and motivation in return for me to ever reach a milestone others might care about.. :P I sure know that making guesses on a lot of these values is a lot of annoying hazzle, involing losalotsa trial and error getting what you're satisfied with, having somewhat the same behaviour kinda matching Dune 2's.. Ie. creating separate classes for each unit, structure, missile etc. in the game, figuring out frame offsets etc. used for each of these I sure know feels a "bit" tedious (trying to get the cutscene playback, with timing, looping etc. correct, and still failing was definitely the worst one for me, which I never even got in an okay state, for the playback itself nor design-wise;p).. So for all you doing your own Dune 2 engines in C++ at least, I hope to grab some of your attention, what you'll mainly find here is various components (of your choice which in specific you'd like to use, mostly individually if you'd like a well;) that you can easily plug into your engine without doing major rewrites. This is the main gain and focus of mine as well, rather than a complete engine matching ~identical original gameplay (OpenDune has this focus already, succeeding a lot better at it, with far more progress:o). Now the remaining component of OD2 that libeastwood's not fully complementing at the moment is EMC stuff, I've merged in the code of DST in the past, now I need to merge in the appropriate parts of the EMC interpreter into that code, then the major work left of on this one is the dark voodoo of the EMC scripts+functions that I need to identify and figure out (my biggest fear so far, hoping to dip into OpenDune efforts getting to much of it first, before me ;p). Blablablabla, at least some new rambling and Dune 2 related news again in here, haven't been much of that over the last month.. ;)

ahh, so it's been fixed since last time I tried it then, earlier I made it compile, but had trouble running it and pascal isn't really a language I know and wanna know enough to fix stuff.. good to see others did though :)

heyo, as I wasn't able to figure out how to run your editor under wine in the past, and rediscovered the issue again when trying tonight: $ wine d2editor.exe "No way to get console screen buffer info" I figured that I'd share how trivial it was to get working with others, just execute it with 'wineconsole d2editor.exe' rather than 'wine d2editor.exe'. Pretty simple :)

Hm, I thought about "Spice Dynasties" earlier myself as something that would sound Dune specific enough, but I don't think it would sound classy enough.. ;p For the graphics, yeah, I certainly have some interest in it (given that it's not only redistributable, but truly *free* wrt license as well), it would make the engine usable without the non-free data. Some Linux distributions won't ship packages which depend on non-free stuff, since having the game shipped by vendors is important to gain some popularity etc., this data would be very nice helping this. As I intend on making my engine as generic as possible to support multiple games, separating the engine from the game and all, it would also be nice helping out on this. Hopefully I'll get some help from others that have greater interest in this sometime in the future.. :P

Any plans on adopting libeastwood? The library should be more mature(/less nasty;) for such than when we discussed it in the past. :O) I also plan on merging most of the code I pick up from OD2 into libeastwood (ie. the EMC interpreter), so I'd think this should make it more interesting to you as well, you were the first one suggesting to me implementing support for authentic Dune 2 AI after all. ;) I think the more we're able to separate game components and make them as generic and reusable as possible, it would make it easier for us to progress towards a merge in the future, or at least share efforts as much as possible. Since you don't seem to want to use launchpad and bzr, I could after all open for svn access on sourceforge if you'd like.. I still have some concerns about the possibility for trademark issues etc., especially since Paramount already has slammed some cease & decists against some second life communities etc. after they bought all the rights for Dune related to their upcoming movie... Since you're doing pretty much the same as I do to avoid copyright issues, it would kinda be in vain unless you resolve trademark issues as well... I'm still looking for a new name though, "Doon Lunacy" is just a working name for now, I'd like some name with "dynasty" (as in "Dune 2: The building of a dynasty" ;) in it. "Dynasty" is such a fancy word. ;p

I've finished doing the initial work of getting OD2 building and running on Linux now at least.. Let's see how much further I get from there, I've figured out that if anything, I'll merge the code into doon lunacy rather than the other way around at least.. ;)

Eyo! Haven't touched any of these things in a few months, but since OD2 is written in C++ and using an older version of my library, I've been thinking of looking into it and what use I might have of it's code and all ever since it were first announced. :D I figure that porting the thing to using latest libeastwood of mine and to a more gnu'ish dialect of C++ shouldn't be that hard, so I've started doing this now and for anyone who'd find it of any interest, can find my progress here: https://code.launchpad.net/~proyvind/doonlunacy/od2 Not much yet, I only started a half hour before I went to job this morning, but eventually I guess it shouldn't be that big of a job to get it just working for me (with even font support added when I get around to it! ;). From there I'm thinking of trying to merge things with my Doon Lunacy project. Currently I haven't touched the code for it in like a year (only focused on libeastwood) and I know of so many mistakes and much ugliness in the code that should be fixed and even then I still have yet to implement actual gameplay, so perhaps I'll just base myself on OD2 and merge my code into it along the way as I progress, or I might do the opposite... Time will tell, I at least wanna release something playable sometime soon, so just porting OD2 seems like a less demanding project on this with far less amount of code and without shitloads of functionality that won't be of any use anytime soon anyways.. Oh well, I'm babbling, just thought that I'd let you know, if I ever manage to release something playable, you're probably even likely to find interest in it. ;) PS: I'd still appreciate if anyone on win32 could nail down the last couple of remaining issues to get libeastwood and the python bindings / tool working, then I'd release a new version of it and provide you with another tool I surely think could be of use to you, especially as it's far more complete and full fledged than most other Dune 2 tools out there. :P cya! :)

try run the test suite and you'll find out :) the endianness stuff are known to be in order :) the error might be just limited and as simple as the PakFile class, since it didn't work fully reading pak archives, all the other tests ran by the friend who helped would fail... the PAK format is the simplest of all the data formats, so should be easy to fix, I just don't have any windows system or anything to even try running it on myself. for system I'm developing on, it's x86_64 gcc 4.4* mandriva linux cooker :)