Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.

* Add gettext support
  - http://www.glug.org/patches/2001-07-29.gettext-support/ : a
    previous working attempt to internationalize gettext.
  - http://mail.gnu.org/archive/html/guile-user/2002-10/msg00003.html
    : an attempt to apply this patch to a more recent version of Guile
  - http://mail.gnu.org/archive/html/guile-user/2004-01/threads.html
  - http://mail.gnu.org/archive/html/guile-devel/2004-01/threads.html
  - ftp://atrey.karlin.mff.cuni.cz/pub/local/0rfelyus/guile/ : another
    gettext page from the same author

* Add Guile support

* Add Guile support for gettext, or gettext support for Guile, or both

* Check whether the dinksmallwood.ini file is still created under msw,
and whether it is possible to create such a mechanism for the GNU
system.

* Change Seth's data license so it does not mention only 'Linux'
distributions, which is nonsense, and at least include all free
operating systems, including GNU/Hurd. It would be better provide a
more free license.

* Support the true behavior of --debug. Make a better way to debug
things, above all under msw.

* Complete the HISTORY file to describe what was before the first
source release and include it in the documentation as an Appendice,
and do think about including that part as an invariant section.

* Check which palette is the default one. My experiments
(http://rpgplanet.com/dink/archives/prowler/posts/000401.html) showed
it was Tile-01.bmp's, but the source code (init_video ()) seems to
definitely use splash.bmp...

* Change burn_revision so it matches the Windows' freeware version
(DinkC get_burn())

* Any sprite object that is touched moves South-East instead of
growing larger.

* The numbers in the Experience Counter are not displayed properly;
moreover, there is errors in the loading log

* The letter in Dink's house sometimes doesn't show up

* Remake the case-insensitive code, but with a better C design

* Better error handling. SDL crash when --game is not specified is
'quite unacceptable'

* Add or make maintainers add support for .ico in SDL_image, so the
same picture can be used for the .exe icon and the windows'
title/status bar icon.

* Check with SDL staff why their .m4 is apparently opening a file for
no avail.

* Make savegames and DinkEdit's outputs portable.
  0) Check the note on savegame extendability
  1) Do not rely on 32-bit architecture. Notably, the savegames is
just a dump of a big C structure. The original dink.exe reads it up as
a new structure, and so future versions has to stay compatible with
that, even when they output savegames on 64-bits architecture, so the
savegames can be shared between players.
  2) Do not rely on Little Endian architecture such as Intel
x86. When/if Dink is ported to MacOSX, it will run on a Big Endian
architecture, so all the bytes will be swapped, and again, it has to
be able to read savegames generated by Pentiums.

* I got: warning: `newret' might be used uninitialized in this
function when converting var_equals in processes.c. I do not like that
at all. Now newret is initialized to 0, but the function has to be
checked in detail.

* Idem for dirx et diry in get_distance_and_dir (spriteinfo.c)

* Find a better fix than Livio Baldini's Soares:
	0x080656dd in init_scripts () at processes.c:5492
	5492              if (spr[rinfo[k]->sprite].active)
	(rinfo[k]->sprite == 1000 && ubound(spr[]) == 299...)

* Convert Dinkedit to C

* Interesting discussion: http://dynamic4.gamespy.com/~dink/forum.cgi?MID=24845
===========
magicman
Re: Dink can't calculate	January 4th, 17:44
This is weird. I did my routine for another variable (also global), and it worked.

Also, the script I included is called by another script in this way:

&crap = create_sprite(1,1,1,1,1);
//Yeah whatever...
sp_script(&crap, "lifhun");

The script that does this is spawned, and so survives screen
changes. I made a loop, so that with a screenchange it will execute
the create_sprite(); and the sp_script();

Now the funny thing is: After a few screenchanges, the numbers act
like they should! They display the correct value of &life, any tips on
this one?

Just say so if you get bored of my questions
 
redink1
Re: Dink can't calculate	January 4th, 17:46
Dink does have some problems with re-using variables in math
operations. I can't fathom the cause, but in most cases using a global
or initiating another local will cure it.
 
magicman
Re: Dink can't calculate	January 4th, 18:02
Ah... reminds me of something else (yes, yet ANOTHER thing). The plan
is to have two of these number-splitting scripts running at the same
time. That I did, but with the other variable it went wrong. I've put
an "a" after all the var-names and it worked! (before, these two
routines were EXACTLY the same)
 
redink1
Re: Dink can't calculate	January 4th, 18:39
Oh... that looks like another problem you're experiencing. From time
to time, it seems that two instances of the same script 'share'
variable information, which is annoying as hell.
 
magicman
Re: Dink can't calculate	January 4th, 19:19
Wow, thanks again. Ehm, quoting your last two answers:

"Dink does have some problems with re-using variables in math
operations. I can't fathom the cause, but in most cases using a global
or initiating another local will cure it."

Oh... that looks like another problem you're experiencing. From time
to time, it seems that two instances of the same script 'share'
variable information, which is annoying as hell.

Well, just look at the bold pieces. My conclusion: Very unstable
engine, hope the new one doesn't have these errors.
 
redink1
Re: Dink can't calculate	January 4th, 22:05

Uh... yeah... I would've thought any one following Dink development
for more than a month or so would see how bug-ridden the engine is
===========
=> Make sure to understand what the problems are, and check whether it
is safe to fix them.

* Test extensively the 'new' I/O code. Our savegames should be usable
by the freeware version, and vice-versa. Same for Dinkedit as soon as
this one can be used. I am not 100% sure that I respected all the
structures when converting from C++...

Update 20030512: I loaded and saved a game straight away, then
compared the differences. All the differences can be explaines: change
in frame, pframe in the header, and change in non-global &basehit (0ed
since I did not pushed the hit button), and in &result because I
changed the savegame slot. So it should be ok. The Dinkedit code still
has to be tested.

* Study how the savegame format can be extended (notably: infinite
global variables). If it can't, design a new savegame format, and make
a loading code that can check the savegame format, and still can load
the old format. Do that before working on portability issue: no need
to make a portable savegame writter if there is no need to save with
the old format anymore...

* If the user press Escape -> Quit to Windows -> Kidding!, and before
the "Close one" message appears, talk to somebody which implies
freze(1), then will the "Close one" message 'kill' the conversation?

* Use some autoconf to detect whether to use ltoa from util.c or
<stdlib>... or 'inline' all occurences.

* Add getopt from glibc so we can use getopt_long_only, and add some
autoconf to detect whether to use the system's getopt or the included
one.

* Check why some tiles are missing under MS Windows.

* Strange bug: http://dynamic4.gamespy.com/~dink/forum.cgi?MID=24886
-----
SimonK	
Re: Add Graphics to Dink.INI	January 6th, 05:45
I would recommend basing the 'number' or amount of bmps of your
graphics for specific slots on those used in the original.

By this I mean:

Dink crawling into a hole: this sequence has 18 bmps. If you replace
these bmps with ones that require more than 18 bmps some strange
things start happening. I tried this in Belgotha DMOD in which the new
main character flew into a hole, it had 19 bmps, and suddenly rocks
were turning into pillbugs when I tested the game. I removed bmp
number 19 and the rocks stayed rocks.

I'm guessing that those graphics that the original engine calls
directly by sequence slot number are used with code that expects only
a certain number of graphics (i.e. 18 for the crawl thru a hole).

Dink based graphics such as dying, blood, status bar stuff such as
numbers, health bar, magic recharge bar would all be ones to watch out
for.

Eldron is the only one I know of who has attempted total conversion
before. If you can track him down, ask him questions.

I had planned on Necromancer being a total conversion, but my dreams
are now nightmares.
-----

* Merge all Dink & Dinkedit common code - such as gather_event()

* Do some autoconf to install Dink in (http://www.pathname.com/fhs/2.2/):
/usr/games or /usr/local/games: binaries
/usr/share/games or ^^^^/share/games: base data, ie original Dink game
- if possible
/var/games: should be used to store eg. autosaves(rather in ~) & high-scores. Have
it created and trwxrwxrwx

* Rename dink.c in freedink.c and have a 'dink' symbolic link created.

* Make the window version then work outside of MSys... Gaim may be a
good example to follow

* Have saved games put in the home dir for Unix. Under MSW, usually it
is the registry, but in that case it would be tedious, notably when
you want to share a saved game with a friend. It would be better to
create a 'freedink' or so directory in the user's homedir ('My
Documents'), and have it changeable with an installer or a dedicated
program. This setting (where to put saved games) should be installable
both in a ~/freedink/freedink.conf/ini/etc, and in the
registry. System-wide settings should be also taken into
account... Check how the recent games work...

* Write free C replacements for compress and its counterpart expand.c,
for ffcreate (from WinDinkEdit) and ffextract (improve ffrextract.c to
handle - eg do not crash on - format errors. Begin with Mystery
Island's unique dir.ff. Add a 'freedink' or maybe 'dink' (or maybe
both using symlinks) prefix to all these programs.

* Apply GNITS standards to the package ;)

* Add a "Save?" prompt when DinkEdit is quitted using the window's
cross.

* Add some support for VC++, ie fix the missing config.h issue.

* Add more support for MinGW, thus for BSD along the way, I
guess. Notably headers, and include a version of getopt (see above).

* Add malloc checks (xmalloc ala Ratpoison...). Check what gnulib can
do on that point.

* http://dynamic4.gamespy.com/~dink/forum.cgi?MID=25135 : OkalyDDink's
planned features. A number of tweaking is involved, and should be
permitted in a more easier way in FreeDink

* http://dynamic4.gamespy.com/~dink/forum.cgi?MID=25033 : some of the
troubles involved in relooking Dink's UI. Same remark.
