bigs

@mrOuxxx: D:\SVN\dunerevival\compiled_snippets\DuneReloaded 1.4\DuneReloaded\Data\Dune\CREDITS.HSQ ... you are providing copyrighted materials in svn.

http://bigs.fr/dune_old/

Some of those file are know. I think I already explained here what SAL files are. And Im sure I provided the code about how to exploit them. map.hsq and map2.hsq. One is the full globe data (ie relief data etc) , the other is the map were you can see who is owning which territory (zone of influence). The second one also provide (the initial influence zone for atreides and arkonens). GLOBDATA.HSQ, Im almost sure those are trigonometric date used to put in good shape and/or rotate the previous map.hsq maps decode ok (just I dont understand yet how to put them in good shape with globdata.hsq..... so I get something deformed like a plane world map) CONDIT.HSQ DIALOGUE.HSQ those 2 (or one of them, dont remember exactly) are some state/transition datas I was speaking about in a previous post.

- some kind of repository is a good idea anyway. - your prealfa logo in C should not be too big, why not sharing it here, maybe it will provide ideas or motivation to some other persons. - those 12Mb data is your ongoing disassembly work ? I dont think it is allowed to share disassembly of copyrighted data on sourceforge. - I can set up some online space to share those 12Mb if needed. Or you can use any free filesharing system available on the net. - did you worked a little on disassembly the main exe ? does interesting informations came out ?

About understanding the original game logic/game engine or recreating it from scratch, I would say this: - recreating it from scratch without taking time to understand the original will just bring us a different game behaviour (because we will probably miss something important but maybe not so obvious). If you want to make a game that looks like and sounds like the original, but behave not exactly the same, then its fine. - Personaly I would like to reach a perfect copy (something like a port, except that there is no available sources :P ), so understanding/disassembly step is necessary. - For some people this understanding/analysing process is part of the fun. Honza is going the disassembly way and he seams to be quite into it. He may bring up a perfect copy, and discover all the game engine tricks, but it is really time consuming. I go the data-modification/test/watch-memory way and try to figure out how works the game engine. I get some fun like with a strange puzzle, but I wont be able to figure out every details. Only disassembly can. - What the point in figuring out the gfx formats and implementation, the music formats,.... and then forgetting about the game-logic, deciding to implement it very approximatively. - Even in case of writing a perfect copy, you can still write it in a way that allow flexibility and further expanxion (here your scripting idea may be of some use) about the "Paul talks to Character X, then sietch Y appears on the map" part: I think this part is specified in a datafile in the form of state/transition (finite state machine?) datas (and I dont think it is a "very little part" like you said). I guess the game engine use those datas to do what you said ( "Paul has had vision X, so room Y appears in the palace" ). I have been playing a bit with this but it is still obscure. About scripting; Im not interested in going that far for now, but just thinking .... Instead of a scripting language, maybe a specific editor for this "state/transition data" file may be enough. Or maybe better, with some knowledge of the engine and hard-coded things in the exe, it is possible to do a separate tool that build a script from "original data file". The so said scripting language being flexible enought for later expansions/modifications/whatever... Just curious... what everybody thinking about all this ? what are your expectations ? for Honza or MrOuxx I can tell , but the others ? :P

3vs1 :P Integrating with scummvm isnt a bad idea, but far too early imho. I guess we're still in the discovering phase. We're still not sure of the format of all datafiles. So, like honza said, planning integration with this or that, just add confusion and doesnt help achieving the main goal. With the graphic part that have almost nothing difficult left, and honza working on the sound/music part, what we really need now is to understand the game logic. As far as I can see, the main game logic is hardcoded in exe, and some state/transition elements are defined in 1 or 2 datafiles. I would say that for now we can (or already have) produce some code snippet or demo program for what we understood, and continue with datafile analysing/understanding and binary disassembly/analysing. For now I see no worry matter in honza way of doing. If he's gonna share his discoveries or/and produced code, then its already a good progress. Just my opinion... :P

We don't have much so it's not really a big problem. :P So you have information on how rooms transition are done ? (Information about for exemple "if a go south, which room will I need to display ?".) where are those information ? Where are dune map graphics and how do you decode ? dynamic palettes shouldn't be really difficult to find. It will be my next step as soon as I get some free time.

no, they dump correctly. I just forced a grey pal for these sprites. In fact they dont have a defined pal because in-game they use palette defined by the game engine (because it is sprites with color changing depending of time or place). So it's not intersesting to dump them with a "good" color. A good color index is enought. http://www.bigs.fr/travaux/dune/

The dumper program i made extract sprites (bmp format) from files previously uncompressed (UNP comming from decompression of HSQ files with the help of a tool provided by someone on a previous post). I also provided a tool to compress a UNP file to a HSQ to test modification of the game, and to help finding file format informations. Those tools may (certainly) have bugs; but source are provided, so...

Je pensai tout haut ...d

hi, I see things like this: (for balcon) [00h, 01h] is a short giving offset of end of data pal. (with chan.unp there is a gap of one byte between 0xFFFF and the given offset...dont understand why) [02h] offset sub-palette #0 (here 0x00) [03h] nb of colors (here 0x01) [04h,06h] rgb of the color (here black: 00 00 00) [07h] offset sub-palette #1 (here 0x53) [08h] nb of colors (here 0x09) [09h,23h] rgb of the colors [24h] offset sub-palette #2 (here 0x5F) [25h] nb of colors (here 0x02) [26h,2Bh] rgb of the 2 colors [2Ch] offset sub-palette #3 (here 0x70) [2Dh] nb of colors (here 0x10) [2Eh,5Dh] rgb of the colors [5Eh,5Fh] 0xFFFF [60h, ...] ??? look like rgb values are defined on 6bits so I read R=0x36 G=0x20 B=0x0E in data pal supposed to be one of orni color in balcon.hsq and I do shift 2bits to left and I get R=0xD8 G=0x80 B=0x38 this is verified to be a color of the orni.