The Dink Network

Is there anyone with enough programming experience and prior insight into the Dink source who knows what it would take to change some limits around and compile a new version? We know DinkHD is largely the same code but it has expanded limits. I'd like to research how we can go further into this, because I'm sure I'm not the only one getting tired of some of the limits we need to work with

I'm thinking the following limits:

- Global variables
- Concurrent variables
- Sequence slots
- Sound slots
- Dink.ini lines
- Tiles and hardness tiles
- 99 Sprites on screen

Let me give some examples of what the abolishment of certain limits could mean for us:

- Global variables
- Concurrent variables

For us this would mean a lot less juggling with variables and a much easier time managing data. We would also be able to create certain scripts in an easier way with "unlimited" globals, cutscenes with many actors comes to mind, etc... A questlog also comes to mind, where it would be very easy to keep track of quests, steps inside quests, ... but also in general just an easier and more manageable way to create new battle systems.

- Sequence slots
- Sound slots
- Dink.ini lines
- Tiles and hardness tiles

One of the biggest learning curves or motivation breakers for new d-modders and experienced ones a like is integrating a bunch of new graphics, sounds, ... only to realize that if you want to make use of the many great files that have been contributed on this site, you will soon run into the small limit on sounds and (especially) graphics slots. By breaking the limit on graphics, sounds and tiles, we could potentially create one community driven skeleton d-mod that includes every graphic ever contributed with hardness, depth and other values already set and without a need to choose between which to include or without having to make use of init() all the time, which is a very annoying and advanced process. With such a community skeleton file available, it wouldn't even be necessary to include all the graphics into each and every d-mod anymore but rather everyone downloads it once and pastes it into the regular Dink/Graphics folder.

- 99 Sprites on screen

I think we've all had this problem now and then where we want to make a truly impressive screen full of detail but we quickly run into this limit. Excessive use of fern, flowers, mushrooms comes to mind which can really bring a scene to life. Abolishing this limit would grant us more freedom and creativity to make our screens breathe.

_____________________________________________________

I hope I've gotten through to those of you who could assist in making this happen, because together with the advent of Shevek's new editor, we could really make a lasting change. We've seen an increase in people trying to start out with d-modding and I think I speak for many of us when I say some or all of these limits have been a huge disappointment at one point or another and a detrement to the creativity that we seek to express.

Haven't looked into the source code, but it should be as easy a locating and changing a few numbers. It will probably take a few days to do, and a few months of beta testing before we find all the bugs we've created.

A few possible issues I foresee:

* There will be no backward compatibility for mods that make use of sprite (1000). In point of fact, Dink Smallwood its self will need to be rewritten.

* All editors written up until now that rely on the original limits will need to be rewritten too to allow for the new limits.

We could also re-vamp the whole thing so that there were no limits, but that would cause even worse compatibility problems that would take longer to fix.

It would be no different from any interpreted language taking a major leap. (Such as python 2 to python 3.)

EDIT: That being said, all it will really take is a little time before it can be considered a functional alternative. We should probably give it another name, such as dink+ or something, so dinkers know the difference. It is most likely they will just have to have both versions on their computer. The old version for old dmods, the new version for new dmods.

I do have programming experience, but have not looked that much into the Dink source code. I just remember it seemed to be very little code at all, but maybe I remember wrong.

One interesting thing would be to add support of user defined brains, making the monster more clever, add some basic AI support, A* search for movements and such.

It is not necessary to have more than 1000 graphics, because one can load some enemy graphics over another enemy (when Dink enters an area), and then load it back, when Dink leaves the area. I use this for my DMOD.

But of course, the best would be to have all graphics in one base folder as you suggest!

The most irritating part is the lack of sufficient number of globals. More globals and it is more easy to make the DMOD nonlinear. It is possible to split up a global and use different parts as individual smaller counters, but that is not very user friendly.

About the "99 Sprites on screen" limit, I guess the limit should be to sprites with a script or something that must run, that background sprites count into the limit seems strange (do they)?

I would be interested in this project!

Changing some limits may be easier than others. Not all changes would prevent backward compatibility.

If no one else takes the job, I'll look into it once I've finished my current dmod and see what I could change easily enough, without destroying backward compatibility.

Yes, I am aware of the backwards compatibility problems that would originate from changing the source code. But, what I'm suggesting is having a seperate version of Dink that we would create with the community's needs in mind. Any d-mod that would be created with this new version would then of course require people to install this new version of Dink on their computer. The goal would be to make the best possible version we can with the possibility of expanding it when needed, so that everyone will eventually switch over, especially those of us starting new projects or for the beginners. I had high hopes for DinkHD to be this version, but unfortunately many limits still remain and the game itself fails to run for some of our community members. It would defeat the point of creating something for the community if some productive members can't even use it.

It is true that we can swap graphics in and out, in fact I do this all the time for my own d-mod in production. At this point I have 5 scripts working towards managing this process, because I already have a library of graphics integrated in the d-mod that far exceeds 999. Let me tell you, managing this is HELL. Also, the init() method can not be used to change or add lines to the dink.ini file that are not load_sequence commands. Therefore changing transparency or attack frames, etc... can not be done in this way. The ultimate goal would be to make everything easier and less of an obstacle for d-mod development in general. Plus, everyone loves "shopping" around for graphics. It is true that the editors would need to be adjusted, but in this case I believe it would be a simple number change (for WDE+).

I would have absolutely no problems betatesting these changes for long periods of time. I would really LOVE to see this happen and am 100% comitted, but unfortunately my programming skills in C are severely lacking for me to lead this project. But I would like to be a part of it for sure and do whatever I can to contribute.

Well, seeing your passion, Kyle, inspires me! O.k. I'm in!

I guess one can have an option in DFArc whether running the DMOD with the new improved engine or the old for old DMODs, running the old by default.

Since we're bothering at all, I say we go whole hog and remove the limitations altogether.

Good idea Raven!

Also, we definitely need to modify freedink, so it will be cross platform, instead of the original.

Since we're bothering at all, I say we go whole hog and remove the limitations altogether.

This would be amazing, but first and foremost we should assess what is possible and what is beyond our reach. There have been projects that set out to do great things such as creating a whole new engine, but eventually came to nothing because motivation died out I definitely don't want that to happen to this. So we shouldn't overreach, but I'm not one to say what can and can't be done because I simply don't know.

We should start with setting up the development environment to at least be able to create new builds of the game. I'll get to that as soon as possible
I'm sure as the 24 hour cycle continues more community members will chime in with their thoughts too!^^

It shouldn't be difficult for experienced programmers to do something as simple as removing the limits, although expanding the AI may take more doing.

Is it possible the removal of some of these limits could require changes to the savegame format?

I'd love to see better AI and such, but perhaps we should keep that for later, because it would change the way the game is played, AND designed too. Perhaps even what scripting to use, which might not be a good idea at first.

All of the above is dependent on HOW we do it. If we play it careful, we shouldn't have to have everyone relearning dinkc. We will just have extra stuff. And that savegame formats will probably change some is a given, but it shouldn't be enough to throw anyone off.

If one changes the storage type for the total number of globals, then the save game format must be changed to reflect this, because such information must be stored in the save games.

Just briefly looking through the 1.08 version of the code, I see that

const max_vars = 250

(Line 356 in dinkvar.h)

defines the maximum number of variables, it seems redink1 cleaned up the code, because it is not hard coded 250 everywhere as I feared.

That makes life a little easier, but if we want to unlimit it completely, it's going to be a moot point.

Are you looking at the original, or freedink? Because I cant find that variable in dinkvar.h in freedink.

I was looking in the original, v 1.08, that was updated by redink1

I was thinking we aught to modify freedink. The original is windows specific, so I can't be much help on that one. (I run Ubuntu Linux.)

Hmm, ok, I have to check the free dink code then. Maybe Beuc has solved most of those problems already?

Worth checking, but I don't think so. By the look of it, it still relies on limitations.

Going forward it would definitely make most sense to alter FreeDink, IF FreeDink plays nice with compatibility and editors. I've never run it, so I don't know if it has any problems. I'd think not, or I would have read about it I guess.

Btw, you mentioned Beuc's name, he will now magically show up, like Martridge and aid us in our plight!

Ok. I have Windows / Debian Linux on my computer, so for my part it can be done developed on Linux, the question is what other potential programmers prefers.

I haven't had any trouble except with one dmod: "The Blacksmiths Trail" had the colors all f'd up on me. It looked like a bunch of brightly coloured tinsel pieces floating on grey. It was unplayable.

It's good that you have Windows, because we will need to test on that one way or the other. Freedink works on all major OS, even BSD, so it would be the logical choice. It would be just plain mean to make it Windows specific in my not so humble opinion.

I was more thinking that it could be problem to get freedink to compile on windows but maybe that is not the case, I have to check it out.

Ok, it is your responsibility to summon Beuc then

I've contacted him by e-mail, hopefully he can share some wisdom about FreeDink that could be of use to us

I can't see why increasing the limits would be difficult. Change the limits, recompile, then include the modified free/dink.exe in with your DMOD.

I'd much rather see an entire new scripting language being added to Dink. The variable limit is fair less irritating to me than the lack of arrays. It is almost possible to create an array in 1.08 by using a variable name in with sp_custom, but frustratingly v1.08 doesn't check for variables in the sp_custom string..

I'm pretty sure we've had this exact discussion once or twice before!

If you're going to change all this sort of thing and add features, you're essentially left with something that isn't Dink anymore.

If you want fancy pathfinding, a real scripting language, and stable timing then use a different engine.

Considering most people are still apparently using 1.08 they're not going to be bothered to use a custom exe.

Challenge is fun!

and not being backwards compatable - you loose the 300 plus games already made... is there gunna be that many new ones made? I actually agree with Ye old here.

You don't lose the ability to play the 300 some d-mods because this isn't meant to be Dink 1.09. It's more like Dink+, where we will be able to expand the possibilities for future d-mods. There's no point sticking with an old engine when we have the ability to change it. This is the reason Seth was asked to release the source code back in the day. There is no rule against installing both Dink 1.08 and the new executable. The best solution would be as was mentioned before to have a simple checkbox/listbox to run the one you need at the time

I also don't see how adding features (not complexity) is changing what Dink is about. Dink is about regular people without the ability to use complex engines or can not pay for all the art, ... It's about people bringing their imagination to life. And if we can simplify this process, wouldn't that be progress towards evolving Dink in the same spirit as the original?

Nobody is saying you'll have to use this, but I'm pretty sure you'll want to after you realize the possibilities that open up.

As for a new scripting language, I think what Shevek is doing with his pre-processor could be the preferred solution here. This way people who are familiar with the original Dink and are happy with can just continue the way they always have and those (like me) who would like a more modern approach to scripting with all its functionality intact can get that too.

To me, Dink is about limits. You can use those limits to your advantage. You can expand those limits. Or you can find your way around those limits. It provides a fun challenge.

I have nothing against this idea and the people who wanna use it. Wanna use it? Then use it. But I simply just wouldn't.

But if you had access to all existing graphics without lifting a finger?

Yes, it's fun until you run into having to write hundreds of lines of SET_FRAME_FRAME to get your own stuff working. The convenience factor falls pretty short.

Beuc's too busy writing opengl tutorials these days.

Don't get me wrong here, I would like to see what can be done with certain limits removed. I would love to see someone make a 5000 screen mod in some sort of big maze, but these sorts of discussions always end up with people making really far-fetched feature proposals and then of course nothing happens.

Just out of interest, what sort of cases have people run into that caused them to want more than 200 global vars?

Shevek's pre-processor by definition cannot increase power or functionality. It's only for convenience. It's still DinkC; it just writes some of the tedious stuff for you.

If the people working on it use agile software development practices, then if they give up partway, at least we'll have something. Pick a few features you can add in a short period of time, implement them, release the new version, and repeat.

If you're gonna Remodel dink,remove that annoying error where the game suddenly stops between Midi's please!

Duckhater, that problem is fixed if you run Dink using Aural+, like I do.

Yeolde, the point of the graphics is that you DON'T have to write the frame lines, because I would like nothing more than to build a repository for all the community work and have it ready as a community pack to build d-mods from. In essence, nobody would have to write a single dink.ini line anymore unless they want to add their own new content, all the other content would be made readily available with dink.ini lines included, as well as logical order in sequences (unlike now...).

Someone, I know the preprocessor can't do anything new like arrays, but it definitely makes scripting a million times more manageable when you're doing some more intricate stuff I mean, I've looked through your MouseDink scripts and although it's miraculously well scripted using DinkC in its current form, it could be so much more readable through the preprocessing, wouldn't you say? This is mostly a quality of life change that I support.

New features such as arrays would be nice too and could be included. Altering existing scripting functions would be too much for 90% of this community.

And I've already run into two sitatuations where I run into the globals limit. One is a log/treasure map keeping track of all the secrets that have been found with their location dynamically stored and the second is a questlog. Both require so much data storage it's almost impossible to do without using globals (yes you can use supervariables but that's a mess and it doesn't allow values over 9 to be stored).

@Kylie
Thanks!

I'm not denying that Shevek's preprocessor scripts would be more readable. I'm just saying that the reason I would like a new scripting language is not for convienence or quality of life or anything, but added functionality, and Shevek's preprocessor language is just DinkC in terms of functionality.

'Supervars' allows values over 9. Read my advanced tutorial. The inventory system in MouseDink is very extensive (24 different slots with 35 different possible items for each slot.. so 24^35 different possible inventories) and is stored in 4 variables.

On the topic of supervars and Shevek's preprocessor, prehaps Shevek will like to integrate my 'supervar' read & write functions into his preprocessor. For most, that would effectively remove the var limit. The DMOD author would just have to specify the range of values their pseudovariables can have when they initialise them. And no custom exe would even be required. But of course, this doesn't remove the other limits.

I realize the possibilities supervars hold, I have read your tutorial many times over and use them in my own d-mod from time to time. I also use another method described in your tutorial to store data, that of quickly loading a screen and changing sprite editor_seq and frames. All of this works, but it is a nuisance to work with, requires a great deal of organization to know which var or part of a var stands for what and above all, it is completely impossible to expect new authors to work with these methods

I admit that for me the ultimate goal would be to build a complete repository of all kinds of resources for new and old authors to use. This would include all community graphics already implemented and available for us and a vast amount of script templates for things like shops, items, magic, interface elements, timers and the like. For these templates to work together and be easily expandable and for the graphic slots to be available, we need these limits removed!

Has anyone tried recreating Dink in an entirely different game engine? That would solve some problems while creating others, I'm sure. It would be interesting in any case.

btw, if I wasn't clear, I meant that Shevek could set it up so you could do this:

intp &var1 [1-10];
intp &var2 [1-10];

and then use &var1 and &var2 as normal, but they are stored in the same int. All the 'supervar' code will be hidden away.

Anyway, a lot of the other suggestions of what to do with Dink (like mine, sorry) distracts from Kyle's original suggestion. I think increasing the limits and having all the community graphics implemented in the one ini file would be a great idea.

dinkulum wrote:
Has anyone tried recreating Dink in an entirely different game engine? That would solve some problems while creating others, I'm sure. It would be interesting in any case.

Novashell comes with a Dink demo game, and Rabid wolf attempted to rewrite some of the game in it just for fun. It isn't screen-based however meaning it's not at all similar.

What would be interesting is a complete rewrite from the ground up, but nobody will ever do that.

change some limits around and compile a new version

Been trying to, since 2009.
Hopefully Dink 1.08 Unlimited will emerge in roughly 2015

Keep in mind that there are a few off-by-one errors that can crash a modified build, and one may need memory breakpoints to find them(Red had noticed fgold was altered by the palette entries array, I've had a graphics buffer overlap with the callbacks array etc.)

Did you try this with the freedink source code or the original 1.08?

Original 1.08. Never seen the FreeDink source to tell if they've been fixed there.

The FreeDink source is very different.

/me was forcefully dragged out of his OpenGL hacking by evil magic powers and finds he's been teleported on the DN board

/me blinks

Hi!

Not sure what kind of wisdom you want??

FreeDink can certainly be modified, though some parts of the original engine are still easy to break. A number of things were broken with 1.08, and it made be wonder if I would have to maintain 2 versions (FreeDink 1.07 and FreeDink 1.08), but eventually I could code the 2 at once using the "1.07 mode" option.

Changing the 99 sprites/screen limit requires a change to the map and savegame formats.

A way to keep compatibility is to ask D-Mod authors who use the new version to explicitely specify what version they target. For instance they could create a version.txt file containing "1.09" or whatever. This way the engine could switch between different compatibility mode. That's what's used in Flash or Java.

I compile FreeDink for windows without problem, but using either MSys+mingw, or cross-compiling it from GNU/Linux using mingw (I'm a command-line guy). One could easily create a Code::Blocks project and copy/paste a mingw config.h if necessary.

I guess it's better if you ask me questions instead of letting me rant this way

Hi Beuc, thanks for coming along!

I understand very little of the second part of your post so I'll leave that to smarter people

But did you ever look at the possibility of changing some of those limits or were you just focused on doing a straight port?

It would seem we could still adapt this then and indeed have some sort of "legacy mode" available for older d-mods the way you suggested. This should alleviate some concerns people had too

I added multi-dir support (dink dir + a separate d-mods dir), on-the-fly translations from .po files, .ogg music support, and I considered adding more features, but I kinda stopped half-way. It takes guts to make big changes

I already did some work to maintain both 1.07 and 1.08's different limits,
I think it's well possible to experiment.

Make sure you use the latest (unreleased) FreeDink source btw:
http://git.savannah.gnu.org/cgit/freedink.git/log/
There are a few additional bugfixes there (including the palette stuff in Blacksmith).