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?

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.

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.

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.

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!

Im sorry, attachment CDune.zip

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

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.

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.

I can do it. I'm working on duneadl and duneagd drivers now. I would like to write music player/wave dumper. I'm using emulators for adlib (2-operator fm synth) and adlibgold (4-operator) chips from mame project (fmopl.c and ymf262.c) Audio rendering will be direct sound/wav writer. Stay tuned it will take more time.

BIG THANKS TO LAMPEL AND ZIF FOR PUBLICATION OF LZ ALGORITHM

Hello Several months passed. I think I solved mysteries around hsq. I discovered more info about compression on wiki [url=http://en.wikipedia.org/wiki/LZ77] http://en.wikipedia.org/wiki/LZ77 Our hsq is a kind of old well publishded Lampel Ziv algorithm. Methods like this are known as a dictionary coders. I found same algos in unlzexe for dos, I have to suspect it would be lampel ziv, to save work with compressor/encoder. Advanced encoders use KMP algorithm for pattern matching to work faster. I think, LZ77 encoding was very polular at end of past century. Hsq compressor already posted is using simple intuitive match-comparison method, which is slower than KMP. I hope I get some free time during christmass holiday. I would like to continue rewriting disassembled duneprg to C. Do you know that zip is improvement of this algorithm? (zip stores dictionary in huffman tree) Do you know that excelent lzma (7 zip) from Igor Pavlov is latest improvement of this type of compression? From time to time some body learned about this algo and wrote new one improved (most of them was/are popular and famous)

Hello segra I'm not responsible to work with ida db files (I'm lazy). If you can export data to any text format and send your results to me, you might be very helpfull.

Don't worry. I just want to ask which kind of enhancemets you are planning to make. I have only ideas what should be discuss. I'm new in 3d. I wont to know more about yours opinions. First task to solve is just rewriting game to C from assembly and make sources portable to be system independent. If some one wants to be helpfull and knows assembly/C language I may send him some pieces of code try to translate them. But it will take long time, so please wait. I have about 10% rewriten now, but not debugged even not tested.

3. More about music. I like Jescola Buzz Machine composer for electronic music. FSM Infector would be able accept parameters from adlib insdruments. These generated sounds can be proccesed in more advanced effects than adlib can do and you get better sound. Finaly music is exported to WAV. I'm mostly using OGG vorbis codec insted of WAV or MP3.