Dink Source 108
Wow, Redink1... I didn't realise how much work you did on Dink Smallwood 'til now! (Context: am examining dink.cpp.)
Would it be difficult to rewrite Dink Smallwood to scroll rather then flip screens? Or is it like any math: there are harder and easier ways?
Coz, y'know... flip screens make me claustrophobic.
Would it be difficult to rewrite Dink Smallwood to scroll rather then flip screens? Or is it like any math: there are harder and easier ways?
Coz, y'know... flip screens make me claustrophobic.
Do you mean a continuously scrolling world, Link to the Past-style? (Which admittedly *does* break up the large overworld in segments, but inside these segments, it scrolls.)
The concept of screen is embedded pretty deeply into the game's core mechanics. There's screenlock, screen scripts, and overworld music is also screen-based. An extension to the screen script is the idea of visions. The engine doesn't know what sprites to draw until after it gave the screen script a chance to run.
Some script instances get removed and garbage collected on screenchange. Sprite numbers are based on their drawing order on a screen. Getting a sprite with a certain brain through DinkC will only look at the sprites on the current screen. Suddenly getting a sprite that's visible from the next screen may or may not be something you want.
Heck, the engine right now doesn't even know what *screen* to draw next until you actually go to it. Some D-Mods use this fact to trick the engine into making screens that aren't adjacent in the map file appear adjacent. This trickery is usually done when Dink is very close (25px or so) to the screen's edge.
TL;DR: It'd do weird things on a lot of D-Mods, and completely break some of them.
The concept of screen is embedded pretty deeply into the game's core mechanics. There's screenlock, screen scripts, and overworld music is also screen-based. An extension to the screen script is the idea of visions. The engine doesn't know what sprites to draw until after it gave the screen script a chance to run.
Some script instances get removed and garbage collected on screenchange. Sprite numbers are based on their drawing order on a screen. Getting a sprite with a certain brain through DinkC will only look at the sprites on the current screen. Suddenly getting a sprite that's visible from the next screen may or may not be something you want.
Heck, the engine right now doesn't even know what *screen* to draw next until you actually go to it. Some D-Mods use this fact to trick the engine into making screens that aren't adjacent in the map file appear adjacent. This trickery is usually done when Dink is very close (25px or so) to the screen's edge.
TL;DR: It'd do weird things on a lot of D-Mods, and completely break some of them.
All right, here's what you gotta do.
Place all your tiles and whatnot to build the world. Screenshot them and put them together into one giant sprite.
Create and delete sprites based off dink's location.
Adjust the x and y of all sprites simultaneously whenever dink moves.
Oh and uh hardness. Yeah let's not talk about hardness.
There you go. Scrolling world on one screen. I never said it would be easy.
Place all your tiles and whatnot to build the world. Screenshot them and put them together into one giant sprite.
Create and delete sprites based off dink's location.
Adjust the x and y of all sprites simultaneously whenever dink moves.
Oh and uh hardness. Yeah let's not talk about hardness.
There you go. Scrolling world on one screen. I never said it would be easy.
Heck, the engine right now doesn't even know what *screen* to draw next until you actually go to it. Some D-Mods use this fact to trick the engine into making screens that aren't adjacent in the map file appear adjacent. This trickery is usually done when Dink is very close (25px or so) to the screen's edge.
Could this possibly explain Goblin Trouble?
Could this possibly explain Goblin Trouble?
I'd imagine it would be rather difficult to scroll rather than flips screens. I actually had an idea to try to do that at one point (whilst understanding I'd be breaking backwards compatibility), but I didn't get very far.
Most of the logic would have to be rewritten. Dink is full of assumptions about single screen worlds, things with artificial limits on them (e.g. X things per screen) and things that get overwritten on each new screen switch.
You'd probably finish faster by programming a new engine from scratch
You'd probably finish faster by programming a new engine from scratch
Interesting thoughts, all!
I guess it would be easier to make a game in another editor and "port" it into a .dmod file.
The limitations of Dink Smallwood can present a fun challenge and push one to think creatively, though. That's a bonus.
Now if only we could get an Infinity engine editor with WinDinkEdit GUI....
I guess it would be easier to make a game in another editor and "port" it into a .dmod file.
The limitations of Dink Smallwood can present a fun challenge and push one to think creatively, though. That's a bonus.
Now if only we could get an Infinity engine editor with WinDinkEdit GUI....
