The Dink Network

As you can see, a new forum has been created dedicated to discussion about the impending release of the Dink Source Code. I felt that such discussion deserved a forum seperate from general development questions.

The only current problem is the icon for this forum... its a red bomb. What does a red bomb have to do with the Dink Source? Not a dang thing. But it is different enough. If you can think of a more suitable icon, post a reply.

How about a scroll, or a piece of parchment?

Hot topic !
Bomb good

Hot topic !
Bomb good
< moved from wishlist>
hm...
continuous scrolling...
Sprites would need to be there, but frozen or at least scripts paused until a player is in sight. Any player ( I'm thinking ahead to multi-player too) kills a sprite, it changes the editor_type to 1 (kill it) for all players, so how to pack that into the data stream to other players?.
Let the screen scroll so each player sees himself in the center, it will help to use 600 * 800 res. to see a bit further. For screenlock, no problem. The screen just stops scrolling.
When a screen is marked (as per indoor,) the screen will not scroll further in that direction. (?)
Should the engine load the entire game or preload each screen around the current? Preload the whole game! It may use 10 MB, oh well most of us have at least 128MB.

Nexis wrote a good point about bugs. We should fix them, but we lose backward compatibility by doing so.

So I suggest we make a list: if you remember a bug in the Dink engine, write it down here.

You can also comment the previous reported bugs (maybe some of them can be easily fixed, or are not really bugs, maybe the bug was not described completely...).

Each bug should be described with 5 or 6 parts:
- Title: sums up the bug
- Explanation: details how this bug occur
- Eg: give an example - a DMod where the problem can be seen, a script that makes the bugs appear, the way we could reproduce the bug...
- Bad Side(s): the problems coming from this bug
- Good Size: sometimes bugs can be usefull to - see bug #1.
- Fix: how to fix the bug without a new patch from Seth

Here are some I found:
1) Title: Background sprites and auto-changing tiles
Explanation: We set sprite as background (press 2 in DinkEdit). Then, under it, we use a tile that automatically changes (as the fire or the water). After, when playing, when Dink.exe redraw the tile that changes, then the background sprite is 'replaced' by the tile, and is not redrawn.
Bad Side: of course, this spoil the design of the screen: some sprite can partly or completely disappear of the screen.
Eg: I set a dead branch as a background sprite near a lake, and when I played, the sprite had disappeared! It took me some minutes to understand why...
Good side: in Dink's Doppelganger, in the alien basements, when you kill a player, a cool effect occurs: his body only remains for a few seconds, and then disappear, because all the ground is in fact one of these "special tiles", modified to show a ground and not some fire or water - so does this bug need to be corrected?

2) Title: The wait(&ms) command is supposed to wait for &ms milli-seconds. But this gets faster is the computer is faster. Seth said he did not find where was the problem.
Eg: Dinkanoïd, cool on my P133, unbeatable on my P650.
The Other World intro, when the snow when reach the ground, this one is supposed to become white, but he does not on every computer (on mine, he become white before the snow reach the ground).
Good Side: I do not see any.
Bad Side: This prevent the DMod maker from doing complex timed animation or games.

3) Title: diagonals & hardness in locked screen
Explanation: when the screen is locked, or when the is no screen around the current screen (so Dink is also stopped at the edge of the screen), and when Dink is walking in diagonals at one edge of the screen, then he can walk through hardness.
Eg: in Lost in Dink, the are several screen going up toward the end boss (with lost of evil maiden, ducks and co), with DarkLands-like tiles. The screen is locked each time you enter a new screen. If you walk in the bottom of the screen, and go southwest, then you pass through the edge of the road.
Good Side: I can cheat and destroy this dang evil ducks & co without being hurt ))
Bad Side: I can be "trapped" in the other side of the road ((

4) Title: The 1-pixel height line just above the status bar
Explanation: In this line, regular sprite are not displayed, only 'noclip' sprite can be.
Eg: in DinkEdit, put a rock in the bottom of the screen so that in the game, we will only see its upper part (the lower part should then be in the screen below). Play this screen, and you will notice that the lowest pixel line of the rock is not displayed; the tile is displayed on all this line instead.
Good Side: ?
Bad Side: This is quite boring, above all in cutscenes where you did not drew the status-bar and make a sprite come from "under" the screen.
Fix: if possible, use sp_noclip(), but this cannot work in all situatoin (eg: in the cutscene where you did not drew the status bar and have tiles displayed - not only a black background).

5) Your turn now.

When in the game, changing from one screen to another, there is often a (long) pause. I have found this to be because of the MIDIs changing. Maybe it would possible to pre-load all the MIDIs? After all, they are only ~50-100kb each.

I am not sure this is related to Dink: I did experience that under WXP, because it did not recognise the MIDI part of my sound card. Under Win98, with the same computer, I do not have the problem at all.

Probably is Windows XP. Remember Dink came out before XP did (don't know if that makes any difference).

The problem with a scroll/piece of parchment is it would be easily confused with the current icon for the News topics.

Okay, keep the bomb. It relates to the way Seth codes (or so I've heard).

Well, I add the feeling that when playing a midi, if a direct midi hardware is not found, WXP (or DirectX) will first transform the MIDI to a WAVE file in memory by software methods (as TiMIDIty++ does), and that takes a little while. Unfortunately, this is done each time the midi changes. Maybe, though, there is a way to tell DirectX to handle that better.

There are some soundcard who deactivate the software transform ( midi to wave ) and do it themselves. Ive got one lying here who does that, no midi pauses....

I dont know the name, I will search it in the soundcard databases...

Even though a scroll could be messed up with the news-icon, I still think it'd be better to have it as an icon for the source-forum, rather than something that has absolutely nothing to do with it...

A chest would be a good icon for the source though, so I thought you could change the icon for the file discussion forum instead, since I can't really think of a good connection between the chest and discussion of files... Oh well.

I Think It Should Be A Barrel

Many of us are worried about the download size if dink get mp3 support. How about if we enable dink to look first for an mp3, then if not found play the equvilant midi. For eg.:
playmidi("forest");
Have dink look for an mp3 named forest.mp3, and if there isn't one, play the midi equivilant named forest.mid. That way big mp3 files can be downloaded separatly, or the game can be played fine without them. This would be similar to dink as it is, looking for a .wav or .c file first in the dmod folder and if not there looking in the original dink folder.

I agree with you ric, thats a good point, and it'll work, Although, its up to the dmod author to make their music amount small enough, though some will stuff their mod with tons pirated music,..

But thats not the only thing, graphics, if enhanced to lets say 32-bit, will get some size change too.. like four times the normal size, This is something we have to live with though..

That is only for mods that have intention to make new stuff that would support that..

Another important thing is that too many would use those features badly,.. If one is to use enhanced graphics and mp3's then they should really use it well or not use it at all.. or their download will not be worth it..

32 bit graphics, are you insane?

Title: compare_magic() doesn't work
Description: When you try to use it as you do with compare_weapon(), it returns a strange number.
Good: none
Bad: see Title.

christian, far from it, 32-bit graphics is quite normal nowdays, There's no reason not to support it, And, since we are not going to make a dink3d we might aswell go as far as we can with 2d.. Namely, 24-bit color, with the 8 bit alpha channel, for smoothed out edges on the sprites, even an old tnt2 can handle that..

I'm sure that more people would be happy to no longer have to worry about palette problems and ugly colors..

the issue isn't whether what system can or can't support it, the issue is the size of it. not everyone has cable or dsl, so us 56k dialup people would be stuck with huge 50 to 100 meg downloads just so we can look at some pretty pictures in a game or listen to mp3's in the game.

But then whats the point of upgrading the dink engine?.. Nowdays adsl is very cheap, even computers that can run with what I propose are cheap,

the dink engine will go that way, thats the whole point of the source release, to modernize the engine, to make more people interested in dink.. no one wants an outdated engine with weak scripting capabilities and limits in graphics that makes any artist scream in agony.

We _do_ need a higher color amount, and we do mp3 support and such, no one _HAS_ to use those features even if they were implemented, but I suspect that most will..

true, but the point of it was also for adding new commands and such for making scripts in dinkc, and fixing some bugs that are in the engine

well, not mainly, for some persons yes, For others..

I stopped modding because of the color flaw in dink..

imo, the main reason was to both update the dink engine graphicly and the scripting system.. to do either of them we'll have to redo most of the stuff in the dink engine anyway, so we dont have much of a choice..

though, in addition to the size limit, People can do 100 meg dmods now aswell,.. If people do big dmods, then blame then, and dont download the dmod, But if the space is well used, then it might even be worth it..

The point of the source release is in my opinion to improve some stuff, taking out bugs, making things simpler and so. If Dink becomes 32 bit with mp3 sound, I'm outta here

Then pack your bag..

That attitude of yours isn't doing any good..

actually, I do hope you come to understand what the dink engine can become if you just give it a chance without having any prejudice against modern(quite old actually) technology.

Then pack your bag..

Why don't you stick your head up your arse, see if it fits, fool

That attitude of yours isn't doing any good..

That's like the most stupid comment I ever heard. There are a lot of people with me here, so I guess YOUR attitude stinks. Why would you wanna make dink 32 bit with mp3 support and all? I've got some very clear reasons why that would suck.
1) Most of all, it simply won't be Dink anymore. It would become a totally different game. Gone is the Dink feeling, gone is the entire sense of dinking
2) Too big to download. Not for me, I'm on broadband, but there's a thing called empathy. I know how it is to be on dialup and the argument "adsl is cheap" is actually CHEAP. Parents don't think that way, get out more often.
3) Many people will leave, like me, if Dink is gonna be changed dramatically. Now you won't care, but there are some social people here too, who DO care.
4) The old dmods, and the dmods now being developed will be 'worthless' when this new engine is released. Now that would be a total shame.
5) If I'd want to play a 32 bit game with stunning sound, I'd play some other, 32 bit game with stunning sound. I want dink, and that's it.

actually, I do hope you come to understand what the dink engine can become if you just give it a chance without having any prejudice against modern(quite old actually) technology.

I DO know that, and that's exactly why I would leave if this is gonna happen. I know tastes differ, but don't act like you're 'right' and I'm 'wrong'. There's no such thing as right or wrong. You really need to grow up dude. I'm just saying I'm gone if this is really gonna happen.

When it ain't broke, don't fix it

i completely agree with you christiaan, but some people like us are going to realize that not everyone appreciates downloading massive downloads filled with 32 bit graphics and mp3's and not include them in their dmods

ok, sorry for winding up a bit, but what are we supposed to do?.. just fix up dink a bit and leave it like that?..

Trust me, as an artist I've tried to make a dmod once for dink, running into the graphical limits was not the nicest thing to experience, 256 colors is not the best thing for rendering 3d images with.., Also, The dmod sizes wont change, thats up to the authors.. If they add enough junk to make it 100 mb's then they shouldn't be adding new graphics..
A good artist can manage his artwork and not add unneeded artwork that will take up unneeded space, also he wont steal a hundred mp3's to just shove inside the dmod, he'll make a couple of them of high quality..

Ok now, we are having different feelings on what makes Dink feel like Dink, I will work towards redoing it into a more modern engine, IF it then ends up with a majority not wanting that, then I wont add anything to it, and I'll work for myself instead with the source, because I definately want support for better graphics AND compressed sounds.

there are also things called 16 and 24 bit graphics that aren't quite as big that look just fine

that sounds a lot better argumentated, thank you. I also find it a good idea to make a poll about this, but I think the community needs some time to think about it, 'cause now people are blinded by the good stuff, forgetting the, well.. less good stuff I know the 256 color limit is crap for artists who wanna make something really cool, and mp3's.. well. hmm. It's really a matter of taste here anyway, so a discussion about yes or no for all these features is a waste of time.
I say everyone say waht they think, well argumentated, have a poll in a week or so, and wait for the results.
I'm curious, for one. I really am.

16bit graphics are fine, but it has some issues too, 24-bit graphics is just what I mean too, and 32-bit is for the extra alpha channel that can be needed.. Now read carefully,.. You say that 16-bit could be better?.. then fine, There can be full support with that, along with 24-bit and 32-bit graphics files, even the old 8-bit paletted files can be fully supported, Now the author can just pick what bit-rate he'd prefer.. does that sound good?

sounds great to me, but you were making it sounds like 32-bit-or-else

ok, sorry for making that impression.
Though I really want to beef up the dink engine I also want it to be backwards compatible, and still allowing midis and old graphics..

forgiven. i just hate to see such a classic thing become so "modern." you play dink and it looks as if it's set back several hundred years ago or something. the graphics, the sound, and all that good stuff. nevertheless, there are tons of things that could make it better without actually changing its classicness. 32 bit graphics and mp3 support are not included in that.

Yea, I've been taught that from a different perspective though, I really dont want to add features to modernize, I want to add features to be able to artisticly make more awesome things, to make enviroments in dink look really cool, to make the colors more living, and as for the mp3 support, its mainly just to be able to compress all sounds added , Although it can be used for music so can wavs.. so mp3's will help to cut down file size..

now, I was thinking of how true color graphics could help the filesize of a dmod,

first thing I was thinking was, most people when making new monsters just tint them witha new color, This is a bad approach and a waste of space when making new graphics..

in a 32-bit enviroment any sprite/terrain could be color-tinted either from start or in real time, meaning, any monster could have any color without having to add any new graphics files, it could also be given cool ghostlike transparency or similar without having to add new graphics..

Also, with some inbuilt 2d particle system or similar you wouldn't have to add graphic files to the dmod to make magic effects, heck, you wouldn't even have to be an artist to make cool new magical effects..

It'd all be there and easy to use, and making such things would use nearly no space at all..

this would cut down the filesize on any dmod having colored terrain, colored monster, or even new magic from nowdays to maybe half the size, I say this is a great thing for anyone on a modem..

Also, to go deeper into the mp3 support, (This will most likely be ogg instead)
well, Every sound effect could then be compressed to a tiny size, while at the same time having higher quality of the sound effects..

This could also cut down on filesize..

I know some of you are afraid of people using it for music, But thats something that can be done with wavs nowdays aswell, And that cant be helped.. midi support would still be left in ofcourse..

now as for new graphics.. I've been thinking like this: if and when higher bit graphics are supported I will work on a new set of graphics, proffesional quality aswell , containing a medium amount of fantasy enviroments.. some dungeons, some landscapes, and several sprites..

a sort of a main graphics pack, a one-time download..

just like the main graphics for dink, meaning you'd only have to download it once and everyone could use it for making new high-color dmods..

How about a wizard, or a blue star, perhaps a fairy? Something magic oriented. Or a heart as the source code in the "heart" of the game. And axe for "hacking", a hammer for building.

Hi,

The Dink Project, being hosted at SourceForge, has access to a nice tool for tracking bugs (called a "Bug Tracking System", amazingly enough). Please put your bug reports there, this will allow them to be assigned to developers and for observations to be added, which should be quite useful once we're beyond the clean-up stage.

-- Christoph

"Also, to go deeper into the mp3 support, (This will most likely be ogg instead)
well, Every sound effect could then be compressed to a tiny size, while at the same time having higher quality of the sound effects..

This could also cut down on filesize..

I know some of you are afraid of people using it for music, But thats something that can be done with wavs nowdays aswell, And that cant be helped.. midi support would still be left in ofcourse.."

The solution would be to limit the size of the files, and use ogg, not mp3, as most music files are mp3 (tell me if i'm wrong). Also, i think the DN should be very strict on this, and reject all D-Mods with longer parts of pirated music.