Dungeon Master Forum

Cool, thanks, this will be useful in making some *redacted*

Is it possible to make fullscreen renderers transparent? If not, how could I render something like a semi-transparent scroll over the entire screen (while locking the game as the renderer does)?

Also, what are the three damage_types represented by the 3 coloured stars in damage.pcx? First is clearly "physical", but the other two?

Oh, and in other news, I finally tried dsb_game_end(). Nice!

^^^ Just a quick bump re: the above

I am seriously like 90% sure I wrote a whole post in reply to this a couple of weeks ago.
I wonder what happened... Eh, anyway, sorry for the delay.

You can lock the game via, surprise, dsb_lock_game. Using a combination of that, overlays, and control over the system renderers, I think you can draw whatever you want on the game screen. If there's something you want to do that's still eluding you, let me know, and I'll try to figure something out.

The three images are health, stamina, and mana damage, respectively.

Sophia wrote:You can lock the game via, surprise, dsb_lock_game. Using a combination of that, overlays, and control over the system renderers, I think you can draw whatever you want on the game screen.

I've not yet looked at your suggestion, but just thinking about it now, is the only way of doing an overlay to use a condition? If so, bitmaps placed during conditions seem relative to the the viewport, so presumably I'd have to work out offsets correctly to draw a fullscreen image relative to the top/left of the viewport?

Basically, I'd just like to have the functionality of a fullscreen renderer, but its background to have semi-transparent parts. Would it be possible to make the fullscreen renderer do that, or does it always have to blank out the game view first?

As I understand, fullscreen renderers completely override the normal game renderer (it's not an overlay, it's a replacement).
However, you can take a screenshot of the screen, then paste it on the fullscreen renderer with alpha channels.

My 2 cents.

Joramun wrote:However, you can take a screenshot of the screen, then paste it on the fullscreen renderer with alpha channels.

Aaah, interesting, though I'm not entirely sure how I'd do that? I can't see any dsb_* functions that could grab the whole screen?
EDIT1: Just saw dsb_screen_bitmap(???) = ??? at the bottom of the list.... hmmmm.... think I need some Sophia input here
EDIT2: Tried it out, it takes a screenshot of the whole desktop: so it works if you're playing fullscreen (Yay!), but not if you're in a window (Just grabs desktop from top left 0/0, boo!)
So maybe if there was a simple function to grab the full 640x480 of the game rather than the desktop, all my problems would be solved... hint, hint

In other news, I finally got all my DSB code into Git, which will make testing out different approaches a bit easier!

So, if I understand it correctly, what you want to do is to have a full screen renderer that draws the game screen underneath.

If that's right, the simplest way to do that would probably be just to set up the full screen renderer to actually just do that, rather than messing with screen grabs and such.

Yes, but how do I do that? What are the functions for rendering the entire game screen? I know I can render the viewport in one dsb_ function, but what about everything else?

Sorry, I wasn't clear.
You can't do it yet. I will add it.

Aha, right, I see! OK, cool, thanks

I've expanded the fifth parameter of dsb_fullscreen from simply being a boolean to also being able to take a table of bools. Fading is still controlled this way, by fade in that table, but I've also added game_draw, which allows you to have the game view drawn in the background. So, for example, for a fullscreen view that fades in and draws the game view, do: The flexibility of Lua makes this kind of thing fairly painless.

What does "Preserve Previous Originator" mean in the trigger controller dialog?

It means that the "sender" of the outgoing message will be set to the instance that sent the message activating the trigger controller, rather than the trigger controller itself.
(That is, the trigger controller becomes essentially "transparent")

OK, thanks, I understand. What would be a use case for that? I can't think of any mechanisms where it matters what sent the message?

Gambit37 wrote:OK, thanks, I understand. What would be a use case for that? I can't think of any mechanisms where it matters what sent the message?

e.g: If you want the triggered item to delete the triggering item, but there are several possible triggering items (5 buttons, one button triggers the trigger_controller, which triggers an event, and in that event you want to destroy the originating button - but only if the trigger_controller "passes the message", for example, only if the party faces north)

The example is a bit absurd but that's the typical case.

Joramun's example is indeed a bit absurd, but he's got the basic idea.

Admittedly, it's not terribly useful most of the time. I just included it for that one time when it really is needed.

Time for me to ask a question:

Is there any way to detect when an object is about to collide next frame... so an object is flying through the air and next tick it will hit a monster, but that monster is friendly and we don't wanna hurt our friend, cause he might go all Hulk-like on us
And if we can detect when an item is about to hit, can we determine which object (instance) is about to be receiving an item to the head?

Yes, instances that are about to (possibly) get hit trigger on_incoming_impact. I say "possibly" because there is no collision detection checking done: it is based solely on the fact that the flying instance is about to intersect something; e.g., a fireball will still trigger this when flying at a rive, or a dagger at a portcullis. The parameters for on_incoming_impact are (arch, inst, flying_inst), so you do know what is about to hit, too.

Take a look at monster_dodge in base/monster.lua for the code that makes monsters hurriedly rearrange themselves on the tile if a projectile is about to hit them and there's somewhere to go. (They often randomly fail to do so because otherwise initial testing they were just too good at it!)

If you need to take this apart further, the warning is generated via sys_warning_flying_impact in base/system.lua, but the "object oriented" way to handle it will probably result in saner code.

Cool. Thanx.

EDIT: This needs to get put on the DSB wiki. If I've gone looking for it within just days of downloading the latest version of DSB, then something tells me that there's gonna be plenty of people wanting this functionality.

The thing about a wiki is that anyone can edit it...

Ok. Next question, how do I make the flying object do the detecting (say it's about to hit a wall, and you want to make it turn and keep going)? The way you describe above is useful for making a monster "dodge"... but, how about making the object avoid the monster?

how about making the object avoid the monster?

for that, maybe look at the special axe in the Test Dungeon, which flies all but straight.
possibly manageable to tweak it to evade monsters..

Yes, zoom has the right idea. The on_fly event will help you, and the "crazy axe" has a good demonstration of its use.

While testing the idea of getting the axe to avoid party members and walls (so throwing it into a tight space is interesting)... using the on_fly method... I discovered that stepping onto the tile when a flying object is already there (1 character in party, on the NW corner of tile... flying object on SW corner of the tile in front of party, heading towards the character) when stepping forward, the object should impact the character... but it doesn't hit at all, and keeps on flying down the corridor behind the party.

If anything it should hurt more because they actually stepped forward into it. But, that's just my personal opinion.

The issue here was that in some recent version I disabled the code that "pushes" collisions when you step into a flying object, and forgot to re-enable it. In the next version of DSB, it will be re-enabled and this issue will be fixed.

Good to know. Wasn't sure if I should post it as a proper bug-report, or (because it is related to the question I was asking here) if I should ask it here. Keep up the good work.

Yet another question... when using the on_fly method, the flytimer value seems to decrease by a variable amount, depending on the skill level of the throwing character. Sometimes it decreases at 10 per tick (like when a n00b throws stuff), and sometimes decreases at 5 (archmaster ninja). Is there a way to determine this value inside the on_fly method? I'm guessing it's an exvar, but I don't know what it's called.

The reason I ask is because I'm trying to make objects randomly fly a further... if the reduction value is 5/tick, then adding dsb_rand(4,5) onto the flytimer each tick keeps the object in the air a whole lot longer. But, this doesn't quite work the way I'd hoped, when the reduction per tick is higher than 5.
Basically, what I'm looking for is: flytimer = flytimer + dsb_rand((reduction_per_tick - 1), reduction_per_tick)

The value is called the delta, and it's determined by the skill of the thrower (usually), although it can also be set directly when you launch an object from a shooter or something. There's currently no way to set this directly, which I consider to be an oversight in the API, so I'll add it.

If there's no way to set the value, I'm taking it that there's no way to get it either (cause that's all I need).