Mon Ful Ir wrote:I'm struggling because ESB doesn't handle graphics.
Yes, this is probably its biggest weakness at this point.
Mon Ful Ir wrote:RTC-compatible dungeon graphics in .png format should be directly importable into DSB--I believe the scale, and the "hot pink" background, will work in DSB in the same way as they would in RTC. Is that right?
Yes. Almost all graphics that will work in RTC will work in DSB.
So, here's a simple walkthrough on how to import graphics:
This first step needs to only be done once (per dungeon); in your custom dungeon's directory, create a file called
startup.lua and add the following to it:
This step is not strictly necessary, but it will allow us to put all of our graphics importation stuff into a separate file. It also allows us to add more source code files to the custom dungeon simply by adding another filename to the
lua_manifest. ("graphics.lua, "code.lua", "new_spells.lua" etc.)
In
graphics.lua, a basic graphics importation command looks like this:
Code: Select all
gfx.something = dsb_get_bitmap("SOMETHING")
Don't specify a file extension as DSB will figure it out. If your organization scheme is something past the days of DOS, you can also use a longer scheme:
Code: Select all
gfx.something = dsb_get_bitmap("SHORTNAME", "path/to/actual/file.ext")
In this case, since you're specifying a path, you need an extension. The short name is still essential because this is how DSB will refer to the file once a
graphics.dsb is compiled. There is no rule that the short names have to be in all caps, it's just a convention I've been using, by the way.
Once your graphics have been entered into the
gfx table, you can use them in custom objects. You'll need to create (or edit, if you already did) the file
objects.lua, also in your custom dungeon's directory. This file is always automatically parsed-- you don't need to add it to your
lua_manifest.
So, let's say we've loaded a graphic that we entered into the
gfx table as
gfx.new_apple_icon, with the intention of replacing the icon of an apple. Add the following line to
objects.lua:
Code: Select all
obj.new_apple = clone_arch(obj.apple, {
icon = gfx.new_apple_icon
} )
What
clone_arch does is make an exact copy of the object archetype, and then merge the provided table of changes into that copy. In this case, the table only has one entry, so all that changes is the icon. Let's say we wanted to make our new apple heavier, give it a different look in the dungeon, and raise its nutritional value. Something like this would work:
Code: Select all
obj.new_apple = clone_arch(obj.apple, {
icon = gfx.new_apple_icon,
dungeon = gfx.new_apple,
mass = 8,
foodval = 1000
} )
The process of creating a monster, wallitem, etc. or anything else based on an existing one is the same as the process for items. All object properties can be discerned by looking at
base/objects.lua, I'd think. It is a little more arcane than the RTC approach to object creation, but, on the other hand, all properties are 100% there and editable, as opposed to having to worry about cloning and inherent properties. It's perfectly possible to define objects completely from scratch in DSB, as well, as many of them are in
base/objects.lua. I should point out, having said that:
clone_arch is just a convenience, as there is no real "cloning" in DSB and all object archetypes are independent entities. That is to say,
clone_arch creates a simple copy, and there is no real sense of "inheritance."
Sorry if this seems messy but it's really not so bad once you get the hang of it. All of this has already been done in the DSB test_dungeon if you'd like an example of it in use.
One final note: When your dungeon is ready to go, all you have to do is add a "Compile=1" to line to the first section of
dsb.ini and a
dungeon.dsb and
graphics.dsb will be created, which are compiled (and compressed/obfuscated) versions of your dungeon and graphics. You can hide your Lua code from prying eyes with the LuaC compiler.
I reduced the character to a mere mortal and the additional text works fine.