The Dink Network

Seth has asked me to organize a v1.08 release of Dink, with your help.

The goal of this release is to implement "some bug fixes to provide a smoother experience for new Dinkers."

The current plan is:

* Make it so the frame-rate will not exceed 60.
* Add some (or all) of the changes from reDink
* Install a .dmod file archiver with Dink, automatically associate .dmod files with it (probably DFArc.)
* Use a NSIS (Nullsoft Scriptable Install System) installer.
* Add Dink Smallwood registry key.

Other changes that aren't guaranteed to appear are:

* High/True Color support (maybe... at the very least it can't affect performance on older machines.)
* Small fixes in the original game (fix where one of the character's says Dink's line, hardness holes, hardness sticky points.)
* A frontend that doesn't crash when you have more than 50-or-so D-Mods installed.
* ffcreate2
* DinkC Reference v3.2

So... anyone have any suggestions?

And remember: the goal is to fix bugs and ensure compatibility on older machines. If you think of something really cool that should be added to the build, you need to justify it.

Locking the frame rate (at 60, no less) is the worst idea I've heard in a long time. No need to say more on that. The other stuff looks pretty logical. Maybe you could package WDE with it? I've never tried WDE (dink edit works fine for me), but other people like it, and it can do some good stuff.

Locking the frame-rate at 60 is one of Seth's main goals in v1.08. Perhaps Seth used the wrong term... he said the frame-rate should not exceed 60. It won't be *locked*.

And packaging WDE... yeah, that would ne nice.

Hrm... I think the highest frame delay I use is probably around 100 and the lowest is in the 10 to 20 range, but I fiddle with frame delays quite a bit. It gives you much better control over projectile speed than anything else.

Ah, that's right... any frame delay under 17 would just act as if it was 17, right?

Anyway, Seth said:

"I would lock the framerate to 60 FPS or so. (if less than 17 milliseconds passes since the last update tick, just do a Sleep(1) and then check again would be a simple way to do it."

I think there are some machines where Dink doesn't work because it can update too fast or something... hrm.

What if it calculated all of the positions and everything on each frame hit, and then decided to draw the screen or do a Sleep(1) depending on the last actual draw time? The projectiles should still be about in the same place... though it might screw other things up, I haven't thought it through.

I'm a bit confused, but it's probably because I don't know the engine.

Let's say I have two sprites on a screen, one with a frame delay of 18, the other with a frame delay of 19. (18, 19) = 1, so eventually one will update exactly one millisecond before the other. So the screen has to update every millisecond no matter what you do.

But that doesn't happen in reality. There's no way that anyone gets 1000 frames per second. The difference is visible over a course of time.

Lets say that we get exactly 60 frames a second, or 17 milliseconds a frame. This will never happen with the Dink engine, but we're pretending.

Say we measure two sprites with frame delays of 18 and 19 with the same sequence.

Draw 0 (0 ms elapsed): S1=1 S2=1
Draw 1 (17 ms elapsed): S1=1 S2=1
Draw 2 (32 ms elapsed): S1=2 S2=2
...
Draw 8 (136 ms elapsed): S1=8, S2=8
Draw 9 (153 ms elapsed): S1=9, S2=9
Draw 10 (170 ms elapsed): S1=10, S2=9

So, for 9 or so frames, the sprites will display the same frame. But every 19 draws (the first increment happens around 19/2), S1 will increment one faster than S2, making it *appear* to update 1 ms faster even though updates only happen every 17 ms.

If you hard-lock it so a frame is only calculated and drawn at least 17 ms, then any frame delays under 17 ms will appear to be 17 ms.

And I just thought of something... Seth may want the hard-lock-at-60 as a quick-fix for Dink's speedy problem... but it should be possible to fix it without that lock.

I feel pretty stupid, it all makes sense now.

Edit: I mean, you could still have a frame delay of ten for all important purposes (speed?), but the pic would update every 17 ms, or that's how it seems to me.

Hmm... although, it could update *twice* in 17 ms, right, so it would still appear to be 10 ms over a greater field of time?

It'd skip a frame on occasion? For a fire, it'd seem to play at the same speed, for an attack it'd seem faster.

Windowed mode would be very useful.

Also, for the frontend... I could create a custom skin for CustomFE2 and use that. I checked it out, and it would be possible to add check-boxes for windowed mode, a button for WinDinkedit, and so on.

Make it so the frame-rate will not exceed 60.

Well, I think Seth is using HORRIBLE terminology when he's saying lock it at 60. What I think he really means is not to make it run too fast. What really needs to be done is to set up a time delta and synchronize buffer swaps with it. The engine should be perfectly capable of running at 120 fps if necessary (which, frankly, it isn't, but that really isn't my point). What Seth is saying, I HOPE, is that it should just run at normal speed (60 updates/second?), regardless of the actual fps value. You're on your own on this one. I'm the OpenGL guy, heh.

Add some (or all) of the changes from reDink

All. I think the most useful will be the math functions and variable association problems.

Install a .dmod file archiver with Dink, automatically associate .dmod files with it (probably DFArc.)

As per our discussion.

Use a NSIS (Nullsoft Scriptable Install System) installer.

You can steal DFArc's if you want.

A frontend that doesn't crash when you have more than 50-or-so D-Mods installed

I can make one so it pairs up with DFArc.

---

Now, are you sure you're not volunteering to help code Windemere?

but why shall we have a CD-Key?

Well, I think Seth is using HORRIBLE terminology when he's saying lock it at 60.

Yeah...

reDink... All. I think the most useful will be the math functions and variable association problems.

One slight problem is reDink has never been extensively tested, and some of the changes (like the variable association problems) might cause unforeseen problems.

I can make one so it pairs up with DFArc.

Instead of making an 8th frontend... I think we should just use a custom skin for CustomFE 2. The skinning system is really quite powerful, and I could even add a button like 'Create .dmod' to make a link with DFArc.

Other potential ideas...

* Look at the source code of unDink to see if there's anything we can use (like any of the sound functions, so the game doesn't pause whenever it tries to play a new midi on some machines). Heck, maybe we'll even get MP3 or WMA support via DirectX with no problems.
* Make Dink compatible with a 'User' account in Windows XP/W2k. This would require that all of the D-Mods be installed in a folder in the user's My Documents area. An adminitrator would still have to install it.

Why would there be a CD-key involved?

Why would there be a CD-key involved?

Quote: "* Add Dink Smallwood registry key."

I think he's asking what that registry key's gonna do.

Ah. The registry key would just hold the directory of Dink Smallwood, so programs could rely on that instead of reading the dinksmallwood.ini file.

do you mean like this,

when you shall add graphics (example) you just put all thing in the dinksmallwood folder, and no .ini editing?

It would hold the directory so a path like C:\Program Files\Dink Smallwood or E:\Dink Smallwood or where you've got it installed.

Look at the source code of unDink to see if there's anything we can use (like any of the sound functions, so the game doesn't pause whenever it tries to play a new midi on some machines). Heck, maybe we'll even get MP3 or WMV support via DirectX with no problems.

I had this problem on Windemere for Windows. I managed to get some code working that has no pausing problems. I can give it to you if you want.

MP3 is, if I recall, directly supported by DirectX. Then there's the issue of licensing for the format (see previous threads for this issue). I seriously doubt WMV is supported. I do believe that AVI is supported though.

Instead of making an 8th frontend... I think we should just use a custom skin for CustomFE 2. The skinning system is really quite powerful, and I could even add a button like 'Create .dmod' to make a link with DFArc.

I guess I meant one that integrates with DFArc so it's the same program. But, your way works too. Heh.

I mean WMA... doh.

For the licensing issues, wouldn't that by covered by DirectX? Because Dink would just use a common library, I wouldn't think it would be affected.

For the licensing issues, wouldn't that by covered by DirectX? Because Dink would just use a common library, I wouldn't think it would be affected.

Probably. I'm just not used to using Microsoft stuff.

I believe WMA is supported along with MP3. I can't tell for sure. I hate MSDN (because I can't use it .)

I really hope you get that miidi fix in. The pause in my system is so bad I decided the only thing to do was disable MIDI copmletely.

Besides that the number one evil bug, is the local variable bleed over problem. I don't suppose there's much chance of fixing that.

Yes, can the local variable bleed over get fixed... it's tripped up a few players on SOB and PQ (at least I believe that's the problem)....

And welcome back Paul, haven't seen you around for a while...

I think the local variable bleed was fixed in reDink? Or was it just planned, hrm...

Is it fixed in reDink? I didn't remember that (though I don't remember it not being fixed either...

Great if so.

Local var exchange (or bleed, however you call it) is fixed, as well as the naming bug

Obviously it's because I have very little development experience, but I never understood exactly what the "variable bleeding" bug entailed. Explain?

I never figured out exactly when it would happen (which is part of why it was so annoying) but basically if two or more scripts running at the same time had local variables with the same name then the values can get mixed up.

The naming bug is only fixed if there is a space character following it... sort of a half-donkeyed solution.

You know, this is really minor, but I just thought of something that always bugged me (no pun intended) in the original game. You know Dink's first real quest, to clear out Smilestien's field?

The four "henchmen" pillbugs are wierd, they don't give experience, make sound, or die properly. Now maybe Seth had some reason for doign that, but I can't imagine what.

If it were me, I'd give the four of them a script just like the normal pillbug script, only with code added to stop them from reapearing after the boss pillbug is dealt with.

An idea i think could be usefull for popularity, would be to make an options menu on the main screen that would have languages to select from. Maybe that would be too much to handle, but seeing as there are many foreigners with not-so-good english, looking at the game in their home language would be easier for them.

There are French and German versions of Dink available... but I'm not sure it would be necessary to include them in the main distribution. Maybe... hrm.

Most people play dink for the Dmods. The Dmods are done in English. Problem solved.

YEah... i dont really get how that is problem solved.

I have a few feature ideas...
Maybe you could allow people to change their name from dink smallwood...
or Make more secret dungeons...
Or add some time of inbuilt map changer in mod... So mods can get larger, and better, think about it FB3 that had two map files, what if it changed them automatically when you went to the certain place, you could make games as epic as Morrowind for Dink Smallwood,

SirCabbage.

Name change - Won't happen. Seth really just wants a bug fix for the original game, and allowing you to change the name of Dink would not be very cool.

Secret Dungeons - Also won't happen... nothing *new* will be added to the original game, only fixes.

Map Changer - Likely. I implemented a function to do this in reDink, and I might be able to sneak it in

Umm... I'd assume adding more graphics slots or variables is out of the question...

The double space in the line "I'm gesturing wildly to no avail!" or something along those lines should be fixed. It just looks annoying!

There is a bug that lets you walk on the mountains, Here is a screenshot, so you can see where! Here is the pic of the bug!!

Sorry about the url mr.Redink1

Also, what about more tiles?
Or fixing lraise so it doesn't fudge everything up.

FRONTEND:
- I wanna see more options in the FrontEnd... Like 'set standard editor' because I use WinDinkEdit.

- Yeah, Windowed mode, as mentioned, but put in the FrontEnd as an option, too.

- I'd like to see a normal list instead of a dropdown list, too. Maybe customizable full/dropdown?

- And a "show help file" in the FrontEnd to show readme.txt or dmodname.txt.

- Yeah, that Frontend window is resizable and that looks bad too.

GAME:
- High sound support up to... Well, the max.
- More color codes for text!

That's all I can think of at the moment.

He is not chaning the engine just bugs and such!

Frontend - It is very likely that the Frontend will either be a new skin for CustomFE 2, or something completely new. So yeah... some sort of options for WinDinkedit and windowed mode should be available.

reDink allows you to change existing tile sets, which could be extremely useful... say change them from Grass to Snow when something cataclysmic happens.

What's wrong with lraise?

How long will it be till we should expect this patch to come out...

It's supposed to pause scripts, but it has a nasty habit of killing them?

1-3 months for the beta, I think. I might try to work on it a bit this weekend... right now I'm in website-programming mode.

I suck at HTML.. but something id liked to see in 1.08.. I dunno.. no idea.. Sorry im not helpful!

I'm sorry, man, but that's the silliest suggestion I've read in this entire thread. What good would website scripting do in Dink?

He didn't suggest it. He was just replying to redink1's website-programming mode. After that he said he didn't know of anything to suggest and apologised for not being really helpful.

Ah, I didn't even acknowledge redink1's website bit. Though Darkraven's post was still a bit... confusing. Thanks for making sense of it, heh.

The site isn't even DONE in HTML...

Lol, I still have to see the first site that isn't made with HTML. Sure the extension is cgi, but that's just the name of the script that's making the HTML. If not, it's a script that generates the code for non-static things and places it in a template written mostly in HTML.

<nod> Sorry to screw up this.. Topic.. But i didnt mean to start a whole thing on HTML. This if for the 'Suggestions of 1.08' >.<

Red text would be nice It isn't that hard to implement, I imagine.

Hi guys,

Thought I'd pop in and add my two cents!

To clarify, yeah, I mean limit the game logic (and backbuffer frame update, no reason to keep updating that when nothing changed) speed to 60 frames a second or so. (it just adds a delay so even if the video card isn't locked to refresh, timing doesn't break because the game is being updated 1000 times a second)

I don't mean playing with the refresh rate, of course.

The reason for the limit is because of the horrible int-based timing system used in Dink... it's a very simple band-aid fix, much easier and less likely to break things than actually fixing the timing system. (it's just a few lines of code)

Also, I wouldn't add hicolor support, unless it's in a separate non-default mode/exe. The reason is it basically triples the hardware/mem requirements without any noticable improvement in Dink or any dmods, as they are all designed for 8 bit dink I would assume.

It also introduces more things to deal with such as needing to redo screenfade code.

I'd keep things very simple to get out a simple bug free, fully backwards compatible release pretty quickly. Can always add stuff later.

-Seth

Hmm... what fixes to the fade? Like how any white pixels still show when faded?

I meant if hicolor mode is added, you need to worry about fading - High color screens don't have palettes, so palette fades don't do antyhing.

Is there a bug with the current fading and white pixels? Hmm, you know, I kind of remember that, maybe I was not touching every index of the palette correctly, not sure.

redink explained it pretty well...

Will it be possible for a script to run twice in the same cycle? I guess this isn't really possible now, but a wait(1) creates no perceptible delay; for instance, if you do something with a script like:

void main( void )
{
//make it hard, but don't calculate yet
sp_hard(&current_sprite, 0);
wait(1);
draw_hard_map();
}

Now, if Dink walks into this from another screen, he doesn't get "stuck" (because his frame delay is greater than the delay created by wait(1), I imagine). So, this script runs (seems to run) twice before Dink's position gets redrawn; the sp_hard line runs, and then other scripts get run, and then the draw_hard_map() line runs (god only knows how long passes between the two ) So, my question is, will there be anyways to have a script run twice between screen redraws? If that doesn't make sense, I'm probably being stupid .

Actually, I can't think of any situations where it actually matters, besides the one I described (in which there are many, many other ways to do things)... so, nevermind, sorry...

Hmm, a hicolor engine was done (also the windowed mode). If people (like myself) want it, they can use that. It's not a big thing, but someone mentioned a command to check if screenlock was on...?

ooooooh, Seth the almighty is here, ALL PRAISE SETH!!

thanks for making such a good game!!

I looked into the midi slowness problem, and it appears to be a problem with the Windows 2000/XP implementation of mciSendCommand and mciSendString.

Using DirectX's DirectMusic framework would boost the requirements of Dink to DirectX 8, and would require fairly extensive changes to the midi playback functions.

There is another option related to a 'MIDIPlyr' example in MSDN, but the only reference to it I found said it was extremely difficult to implement.

BUG: If the screen is faded out, all text showing is white instead of the selected color (or yellow). Maybe ignore the pallette change for fonts in some way?

DaVince, I don't think that's a bug, per se...

White is the only color that is visible when the screen has turned dark courtesy of fade_down. I believe Seth set the font colors to white so the player could still see text while the screen was dark.

Yeah, that's a bug. Can't you use some unused pallette colours (if any) to reserve them for font colours, then ignore them in the fades so they will always stay at their original colours?

Is it really that big of a deal to you? (Not trying to be harsh or anything...)

And I will agree with redink1 that Seth probably intended it that way for all fonts to be read during a fade-down. Granted, most are legible already, but the dark gray font against black wouldn't be too pleasant for the eyes, for example.

I agree with tal, Would you really want to read something like that

Ditto, not a bug, just a quirk. It can be a little annoying, but I found it easy enough to work around. Fade down, put a big black sprite over the screen and fade up. The screen's still black, but the text is in color. No problem.

Heh. Oh yeah.
It's not really a problem anyway, I just thought it was a bug.

It moderately annoys me when you have tiles like snow with lots of white dots on the backround. I wouldn't say it's a bug but a lazyism-mistreat... I mean, you could have two white colours or one pure white and one a shade darker than white in the pallete of which the other would be used in tiles and the other for text. of course people could also edit the tiles and remove the white dots...

so it's not a big deal. I spoke myself to a bag... can you say that? did anyone understand? nonetheless the jolly good scratcher has now spoken. ugh!

Now, see, that I don't like. What I like about e.g. Firefox is that it can be installed in user space, and still run, given that the Administrator doesn't disallow running arbitrary .exe files in the user space. Why can't Dink be that way?

I also STRONGLY dislike that second idea.

Aye. I decided not to pursue it, if that's any consolation.

What about a Dink Internet plugin for playing dmods in the browser?

That'd require too much effort for something that would probably not be used often, if at all. Is it even feasible?

You'd have to use a Java applet, but still, it would be too much effort for the value.

Hey, I was just joking!

dunno if I'm late or if they already exist or somebody already suggested them but commands to check the screentype and whether music is attached to a screen or not would be quite useful, also the frontend should sort dmods by their name as they appear on the list instead of their directory names.

on the repair side I would see fixing the screenlock bug would be most important...

It might be late, but I have two suggestions:
-The first one is a bug(it might have been fixed in 1.07, because I played the original game with 1.06 version). In Terris(north of the castle), there is a cave that takes you at the "Edge of World", and it's only visible after you return from the Dragon's Island. If you walk one screen right, then return, staying exactly near the cliffs, you can walk on them, and if you move some screens right or left, you can even walk around the houses on the dark area.
-The second bug is that if you quit the game using Alt-F4, and a midi is running, it still runs, and there is no way to stop it.
Hope this suggestions are not too late.

More cowbell.

you can alt-control-delete the midi out, for some reason Dink keeps running in processes...

The first bug is a hardness error (is redink1's hard.dat rewrite going to be in the new dink?)

lol at Striker.

you can alt-control-delete the midi out, for some reason Dink keeps running in processes...
Belive me... I can't with alt-control-delete. I tried. Of course, the midi stops after one minute or two, but there is no way to stop it before(unless I turn the speakers off).

Ah right, can't there be a new function which makes user-started MIDIs loop? Because they don't.

What is the local variable bleed and is there a way to avoid it affecting my dmod?

I still think an option screen is a good idea. A few small custimoisation options would be nice. Perhaps the true colour version could be done from there instead of with a seperate icon.

A map changer would be cool!

More graphics slots and variables would be cool.

Instead of making an 8th frontend... I think we should just use a custom skin for CustomFE 2. The skinning system is really quite powerful, and I could even add a button like 'Create .dmod' to make a link with DFArc.

I guess I meant one that integrates with DFArc so it's the same program. But, your way works too. Heh.

How about an updated version of DFArc that includes a FrontEnd?

More tiles would be good. That way instead of replacing original tiles with new ones we can just add new ones.

How about a windowed version of Dinkedit? I know WinDinkedit is such, but Dinkedit has features that WinDinkedit doesn't such as editing hardness boxes and moving the center of the sprite. I would like to access these from a window rather than full screen. With the exception of movies I hate using full screen.

There's a file that does that somewhere here... prolly in the development section.

edit: http://www.dinknetwork.com/display.cgi?action=File&ID=396

You sure you tried closing dink.exe under processes tab? because that always ends it for me... oh well, it's good most dmods don't have classical music then.

Well I wouldn't know about that since it doesn't work for me.

I also can't get that undir.bat thing in unDink to work.

Man, talking about double posting!

One more bug... If you're in a screen with monsters and a save bot, you kill the monsters, save the game(whitout leaving the screen) and you reload it, the monsters are back(alive). I think this bug is in the savebot script... I don't know...

There is a bug in the bar at Terris (With those two guys who insult Dink when Milder comes). Finish the game without talking to them. After you have killed The Seth, go and talk to them and Milder should walk in.

More control. I want more stuff out of the executable and into scripts. The item menu, for instance, could then be replaced by adding another script with the same name to the Dmod folder.
Some way to script custom holdable keys (I mean like the arrow keys). That way, two players could have a fight on the same screen, using for example the arrows and WASD, or other cool stuff could be done.

Not that I am going to use any of the features, but it would simply be cool.

PS: I think the hard.dat rewrite messes up the fun with shooting the guards from the edge of the world.

Good idea, indeed. i would definetly use it. Not they would even do it even if they could, though.

"They," the team behind the engine fixes/additions for Dink 1.08, is... redink1. And guess what? He has more things to do with his life than work on additions to the Dink engine day in, day out. He's currently looking for a job and also looking into developing software which he may make a profit out of.

As Seth said before, and as redink1 seems to be following, tweaks and fixes are the primary motivation for 1.08's release... there will be a few nifty additions as well, but this is not intended to be the end-all, be-all version of Dink that everyone lusts for. Should redink1 or anyone else kind enough to help wish to make further additions down the line, then so be it.

I apologize if I sound bitter lately; I have been stressed out more than you'll ever comprehend.

It's okay, I think I do understand. I've been through a few of those moments. And what you were saying about him not having the time, well I'd guessed that and that was part of why I said in a poor way mind you) that i didn't think it would be done. That is a large part of why I am working on small packages for Dink right now rather than a dmod or any other full time project - I just don't have the time and I too want to move onto software development and maybe even make a few bucks off it (though I will have free versions of my software, however). And I said "they" because I wasn't entirely sure if it was just redink1 or if others like yourself were involved.

//Ah. The registry key would just hold the directory of Dink Smallwood, so programs could rely on that instead of reading the dinksmallwood.ini file.

dinksmallwood.ini can be read via %windir% (Windir is a Norwegian band, BTW), independent of the windows directory name and position. How would a registry key be better?