Reply to Re: shevek creates a DMod! with PyDink
If you don't have an account, just leave the password field blank.
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).
