The Dink Network

So I planned to finish my DMod in the weekend, but instead I worked on my editor. Why? Because I was missing a feature that I needed for my DMod. So I was working on my DMod after all.

Anyway, I'm sure you all want to know what this awesome feature is. And I'm telling you, it really is awesome. It means the end to hardness editing (which I had made much easier some time ago). Please welcome sprite-based tile hardness!

So what is it? It is, that sprites have two images linked to them: the image that is shown, and the hardness image. Whenever the sprite is placed on the map, the hardness image is pasted onto the tile hardness map. When building the DMod, this hardness is used like tile hardness always is.

Because this is tile hardness, it can be normal or "low" hardness (that fireballs can fly over). It will not move with the sprite. Also, it cannot be used to trigger a warp or a push script. But for those, the regular hardbox is still available, of course.

And finally, I have spend a great deal of time drawing the default sprite hardness tiles for all the sprites. So you don't even have to do that work anymore.

And it works beautifully well, too. It does however require proper placement of the hotspot (which seems to be called "depth dot" by some), which Seth didn't alway do. So I suppose I'll have to fix that as well. But that can be worked around by changing the depth que. Sprites which use this can't move anyway.

You can find the editor at github,
and as a convenience zip archive here.

Hurray! I always thought hardness should somehow be more automated.

As a side note, now that you have an account, are you planning to upload your editor to the Dink Network? It would make it easier for people to find than digging around in the forum for the link.

now that you have an account, are you planning to upload your editor to the Dink Network?

Yes, I was planning to do that, but it is unrelated to me having an account. I could upload a DMod without an account as well, so a non-DMod file should work just as well.

Anyway, I'm waiting a bit until it's getting slightly more stable. For those who don't care about stability, it is already available in github.

Are you able to edit the original post in that thread? It would be great to have the link there or some other prominent place.

No, because I declined Dan's offer to link my login to all the post I made so far.

However, I can put a link in the top post of this thread, which I will do now.

That sounds cool.

Awesome!^^ Makes me all tingly inside^^

Now if only the dream I had last week of a cutscene editor inside a map editor would come to be

Well, you know. Admittedly, it's very very bare-bones, and not as useful as it could be.

Too rudimentary and it only works with DinkEdit, making it really hard to use. I'd say it's just as fast to copy/paste some move_stop lines and hover over the coordinates in WDE

But it's part of what such an editor would support at least

I gave the editor a go a few weeks back and it's just too slow for me to use. Every time I move the mouse the CPU usage spikes tremendously. I am guessing there's no hardware acceleration, is there?

I gave the editor a go a few weeks back and it's just too slow for me to use. Every time I move the mouse the CPU usage spikes tremendously. I am guessing there's no hardware acceleration, is there?

Oh, that's bad. There is no hardware acceleration, indeed. I did however add a setting for making it faster at the cost of appeal. If you disable the backing store, it should flicker when you do things, but it should do the things a lot faster. To try it, change the value of "nobackingstore" in pde.gui from "False" to "True", using a text editor.

But it shouldn't be slow to just move the mouse. Dragging with a button pressed might, though.

On the other hand, it was slow but acceptable on my old laptop, which had very low specs. Now I'm using it on a 2.66GHz machine, and it is really fast, even when zooming out and having a lot of things at once on screen.

I have seen some other programs which become really slow when running them on Windows; perhaps Python isn't optimized for it. If that is the problem, there isn't really anything I can do.

Except that I was running it on Raspbian with my Pi overclocked to 1Ghz. I tried the nobackingstore thing and it didn't change much at all

Except that I was running it on Raspbian with my Pi overclocked to 1Ghz.

Ah, then Windows isn't the problem. But the Pi isn't really known for its speed either. It a great machine for its price and easy hacking, but not for its speed.

I tried the nobackingstore thing and it didn't change much at all

Hmm, too bad. I haven't used it much, but I hoped it to change things by almost a factor of two. Appearantly not.

I was just surprised that the map editor has higher system requirements than the actual game.

I was just surprised that the map editor has higher system requirements than the actual game.

You have a point. The "problem" is that it's written in Python, which is an interpreted (and therefore relatively slow) language. I was slightly surprised it was usable at all (on my not too fast machine anyway).

However, I'm thinking of adding a feature which should mean an improvement in responsiveness on slow devices. If I do that, I'll let you know of course.