Reply to Re: shevek creates a DMod! with PyDink
If you don't have an account, just leave the password field blank.
November 12th 2012, 07:31 PM
shevek
How is adding custom sprites or tiles done? I mean regards your new features like sequence collections, sprite names, tile paths etc.
Currently you have to do this by hand. The edited DMod is in a directory. There is a subdirectory named seq and another one named collection. in there, there are subdirectories, one per new thing. In case of collections, there are subdirectories for directions (1,2,3,4,die,6,7,8,9) under that with sequences in it; for seq the sequence is immediately there. A sequence is a list of files named 01.png, 02.png, etc. Transparent parts must be transparent (not white or black). Extra info (like hardbox, depth dot, etc) can be given in a file named info.txt.
These new graphics will show up in the selection automatically and will be named the same as the directory.
For tiles there is simply a directory called tiles, where files called 01.png, 02.png, etc. and 01-hard.png, 02-hard.png, etc are located.
If I draw a circle (or square, rather...) with the tile path tool, how does it know if I want a hill or a pit?
I used the right-hand rule that is also valid for several physics things regarding electricity and magnetism: If I point the thumb of my right hand upwards, my fingers are going counterclockwise. So if I draw the square counterclockwise, it will be a hill. In the demo, I was drawing both borders clockwise, so with the same rule, this means I was drawing pits (as you could see).
Also, how does hardness editing work?
I showed this in an earlier video. In short: with your favorite photo editor, make hard pixels white (or blue). The compiler will compute hard tiles from it automatically.
The downside of this is that you can easily run out of hard tiles if you have many screens with custom hardness. I'm working on a solution for that, but it may take a while. For now, the workaround is to copy hardness from another screen and edit that if you want something similar.
I think there should be a colored background for the sprite selection though.
Sounds like a good idea.
Does each layer support 100 sprites, or is there still only 100 sprites total when you add up layer and visions?
That wasn't his question.
100 sprites is not a limitation of my editor. In fact, my editor doesn't complain if you put 1000000 sprites in one screen. It will complain when you compile it into a dmod, though. This is because it is impossible for the files to contain more sprites.
So why do I allow it anyway, you may ask. The reason is that PyDink is not only an editor. It is also a new engine. The PyDink engine doesn't have any limitations (but DMods pushing the limits will have performance problems on low-resource computers, of course) like the original. Note that the engine is not currently functional. And it won't be able to play DMods from other editors, because it directly executes the uncompiled scripts. (For the rest I'm writing a decompiler, but I'm not going to decompile scripts.)
if I were to switch the editor I was using, it'd have to be for something major.
Makes sense. I've written this editor as an alternative to DinkEdit, because I can't force myself to do the workarounds that are required for it (mostly when writing scripts). I've never used WinDinkEdit, so I don't know how it compares. I do know you still have the same problem with the scripts there, though.
Which seems to be layers, but I'm not sure if I'd ever use them.
The idea behind layers is that you can "store" a selection of sprites for later use. There are fast keys for "select all sprites in active layer" and "invert selection in active layer". The option to have one layer with "in-progress" sprites, which will not be present in the compiled DMod, fits well with that idea.
One being sprite-cropping.
Check. I didn't show it here, but it works great: press control cursor for the side you want to crop; move the mouse or press cursor keys to set cropping, then press enter or click left button to confirm. Works with multiple sprites selected as well.
Another would be custom hardness drawing.
Check. See the above link to the older video.
let moving sprites actually move in the editor.
Not sure what you want here. Do you want sprites with a brain to walk around the map screen in the editor, or do you want to see a cutscene in the editor. The first doesn't seem very useful; the second is pretty hard, because the editor would need to execute the script. Now since PyDink includes an engine, I might actually support this in the future. What I do already support is playtesting: press ctrl-p while pointing on the map, and the DMod is compiled and started with a custom start scripts which sends you directly to the place you pointed at (without showing the title screen or intro). So it is preety easy to see how things are working out.
make the background sprite draw into the tiles and not count as sprites.
I hadn't thought of this, but that would actually be quite easy to do. Since I'm compiling anyway, I can just generate a map script which draws them in its main function. I'll keep it in mind.
Currently you have to do this by hand. The edited DMod is in a directory. There is a subdirectory named seq and another one named collection. in there, there are subdirectories, one per new thing. In case of collections, there are subdirectories for directions (1,2,3,4,die,6,7,8,9) under that with sequences in it; for seq the sequence is immediately there. A sequence is a list of files named 01.png, 02.png, etc. Transparent parts must be transparent (not white or black). Extra info (like hardbox, depth dot, etc) can be given in a file named info.txt.
These new graphics will show up in the selection automatically and will be named the same as the directory.
For tiles there is simply a directory called tiles, where files called 01.png, 02.png, etc. and 01-hard.png, 02-hard.png, etc are located.
If I draw a circle (or square, rather...) with the tile path tool, how does it know if I want a hill or a pit?
I used the right-hand rule that is also valid for several physics things regarding electricity and magnetism: If I point the thumb of my right hand upwards, my fingers are going counterclockwise. So if I draw the square counterclockwise, it will be a hill. In the demo, I was drawing both borders clockwise, so with the same rule, this means I was drawing pits (as you could see).
Also, how does hardness editing work?
I showed this in an earlier video. In short: with your favorite photo editor, make hard pixels white (or blue). The compiler will compute hard tiles from it automatically.
The downside of this is that you can easily run out of hard tiles if you have many screens with custom hardness. I'm working on a solution for that, but it may take a while. For now, the workaround is to copy hardness from another screen and edit that if you want something similar.
I think there should be a colored background for the sprite selection though.
Sounds like a good idea.
Does each layer support 100 sprites, or is there still only 100 sprites total when you add up layer and visions?
That wasn't his question.
100 sprites is not a limitation of my editor. In fact, my editor doesn't complain if you put 1000000 sprites in one screen. It will complain when you compile it into a dmod, though. This is because it is impossible for the files to contain more sprites.
So why do I allow it anyway, you may ask. The reason is that PyDink is not only an editor. It is also a new engine. The PyDink engine doesn't have any limitations (but DMods pushing the limits will have performance problems on low-resource computers, of course) like the original. Note that the engine is not currently functional. And it won't be able to play DMods from other editors, because it directly executes the uncompiled scripts. (For the rest I'm writing a decompiler, but I'm not going to decompile scripts.)
if I were to switch the editor I was using, it'd have to be for something major.
Makes sense. I've written this editor as an alternative to DinkEdit, because I can't force myself to do the workarounds that are required for it (mostly when writing scripts). I've never used WinDinkEdit, so I don't know how it compares. I do know you still have the same problem with the scripts there, though.
Which seems to be layers, but I'm not sure if I'd ever use them.
The idea behind layers is that you can "store" a selection of sprites for later use. There are fast keys for "select all sprites in active layer" and "invert selection in active layer". The option to have one layer with "in-progress" sprites, which will not be present in the compiled DMod, fits well with that idea.
One being sprite-cropping.
Check. I didn't show it here, but it works great: press control cursor for the side you want to crop; move the mouse or press cursor keys to set cropping, then press enter or click left button to confirm. Works with multiple sprites selected as well.
Another would be custom hardness drawing.
Check. See the above link to the older video.
let moving sprites actually move in the editor.
Not sure what you want here. Do you want sprites with a brain to walk around the map screen in the editor, or do you want to see a cutscene in the editor. The first doesn't seem very useful; the second is pretty hard, because the editor would need to execute the script. Now since PyDink includes an engine, I might actually support this in the future. What I do already support is playtesting: press ctrl-p while pointing on the map, and the DMod is compiled and started with a custom start scripts which sends you directly to the place you pointed at (without showing the title screen or intro). So it is preety easy to see how things are working out.
make the background sprite draw into the tiles and not count as sprites.
I hadn't thought of this, but that would actually be quite easy to do. Since I'm compiling anyway, I can just generate a map script which draws them in its main function. I'll keep it in mind.
