Tutorials: wallsets and custom monsters, objects, etc

[Gambit37]

Use of RTCWM: I’ve been using this very useful app [but] the final output it produces creates a very slight blur to the final image. [...] also has a very minor scaling difference to the source image.

Yep it's a great tool, it was created by forum member Linflas (Guillaume) but I don't think he's around here anymore. I also found issues with it so while it's useful to get the initial views of side walls, I don't use it to create final imagery. I always then worked over the top of those images in PhotoShop (for far too long!) to get what I wanted.

Seams and corners: And in particular, corners. This was an interesting read, which I think (stress think) I am following viewtopic.php?p=161014&hilit=Tall+walls#p161014 with Gambit and Sophia. Any tips or examples anyone could share here?

No tips to share so far. I did some brief experiments but I think there were some issues with the implementation and I never went back to it. I vaguely recall problems with corners looking wrong next to secret walls that open and close.

Also there is talk over DM 2.x / 3.x graphics: what exactly does this mean?

The original DM had several major version upgrades (v1, v2, v3). The v2 walls are what DSB graphics are based off, but the v3 walls changed the perspective and added an extra tile distance view. I think my original wall experiments for DSB used v3 walls as a base, which is why I had some problems with it all. There's more info on dmweb.free.fr but it's down for me right now.

Wallitems rendering question: is there a way to make a wallitem appear rendered on the Side0 on the player’s tile?

Yes, add an extra definition to your obejct.

Code: Select all

obj.alcove.near_side = gfx.name_of_your_imported_image

Here's an example of the magic mirror with that view showing on the left:

Tall walls/no ceilings: I haven’t tried yet, but is this possible in DSB? If so, any pointers / examples as to how this works?

Yes, this is doable but I've not looked at that for probably a decade! I vaguely recall you have to be very specific about how to contruct the wallsets to get all the pieces to fit together, and it involves using a wallset painting mode in ESB. I really don't recall exactly how it works now, but it is possible, here's some screenshots of my old experiments:

[Ser Xav]

Thanks so much Gambit. Ahh.. Near side… that’s how it’s done. Is that a DSB specific thing or was that part of DM? Am I mis-remembering? Your dungeon graphics are beautiful, amazing job.

Regarding the DM versions I don’t think I’ve ever realised there were versions that differed graphically. I’ll have to go back to the emulators to check this out.

Thank you.

[Sophia]

In DM, if you are standing right next to a pit, you can see the corner of the pit, and if you are standing next to stairs, you see a little bit of the wooden railing. So what DSB calls near_side existed in DM but was very limited.

DSB actually uses neither the v2 or v3 walls, strictly speaking. Originally, it used v2 walls (like CSBwin) but the biggest issue with v2 walls are that the bricks are laid out differently; there is a seam between bricks right where most wallitems go. The way v2 walls created the side views was also less intuitive and made custom wallsets a bit harder. So I got a bit tired of all of this and added the "ext" wallset, which is more v3 style, although in reality is kind of a hybrid. This is actually the same thing RTC does: it uses the 3.x wall bitmaps, but the far left and right are the darker and less detailed v2 versions. In DM 3.x, these far walls were a little brighter and wallitems were rendered on them, but these were automatically generated stretched versions of the wall graphics, and there was a pretty high chance custom graphics would look awful using the same algorithm, so I didn't bother doing any of that.

[Gambit37]

The DM Encyclopaedia has a brief explanation of the perspective differences:
http://dmweb.free.fr/games/dungeon-mast ... comparison

[kaypy]

Also, meant to ask one more, regarding sounds: is it possible to to play a sound when I put an object into the inventory or pick it up? Is there any example code as to do this?

I accidently replied to this without realizing that it was a page old. Then deleted the reply. Then realized I dont think you have been given an answer, so replying again:

Check out obj.rabbits_foot for an item that calls some custom code whenever it gets put into inventory via the to_anywhere callback. Then you just need to play sound instead of doing luck adjustments.

Also, obj.compass has an example of running some code every time its picked up, by using the on_click callback.

[kaypy]

I put together a more concrete example:
startup.lua:

Code: Select all

snd.doom = dsb_get_sound("sounds/doorslam")

function helmdarconpickup(self, id)
	dsb_sound(snd.doom)
end

function helmdarctofrom(self, id, who)
	dsb_sound(snd.doom)
end

objects.lua:

Code: Select all

-- when picked up off ground
obj.helm_darc.on_click=helmdarconpickup
-- when put into inventory
obj.helm_darc.to_anywhere=helmdarctofrom
-- when taken from inventory
obj.helm_darc.from_anywhere=helmdarctofrom

got me a very noisy helm.

[Ser Xav]

Thanks so much Kapya. This is so useful. I’ll have to have a go at this tomorrow when I get a chance. I’d been looking at the DSB wiki but I admit I’d still probably be a little lost trying to implement.

Question: I haven’t seen a line like this before:
obj.helm_darc.to_anywhere=helmdarctofrom

Can it go like this in the object.lua in an object archetype?:

obj.object = {
name=“object thing”,
.
.
.

to_anywhere=soundtofrom
}

Thank you.

[Sophia]

Yes, those are equivalent in Lua.

A short summary of how Lua tables work (copied from here):

Lua tables are defined within { }'s, with a comma-delimited list of elements. { } alone is an empty table, which isn't useful by itself, but is necessary to create a table if you want to add elements to it. Each table can have an arbitrary number of elements, which are accessed via the syntax table[element]. If the name of an element is a string, a short form with a dot can be used. That is, table["thing"] and table.thing are identical.

The following code creates a new table, t, and sets the element x equal to 1.

Code: Select all

t = { x = 1 }

You can then modify the value of x by setting t.x.

Please note the following important distinction.

Code: Select all

-- The following line of code adds an element y to the table t.
t.y = 2

-- The following line of code creates a new table, with a single element y = 2.
-- Any previous table stored in t is gone, as this overwrites t with a COMPLETELY NEW table, containing ONLY the element y.
t = { y = 2 }

[Ser Xav]

Brilliant, thanks Sophia and Kaypy.

I am having another noob moment, advice welcomed please! I have a few door and door frame issues: A custom door graphic I have made appears in front of the doorframe. I have the door and doorframe set like this on the tile in ESB, with doorfram above the door:


1. It all appears fine from close head on for front position 1 and 2, here is Front 2 position:


2. However side 1 and 2, the door is drawn over the frame:



3. And from side 3 - aside from having to adjust my doorframe bitmap with offsets (not yet shown in this screenshot), and aside from the thin grey line that DSB adds (I need to make a custom bitmap for this) - the dooor bitmap looks like it needs an offset towards the left somehow to make it sit back in the frame, but I don't think you can do offsets on door bitmaps? And it's still appearing in front of the door frame:


4. Front position 3, however, exhibits the thin grey line, which again I think is DSB's graphic which I need to manually edit, although for the record here is that position:


I am not sure what I am doing incorrectly here, and what I need to do to ensure the doorframe always appears in front of the door. Any tips most welcomed! Thank you.

[Gambit37]

What happens if you swap the order in ESB?

[Ser Xav]

Then the door appears behind the entire door frame bitmap:

[Gambit37]

I honestly can't recall if I had this problem or if I needed to fix it. I'll have a look in my code at some point but might not be until next week.

By the way, it looks like you've added a soft shadow to the portcullis. It looks a bit strange to be honest, I'd recommend removing it.

[Sophia]

The door is either going to be drawn before the doorframe or after it.

If you want to do something more complicated you may have to split up your doorframe image into two objects: a "near side" doorframe that is always drawn before the door, and a "far side" doorframe that is always drawn after the door. You can then tweak these two separate sets of bitmaps to get whatever look you want.

If you want to automate this, you will have to experiment with create_linked_object to get it working right. I think it just plops the object down on the top of the tile (meaning you have to use the far bitmap as your "base") but I'm not entirely sure.

[Ser Xav]

I've worked out the problem. Looking at the base graphics, DM doesn't actually have side 1 and side 2 doorframes... at least not vertical ones, they're not what I thought they were... side 1 and side 2 are thin horizontal strips.


And in DM you can't see the doorframes at all, compared to my dungeon project screenshots in previous post above:




Doorframe gfx from DSB base graphics.lua... the SIDES are used but only SIDE3 is visible in-game as an actual 'side' bitmap:


So in DM, as actual sides, 1 and 2 are not actually sides. So what confused me is RTCWM creates a doorframe side 1 and side 2 that are vertical, and in my dungeon test shots above they sort of appear positionally correct. But I don't know why they appear 'correct' if it's not intended in DM...! I had unintentionally thought the frames would always be seen, but that's obviously not standard. So if DM and DSB don't draw these side frames as standard, how come they pretty much work in my mistaken test shots?

But to use the RTCWM 'visible' doorframes and for them not to encounter the door overlap issue, the logical solution would be to have two doorframe graphics, and have one drawn before the door and one after, for the frame this side of the door and the other half of the frame on the other side of the door....... which now I understand what Sophia's post is talking about...!

By the way, it looks like you've added a soft shadow to the portcullis. It looks a bit strange to be honest, I'd recommend removing it.

I like my soft shadow!

[Ser Xav]

Just realised also that my farwall3 bitmaps have all been coming out of RTCWM with too much light on them. I'll need to manually blend them to black on their 'far' edge, or go and readjust the Fog setting in RTCWM prior to re-exporting the base bitmaps again.... This would also affect the very far 'side' of the floor, which I've noticed is also slightly incorrect. Uurrghh.

[Gambit37]

By the way, it looks like you've added a soft shadow to the portcullis. It looks a bit strange to be honest, I'd recommend removing it.

I like my soft shadow!

What I mean is that it's not realistic. The gate is shadowed as if there's a light in front of it casting even light on every face, so that the shadow appears to be flat against a kind of invisible plane behind it. When the door moves that's going to look very weird. I did a lot of similar things and found it was just better to remove them all. Up to you of course, just thought I'd offer my view.

As for the doorframe stuff: I don't recall having any of these issues and I can't quitye work out what state my graphics are in so I'm not sure I can help. I'll take another look later in the week and see if anything useful comes up.

[Gambit37]

I managed to grab some time to look at my doorframes. Looks like I did create the missing side views and played with the offsets, but I didn't finish it. My personal devlog todo list has these unticked items:

• Door frames (need 0.78 to finish other_side images)
• Door buttons (need 0.78 for doorframes with buttons)

And the last version of DSB I was using was 0.76. Now that I've updated to the latest 0.84, it's time to revisit this. But it'll be a while until I can, so I reckon you've probably got enough info now SerXav to go ahead and fix it.

Here's my extra sideviews. I don't seem to have used any door offsets to avoid overlaying issues, so that's something I need to investigate too...:

[Ser Xav]

Great, thank you Gambit, appreciate you taking the time to check it out. I think the xtra doorframes add a really nice level of additional detail over and above standard DM frames, I'll have a go at the double doorframes I think, see if this works. On your dungeon screenshots above, do you have the same issue standing directly in front of the portcullis, where the door appears behind the doorframe? Assume that's what your devlog "finish other_side images" means?

Love the graphics/artwork in your shots there, very nice aesthetic and approach to reinventing the original

[Gambit37]

I don't have any issues with doorframes rendering over doors, so I don't really know what's up with that compared to yours, sorry. Thanks for the nice comments about the graphics. I think I'm gonna revert that wall version to an earlier one though (if I still have it)... it's gone a bit wrong to be honest!

EDIT: Oh I just remembered, there's this extra crucial thing you might be missing: door_draw_info is how you can tweak the door offsets to prevent overlaps. I've added this to my render.lua but you can probably add it anyhwere (startup.lua, etc.).

See this post and the replies for more info on how this works: viewtopic.php?p=156748#p156748

Code: Select all

door_draw_info = {
-- scale factor is N/240
	view_near = { x_off = 0, x_off_side = -46, y_off = -2, bottom_cut = 4 },
	view_med = { x_off = 0, x_off_side = 38, y_off = -2, bottom_cut = 2, xscale = 166, yscale = 166 },
	view_far = { x_off = 0, x_off_side = 88, y_off = -4, bottom_cut = 2, xscale = 110, yscale = 110 }
}

[Ser Xav]

The door is either going to be drawn before the doorframe or after it.

If you want to do something more complicated you may have to split up your doorframe image into two objects: a "near side" doorframe that is always drawn before the door, and a "far side" doorframe that is always drawn after the door. You can then tweak these two separate sets of bitmaps to get whatever look you want.

If you want to automate this, you will have to experiment with create_linked_object to get it working right. I think it just plops the object down on the top of the tile (meaning you have to use the far bitmap as your "base") but I'm not entirely sure.

Can confirm this works well, including the create_linked_object method - code below added to the "back" half object of the door frame in obj.DH_doorframe_back. I simply split the door frame bitmap into front and back bitmaps, splitting just behind the door "seam" or side channel. Did the split for front, front_med, and front_far positions in the object, and may need to do a split for the far3 position also - once I fix another issue with far side3 position for the door bitmap itself (it seems out of position for this position and may need some offsets somehow).

Code: Select all

create_linked_object=obj.DH_doorframe_front

So I have two doorframe 'FloorUprights' objects, one for front of frame, and one for back.



Thanks

[Gambit37]

once I fix another issue with far side3 position for the door bitmap itself (it seems out of position for this position and may need some offsets somehow).

You might have missed my post above about door_draw_info -- that's how you can change door offsets.

[Ser Xav]

Thanks Gambit, very good, that sounds exactly like the problem I am having, I will give that a go later tonight. Both for the distance sizing issue which I had originally on the front 3 door/doorframe, and the far side3 issue. Will report back, thanks.

[Ser Xav]

Thanks for this Gambit (and ultimately, Sophia!). I’ve had a go at implementing the door_draw_info. Got it about 95% working. Some minor refinements still needed for getting the fine tuning of the positions and scaling just right. But definitely has helped me fix almost all the issues. A little bit more tweakage and it’ll be there.

Trying to work out why there’s a very minor y position different between my split door frame and a standard doorframe - it’s like 2 or 3 pixels. Can’t work out why yet as the bitmaps are identical dimensions and gfx positioning. I’m sure it’s probably something I’ve got wrong somewhere.

[Ser Xav]

Regarding the create_linked_object , I thought I had it working, but now it appears not to be working. I have copied my code below from the OBJ file, showing the front and back half of the doorframes. The back half doorframe contains the create_linked_object code. ESB/DSB reports no errors with this, but the front half frame is not appearing, either in ESB, or in DSB once the dungeon is run.

Does the new code generate the object at the time the dungeon is run, or when it's placed in ESB?

I am sure this worked when I tested it first. If I place both the front half and the back half manually in ESB, it all works fine. So it's apparently just an issue with create_linked_object it seems. Thanks!

Code: Select all

---------------------------------DOORFRAMES EXPERIMENTAL---------------------------------------------
--DOORFRAME FRONT HALF
obj.DH_doorframe_front = {
	type="FLOORUPRIGHT",
	renderer_hack="DOORFRAME",
	class="DOORFRAME",
	col=doorframe_col,
	same_square=gfx.DHWS01_DOORFRAME_FRONT0,
	front=gfx.DOORFRAME_FRONTHALF1,
	front_med=gfx.DOORFRAME_FRONTHALF2,
	front_far=gfx.DOORFRAME_FRONTHALF3,
	side=gfx.DHWS01_DOORFRAME_SIDE1,
	side_med=gfx.DHWS01_DOORFRAME_SIDE2,
	side_far=gfx.DOORFRAME_FRONTHALF_SIDE3
} 

--DOORFRAME BACK HALF
obj.DH_doorframe_back = {
	type="FLOORUPRIGHT",
	renderer_hack="DOORFRAME",
	class="DOORFRAME",
	col=doorframe_col,
	create_linked_object=obj.DH_doorframe_front,
	same_square=gfx.DHWS01_DOORFRAME_FRONT0,
	front=gfx.DOORFRAME_BACKHALF1,
	front_med=gfx.DOORFRAME_BACKHALF2,
	front_far=gfx.DOORFRAME_BACKHALF3,
	side=gfx.DHWS01_DOORFRAME_SIDE1,
	side_med=gfx.DHWS01_DOORFRAME_SIDE2,
	side_far=gfx.DOORFRAME_BACKHALF_SIDE3
} 

[Sophia]

Linked objects are generated at the time the dungeon is loaded into DSB. They won't appear in ESB.

Try changing the line of code with create_linked_object to

Code: Select all

create_linked_object = "DH_doorframe_front",

There's nothing theoretically wrong with the way you wrote it but direct object references can be finicky because they'll evaluate to nil and silently disappear if you define your archetype in the "wrong" order. So DSB generally prefers to use strings.

[Ser Xav]

Hmm. Thanks, I tried that exact code, but it's still not working. The backhalf doorframe appears, but the front does not come through in DSB. Have gone over my code multiple times but can't work it out. Could it perhaps be related to how I call in the graphics with the .cfg file, or how the .lua files are structured with individual OBJ .lua files?

[Sophia]

Well... the actual problem is that your code does nothing because it's wrong.
I haven't actually messed with this stuff in quite a while. I guess I should have double-checked rather than assuming you used the proper syntax.

Check obj.pit for the proper structure. Something like this should work:

Code: Select all

	on_spawn = create_linked_object,
	link_object = "DH_doorframe_front",
	link_offset = {0, 0, 0}

[Ser Xav]

Great, thanks, all working. Definitely now..! I must have imagined it before. Thank you.

[Ser Xav]

Is there a way to suppress or hide the original DM / CSB monsters and things, objects, etc, from ESB?

My project is based on everything being custom, in ESB my new assets appear alongside the originals from DM / CSB. I give them a project specific prefix to group them together alphabetically in the ESB menu : ie DH_monstername1, DH_monstername2, etc. I keep the existing ESB Class groupings for all assets, ie, for Monsters: HUMANOID, FLYING, EDIBLE, etc - which I guess I could change to my own Class.

But is there way to suppress originals? Or have I just answered by own question - just utilise a custom class naming scheme for assets? Many thanks

[kaypy]

I tested unallocating the object definitions but it wound up crashing things.

Code: Select all

-- dont do this
obj.screamer=nil

So I'm guessing your put-them-in-an-unused-category approach is probably the best option

Code: Select all

obj.screamer.class="UNUSED"