Dungeon Master Forum

Yes, in the fantasy world where I have unlimited time to work on whatever, I have thought what a wonderful thing it would be to provide a sort of framework of Lua functions that would allow clone authors to have a DM "kernel" running and focus on the aspects that were the most interesting to them.

I personally find mechanics, spells, AI and so on more interesting than graphics so it'd be a harmonious match.

As it stands, I'm not sure how useful the DSB code would be in a project that isn't DSB. The only thing missing would be the "dsb_*" functions, most of which are related to graphics and such-- but your mileage may vary depending on how different your internal structuring is from DSB.

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 ?

In fact that's why I pointed to DSB - it's probably the easiest way. But be fair and prepare a bag of cookies for her

btw: converted CSB-graphics also and CSB-version is running too now. Just caught the first bug. Text doesn't scroll up - at least not the initial message of the first level. grummel grummel. Not uploaded yet.

But now it's uploaded here!
I already spotted one problem: teleporters' side view - they simply vanish. That's a mask problem. One of those converted graphics is a pure mask and its color doesn't fit to the expected one. If I remove all graphics, it's all okay. Have to check it out later, can't say quickly which graphic that is.
A basic savegame is added to start with.

Bit wrote: version of my DM/CSB-clones working in truecolor and hires

Which resolution do you go for? I'm asking because with my own DM-like rendering framework I have the problem that the file size of the graphics totals to much more than I'm comfortable with. I'd like to get a feeling what is considered "hires", so that I can adjust my plans. Lately I am pondering about changing to 640x400 or even 512*350 for the dungeon view.

Well, today most of the monitors go with 1280*768, go up to 2048*1536.
If I'm not wrong, then 1024*768 is the limit of Allegro (at least it was).
In our case, we must do multiples of the original 320*200. 960*600 is the maximum which is allowed then.
(And in that case 0,5 GB memory should be enough - and I'd say every modern computer got this).

It is easy to add a multiplier in the routines, and stretch bitmaps when loaded, that's what I would suggest.

With hires we run into the same problem as the DM-makers - memory. Even if you got 2 GB onboard.
You carefully have to count together what can come (per level or per zone). If there things pass the limit, you have to have a graphics cache, and maybe some things stored as PNG or others. Thinking access time to harddiscs is pretty fast nowadays and grabbing from there all the time is not such a good idea.

Unfunny side effect for hires for DM/CSB-clones based on the original:
To have all coords as they are, and just enhance the drawings and bitmapcopies, this also includes the mousecursor. And then it goes in steps of the multiplier too. It would be possible to have Allegro's mouse too, but interrupts have to lock code and variables - and this can go pretty deep with bitmapcursors like the one in the upper zone that is partially masked when you got an item in hand an go into the viewport.

one thing:

if i come to the csb ending screen menue I can select only "restart"
If I choose restart
then the normal (tiny screen message) comes, there I can again select "restart" and also "quit"
kind of double-ish, just wanted to report.

when in dm,
the scroll appears with the credits on it and there comes the tiny message with restart and quit!

Bit wrote: In our case, we must do multiples of the original 320*200. 960*600 is the maximum which is allowed then.

You never make tiles in other dimensions? I started my own DM-like project with rendering new walls and floors. So I am free to choose whatever size I want, but if I change my mind it will take hours or days to render all the views again in the new size. Till now I had expected that is the common aprroach - ah well, learned something new

Bit wrote: (And in that case 0,5 GB memory should be enough - and I'd say every modern computer got this).

So far my two wall types, two floor types, one sort of gates, and a few minor items fit into 48mb ram, together with the walkaround demo code. An item of average size will add about 300-400k to that. Monsters a bit more, due to animations and such ... but you are right, there only has to be the data for one level in ram, or a clever streaming solution in place.

Bit wrote: With hires we run into the same problem as the DM-makers - memory. Even if you got 2 GB onboard.

Since projects use to grow all by themselves I rather want to plan small, and have reserves to grow into. So at the moment I want the core in 64 MB, and the next few version not exceed 256mb ram.

960x600 are huge tiles. If you stand in front of a wall, and it fills all that area (I think a standard wall block doesn't, but I don't know how big the gaps left and right are) it will be ~ 1.7 mb in ram (assuming 24bpp), and you need a few more not much smaller views of such wall blocks.

Ok, that is good to know and also good to have a comparison. Since my 640x480 appears rather small in comparison to these numbers, but so far I had considered it large, I think it's alright to call it "small" instead and then go to "really small", 512x350, save disk space and ram and have the option for many more items, monsters, and of course lower times to create the tiles, also quicker loading.

Thank you for helping me to sort this out

To keep the multiples is a very specific problem.
The original datas come with (more or less hidden) coords and rectangles.
There are a *lot* of calculations with them which had to be adjusted too - there you can't trick me in!
For not having to change them, I just multiply their values in routines like shrinkblit, mirror, blit etc.
In conclusion that means, that there is a kind of a grid now. Nothing can be *positioned* within the grids, but all that is once there (like a loaded bitmap), can be copied and will be kept. Shrink and mirror also work within bitmaps, because the grid is kinda outside.
Try to resize one of the graphics and play it with that one - effect is: *nothing*
That's because size and height of the bitmap is defined by the rectangles within other datas, so I simply shrinkblit the graphic to the needed size when loaded! As I said - that's very project-specific!!!

There's just one problem: the teleporter animation.
Here, the calculation starts randomly within the bitmap and then just steps (modulo) ahead.
With the bitmap stretched in X and Y you got a lot of more pixels, and even a step of *3 won't help, because there are the additional Y-lines too. I decided to trick here, resizing the graphics back to the original and painting 'thick' pixels then - at least it looks original in the newest version (not uploaded yet).
The mask-problem became solved too meanwhile! I'm in good hope that I got it now!!!

@zoom:
Hey, you already played it to the end with no more bugs? - Don't tell me you killed poor Petal

Yes, I'm aware of that thing. That comes because original CSB leaves the game 'from deeper in the routines' and I want a clean restart instead of doing an endless loop, so I have to climb up the routines and get this effect. Perhaps I should simply do a division by zero and catch the exception
But hey - the whole clone is nothing but 'development environment' for the adjusted graphic routines. Only those shall go to CSBwin if somehow possible!

Links to fixed versions updated in the first post. Let's press thumbs that all works now!

Try some modifications!
If you got the Irfan viewer, load the mummy 475pic.png-478pic.png, apply the effect 'oil paint' (maybe even twice), save back and play to it. Or do it with the entrance door - 004pic.png. Works fine!
Just don't change maskcolors. A whole picture with a maskcolor in it 1 point darker or lighter - and the mask fails!

I see, you need to make this fit into the original code constraints. I took the freedom to start all new, which of course also means a lot of extra work to create the games core. But I think I can steal some code from my former tries to create RPGs, so it should be fairly swift once decided what I want to create.

I just took a look, and was reminded about an old question that I never could solve. The monster from images 462pic through 464pic - I met that in the original DM, but it seemed peaceful. At least I do not remember it attacking my party. I didn't quite know what to do with it - in one game I just left it, in a second game I think I killed it.

What is this monster? It seemed the only peaceful inhabitant of the dungeon.

Bit wrote:If I'm not wrong, then 1024*768 is the limit of Allegro (at least it was).

You're wrong.
Allegro can display any resolution that your computer and video card can... so if this is the limit for you, I don't think it's Allegro's fault.

Hajo wrote:I met that in the original DM, but it seemed peaceful. At least I do not remember it attacking my party. I didn't quite know what to do with it - in one game I just left it, in a second game I think I killed it.

That's a ruster. It was supposed to rust your equipment, but it doesn't. So it doesn't do much of anything.

Thoguh it does attack. Just it has no attack graphics. Still does damage and poisons you.

Good news Sophia!
So I can change X/YFACTOR from a define to a variable and people can handle tapestries

Sophia wrote:That's a ruster. It was supposed to rust your equipment, but it doesn't. So it doesn't do much of anything.

Thanks for solving that mystery

Sooooo - got now Win 7 and MSVC 8.0 express on a little notebook - and it compiles and runs (and immediately spotted and fixed one more graphic bug - zokathra wall in DM got screwed in distance...). Now I slooooowly will try to apply the drawing routines to CSBwin. Once more a thing that I cannot promise that I can make it, but - so far I gladly could realize all the ideas.
One thing is for sure - there must be a cut in the original graphic's cache management. Once a graphic is loaded I can't delete it anymore. That's because I never really understood the way they handle that and had to get rid of those variable sized structures. I think today's onboard-memory can handle a lot of large truecolor graphics.

Just wanted to stop by a tell you that everything works as it should Good job!!

Hehe, yes, on the first view. Just go to the hall of champions and ask yourself if the inscription at the wall isn't a bit bright - that's because the distance-lighting in the shrinkblit-routine is there, but commented Probably I'll find some more of those, will clean up now. Fix not uploaded yet.