Graphics Replacement in DSB

This forum is for the Lua scriptable clone of DM/CSB called Dungeon Strikes Back by Sophia. Use DSB to build your own highly customised games.

Moderator: Sophia

Forum rules
Please read the Forum rules and policies before posting.
User avatar
Gambit37
Should eat more pies
Posts: 13714
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Graphics Replacement in DSB

Post by Gambit37 »

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:

Code: Select all

gfx.apple = dsb_get_bitmap(path .. "apple-red")
This code is in a linked objects file items-food.lua that's pulled into my objects.lua using:

Code: Select all

dsb_import_arch('_lua/items_food.lua','')
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?
User avatar
Sophia
Concise and Honest
Posts: 4239
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Re: Graphics Replacement in DSB

Post by Sophia »

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.
User avatar
Gambit37
Should eat more pies
Posts: 13714
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Graphics Replacement in DSB

Post by Gambit37 »

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?
User avatar
Sophia
Concise and Honest
Posts: 4239
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Re: Graphics Replacement in DSB

Post by Sophia »

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.
User avatar
Gambit37
Should eat more pies
Posts: 13714
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Graphics Replacement in DSB

Post by Gambit37 »

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.
User avatar
Gambit37
Should eat more pies
Posts: 13714
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Graphics Replacement in DSB

Post by Gambit37 »

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....!
User avatar
Sophia
Concise and Honest
Posts: 4239
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Re: Graphics Replacement in DSB

Post by Sophia »

So it's working ok?
User avatar
Gambit37
Should eat more pies
Posts: 13714
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Graphics Replacement in DSB

Post by Gambit37 »

Yes, it's fine, I was being a complete muppet and saving the updated icongrid in totally the wrong folder :D
User avatar
Gambit37
Should eat more pies
Posts: 13714
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Graphics Replacement in DSB

Post by Gambit37 »

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.
User avatar
Sophia
Concise and Honest
Posts: 4239
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Re: Graphics Replacement in DSB

Post by Sophia »

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. :mrgreen:
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.
User avatar
Gambit37
Should eat more pies
Posts: 13714
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Graphics Replacement in DSB

Post by Gambit37 »

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.
User avatar
Sophia
Concise and Honest
Posts: 4239
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Re: Graphics Replacement in DSB

Post by Sophia »

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.
User avatar
Gambit37
Should eat more pies
Posts: 13714
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Graphics Replacement in DSB

Post by Gambit37 »

Nice, thank you :)
User avatar
Gambit37
Should eat more pies
Posts: 13714
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Graphics Replacement in DSB

Post by Gambit37 »

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.
User avatar
Sophia
Concise and Honest
Posts: 4239
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Re: Graphics Replacement in DSB

Post by Sophia »

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?
User avatar
Gambit37
Should eat more pies
Posts: 13714
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Graphics Replacement in DSB

Post by Gambit37 »

I used code you previously gave me when you were developing the feature:

Code: Select all

function monsters_going_through_doorframe(arch, id, boss, dir)

	local lev, x, y = dsb_get_coords(boss)
	
	-- Someone from the front row should step through first, or
	-- it doesn't look right
	local frontguy = search_for_type(lev, x, y, dir, "MONSTER")
	if (not frontguy) then
		frontguy = search_for_type(lev, x, y, (dir+1)%4, "MONSTER")
		if (not frontguy) then
			frontguy = boss
		end
	end
	
	lev, x, y = dsb_get_coords(id)
	-- dsb_move_moncol works like dsb_move except it also performs
	-- monster movement collision detection, so monsters stepping
	-- forward don't "teleport" through arrows/fireballs/etc.
	dsb_move_moncol(frontguy, lev, x, y, CENTER, dir, true)	
	
	-- returning true means that the monster movement was handled by
	-- this function, and the engine should consider the monster party
	-- as having taken its turn properly
	return true	
	
end

function enable_without_monsters(id)
	local lev, x, y = dsb_get_coords(id)
	for d=0,4 do
		local full = search_for_type(lev, x, y, d, "MONSTER")
		if (full) then return end
	end	
	dsb_enable(id)
end

function check_for_monster_toggle(id)
	if (dsb_get_gfxflag(id, GF_INACTIVE)) then
		enable_without_monsters(id)
	else		
		dsb_disable(id)
   	end
end
And then this is how they are defined:

Code: Select all

obj.door_narrow = clone_arch(obj.door_wood, {
	class="NARROW",
	msg_handler = {
		[M_ACTIVATE] = enable_without_monsters,
		[M_TOGGLE] = check_for_monster_toggle
	},
	bash_power = false,
	fire_power = false	
} )

-- Narrow Door 1
gfx.door_narrow_squarewindow = dsb_get_bitmap(path .. "door-single1")
obj.snp_door_narrow_squarewindow = clone_arch(obj.door_narrow, {
	front=gfx.door_narrow_squarewindow
})
I'll PM you screenshots of the offset problem.
User avatar
Sophia
Concise and Honest
Posts: 4239
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Re: Graphics Replacement in DSB

Post by Sophia »

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.
User avatar
Gambit37
Should eat more pies
Posts: 13714
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Graphics Replacement in DSB

Post by Gambit37 »

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.
User avatar
Sophia
Concise and Honest
Posts: 4239
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Re: Graphics Replacement in DSB

Post by Sophia »

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
User avatar
ebeneezergude
Expert
Posts: 345
Joined: Mon Jan 21, 2013 10:58 pm
Location: I see walls stretching off into the darkness...

Re: Graphics Replacement in DSB

Post by ebeneezergude »

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!
User avatar
Gambit37
Should eat more pies
Posts: 13714
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Graphics Replacement in DSB

Post by Gambit37 »

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:

Image Image
User avatar
Sophia
Concise and Honest
Posts: 4239
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Re: Graphics Replacement in DSB

Post by Sophia »

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.
User avatar
Gambit37
Should eat more pies
Posts: 13714
Joined: Wed May 31, 2000 1:57 pm
Location: Location, Location
Contact:

Re: Graphics Replacement in DSB

Post by Gambit37 »

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 :-)
User avatar
ebeneezergude
Expert
Posts: 345
Joined: Mon Jan 21, 2013 10:58 pm
Location: I see walls stretching off into the darkness...

Re: Graphics Replacement in DSB

Post by ebeneezergude »

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.
Taidef1972
Neophyte
Posts: 1
Joined: Wed Aug 12, 2015 8:05 am

Re: Graphics Replacement in DSB

Post by Taidef1972 »

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.
Post Reply