shevek creates a DMod! with PyDink
November 12th 2012, 07:22 AM
shevek
Just before Scratcher posted his map-making video, I thought about making a video showing some great features of my editor, PyDink. But making a video is not easy, especially on my old computer, so it took some time. But here it is: a screencast of me making a DMod with PyDink, including:
- Made with PyDink, which most of you have not seen in action before.
- 7 cool features highlighted.
- Great Dutch accent.
Find the video here.
Enjoy!
- Made with PyDink, which most of you have not seen in action before.
- 7 cool features highlighted.
- Great Dutch accent.
Find the video here.
Enjoy!
It's looking REALLY good. I particularly love the line drawing feature for cornered areas with tilematching. Also, the layering seems useful for editing purposes, but when you say: "the dirt is in the background", does that mean the sprites are also assigned the background property, nohit set, etc...? Or do you still do those things manually?
Furthermore, while watching your video, I thought of one extra cool feature you could add that would greatly reduce mapping times. Could you implement a shortkey to scroll through frames when you have a sprite selected? So, if you select a flower and press the button it goes to the next frame, making it very easy to put down a variety of flowers in only a short time. You could go further with this with custom "decoration sets", where you would predesignate certain frames of sequences to be in the set and be able to swap between them during the editing phase. Hmmm, it sounds a bit confusing I guess >_>
A concrete example would be making a "forest" set. You would select some mushrooms, some flowers, dirt, etc. and put them in the set. Now, when you're editing, you select the set instead of a sprite and quickly swap through the different frames with the hotkey (probably better to have two, one for next one for previous).
Just some thoughts and feedback, hope it's useful to you
Furthermore, while watching your video, I thought of one extra cool feature you could add that would greatly reduce mapping times. Could you implement a shortkey to scroll through frames when you have a sprite selected? So, if you select a flower and press the button it goes to the next frame, making it very easy to put down a variety of flowers in only a short time. You could go further with this with custom "decoration sets", where you would predesignate certain frames of sequences to be in the set and be able to swap between them during the editing phase. Hmmm, it sounds a bit confusing I guess >_>
A concrete example would be making a "forest" set. You would select some mushrooms, some flowers, dirt, etc. and put them in the set. Now, when you're editing, you select the set instead of a sprite and quickly swap through the different frames with the hotkey (probably better to have two, one for next one for previous).
Just some thoughts and feedback, hope it's useful to you
November 12th 2012, 08:13 AM
shevek
when you say: "the dirt is in the background", does that mean the sprites are also assigned the background property, nohit set, etc...?
I've split up the "type" property in two, namely visible and background. They do:
not visible, not background: skip all sprites in this layer (Dink doesn't support it). You can use it to have some debugging sprites or so.
visible, not background: type 1.
not visible, background: type 2.
visible, background: type 0.
All sprites in a layer are automatically given the type value that is set for the layer. It doesn't do anything else, so things like nohit you still need to do manually (but you can select all sprites in the active layer with ctrl-a, then set the property for all of them at once, so it's not much work at all).
Could you implement a shortkey to scroll through frames when you have a sprite selected?
Yes, that sounds useful indeed.
You could go further with this with custom "decoration sets"
I think I'd prefer to do that similar to the random or pattern tile filling: selecting the set, putting them in a buffer, and then using that for "paste random from buffer" or "select next/previous from buffer".
As for the keys, the scroll wheel would seem to be the most logical "key" to map this action to, probably with ctrl pressed (without a modifier it scrolls the map).
hope it's useful to you
Definitely. Thanks.
I've split up the "type" property in two, namely visible and background. They do:
not visible, not background: skip all sprites in this layer (Dink doesn't support it). You can use it to have some debugging sprites or so.
visible, not background: type 1.
not visible, background: type 2.
visible, background: type 0.
All sprites in a layer are automatically given the type value that is set for the layer. It doesn't do anything else, so things like nohit you still need to do manually (but you can select all sprites in the active layer with ctrl-a, then set the property for all of them at once, so it's not much work at all).
Could you implement a shortkey to scroll through frames when you have a sprite selected?
Yes, that sounds useful indeed.
You could go further with this with custom "decoration sets"
I think I'd prefer to do that similar to the random or pattern tile filling: selecting the set, putting them in a buffer, and then using that for "paste random from buffer" or "select next/previous from buffer".
As for the keys, the scroll wheel would seem to be the most logical "key" to map this action to, probably with ctrl pressed (without a modifier it scrolls the map).
hope it's useful to you
Definitely. Thanks.
That looks really good
I have a couple of questions:
How is adding custom sprites or tiles done? I mean regards your new features like sequence collections, sprite names, tile paths etc.
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?
Also, how does hardness editing work?
I have a couple of questions:
How is adding custom sprites or tiles done? I mean regards your new features like sequence collections, sprite names, tile paths etc.
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?
Also, how does hardness editing work?
That's pretty rad.
I think there should be a colored background for the sprite selection though.
And I repeat Sparrowhawk's questions.
Does each layer support 100 sprites, or is there still only 100 sprites total when you add up layer and visions?
Also, on a personal note, if I were to switch the editor I was using, it'd have to be for something major. While your improvements are fantastic, I'm not sure I'll switch to it yet. I'd only switch if there was something I could do on the newer one that I couldn't on the current one. Which seems to be layers, but I'm not sure if I'd ever use them. There are a few things I'd like to see in an editor. One being sprite-cropping. Now maybe I can do that in WinDinkEdit, but I certainly haven't figured out how-to. Another would be custom hardness drawing. Not like pasting a pre-created block. It would be something that would let me create a very nice and exact hardness for a house. Another, and this might be the most difficult to do, would be to let moving sprites actually move in the editor. The last one I can think of would to make the background sprite draw into the tiles and not count as sprites. Now it wouldn't draw into the main tile, only the one on that screen. I might be hoping for a little too much though.
I think there should be a colored background for the sprite selection though.
And I repeat Sparrowhawk's questions.
Does each layer support 100 sprites, or is there still only 100 sprites total when you add up layer and visions?
Also, on a personal note, if I were to switch the editor I was using, it'd have to be for something major. While your improvements are fantastic, I'm not sure I'll switch to it yet. I'd only switch if there was something I could do on the newer one that I couldn't on the current one. Which seems to be layers, but I'm not sure if I'd ever use them. There are a few things I'd like to see in an editor. One being sprite-cropping. Now maybe I can do that in WinDinkEdit, but I certainly haven't figured out how-to. Another would be custom hardness drawing. Not like pasting a pre-created block. It would be something that would let me create a very nice and exact hardness for a house. Another, and this might be the most difficult to do, would be to let moving sprites actually move in the editor. The last one I can think of would to make the background sprite draw into the tiles and not count as sprites. Now it wouldn't draw into the main tile, only the one on that screen. I might be hoping for a little too much though.
"One being sprite-cropping. Now maybe I can do that in WinDinkEdit, but I certainly haven't figured out how-to."
Select sprite, press Z or X.
(Edit: Use arrow keys while holding Z or X to crop.)
"Another would be custom hardness drawing."
Stamp hardness, press Q (I think). You can change the size of the hardness painting brush in the menu.
Enjoy
Select sprite, press Z or X.
(Edit: Use arrow keys while holding Z or X to crop.)
"Another would be custom hardness drawing."
Stamp hardness, press Q (I think). You can change the size of the hardness painting brush in the menu.
Enjoy
November 12th 2012, 05:15 PM
DSPT
DinkSmallwoodPT channel has subscribed to you & added you to the featured channels.
Keep up the good work.
Keep up the good work.
"Another would be custom hardness drawing."
you can draw the hardness u want but of course it squares off the edges as pixels are square I suppose. Hold shift and u get three clicks to make a shape.
Just about to try this out shevek looks awesome tho - i am so frustrated with the other ones.
you can draw the hardness u want but of course it squares off the edges as pixels are square I suppose. Hold shift and u get three clicks to make a shape.
Just about to try this out shevek looks awesome tho - i am so frustrated with the other ones.
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.
Well don't I feel silly now. I'm gonna crop so hard tomorrow; do some hardnessing too.
Thank you Sparrowhawk, and MsDink.
Also, MsDink. Is your name like Miss Dink, or Microsoft Dink? This has been bothering me for going on like 30 seconds now.
Thank you Sparrowhawk, and MsDink.
Also, MsDink. Is your name like Miss Dink, or Microsoft Dink? This has been bothering me for going on like 30 seconds now.
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…
Well either would be fine, but the cntrl-p thing sounds fantastic, and also disputes any reason to have those.
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.
I want this because what I found is that I seem to put a lot of focus into mapping, which means I used background sprites on I think every screen but one. Some of them really add up though and there's been quite a few times I've hit the sprite limit. So it'd be nice for me to paste things right onto the tiles. From what I saw with the background layer - the one that made sprites slightly transparent - it seems like that would be good to discount those sprites, as they are meant to go only on top of the tile.
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…
Well either would be fine, but the cntrl-p thing sounds fantastic, and also disputes any reason to have those.
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.
I want this because what I found is that I seem to put a lot of focus into mapping, which means I used background sprites on I think every screen but one. Some of them really add up though and there's been quite a few times I've hit the sprite limit. So it'd be nice for me to paste things right onto the tiles. From what I saw with the background layer - the one that made sprites slightly transparent - it seems like that would be good to discount those sprites, as they are meant to go only on top of the tile.
"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)"
Now that's a nice feature! Wow. Beats using the Ultimate Cheat or changing the start script all the time I see it's used in the hardness demo video (which I remember watching now).
All graphics are png? I suppose they're converted to bmp when compiling?
If this will eventually have it's own engine too then D-Mods could be made targeting this engine specifically right, if it can be used to play D-Mods on without having the editor part? They wouldn't be compatible with other engines but amazing new possibilities are opening before my eyes...
Now that's a nice feature! Wow. Beats using the Ultimate Cheat or changing the start script all the time
I see it's used in the hardness demo video (which I remember watching now).All graphics are png? I suppose they're converted to bmp when compiling?
If this will eventually have it's own engine too then D-Mods could be made targeting this engine specifically right, if it can be used to play D-Mods on without having the editor part? They wouldn't be compatible with other engines but amazing new possibilities are opening before my eyes...
Microsoft Dink?
what WHAT WHAAAT - Oh its all on now!! I keeel you deeead (makes stabbing motion at screen) you must promise me never to use that nasty word eva again geesh
what WHAT WHAAAT - Oh its all on now!! I keeel you deeead (makes stabbing motion at screen) you must promise me never to use that nasty word eva again geesh
November 13th 2012, 03:42 AM
shevek
I want this because what I found is that I seem to put a lot of focus into mapping, which means I used background sprites on I think every screen but one. Some of them really add up though and there's been quite a few times I've hit the sprite limit. So it'd be nice for me to paste things right onto the tiles. From what I saw with the background layer - the one that made sprites slightly transparent - it seems like that would be good to discount those sprites, as they are meant to go only on top of the tile.
I just noticed there is no "draw this sprite on the background" function in DinkC. I was thinking of using brain 5, but that is only usable to draw the last frame of a sequence. So here's a new idea; let me know if there are any flaws in it:
- I reserve one editor slot for this purpose. It does not contain a sprite.
- The screen script will repeatedly do:
I'm not at all sure if this works, but I think it might.
Alternatively, what certainly would work is to invert it: put the background sprites (type 0 and 2) in the map, and the real sprites in the script. This also increases the limit of editor sprites from 100 to 300 (but keeps the limit of background objects at 100).
Now that's a nice feature! Wow. Beats using the Ultimate Cheat or changing the start script all the time
You seem to be very excited about this. I didn't think it was a big deal; I just thought it was required for testing smoothly.
All graphics are png? I suppose they're converted to bmp when compiling?
Yes. I wanted png because it has encoded transparency (and I don't want my files to contain incorrect information), and they can be true color (I thought about animated gifs, but they are only possible with a palette.
If this will eventually have it's own engine too then D-Mods could be made targeting this engine specifically right, if it can be used to play D-Mods on without having the editor part? They wouldn't be compatible with other engines but amazing new possibilities are opening before my eyes...
Yes. The editor allows breaking all limitations of Dink. If you don't do this, you will be able to compile it into a DMod which can be played with dink.exe or freedink. In any case it will be possible to play it with its own engine.
The main reason for writing the engine was that play testing is currently slow (at least on my not-so-fast computer), because if must first compile the DMod. But I also heard (at least) Kyle ask for the removal of several limits, so that's another reason. My code currently has exactly one fixed arbitrary limit, which is the number of layers (10). The reason is that they are only used in the editor, and I want shortcut keys for them (now I have: number key=change active layer; ctrl-number key=move selection to layer). Since there are only 10 number keys, that is also the number of supported layers.
Oh, and I copied the limit of 41 tile screens, but I'll probably throw that out at some point.
Ah, but finally, there is a limitation for those who really want everything: my scripts have proper scoping of variables. There are three types:
- local variables, which are only available inside the function where they are defined, from the point where they are defined. Two local variables with identical names in different functions will be different variables (they will be compiled into different names).
- global variables, which are available in any file which has declared them (outside a function, with "extern int foo;")
- static variables, which are meant to be locked to a sprite, and are available in any file which has declared them, as long as it is attached to its sprite. Well, that's how it will work in the PyDink engine anyway. When compiling, defines for these are generated at the start of the main function. If I'm not mistaken, this means they will be available in callback functions (like touch or hit), but not in functions called from there. Since I don't support goto, this puts a slight limit on the scripting possibilities (which can be worked around with global variables, but they have a limit, too).
I just noticed there is no "draw this sprite on the background" function in DinkC. I was thinking of using brain 5, but that is only usable to draw the last frame of a sequence. So here's a new idea; let me know if there are any flaws in it:
- I reserve one editor slot for this purpose. It does not contain a sprite.
- The screen script will repeatedly do:
editor_seq (&slot, ...); editor_frame (&slot, ...); editor_type (&slot, 3 or 5);
I'm not at all sure if this works, but I think it might.
Alternatively, what certainly would work is to invert it: put the background sprites (type 0 and 2) in the map, and the real sprites in the script. This also increases the limit of editor sprites from 100 to 300 (but keeps the limit of background objects at 100).
Now that's a nice feature! Wow. Beats using the Ultimate Cheat or changing the start script all the time
You seem to be very excited about this. I didn't think it was a big deal; I just thought it was required for testing smoothly.
All graphics are png? I suppose they're converted to bmp when compiling?
Yes. I wanted png because it has encoded transparency (and I don't want my files to contain incorrect information), and they can be true color (I thought about animated gifs, but they are only possible with a palette.
If this will eventually have it's own engine too then D-Mods could be made targeting this engine specifically right, if it can be used to play D-Mods on without having the editor part? They wouldn't be compatible with other engines but amazing new possibilities are opening before my eyes...
Yes. The editor allows breaking all limitations of Dink. If you don't do this, you will be able to compile it into a DMod which can be played with dink.exe or freedink. In any case it will be possible to play it with its own engine.
The main reason for writing the engine was that play testing is currently slow (at least on my not-so-fast computer), because if must first compile the DMod. But I also heard (at least) Kyle ask for the removal of several limits, so that's another reason. My code currently has exactly one fixed arbitrary limit, which is the number of layers (10). The reason is that they are only used in the editor, and I want shortcut keys for them (now I have: number key=change active layer; ctrl-number key=move selection to layer). Since there are only 10 number keys, that is also the number of supported layers.
Oh, and I copied the limit of 41 tile screens, but I'll probably throw that out at some point.
Ah, but finally, there is a limitation for those who really want everything: my scripts have proper scoping of variables. There are three types:
- local variables, which are only available inside the function where they are defined, from the point where they are defined. Two local variables with identical names in different functions will be different variables (they will be compiled into different names).
- global variables, which are available in any file which has declared them (outside a function, with "extern int foo;")
- static variables, which are meant to be locked to a sprite, and are available in any file which has declared them, as long as it is attached to its sprite. Well, that's how it will work in the PyDink engine anyway. When compiling, defines for these are generated at the start of the main function. If I'm not mistaken, this means they will be available in callback functions (like touch or hit), but not in functions called from there. Since I don't support goto, this puts a slight limit on the scripting possibilities (which can be worked around with global variables, but they have a limit, too).
"You seem to be very excited about this."
It just makes it so easy. When creating a D-Mod myself I frequently play test the screen I am currently building, to test a script, hardness, depth que or whatever. Having this feature just makes it faster (especially being able to start at a specific point on that screen too).
Speaking of faster, I have a suggestion to speed up the compiling: what about giving a similar option to Visual Studio's Build or Rebuild? Build would compile only those scripts/graphics that have changed since the last build, and Rebuild would compile the whole D-Mod regardless of whether anything has changed. That way only the first build would take a long time.
Another suggestion for when the engine comes along: if you have features that aren't compatible with 1.08/FreeDink/DinkHD then the editor should give a warning when you use them, either mapping or scripting. Alternatively it might be easier to have two modes depending on the target engine, with some features limited or changed in each mode.
It just makes it so easy. When creating a D-Mod myself I frequently play test the screen I am currently building, to test a script, hardness, depth que or whatever. Having this feature just makes it faster (especially being able to start at a specific point on that screen too).
Speaking of faster, I have a suggestion to speed up the compiling: what about giving a similar option to Visual Studio's Build or Rebuild? Build would compile only those scripts/graphics that have changed since the last build, and Rebuild would compile the whole D-Mod regardless of whether anything has changed. That way only the first build would take a long time.
Another suggestion for when the engine comes along: if you have features that aren't compatible with 1.08/FreeDink/DinkHD then the editor should give a warning when you use them, either mapping or scripting. Alternatively it might be easier to have two modes depending on the target engine, with some features limited or changed in each mode.
November 13th 2012, 05:45 AM
shevek
It just makes it so easy.
Well, yes, that's why I implemented it. I'm not surprised that you like it, but that it's not present in WinDinkEdit.
Build would compile only those scripts/graphics that have changed since the last build, and Rebuild would compile the whole D-Mod regardless of whether anything has changed.
Hmm, that would require me to keep track of dependencies (which parts need to be rebuilt if this or that changed), which may be quite a pain. However, for tile hardness this may be possible, and I think that may be the slowest part of the process. But I really should do some profiling first.
if you have features that aren't compatible with 1.08/FreeDink/DinkHD then the editor should give a warning when you use them
During editing, I'm play-testing often. Whenever that happens, the DMod is compiled, and that will fail if there are incompatible features in it. So it isn't a big problem.
Most compatibility problems are (and can only be) detected when compiling, for example the number of used global variables is determined when preprocessing the scripts. If I'll ever add features which are fundamentally incompatible, I'll mark them or make it a mode. But I don't think I'll do that any time soon.
Well, yes, that's why I implemented it. I'm not surprised that you like it, but that it's not present in WinDinkEdit.
Build would compile only those scripts/graphics that have changed since the last build, and Rebuild would compile the whole D-Mod regardless of whether anything has changed.
Hmm, that would require me to keep track of dependencies (which parts need to be rebuilt if this or that changed), which may be quite a pain. However, for tile hardness this may be possible, and I think that may be the slowest part of the process. But I really should do some profiling first.
if you have features that aren't compatible with 1.08/FreeDink/DinkHD then the editor should give a warning when you use them
During editing, I'm play-testing often. Whenever that happens, the DMod is compiled, and that will fail if there are incompatible features in it. So it isn't a big problem.
Most compatibility problems are (and can only be) detected when compiling, for example the number of used global variables is determined when preprocessing the scripts. If I'll ever add features which are fundamentally incompatible, I'll mark them or make it a mode. But I don't think I'll do that any time soon.
Well I'm so excited about it if you're actually also making an engine around it... God, the possibilities. And of all who have said they're doing this, you're 100% the guy I trust to finish this
If (or when) you have a working engine, it would be nice to be able to jump in/out of the game within the editor
If (or when) you have a working engine, it would be nice to be able to jump in/out of the game within the editor
