Dungeon Master Forum

I'm puzzled how graphics replacement of existing named images should work?

So far, I've been working with brand new entries in the gfx table, and using full paths to images in various folders. It doesn't matter whether I define the new gfx entries in my graphics.lua, or objects.lua, or anywhere else -- they all work fine.

But now I'm working with replacing existing entries and can't get it to work, for example: This code is in a linked objects file items-food.lua that's pulled into my objects.lua using: DSB finds the image OK (no errors), but it doesn't work: the original apple graphic is still displayed in game.

However, if I move the replaced gfx.apple into my graphics.lua -- then it works!?

I don't understand this -- why do new gfx definitions work from any .lua file, while replacements don't? Could you shed some light on this?

Gambit37 wrote:I don't understand this -- why do new gfx definitions work from any .lua file, while replacements don't? Could you shed some light on this?

The reason it doesn't work has to do with the order that Lua files are parsed by DSB.

DSB first parses the base global.lua, then its lua_manifest, then your custom startup.lua, then your custom lua_manifest. After all that is done, it parses the base objects.lua and anything imported by it, and after that, your custom objects.lua and anything imported by it. What this means is that at the time of parsing the base objects.lua, the default gfx.apple is still the one being used (because you haven't replaced it yet) so this is the one that gets pulled in by the core and cached.

DSB allows graphics loading in importable archetypes so that they can be self-contained and load any graphics they need. I don't bother to actually enforce this, because it's a pain, but that's really the only reason it's there and the only thing it's intended to work for. Trying to load graphics for object archetypes defined outside of that file has problems, as you've seen.

So, basically, you're loading your graphics in the wrong place.

My head hurts

I think you're saying that graphics loaded via a linked file won't work, because it's not a named importable archetype?
So therefore I can't keep my files nice and neat, and will have to put any override graphics into the graphics.lua?

What's your idea of "nice and neat"?

You don't have to shove everything into graphics.lua if you don't want to. You can load graphics in as many different files as you want, as long as they're all in your lua_manifest.

What you can't do is load override graphics inside of an importable archetype. Realistically, you shouldn't load anything not used by objects that aren't defined within that file.

OK, cool, I get it now
I was trying to keep all associated stuff together, so in the example above, all new food objects along wIth their graphics AND any graphics overrides of existing food would all be put in the same file.
Clearly, that won't work, so I'll have to do it differently.

Hmm, I'm still struggling with this replacement order issue.

How and where should I change the icons of a base-engine arch to point to different icons on my icon sheet?
For example, I want to have the torch use different icons, in different slots on icongrid. No idea how to do this - whenever I try something, the icons come up blank when I pick up the torch.

EDIT: Argh, never mind, I saved my updated icongrid in the wrong place....!

So it's working ok?

Yes, it's fine, I was being a complete muppet and saving the updated icongrid in totally the wrong folder

I am having tons of trouble creating different sized doors.

In trying a slightly wider door, if I get it looking good at the front position, it's too wide at the automatically scaled 'front_med' and 'front_far positions'. I also can't seem to adjust it's offsets for the side1,2,3 positions.

Is it possible to override all the hardcoded defaults for door scaling and positioning, so that I can instead use my own scaled graphics and position them manually? (As you would for a flooritem)
Simlarly, the door-button hardcoded offsets are a bit weird and it would be great if these could be overriden too.

Gambit37 wrote:In trying a slightly wider door, if I get it looking good at the front position, it's too wide at the automatically scaled 'front_med' and 'front_far positions'.

You can give bitmaps an x_compress (or y_compress) value the same way you give an x_off (or y_off) value. In the standard DM graphics set, I use it to make scaled alcove side views look right. In the current version of DSB, it won't work quite right for doors-- the values you put in won't seem to make much sense with what you get on your screen-- but it will work so you can at least play with it. I'll fix for 0.55 it so it works more sensibly, and the value given is simply the amount to reduce the size of the source bitmap.

Gambit37 wrote:I also can't seem to adjust it's offsets for the side1,2,3 positions.

The easiest fix here is to make a door arch support and use a side property. That will allow you to specify a separate bitmap with its own offsets.
Fortunately DSB 0.55 already supports that, so this problem will go away, too.

Gambit37 wrote:Is it possible to override all the hardcoded defaults for door scaling and positioning, so that I can instead use my own scaled graphics and position them manually? (As you would for a flooritem)

Not easily, because the DSB engine has a certain number of bitmaps allocated to each arch. For doors, some of those are used for the deco, the bashed mask, and other things that flooritems don't have. I could make it work, of course, but I feel like the engine hacks I'd have to do (and all the separate bitmaps you'd have to create!) make it worth trying to tweak the automatic scaling code a little more first.

Gambit37 wrote:the door-button hardcoded offsets are a bit weird and it would be great if these could be overriden too.

What hardcoded offsets? They have an x_off and y_off specified in graphics.lua. You can change these.

Not sure I fully understand how the compress values would work, if I can't also specify my own front_med and front_far bitmaps?

How would I set compress values for only some of the views, since there aren't actually any other "real" views to affect?

The doorbutton offsets I mentioned is the positioning at the scaled views. I need to offset it a bit on the furthest views, but not the closest one. If I adjust the x_off and y_off this affects all the views.

Gambit37 wrote:Not sure I fully understand how the compress values would work, if I can't also specify my own front_med and front_far bitmaps?

How would I set compress values for only some of the views, since there aren't actually any other "real" views to affect?

Ok, I see what you're saying. I'll make it support mid_compress_x and far_compress_x, instead of just using one value.

Gambit37 wrote:The doorbutton offsets I mentioned is the positioning at the scaled views. I need to offset it a bit on the furthest views, but not the closest one. If I adjust the x_off and y_off this affects all the views.

You can modify mid_x_tweak or far_x_tweak (or y, of course) and this will only move the image at those views.

Nice, thank you

I'm playing around with the new narrow doors, and found that the x-offsets for the side1,2,3 view positions are completely off. Is this something I will be able to tweak with the changes you're adding for v0.55?

Also, narrow doors instantly vanish/reappear when opened and closed -- no animation. is this intentional or a bug? Looks quite strange to be honest, would be great if they could animate like the normal sized doors.

Gambit37 wrote:I'm playing around with the new narrow doors, and found that the x-offsets for the side1,2,3 view positions are completely off. Is this something I will be able to tweak with the changes you're adding for v0.55?

Maybe...?
I guess I'm not quite clear on what exactly is wrong.

Gambit37 wrote:Also, narrow doors instantly vanish/reappear when opened and closed -- no animation. is this intentional or a bug? Looks quite strange to be honest, would be great if they could animate like the normal sized doors.

Which narrow doors?
I'm thinking it's probably a bug somewhere. How have you defined them?

I used code you previously gave me when you were developing the feature:
And then this is how they are defined:
I'll PM you screenshots of the offset problem.

Oh, ok.
Yes, they just vanish because that's how they're designed. I just made them work like the RTC version you showed me a while ago.

I'll look into the issue with offsets.

Ok, cool. I think the reason it looks odd is that in the RTC version I left a sliver of door showing which seems to sell it better. I'll try that again here with a floorflat of the sliver displayed underneath the closed door, so that its revealed on opening.

Well, if you want sliding doors, I can do that, too.

For DSB 0.55, I've added four new renderer_hacks for doors:
"LEFT" = opens to the left (always)
"RIGHT" = opens to the right (always)
"NORTHWEST" = slides to the north or the west
"SOUTHEAST" = slides to the south or the east

Hi all, a quick query on bitmap capabilities in dsb: what are the limitations and rules for custom bitmaps in terms of supported file types, min/max colours, transparency options/requirements,etc. If starting some custom graphics, what do I need to know from the outset? (sorry if covered elsewhere, couldn't see it)

Thanks!

PCX or PNG, though I'd forget about PCX as it's super limited and PNG offers better compression.

You can use 8bit (256 colour) images with simple transpaprency using power pink (RGB 255,0,255)
Or you can use 32bit (24bit colour + 8 bit alpha channel) which will allow the full range of transparency for soft edges, shadows, etc.

Here's an example of both:

You also can use 24 bit images without an alpha channel, and they will use power pink transparency.

As for file formats, BMP is also supported.

Sophia wrote:As for file formats, BMP is also supported.

But as they are raw bitmap data with no compression, they are huge. PNG is much better

Thanks both of you, very useful. I like the 24bit/8bit alpha combo. Looks good for object bitmaps when used with higher res RTCWM generated wall bitmaps.

Qwerty wrote:Thank you the answer ,Sophia!!
It is very useful.But I have not understood the usage of Allegro yet.
Therefore, I will get and study the usage of Allegro.

Sofia is always been supportive to the members of the forum. I really her words and support.