Dungeon Master Forum

I'll add this public topic for my works 'in the dark'. Perhaps we find more people to test then.

DM
CSB

That's the first version of my DM/CSB-clones working in truecolor and hires - graphics can be exchanged (see the readme.txt).

I don't want to create a real clone out of this, but maybe we can apply the results to CSBwin.
Any feedback is highly appreciated.

First bug I know is a minimal glitch in the cursor graphic if you rearrange the party formation.
Keep an eye on graphical things - but if you find other bugs, please tell me too.

Distance- and overall-lighting is approximated in truecolor, it doesn't use the original lighting tables.
For that the evil face, and some buttons may appear a bit lighter. That can be adjusted later.

Btw: you should be able to play old DM-savegames with that one - that isn't possible with CSBwin
Savegames created with that clone cannot be played with CSBwin (still, it's the original saveformat!)

Hi there,

tried it. programm crashes when i try to resurrect a champion. Win7 event says: application error event id 1000, category 100, module dm.exe.

It's all Iaido's fault, when trying to resurrect him:

ppName: dm.exe AppVer: 0.0.0.0 ModName: dm.exe

ouch - if Allegro crashes I don't have much chances...
I'll check boundaries carefully - maybe there's something running over.
The Allegro-version is the same that Sophia uses, and because her things are fine, it's probably me.
I always loaded gamefiles and didn't check the early game, but okay, if you can resurrect nothing, you can't save. We must pass that problem quickly - not easy, because Iaidio comes alive for me pretty well
Better all others stop testing then - have no idea how harmful this can be.

EDIT:
Just made a savegame - works, but quits when loading again. There's really something weird going on - that worked pretty well all the time.

When I try to resurrect or reincarnate the champion, the game crashes (do you want the crash text file?), so I only wrote about what I`ve seen as a "ghost": mainly that wallsets are not reverted (the floor & ceiling are ok).

The hi-res wall desc seems to fit well to the low-res wallset; floor decs are still low-res.

Sorry Bit, I haven`t read your posts on other topic, so I might repeat what you already said, but I don`t understand well the technical stuff; it`s interesting! But the game crashes, so I couldn`t test it well as if the door leading to level 01 were open.

What`s that bug with Allegro? I see there`s an Allegro file incuded to your rar pack.

Useless information.....but one more data point.

It crashes instantly for me when I resurrect or
reincarnate a champion.
Running Vista with rather weak, built-in video.

Tried it and it also crashes for me when resurrecting a champion. Windows XP SP2.

Yup - bug shot!
The routine that cleans the spellbox did spend some pixels too much - and those were painted into somewhere. Fortunately the savegame-problem was solved with that too.

There's still one odd effect sometimes in the beginning: a delay (mouse cursor may hang up for even some seconds). I must profile that one (and I'm not trained in profiling...). It may have something to do with the first timers, or maybe it's something with the memory heap - I should count how much space all the graphics need now. Better have 1/2 GB memory onboard... 960*600*32-bit is 72*ST-graphics...
I'm glad that the speed is still okay now - btw - it's adjusted to 70 Hz VBL, not 50. That's for you pros

old link - new exe in the folder
Comes now with catching graphics-overruns and some error codes.
(Doesn't guarantee for the rest - save your pets while testing )

@Adamo:
Allegro is the library that is used for graphics,sound,mouse etc.
It's only used for the very needed stuff, because I ever refused to learn WinAPI.
Then again, with Allegro the clone could be ported to Linux with almost no changes.
Unfortunately - as Paul said - those error informations are usually pointless - and Allegro gets always blamed for my faults. The new version keeps an eye on evil graphic bugs and should shut down the program save with a little error code that helps me finding the problem.

I do have changed something in DM's internal memory organization of graphics, but all the rest should be as close to the original as CSBwin is. If we end up the tests successfully, I will pick one of Paul's CSBwin-sources and try to apply the changed drawing routines to CSBwin - so that they are optional available. I hope that we will be able to load PNG/JPG too then. Allegro can't without add-ons.

EDIT:
Just played a bit with the new version.
There's a funny new bug now - happened when I optimized the speed.
viewportarea depends always on light level - so - on inventory page too.
See it as a feature for the moment
I'll be probably not available for the next week, being out the house for a job.
Just collect the 'features' please.

Now it works for me...

Yeah, but wait for loading a savegame. the hero pics are all black - if it accepts the file at all. i'm at it.
The lighting problem is already solved. i'm now at an odd checksum-problem in the savegame.
hero pictures got saved in the savegame, because there is no index anymore who's who (from the champions hall). There they are in old-ST-graphic-style, so I have to give them back to the savegame in that mode. But somehow I destroy the checksum atm (randomly, sometimes it works ).
Hope I'll find that too today and have a good update then together with the light problem, for that I can quit for the week with a good conscience.
btw: it's okay that some elements are brighter in the distance view - this has to be adjusted later.

it works, successfully killed a mummy runs fast, too.(did not check sound)

in the readme

what do you mean with "overloaded graphics?"
- graphics that are loaded over the normal graphics.
- graphics that are too big to fit into the boundaries of standard graphics?

Graphics can be overwritten by a 24-bit-color-bmp-file.

The overwrite mechanism simply works by filename, use:
###pic.bmp,
whereby ### is the original graphic number

question_:

can there be more items (more item graphics) than in original,
or is it - as it seems to me now- that you have a restriction on item graphics?
###pic.bmp is at least limited to 999pic.bmp, probably less.(did not check ency)

anyway keep up the good work!!

Back at work - savegame problem still not fixed. Drives me crazy.

@zoom:
At the moment there is all just original, and I think 999 is enough.
The whole clone is just meant to test the drawing routines, won't break any other limit and stay close to CSBwin. With 'overloaded' I mean - it uses to take the original graphic, but with a given file having that number you can replace that one with a real hires/truecolor graphic. Unfortunately I have to stay in Allegro's limits, and without another add-on-library it won't accept PNG or JPG. Those extra libraries do exist, but are weird to handle - I understand almost nothing from their documentation.
Perhaps Sophia can give me a simple example how to use them.

If you're going down the high colour/hi-res route, I'd recommend you add support for a lossless compressed format like PNG or TGA. Large, tru colour BMPS consume huge amounts of disk space and would make any future graphics pack a massive download.

Absolutely right Gambit - problem is: standard Allegro doesn't support those formats without another add-on library. I asked Sophia already how to handle libpng with Allegro and she gave me a sample.
I'll apply that as soon as possible. It wasn't meant to have the clone standalone, it's okay as long as CSBwin adds the support for those formats later. But well - we don't know how long this testing takes.

There are still some ideas to be realized which aren't implemented yet:
- hires fonts, hires basic cursors
- finer masks, probably something that gives the possibility to swap monstercolors the old way, but in a larger range. It's ridiculous if we make it truecolor and hires and then replace one color only i.e.
- heroe's pictures are stored in old-style only in savegame. because i don't want to change the savegame-format, there's nothing that gives hires-portraits after loading. need to have a parallel savegame for that. Photographic wallsets and oldstyle portraits aren't funny too.
- special effects for teleporters,fluxcage and being hit by a fireball should be appliable too.

Current known bugs are now fixed and uploaded:
- inventory screen in full color again
- savegame checksum problem maybe solved, maybe not, but atm it works
- heroe's pic after loading savegame available

EDIT: again an upload: - new version uses PNG instead of BMP
I just hope that Win7 likes the dlls.

And now - harhar - it's getting wild!
I've added a 2nd link here!!!
That one contains all the replaceable graphics in truecolor und hires!
The clone looks first for a numbered bmp-file, if that isn't available for a png-file, if that isn't too, zooms the original graphic. Those graphics can easily be handled by graphic programs. If there is a maskcolor in, better pick the color from there and draw then with it. Big question is not if the graphics are finer now, but if it handles all those graphics correctly. At the moment I don't do 32-bit, but 24-bit color!

For internal information - the steps to create those files:
- got the sck-java-extractor that extracted the files from original graphics.dat - did throw away non-graphics.
- renamed files with win commander 32
- batch conversion with irfan-view to stretch and color-enhance. color-enhancement did not work absolutely correct, so i needed
- a routine that i put directly after the intro, that converted colors back exactly to the default palette, then converted back to truecolor like I need it. That's a thing you can't make now - will later make a tool out of that.
- another batch conversion to make png out of them. fortunately colors stayed same!
So - there it is! Looks pretty fine so far that I tried. Again: many thanks for the png-handler Sophia!

all right, just wanted to report that Win7 likes the dll´s.

Hello, can I ask if your damage and combat calculations are accurate to the original or is this an approximation that 'feels' right? Im interested in where people are getting the combat and damage calcs from, thanks.

DSE wrote:Hello, can I ask if your damage and combat calculations are accurate to the original or is this an approximation that 'feels' right? Im interested in where people are getting the combat and damage calcs from, thanks.

Hehe, it should be - but I doubt that I converted it that high without faults.
I took the same way CSBwin was created, just my variables are still anonymous numbered.
There's nothing better than in CSBwin, except there are the new rendering routines that we need to test.
Well, in the early beginning, I mixed both sources together, DM and CSB, and there's an #ifdef now to create both separately. If you need the source to checkout the differences, tell me. I'll release it sooner or later anyways, but not to have another clone, but for cross-checking etc. At the moment it's pretty overloaded with TODO and URGENT and other comments, you won't really read it

@zoom:
Good news! Thanks!!

I was hoping you were going to say you had an elegant version of the original. I have looked at the original code snippets and stuff and its all a bit of a mess.

Is CSBwin open source, are the routines for combat, etc available then ?

Yup, it's all inside of CSBwin.
But it's right - because Paul stayed very close to the original he had to left it that way. So it's hard to read. You would need ages to make a modern C++-code with the same functionality (out of this). Paul did start that in some parts, but that's just one gigantic puzzle - even with those 140k source in the beginning - it have been 52000 lines of assembler code... I didn't expect that too - and see - I just passed to be two years here now - and the variables still have no names! Look how long it took to have RTC...
So don't worry about the time you invested for Entombed - it's just normal and just a question of endurance. It's just lost if you quit it. Most young programmers underestimate the effort and fail. I'm glad to have met a bunch of hard fellows here

I cant work with code like that .... oh well, thanks.

Hehe, that's what I said when I got the code for the jpeg- and png-library the days. Fortunately we got angels here

Its not that I cant understand it ... I just dont like code that has magic numbers/variables in it.

In CSBwin Paul gave names whereever he could and whereever it was needed.
If there's still some D7 or similar left, it's just a temporary variable like i. Read it that way, and it works.
There are just a few routines left that have a 'tag'-name, those are not important for your needs.
Others code always needs a time to get familiar with it. For your needs you really should spend it, think it's worth it. The pedia helps to understand too.
You also could check the lua-code of DSB - Sophia keeps it at close as possible too, and I think there it is easier to read.

(If you try to analyze 'checkmissileencounter' in original, you know what overloaded functions in C++ are good for )

The problem with (the version I checked) of DSB was the split between hidden and available code. Without the full view I wasnt able to see how it all hangs together. Its not a big deal, just wondered why everyone is going through the same pain when the hard work has already been done once. If someone released a wiki on the original code then maybe a new elegant version code be created .... just a thought. It may of course be a huge job (probably is) so I appreciate why it hasnt been done.

But - that's what they are doing all the years
The hidden code of DSB is nothing more than channeling the lua-code and do the hardware stuff I bet.

My project was just started because I wanted it that way. I started that 20 years ago, and with the available information, I now had the chance to finish that. Wasn't meant to build a new clone, was the challenge only
Then - I was in hope that I can bring it faster to a more readable and editable C++-code and help to gather the informations faster. There I was wrong I think

I assumed the same with DSB but there is a lot of hidden code to do with the engine, so its not transparent and not a complete picture. Again, I havent looked at DSB for months so it may all be in lua now.

About CSBwin:
The structures of CSBwin are partially explained in the headers, more you can find in links like that:
http://dmweb.free.fr/?q=node/1363
Rest of the work is using the 'search in files'-function of MSVC wisely to find all dependencies.
Then you'll find the big image and the exact formulas.
About DSB:
I'm sure Sophia will help with any question, just ask her, (PM usually works instantly )
You maybe even should consider to use LUA too to save a lot of work - just talk to her to have some kind of a common port.

Think we all want to play Entombed one day

Bit is correct. Pretty much everything in DSB that is compiled code and not distributed with the usual DSB download is mostly just to glue Lua together, to handle graphics, and whatnot. All of the actual DM formulas and such are written in Lua and can be seen or edited just by looking at the files. They're not entirely clear, and I'm not 100% sure I've gotten it completely DM-accurate, but I get closer each revision as I learn more.

The combat algorithm is in base/methods.lua in the gigantic method_physattack function. DSE, I'm not sure what you think you're missing, but I assure you, it's probably less than you think. Of course I'd be happy to fill in any gaps in understanding you may have.

I am only playing devils advocat here as writing something that is similiar to the original is probably not massively difficult, however I am trying to see if a common 'engine' can be written that is more open to amendment on the graphics side. Writing the combat, spells, monster ai, etc isnt particularlly interesting to me and wondered if these could be in a shared project with public interfaces that can be used to control the backend of the game.

So, hypothetically ....

Is there any reason why I cant take your lua code and write an exact copy of dm using your implementation of the code with a differenct gfx front end ? I was basing my original postings on a message exchange we had many moons ago (when you first released dsb), I apologise if I got it wrong. I think you stated originally that there was a lot of code for timers or something in the compiled code, I may be wrong.

To clear this up then. I can write, run and interface with lua from my preferred language, so what is required in the host app to make your scripts work ? Obviously, you dont have to answer if you dont want :O)