Questions about DSB/ESB

[Sophia]

You can add the tinted icon back directly into the arch's properties, if you want. (Or maybe that's what you meant, anyway.)

Another option, that requires less of a change from the way you were doing it before, is to simply store the id number of inst whose icon you've tinted and then cache the tinted icon. You only bother redrawing and such if that id number changes. That makes it go from once a frame to... infrequently, in terms of the number of redraws, I'd suspect.

[Gambit37]

I did it in the arch's properties, works great

Tinting function (just averages original colour with an overlay colour for now, I'll look into better algorithms to preserve luminance, etc.):

Code: Select all

function tint_bitmap(name,bmp,width,height,tint_colour,newalpha,method)
	local cx = 0
	local cy = 0
	local count = 0
	local bmp_tinted = dsb_new_bitmap(width,height)

	for cx = 0,width-1 do
		for cy = 0,height-1 do
			count = count + 1
			local rgb, alpha = dsb_get_pixel(bmp, cx, cy)

			--tint the pixel
			red = (rgb[1] + tint_colour[1]) /2
			green = (rgb[2] + tint_colour[2]) /2
			blue = (rgb[3] + tint_colour[3]) /2

			--push new pixel into the bitmap
			dsb_set_pixel(bmp_tinted, cx, cy, {red,green,blue}, alpha)
		end
	end
	__log(name..", Pixels converted: "..count)
	return bmp_tinted
end

Then at the bottom of my objects.lua, I added this:

Code: Select all

for archid in pairs(obj) do
   local arch = obj[archid]
   if (arch.type == "THING") then
   		arch.icon_tinted = tint_bitmap(arch.name,arch.icon,32,32,{255,255,0},128)
   		if (arch.alt_icon) then
   			arch.icon_alt_tinted = tint_bitmap(arch.name,arch.alt_icon,32,32,{255,255,0},128)
   		end
	end
end

Now in any rendering function, if I need a tinted icon, I can look up the pre-processed arch.icon_tinted. And of course, if I want a different tint, then I can just call the tinting function on any bitmap when I need it.

Now that I have this working, it's given me LOADS of ideas for cool features

[Gambit37]

Is there any way of overriding the formatting of the current_text? I'm trying to remove all the uppercase text in the game as it's pretty ugly and hard to read when using new proportional fonts.

[Sophia]

What do you mean by current_text? Is this a variable used somewhere?

If you're just talking about changing text strings, then I can include support for modifying those. The ones I see so far that need changing are "GAME FROZEN" and "WAKE UP." I don't really want to touch the save/load dialogues at this point, so those will just keep the upper case FTL font. Is there anything else that needs changing?

[Gambit37]

The current_text is the UI element for displaying the description of currently held item.
I think all other stuff I can change in the code.
Do you think you'll modify save/load stuff in the future?

[Sophia]

Oh, you mean current_item. I'll change that so you can control how it draws if you're so inclined.

I'll probably get around to the save/load stuff eventually, but it's honestly not a huge priority at this point. The coordinates are all hardcoded and changing them to look nice when the font size changes is kind of annoying. Is having the FTL font in the save/load dialogues really a big deal?

[Gambit37]

Oh, you mean current_item. I'll change that so you can control how it draws if you're so inclined.

Ah, sorry, didn't realise I got the name wrong. Thanks.

Is having the FTL font in the save/load dialogues really a big deal?

It's not a big deal as in "Will people die if this change isn't made?", but it looks ridiculously ugly.

[Gambit37]

Oh, hang on, I got confused about the FTL font vs. the actual save/load panels. I thought you were saying that the save/load panels can't be changed, but I just found them in the DSB graphics resources, so I can change them It's not quite so ugly now

[Gambit37]

Is the party marching order code editable anywhere? I just thought of something cool I could do....

[Sophia]

What do you mean?
If you could tell me more about what you wanted to do (in PM if you'd like) then I could probably work something out.

[Gambit37]

Is it possible to make an item that can't be picked up, and/or is too heavy pick up unless something is done to it?

And connected to this, is it possible to prevent massive items form being put in the backpack?

[Sophia]

Is it possible to make an item that can't be picked up, and/or is too heavy pick up unless something is done to it?

Yes. In the item's arch's on_click, make it return true. Generally speaking, returning true from these handlers tells DSB "I processed the event fully myself, don't do what you normally would." In this case, that means the item won't be picked up. Of course, by putting more complicated code in there, you can check whatever conditions you want to set.

And connected to this, is it possible to prevent massive items form being put in the backpack?

The simplest way is probably to set no_fit_inventory to true. This is what zokathra does, for example.

[Gambit37]

Coolio, thank you

[Gambit37]

How do I blit one semi-trans bitmap onto another? I made a semi-trans bitmap in code by iterating over every pixel, but when I try to blit this source bitmap over a destination semi-trans bitmap, all I get back is the source, it's not merged with the destination? Here's a visual:

The left bitmap is my destination, the right is the source generated in code. I want to blend that partially transparent image over the greyscale one, keeping the solid pixels of the greyscale bitmap, but blending the brown semi-trans image over the top.

[Sophia]

You're using dsb_bitmap_blit, right? That just copies pixels.
You probably want dsb_bitmap_draw, which will respect alpha channels and do the kind of blending that you want.

[Gambit37]

Yes, I was using blit rather than draw. So I changed it and now I get back a completely empty bitmap (fully transparent)

I've tested the function by returning just the grey bitmap or the semi-trans brown one, and these both work finre separately. But if I try to combine them I get nothing.

Here's the last few lines of my function which finishes the pixel manipulation loop then draw the bitmap. Is this correct to achieve the above?
(bmp_stone is the semi-trans bitmap shown above, local_grey is the grey scale bitmap shown above:)

Code: Select all

			--push new pixel into the bitmap
			dsb_set_pixel(bmp_stone, cx, cy, {r,g,b}, alpha)

		end -- column loop

	end -- row loop

	dsb_bitmap_draw(bmp_stone,local_grey,0,0,false)

	return local_grey

end

[Sophia]

Well, that code seems like it should work.
I can't really tell any more without knowing more about what you're trying to do and probably having the bitmaps involved.

It might be a bug in your code, or it might be a bug in DSB, or it might even be a bug in Allegro. I can't tell right now.

[Gambit37]

It's sort of hard to send you it due to how it's all so distributed and messy. What would be most helpful?

[Sophia]

I think that having the offending bitmap and the function that you're using would probably be enough. I can drop that into my testing dungeon and see how it works.

[Joramun]

I think that having the offending bitmap

Beware, I bet it's naked Mophus.

[Gambit37]

Not Mophus. It happens with all bitmaps, so it's a code issue. I'll send you the example by PM, Sophia.

[Sophia]

It was actually a problem with Allegro. I've been able to work around it, though; it'll work right in DSB 0.55.

[Gambit37]

Doorframes and doors seem to have a hardcoded rendering order, regardless of how you order them in the editor.
I'm trying to make a door that requires the door to disappear *behind* the doorframe when it opens -- is this possible?

[Sophia]

Yes, it's possible.

Forcing the rendering order like this made sense when DSB dungeons were hand-coded, and correcting issues like this was something that was actually useful for DSB to do. However, at present, I think that pretty much everyone has switched to using ESB, and ESB tries to get the order right and makes it easy to fix if you don't.

I made a quick test of commenting out the lines of code that enforced drawing doorframes before doors no matter what, and nothing seemed to break. So I'll leave them commented out. This means DSB will now use the tile order, rather than any hardcoded convention.

[Gambit37]

Cool, thanks

[Gambit37]

Is it possible to have a non-aggressive monster that the party can "walk over" without it dying?
I know I can set col=false to allow the party to enter the same square, but monsters will always die.
I'd like to have some 'ambience' critters wandering about such as mice, tiny spiders etc...

[Sophia]

No, not really. DM monsters aren't really designed to work like that.
You could make it a flooritem I guess, and give it simple code to move around randomly.

[Joramun]

Or let people smash the mice !

[Gambit37]

But for that to work, they would have to block the party which is a little silly for such a tiny critter

If by removing their attack AI I can get them to move around and away from the party this might be enough. I'm not a good enough programmer to spend time on writing code to manage truly clever passive monsters, so I'm just working within the properties of monsters that are available to me.

Also, is there a property that makes monsters attack each other, like in RTC?

[ian_scho]

Is there a 'party moves into monster' event? You could always teleport it away.

Also, is there a property that makes monsters attack each other, like in RTC?

You'd have to mess about with monster_ai.lua to achieve this, I think. When I played around with it the version of DSB was 0.40 or earlier but now my modifications have lost it's compatibility, I believe.