Rewriting Cryo's Dune 1 : it seems possible !!!

[Monsieur OUXX]

@Honza.c : Please keep an eye on that thread, as md5 finished converting the small tech demo to a dummy ScummVM engine, and did some modifications.

I'd recommend you contact the user sev of the ScummVM forum and request access to his SVN repository, so that you can have a look for yourself.

[honza.c]

Hello Monsieur OUXX

I read your personal mail and scummvm thread.

I'm not interesting about scummvm at all.

Scummvm is nice library.

At this stage of projesct I dont see much things to integrate into scummvm. My question is why to integrate dune to scummvm? What can I benefit from integration?

I can benefit from is nice encapsulation or modularity of libarary. I'm trying to develop in ansi c (structured programming). I see no reason to design code in c++ (object oriented programming). I need no polymorphism, genericty even inheritance now! But it can change.

I can't build scummvm-1.2.1

I used visual studio solution build files, problem is nasm. They are using visual studio toolchain and write assembly sources in nasm, not masm which is already included in vs? Even more asm optimized code is designed for most powerful platform pc, and not so less powerfull platform where it can more benefit in cpu load (arm have dsp instructions, instructions for paralel arithmetic, have aproximately doubled number of registers than intel and can do fast multiple load and stores ...). I thing object oriented design wast much more processing time than optimized asm can save (in comparison to structured c design built with optimization enabled). Present Intel have inough power to run game like dune, without asm optimalization. But main point of my design is small footprint, to run embedded platforms with minimal hardware requiremens as possible.

What scumvm classes do?

They rewrap and encapsulate code and data from other libraries. Why use mid-interface like this? If I need zlib, I use zlib. If I need flac, I use flac. If I need fmopl, I use fmopl.

Portability

Scummvm runs on SDL, other ports woud be added. But my program can run on SDL directly!

Chip emulators

I need fmopl to write adlib registers and make music (meed no midi). Emulation is already included in scummvm, but redesigned to c++, to be able to support midi. I dont need this. (They rewrite it to C++ and removed mame copyright)

scummvm versus standart (original) libraries

Do I need to investigate what they supported, changed, or removed from standart libraries? Sucumvm seems is under intensive design and reconstruction. They can remade or change everything. Do I need to investigate again and again what hapend.

Documentation

Interactive help would be very handy. I'm busy person and I won't waste my time to learn libraries from sources. Do I need to search complete package if i need some banality function? doc folder includes about 60kB.

I better write my own package, which any body else can port to what ever platform/libraries he wont.

Funny programming

I'm rewriting cryos dune in free time. Until i have no running game, I wont to disturb nobody to integrate something to someting. In this stage i rewriting dune from assembly (or binary code) ansi c and structured programming is the best choice for me. If my package extends to much, probably i will rewrite all to c++ for better encapsulation or modularity. Only I wont to do now is share my results with forum. Some old programming technics woud be reused and is intereting to study them and bring back to life.

This is my opinion, I can be wrong.

Please, try do not disturb too much, I'm busy person. I read forum posts periodicaly at least per week.

Sorry for eventual wrong english.

[Monsieur OUXX]

Scummvm is nice library, but (...)

Hi Honza!

Thanks for expressing your opinion.

Well, my answer will be very short : The choice of ScummVM was more driven by "strategy" than it was by technical choices. I was hoping we could benefit from the dynamism of a larger community.

However, at the moment, you and P. Clément (the guy who wrote the little tech demo based on big's source) think that we should stick to SDL.

That's 2 voices versus one. You win! :-D

Do as you please.

Talk to you soon! and thanks for your big contribution.

PS: You make me VERY worried with the adoption of old programming styles and platform-specific assembly. The goal of having a small footprint is very noble, but I'm not sure it's worth it if it causes dead-ends maintainability-wise and portability-wise

[md5]

Of course, everyone is entitled to his/her own opinion. I joined the ScummVM project

because it provides a very structured, clean and organized infrastructure. It has been

successfully been ported on a vast number of platforms, far more than SDL itself

supports. Yes, ScummVM is in C++, and no, it does not use STL, because of the

overhead. Most of the needed functionality from STL has been implemented. You

can, of course, write in whatever platform or language you desire. As a project,

ScummVM has rewritten engines of several games, and we currently support over

200 official games, fan made games and demos, ported to several platforms, which

classifies it as a highly successful project, and it does have an active programmer

and user community. There are code styling conventions, so the overall code is

formatted in a similar manner across all engines.

As for the small footprint of your design... ScummVM runs on a DS, which is

VERY limited concerning resources and memory (about 2MB of RAM I believe?).

As for the encapsulation.. yes, you can reuse the libraries without the wrappers

that ScummVM provides, but these wrappers are to ease the usage of these

libraries under a variety of situations.

C++ isn't only about polymorphism or inheritance. It's about objectification and

classes. Yes, you can achieve something similar with C, but you're forcing the

language to something it was not made for.

As for building... did you follow the guidelines in the developer central

of the wiki, esp. the MSVC instructions?

And NASM... you can find its executable with a Google search, or just get it

from the precompiled libraries package in the MSVC page.

As for removing the MAME copyright... you realize that this is illegal to do,

right? The copyright is there, if you check the correct files:

scummvm/trunk/sound/softsynth/opl/mame.cpp and .h

scummvm versus standart (original) libraries

Do I need to investigate what they supported, changed, or removed from standart libraries? Sucumvm seems is under intensive design and reconstruction. They can remade or change everything. Do I need to investigate again and again what hapend.

I'm not quite sure what you're talking about here... all projects change and keep being updated?

As for documentation... that's a problem with all major projects

As for rewriting from assembly... that's great, it's called reverse engineering (RE), and it's

how we have rewritten most of the engines we support, unless original sources were provided.

So, in essence, you are doing what a lot of people have worked on from scratch...

Anyway, noone is forcing you to do anything, if you want to program something in your own

way, feel free to do so :) That's just my personal opinion, too

Also, I'd be glad to share all of the code I got up to now. It's not great, I haven't had time to work

on it, but if you need it, feel free to contact me

[bigs]

That's 2 voices versus one.

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.

PS: You make me VERY worried with the adoption of old programming styles and platform-specific assembly. The goal of having a small footprint is very noble, but I'm not sure it's worth it if it causes dead-ends maintainability-wise and portability-wise

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

[Monsieur OUXX]

Alright.

I hate you all (just kidding)

About the game logic, is it really worth it understanding the very little part that's not hard-coded, or should we instead start from scratch, with a small scripting language that we'd design? ("Paul talks to Character X, then sietch Y appears on the map", "Paul has had vision X, so room Y appears in the palace", etc.)

Actually, I definitely want this script language to exist, so I'll be even more specific: I wonder if it's worth it making the script "understand" the very little part of non-hard-coded logic that already exists in the games data files.

[honza.c]

Big do you wont to share results?

Do we can open new project on sourceforge.net or how can I share pakage obout 12MB?

I can upload prealfa, (not finaly completed) logo writen in C (with no asm) running on SDL. It also dumps frames to bitmaps, I think good sprite dumper would be based on algos from logo because it contens rle decoding variants for both left and right row update direction and rle with color key (zero transparent pixel) and no color key. All this variants are used to extract sprites from logo.hnm.

We will probably need some repository, where all work done can be accesibble and available.

[bigs]

About the game logic, is it really worth it understanding the very little part that's not hard-coded, or should we instead start from scratch, with a small scripting language that we'd design? ("Paul talks to Character X, then sietch Y appears on the map", "Paul has had vision X, so room Y appears in the palace", etc.)

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

[bigs]

Big do you wont to share results?

Do we can open new project on sourceforge.net or how can I share pakage obout 12MB?

I can upload prealfa, (not finaly completed) logo writen in C (with no asm) running on SDL. It also dumps frames to bitmaps, I think good sprite dumper would be based on algos from logo because it contens rle decoding variants for both left and right row update direction and rle with color key (zero transparent pixel) and no color key. All this variants are used to extract sprites from logo.hnm.

We will probably need some repository, where all work done can be accesibble and available.

- 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 ?

[Monsieur OUXX]

1/ Instead of a scripting language, maybe a specific editor for this "state/transition data" file may be enough.

2/ 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...

Option 2 is another way of putting what I meant. I like that idea a lot. But then again, I'd still be happy enough if we skipped the "original data files" part.

[honza.c]

I posted minimum for building logo.

Logo is still PRE-ALFA, but I finaly make it working on SDL. It displays final sprites with errors. I will debug and fix it soon, than I send first release. You need sdl with sdl prerequisities to run. You need legal logo.hnm file to run. Original assembly sources CAN'T be distributed of course. NOTE, code does not include assembly from original game or any assembly code for acceleration. Sources is pure standart C.

Porting: With dummy port you may run logo even on toaster. scummvm port can be added if desired.

PLEASE don't be narky in case you don't like it. Wait for first release.

NOTE, logo was rewritten to work exactly as original. (Dumping bitmaps was added, msdos related command line paramer support was removed). Also remember that reversing process is much slower because I need figure out all knowledge befor I can write new code. I also NOTE that some parts recoded still looks horrible. After I finish debuging I will rewrite it to be nice C and add coments, it can be really soon. But now you can use it to study how original work and how video is processed (specialy bliting functions).

Sources of several tools are available too (disassembler, unlzexe, hsq compressor, decompressor, binary image convertoor of executable ..., much bigger package). These are final, releasable

[honza.c]

Im sorry, attachment

CDune.zip

[honza.c]

Current state of reversing

1. LOGO

Rewriting logo.exe is almost complete, but there is some error in displaing sptites. I must found it and repair it. I must missed some detail.

I thing it will come to release soon, after i found that error. Also I add coments and rewrite it to be nice.

Outputs:

- We can benefit from logo algos and design more advanced sprite dumper

- I benefit from logo during rewriting dunevga driver

2. DUNEVGA driver

Rewriting dunevga is in progress. dunevga contents more advanced bliting funcs than logo an more variants than logo.

Basic functions - palette processing, and bliting i have already rewriten to C but no debuuged or tested yet. Thanks to logo I compreheded it quite quickly.

Rewrite more than half of code still remain. Also DUNEPRG nedded to understand how duneprg interfacing with this driver exactly.

3. DUNE386 driver

Same video driver as dunevga. Only diference is in several 386+ 32-bit instructions used for acceleration. I dont need to worry about this.

4. DUNEADL driver

Almost rewriten to C, 4 functions remaining. Several things I don't understand what is doing and how exactly works, inculde main player routine.

I need to rewrite audio related code in duneprg and figure out how works together. Than I can write music player. More and more seems, that music format is

very simple format and music is produced by writing a kind of raw data to adlib registers.

Outputs:

- music player and wave dumper or converting tool to/from ADL,AGD format.

5. DUNEAGD driver

Generaly same driver as DUNEADL but uses 4 operator stereo FM. Diference is only extended adlib gold register set and extended music format.

Fuction interface is same as duneadl. This would be done after duneadl will be completed. This is only extension to adlib and I think it would come very easy.

6. DUNESDB

Sound blaster have same FM chip like adlib + digitized music. Like in point 4 this will be extension of adlib + dma/interrupt driven transfers.

I'm thinkig about supporting digitized sound, because my game contents 11 voc files?

7. DUNEPRG

Rewriting is in early state. I already reversed several first execuded functions releted to initializations. This is main point of interest now because I need to understant

how interworks with drivers. Program counts over 20000 lines of machine code and progress is slow.

REM audiodrivers use verry unplesand code with all kinds of irregular programming applied, counting selfcode modification,

data buffers in code space, where code is executed and reused later as data memory ... I don't know who wrote audio, but I don't like him!

[md5]

And here is what I got up to now

It's a ScummVM engine, with support for the compression (HSQ), image files, sentence files and voice files, in C++.

I've based the work I did on the tech demo and the specs. I haven't had time for dissassembly yet, I'm busy with RL.

dune.zip

[md5]

Ah and here's a map I made of all the Dune files (also in the attachment) :)

General information about game files

== Music (Adlib Gold/Adlib/MT-32)

ARRAKIS.* (AGD/HSQ/M32)

BAGDAD.* (AGD/HSQ/M32)

MORNING.* (AGD/HSQ/M32)

SEKENCE.* (AGD/HSQ/M32)

SIETCHM.* (AGD/HSQ/M32)

WARSONG.* (AGD/HSQ/M32)

WATER.* (AGD/HSQ/M32)

WORMINTR.* (AGD/HSQ/M32)

WORMSUIT.* (AGD/HSQ/M32)

== SFX (VOC files)

SD?.HSQ (0x1 - 0xB)

== Text

PHRASE1?.HSQ (1-2) - English

PHRASE2?.HSQ (1-2) - French

PHRASE31.HSQ (1-2) - German

COMMAND1.HSQ - English phrases and replies (e.g. "Search for Equipment")

COMMAND2.HSQ - French phrases and replies

COMMAND3.HSQ - German phrases and replies

== Movies

LOGO.HNM

PRT.HNM

== Unknown files

CONDIT.HSQ - conditions, perhaps?

DIALOGUE.HSQ - dialogue logic, perhaps?

DUNE386.HSQ

DUNEADL.HSQ - seems to be related to Adlib music somehow

DUNEAGD.HSQ - seems to be related to Adlib Gold music somehow

DUNECHAR.HSQ

DUNEMID.HSQ - seems to be related to MT-32 music somehow

DUNEPCS.HSQ - seems to be related to PC Speaker music somehow

DUNESDB.HSQ - seems to be related to SoundBlaster music somehow

DUNEVGA.HSQ

GLOBDATA.HSQ - global data, perhaps?

MAP.HSQ - map logic, perhaps? (the map sprites are in ONMAP.HSQ)

MAP2.HSQ - map logic, perhaps? (the map sprites are in ONMAP.HSQ)

ORNYCAB.HSQ - Ornithopter cockpit logic, perhaps? (the Ornithopter sprites are in the other ORNY*.HSQ files)

SUN.HSQ - sunrise logic, perhaps? (the sunrise sprites are in SUNRS.HSQ)

VERBIN.HSQ

TABLAT.BIN - tablatures, perhaps? Seems to be music related

HARK.SAL

PALACE.SAL

SIET.SAL

VILG.SAL

***** SPRITE FILES *****

== Background sprites (background pictures and props) - used for locations

BACK.HSQ - Portrait background gradient

BALCON.HSQ - Palace entrance/balcony

BOOK.HSQ - Dune info book (background with 2 sand worms)

BOTA.HSQ - Garden

BUNK.HSQ - Bunker

CHANKISS.HSQ - Chani and someone else (Paul?) kissing

COMM.HSQ - Communications room

CORR.HSQ - Corridors

DUNES.HSQ - Dunes

DUNES2.HSQ - Yet more dunes

DUNES3.HSQ - Even more dunes!

EQUI.HSQ - Emerald-colored base + guards

FRESK.HSQ - House Atreides painting/flag/emblem

FORT.HSQ - Fortress

HARK.HSQ - Harkonnen base

INTDS.HSQ - Sand dunes

MIRROR.HSQ - Mirror room + mirror screen

PERS.HSQ - Persons inside the room (not in portraits)

POR.HSQ - Porch(?)

PROUGE.HSQ - Weapons rack

SERRE.HSQ - Oasis trees, rocks etc

SHAI.HSQ - Desert & sandworms

SHAI2.HSQ - Desert & sandworms

SIET0.HSQ - Cave entrance

SIET1.HSQ - Cave interior (rocks, walls etc)

SKY.HSQ - Horizon

STARS.HSQ - Sky + stars

VER.HSQ - Ring

VILG.HSQ - Village

VIS.HSQ - Top-down view of Dune, or the sky (it uses a different palette so it's hard to understand)

== Character sprites (full sprites and animations, e.g. eyes, mouths etc)

BARO.HSQ - Harkonnen (fat) baron

CHAN.HSQ - Chani Kynes

EMPR.HSQ - Emperor

FEYD.HSQ - Feyd-Rautha Harkonnen

FRM?.HSQ (1-3) - Fremen characters

GURN.HSQ - Gurney Halleck (Warmaster)

HARA.HSQ - Harah (Paul's wife)

HAWA.HSQ - ???

IDAH.HSQ - ???

JESS.HSQ - Jessica Atreides (Paul's mother)

KYNE.HSQ - ???

LETO.HSQ - Leto Atreides (Paul's father)

PAUL.HSQ - Paul Atreides (main hero)

SMUG.HSQ - Smugglers

STIL.HSQ - Stilgar

== GUI sprites

GENERIC.HSQ - Generic sprites (e.g. fonts)

ICONES.HSQ - GUI elements (graphics, sprites, buttons etc)

ONMAP.HSQ - Map + sprites

PALPLAN.HSQ - Palace map

== Sequence sprites

CREDITS.HSQ - Ending credits

CRYO.HSQ - Part of intro, Cryo/Virgin logo

DEATH?.HSQ (1-3) - Death sequence

FINAL.HSQ - Ending

SUNRS.HSQ - Sunrise

== Vehicle/action sprites

ATTACK.HSQ - Attack sprites (lasers etc)

MOIS.HSQ - Some sort of tank

ORNY.HSQ - Ornithopter (exterior)

ORNYPAN.HSQ - Ornithopter (interior, controls)

ORNYTK.HSQ - Ornithopter (exterior, probably for the flying animation)

[honza.c]

Hello mh5, welcome

-First of all I apologize. I'm sorry. All you wrote is true.

-Every body has some opinion. I sad I'm not interested, but forum can be very interested. Don't take only me into acount. It not depends on me.

I also said scummvm is nice library with nice modularity and I have no better knowelede to make conclusions about scummvm, even utilize it.

-At this stage of project we are trying to discover technics how to use original data and handle them.

I think there must be many work done before we can start implement our engine.

-I know some thinks about gba and I'm also developing hardware based on arm7, arm9 and cortex-m3, so this is reason for low footprint design.

Low footprit can benefit on any platform and I don't see much arguments for wasting of resources.

-Classes "objectification" or Structures. I still dont understant why structured programming have to be so bad.

I started programming on i8080 in 1990 and my expiriences orders me to better write structured program primarilly if it is simple utility using arrays,

several variables and several functions. In case I need genericity or polymorphism c++ comes handy, better choice. But I'm sure that package will grow and later will be rewriten.

Leter, not now in stage of debuging and developement. Also SDL works well now. Later we can choose another libraries optimal for our

requests.

-Every good machine dependent interface can garant good portability not only scummvm or sdl. I believe scummvm can run more platforms than SDL supports.

-Rewriting from assembly / reverse ingeneering, bad translation, sorry I'm not expirienced in eglish language much.

-Mame copyright: dosbox (some older version) used shorted or adapted form of mame copyright and was scolded. In last version they rewrote all to c++ and completely removed

fmopl.c. If I'm wrong I apologize again.

Thats all from me. I wish you succes, you making good work.

[md5]

Some things I forgot to say about the code I attached above... its main loop is empty, as you see, and only an image is shown. You can use the console (Control-D) to manipulate the game's resources, making it a glorified resource viewer :) Here are the commands:

- dump: Decompresses the given HSQ file into a raw uncompressed file

- sentences: Shows information about a sentence file, or prints a specific sentence from a file

- sound: Plays a sound file (sd*.hsq). Valid sounds are 1-11

- sprite: Shows information about a game sprite (character/background) and can display it on screen

Another thing that comes to mind: no matter which route is taken (ScummVM or something else), if you're aiming for multiple platforms, the code must be written in an endian-safe way. What I got up to now is (afaik) endian safe, ScummVM has functions helping with that. But parts of the tech demo I saw are definitely not endian safe (e.g. direct casting to uint16 from raw data)

[honza.c]

small remark for md5:

if you convert color components you use formula:

red_new = red_old << 2; /* red_new ranges <0..255>, red_old ranges <0..63>, this gives new intensity 252 for value 63 */

i use commonly this formula:

red_new = red_old * 255 / 63; /* same ranges, but gives 255 for value 63 and results a little more intensity */

same apply for green, blue component.

[bigs]

== Unknown files

CONDIT.HSQ - conditions, perhaps?

DIALOGUE.HSQ - dialogue logic, perhaps?

DUNE386.HSQ

DUNEADL.HSQ - seems to be related to Adlib music somehow

DUNEAGD.HSQ - seems to be related to Adlib Gold music somehow

DUNECHAR.HSQ

DUNEMID.HSQ - seems to be related to MT-32 music somehow

DUNEPCS.HSQ - seems to be related to PC Speaker music somehow

DUNESDB.HSQ - seems to be related to SoundBlaster music somehow

DUNEVGA.HSQ

GLOBDATA.HSQ - global data, perhaps?

MAP.HSQ - map logic, perhaps? (the map sprites are in ONMAP.HSQ)

MAP2.HSQ - map logic, perhaps? (the map sprites are in ONMAP.HSQ)

ORNYCAB.HSQ - Ornithopter cockpit logic, perhaps? (the Ornithopter sprites are in the other ORNY*.HSQ files)

SUN.HSQ - sunrise logic, perhaps? (the sunrise sprites are in SUNRS.HSQ)

VERBIN.HSQ

TABLAT.BIN - tablatures, perhaps? Seems to be music related

HARK.SAL

PALACE.SAL

SIET.SAL

VILG.SAL

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.

[md5]

@honza.c: nice :) though the original game shifted by 2, didn't it? thus the palette will be a bit off

@bigs: I did see your post about SAL files, but all the links it points to are dead now :( Could you reupload?

[honza.c]

video dac on pc-at (ega, vga) has 6 bit resolution (0..63).

game useing two methods to set palette

1. ega, vga bios call int 13h component have to be in range (0..63).

2. direct write to crt controller's dac registers, range (0..63)

original game performs no conversion or shift because component is in hardware format and is written directly.

main point is increase intensity to range (0..255), correct is to recalculate it linearly. do as you wish, it can't be visible.

[honza.c]

For example (r,g, = (63,63,63) represents white color on old machines, if you shift it you get (252, 252, 252) insteed white color (255, 255, 255); you get a bit gray insteed white, and all colors will be a bit darker but will not be changed, clolors will be correct.

If you have for example 16-bit trucolor format RGB565 (5 bit red component, 6bit green and 5bit blue) and if you perform conversion based on shifts than you get completly different color, coloor will be changed; In this case (31,63,31) is white color and after shift you get (248,252,248) whitch is diferent color from white. I'm think i can't be visible diference but it isnot correct. Got it?

[Monsieur OUXX]

I posted minimum for building logo.

Can you explain what's the fundamental difference between your logo displayer and P. Clément's logo displayer? Is it a matter of language, code structure, etc.?

It's just to share the information.

[Monsieur OUXX]

Could we all agree that whether or not we use ScummVM and/or other underlying libraries, all the code written should anticipate hardware portability?

I mean, really, not only as "yeah, yeah, it's very easy to do, we'll do it later" (we know how it ends - same thing for comments, lol)

md5, maybe you could think of a way of taking honza's source and add some macros to be able to :

- compile it for ScummVM (slower, with possibly some disabled features)

or

- make it standalone (all features enabled, faster) ?

(depending on the macros enabled at compilation)

Just a suggestion.

[Monsieur OUXX]

I HAVE CREATED A SOURCEFORGE PROJECT (with a SVN repository)

URL : https://sourceforge.net/projects/dunerevival/

I will upload as much material as I can ASAP.

Request access to me asap.