dink-develop — The Dink Project: Development mailing list

[dink-develop] Investment in Property (Dubai, United Arab Emirates)

[Offers <ei...@bk...>]

Dear Sir / Madame
We are offering property: apartments, offices lands for construction and full buildings.
Biggest database, many offers from developers, professional consultants.
If, interesting for investment, living or set up your business in UAE.
Please, kindly contact to us:
Mobile: 00971508897750
Email: ei...@bk...
We are official real estate agency and developer.
Regards
Rustam Djanibekov
Property Consultant
 

[dink-develop] Status

[Andrew <ae...@co...>]

Windemere Project Status Report, 14 July 2004.


============
= OVERVIEW =
============

A more expansive list of things awaiting completion follows:

* Artificial Intelligence (10/18 brains are complete).
* Gamestate (Player Tracking -- This takes care of game loading and game saving).
* DinkC++ Integration (The language has been written, but the functions to call have not).
* Dink format -> Windemere format converters.



======
= AI =
======

The brains awaiting completion have not changed since the previous status release.
 
* Brain 2: The Bounce Brain
* Brain 4: The Pig Brain
* Brain 6: The Repeat Brain
* Brain 8: The Text Brain
* Brain 9: The Pill Brain
* Brain 12: The Scale Brain
* Brain 14: The Shadow Brain
* Brain 16: The People Brain



=============
= GAMESTATE =
=============

Only about half of this has been coded: the half that tracks sprites.  The part that stores information on the main player needs to be finished (gold, life, etc).



===========
= DinkC++ =
===========

Still working, but my concern is that a 1KB .c file is compiled into a 4KB .dpp file.  Any thoughts on this?


This is an example of a .c file:

	void main()
	{
		&foo = myfunc();
		print("&foo = " +&foo);
		print("myotherfunc(1337) returns " + myotherfunc(1337));
	}

	void myfunc()
	{
		return 1337;
	}

	void myotherfunc(&value)
	{
		return &value;
	}


This is the same .c file in DinkASM (.s)


		; begin function main
	main:
		; allocating variable &foo
		alc	&foo
		ror	&foo

		; calling function myfunc
		call	myfunc
		pop	&foo

		; calling function print
		pushs	"&foo = "
		pushv	&foo
		add
		call	print

		; calling function print
		pushs	"myotherfunc(1337) returns "

		; calling function myotherfunc
		pushn	1337
		call	myotherfunc
		add
		call	print

		; end function main
		return

		; begin function myfunc
	myfunc:
		pushn	1337
		return

		; end function myfunc
		return

		; begin function myotherfunc
	myotherfunc:
		; allocating variable &value
		alc	&value
		ror	&value
		pop	&value
		pushv	&value
		return
		; end function myotherfunc

		return


A part of the compiled .dpp file, though illegible, looks like this:

@...main...@.>.@b....].@.... ....?.@...@.c.@.].@....._.@.U.@.Y.@+... ...0q.@+.....w.........xY.@....._.@..........................................w.`...(X.@...@...@t..@.].@........@..@..... .@`..@.........v.@$].@.].@....E..@$].@. .@.U.@._.@(X.@p...t..@.Y.@........&foo..



I'm trying to compile DinkC++ into a library for easy integration.  That's coming along slowly...



=======
= WGP =
=======

FastFile support has been rewritten to work worth a damn, but why have a new pack format?  Two simple reasons: WGP supports filenames up to 100 characters (unlike FastFile which supported up to 12), and it is checksummed so you don't have to worry about bad FastFiles anymore (or including the FastFile in itself).  If you'd like to test the .wgp pack creator I wrote, please e-mail me.



==============
= ASSISTANCE =
==============

If you would like to lend assistance (not to mention have your name mentioned in the uber-cool credits), please contact me.  Otherwise, feel free to watch the progress slug along.



--Andrew

Re: [dink-develop] New map format

[Phoenix <ale...@br...>]

Well, this ain't a flame, it just got me thinking.. this map, in a space vs.
time comparison is very time-y, but non-space-y. Why? Well, if a user
decides to add a screen in the middle (lets say a screen that is um...
number 300 in the row, and there are a total of 700 maps - say there be 50
maps in front of map nr. 300 and 50 maps after map nr. 300. In Seth's
system, this'd be appended to the end of the file, which would cause no
speed issues. It'd be a quick thing to do. (I don't know if you're going for
an indexed map or a linear map, but to me, your idea seemed linear. Same
with adding sprites.. Seth's method would only require you to seek to a
point in the file, and then overwrite what's already there (be that a
previous sprite or just a whole bunch of 0'ed bytes...) with your method,
you actually would have to rewrite half of the file (unless you know a way
to.. um.. just shove all following data forward when adding a sprite... even
adding text at the start of the map would take quite some time... just
saying that you might want to think about speed a little too.. even the
ID3v2 tag system has padding, leaving space for additional tags/data, to
make editing/adding new tags faster.

Now, today, PCs are quick, so speed might not be that much an issue anyway..
but space is also something we have a lot of these days.. and it may be just
me, but I'd rather waste some space for a faster execution, than to wait a
lot just to have a smaller file. Compression programs will remove most of
the slack space when sending the file out on the internet anyway.

(This is meant to be constructive critisism. ;))

-Phoenix

----- Original Message ----- 
From: "Andrew" <ae...@co...>
To: "Dink Develop Mailing List" <din...@li...>
Sent: Thursday, June 03, 2004 3:06 AM
Subject: [dink-develop] New map format


> It turned out that the converter I wrote actually made Desplesda's map
> format LARGER than the original.  That's a no-no.
>
> I made a new map file format (this is probably going to turn out all
> garbled).  It replaces the old Map.dat, Dink.dat, DMOD.diz, and could
> very easily be accomodated for Hard.dat.  Someone let me know what I
missed:
>
<snip>
>
> So, that's it.  Send all flames to /dev/null.
>
> -- Andrew.
>

[dink-develop] New map format

[Andrew <ae...@co...>]

It turned out that the converter I wrote actually made Desplesda's map 
format LARGER than the original.  That's a no-no.

I made a new map file format (this is probably going to turn out all 
garbled).  It replaces the old Map.dat, Dink.dat, DMOD.diz, and could 
very easily be accomodated for Hard.dat.  Someone let me know what I missed:



The Map HEADER:

First 18 bytes (extra byte for expansion): "WindemereMap v1.0 "
    -- Used for comparison in any future map versions.

-------------- The following replaces the old DMOD.DIZ file --------------

Next 4 bytes: The size of the following map string.

Next x bytes: The name of the map.

Next 4 bytes: The size of the following author string.

Next x bytes: The name of the author.

Next 4 bytes: The size of the following string.

Next x bytes: A description of the map.

-----


Next 4 bytes: Total number of X map segments.
    -- Used to count the number of X map segments, heh.

Next 4 bytes: Total number of Y map segments.
    -- Ditto above, but for Y.




The Map DATA (For each segment):


The following repeats throughout the map file for each screen - the 
total number of which can be found
by multiplying the total number of X map segments followed by the total 
number of Y map segments (above):

First 1 byte: 0 if the screen doesn't "exist", 1 if it does.
    -- If this is 0, the entire rest of this section is skipped and the 
next tile is parsed.

Next 4 bytes: The number assigned to the audio track to play when the 
screen is entered.  This can be left 0.

Next 1 byte: Whether to loop the audio track defined in the previous 4 
bytes.
    -- Sometimes, if you stay on a screen, the audio track finishes and 
there is no audio.

Next 4 bytes: The segment offset from the defined center (X 
coordinate).    }    This is equal to "posX" and
                                                                        
                                          }    "posY" Des's old map format.
Next 4 bytes: The segment offset from the defined center (Y 
coordinate).    }

Next 4 bytes: The number of sprites on the screen.
    -- Whatever the value of this number, the indented below will be 
checked that many times.  For
       example, if this is 152, there are 152 sprites on the screen and 
the following data sizes
       will occur 152 times before the next tile.

---- BEGIN SPRITE DATA ----

    First 4 bytes of the sprite data: The X coordinate of the sprite.
    Next 4 bytes of the sprite data: The Y coordinate of the sprite.
    Next 4 bytes: The sprite's sequence.
    Next 4 bytes: The sprite's frame.
    Next 4 bytes: The size of the sprite (In percent - the size of the 
original graphic).
    Next 4 bytes: Degree of rotation - (0 to 360)
    Next 4 bytes: The size of the following string.  This is 0 if the 
sprite does not have a script
              (The following value is then skipped).
    Next x bytes: The path to the sprite's script.
    Next 4 bytes: The sequence of the walking sprite (Base walk).
    Next 4 bytes: The sequence of the idling sprite (Base idle).
    Next 4 bytes: The sequence of the attacking sprite (Base attack).
    Next 4 bytes: The sequence of the dying sprite (Base die).
    Next 4 bytes: The sequence of the touched sprite (Touch sequence).
    Next 4 bytes: The sprite's depth cue.
    Next 4 bytes: The sprite's vision (0 for all).
    Next 1 byte: Sprite Hardness - True or false.

    Next 1 byte: The possibility of the sprite to be hit - True or 
false.  If false, the next 6 values are missing.
        Next 4 bytes: The sprite's HP.
        Next 4 bytes: The sprite's defense.
        Next 4 bytes: The sprite's experience.
        Next 4 bytes: The sprite's touch damage.
        Next 4 bytes: The sprite's speed.
        Next 4 bytes: The sprite's brain.
   
    Next 1 byte: Warp - True or False.  If false, this is the end of the 
sprite data for the current iteration.
        Next 4 bytes: The screen to warp to - defined in segment offsets 
from the defined center (X coordinate).
        Next 4 bytes: The screen to warp to - defined in segment offsets 
from the defined center (Y coordinate).
        Next 4 bytes: The X coordinate to be placed on the defined screen.
        Next 4 bytes: The Y coordinate to be placed on the defined screen.

---- END SPRITE DATA ----



So, that's it.  Send all flames to /dev/null.

-- Andrew.

[dink-develop] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

Re: [dink-develop] OpenAL?!?!?!?!?

[Andrew <ae...@co...>]

Heh, there's this thing called "Linux"...


Francis Woodhouse wrote:

>Why the hell can't you just distribute the DLL with the game?
>
>- Francis
>
>----- Original Message ----- 
>From: "Andrew" <ae...@co...>
>To: <din...@li...>
>Sent: Thursday, May 13, 2004 12:50 AM
>Subject: Re: [dink-develop] OpenAL?!?!?!?!?
>
>
>  
>
>>Well, FMOD isn't exactly compatible with the GPL.  Besides that, most 
>>people don't have FMOD on their computer; and it being dynamically 
>>linked would mean the people have to go download it.  OpenAL doesn't do 
>>that.  Also, OpenAL sounds *so* much cooler than FMOD. :-D
>>
>>
>>Francis Woodhouse wrote:
>>
>>    
>>
>>>FMOD is already in place and facilitates the playing of every single 
>>>god damn thing you could possibly want! Damnit, why the hell do we now 
>>>have OpenAL in it?
>>> 
>>>- Francis
>>>      
>>>
>>
>>
>>    
>>

Re: [dink-develop] OpenAL?!?!?!?!?

[Francis W. <dea...@va...>]

And now you're back to FMOD. Jesus, Andrew, stop doing this to me. :P

- Francis

----- Original Message ----- 
From: "Andrew" <ae...@co...>
To: <din...@li...>
Sent: Thursday, May 13, 2004 12:50 AM
Subject: Re: [dink-develop] OpenAL?!?!?!?!?


> Well, FMOD isn't exactly compatible with the GPL.  Besides that, most 
> people don't have FMOD on their computer; and it being dynamically 
> linked would mean the people have to go download it.  OpenAL doesn't do 
> that.  Also, OpenAL sounds *so* much cooler than FMOD. :-D
> 
> 
> Francis Woodhouse wrote:
> 
> > FMOD is already in place and facilitates the playing of every single 
> > god damn thing you could possibly want! Damnit, why the hell do we now 
> > have OpenAL in it?
> >  
> > - Francis
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> dink-develop mailing list
> din...@li...
> https://lists.sourceforge.net/lists/listinfo/dink-develop
> 

Re: [dink-develop] OpenAL?!?!?!?!?

[Francis W. <dea...@va...>]

Why the hell can't you just distribute the DLL with the game?

- Francis

----- Original Message ----- 
From: "Andrew" <ae...@co...>
To: <din...@li...>
Sent: Thursday, May 13, 2004 12:50 AM
Subject: Re: [dink-develop] OpenAL?!?!?!?!?


> Well, FMOD isn't exactly compatible with the GPL.  Besides that, most 
> people don't have FMOD on their computer; and it being dynamically 
> linked would mean the people have to go download it.  OpenAL doesn't do 
> that.  Also, OpenAL sounds *so* much cooler than FMOD. :-D
> 
> 
> Francis Woodhouse wrote:
> 
> > FMOD is already in place and facilitates the playing of every single 
> > god damn thing you could possibly want! Damnit, why the hell do we now 
> > have OpenAL in it?
> >  
> > - Francis
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> dink-develop mailing list
> din...@li...
> https://lists.sourceforge.net/lists/listinfo/dink-develop
> 

Re: [dink-develop] OpenAL?!?!?!?!?

[Andrew <ae...@co...>]

Well, FMOD isn't exactly compatible with the GPL.  Besides that, most 
people don't have FMOD on their computer; and it being dynamically 
linked would mean the people have to go download it.  OpenAL doesn't do 
that.  Also, OpenAL sounds *so* much cooler than FMOD. :-D


Francis Woodhouse wrote:

> FMOD is already in place and facilitates the playing of every single 
> god damn thing you could possibly want! Damnit, why the hell do we now 
> have OpenAL in it?
>  
> - Francis

[dink-develop] OpenAL?!?!?!?!?

[Francis W. <dea...@va...>]

FMOD is already in place and facilitates the playing of every single god =
damn thing you could possibly want! Damnit, why the hell do we now have =
OpenAL in it?

- Francis

[dink-develop] (no subject)

[Secret J. <isd...@ho...>]

isd...@ho...

_________________________________________________________________
MSN Messenger http://www.msn.no/messenger Den korteste veien mellom deg og 
dine venner

[dink-develop] Project Status

[Andrew <ae...@co...>]

Windemere Project Status Report, 10 April 2004.

==========
= STATUS =
==========

Recently, the online Dink community (http://dinksmallwood.org) has taken 
more interest in Windemere than ever before.  I must say that before any 
questions are asked, please visit the status page (and yes it is updated).

Currently, the only things that await completion are:

* Aritficial Intelligence (10/18 brains are complete)
* Hardmaps
* Dink format -> Windemere format converters
* DinkC++(+) a.k.a Tablet.


=====
= AI =
=====

Just as a simple fact: there will most likely not be customizable 
brains, especially not in the first release.  Seth's brains are bad 
enough, but modular Seth brains...EW!  People do amazing things with the 
brains that are available, so I really don't think this is an issue.

The brains that need completing:

* Brain 2: The Bounce Brain
* Brain 4: The Pig Brain
* Brain 6: The Repeat Brain
* Brain 8: The Text Brain
* Brain 9: The Pill Brain
* Brain 12: The Scale Brain
* Brain 14: The Shadow Brain
* Brain 16: The People Brain


=======
= Tablet =
=======

Tablet may or may not make the first release, but whether or not it 
does, you can be sure it will be compatible with DinkC++ and DinkC.

So, what is Tablet?  Tablet is an interpreted, object oriented, 
embeddable, extensible version of DinkC.  There are two primitive data 
types: Number and String.  Numbers are represented in double precision 
floating point form.  Scripts are interpreted directly from their source 
and no bytecode compiliation is performed.


==============
= Graphic Formats =
==============

The format used for graphics is a Windemere Graphics Pack [WGP file].  
It is essentially a .tar.bz2 file, so no special utilities are needed to 
create these files.  No longer will FastFile graphic formats be 
available, but instead, a converter will be supplied to convert these 
formats to WGP.


=======
= Fonts =
=======

Different fonts are supported in different sizes.  Say you load:

0: Default.ttf - size 16 (This is the default font: you cannot change this)
1: Font1.ttf - size 12
2: Font1.ttf - size 16
3: Font2.ttf - size 14

You can refer to these in DinkC++ by using a command before the say 
statement.


=======
= Bugs =
=======

There currently are no bugs that we know of (the bugs listed are just 
incomplete features), but then again it's not finished.


=======
= Editor =
=======

Ah, yes, the editor.  Windemere will either 1) not make it's projected 
release date with the editor, or 2) Will not be released with the 
editor.  And what good is it using the leet advanced features of 
Windemere without an editor that supports it?  So, if you know of 
anybody that knows wxWindows (wxWidgets) or GTK, please send them hither.


=================
= Semi-Random Quote =
=================

"Here's the log output:  Wow, its craptasticirific" - DesPlesda



--Andrew

[dink-develop] Back to GPL?

[Francis W. <dea...@va...>]

I see we're back to GPL. Just one question... why? :)

- Francis

[dink-develop] DinkC++

[Andrew <ae...@co...>]

Greetings,

I have added the DinkC++ parser to the CVS Repository as a separate 
module, ``dinkcpp".  It will later be turned into a library (sorry 
Francis) and interfaced with Windemere using the UBAR -ldinkcpp.  YAY!

(Maybe I drank a bit TOO much Coke... Nah)

--Andrew

Re: [dink-develop] Sequence file format

[Francis W. <dea...@va...>]

That's rather over-complicated, isn't it? Plus, we're not actually naming
sequences, etc. - we're sticking with the number/frame referencing system,
as it's clearly the best (especially for things like idle/attack/walk
sequences). Anyway, I think the current dink.ini format is okay...

What I was talking about is where things like which frame of a sequence are
'special' and if so, 'how' special (what their number is for the 'special'
parameter for that frame).

- Francis

----- Original Message -----
From: "Andrew" <ae...@co...>
To: <din...@li...>
Sent: Tuesday, March 09, 2004 6:30 AM
Subject: Re: [dink-develop] Sequence file format


> I would assume that's what he meant.
>
> I'm going for a sorta-human-readable format:
>
> // User Definable objects
> Pack LooseFiles;
> Pack Trees /path/to/pack.wgp;
> Pack Crap /path/to/crap/pack.wgp /path/to/another/pack.wgp;
>
> LooseFiles:1:1 /path/to/graphics/file.png [parameters here];
> LooseFiles:1:2 /path/to/other/graphics/files.png [parameters here];
> ...
> (I think for the pack, you could either include a configure file for the
> first file, or define them yourself)
> [If the config file is not included.]
> Trees:1:1 [parameters];
> Trees:1:2 [parameters];
>
> [If the config file is included, you don't do anything except reference
it.]
> Trees:: ;
> ...
> Crap:1:1 [parameters];
> Crap:1:2 [parameters];
> Crap:2:1 [parameters];
>
> The format is:
> Object : Pack Definition : Number of file in pack (order of file stored
> in tar);
>
> Where pack definition is, take Pack Crap, 1 is /path/to/crap/pack.wgp
> and 2 is /path/to/another/pack.wgp.
>
> --Andrew
>
>
> Dan Walma wrote:
>
> > Uh... why not store it into your dink.ini equivalent file, or wherever
> > hard boxes are defined?
> >
> > Francis Woodhouse wrote:
> >
> >> Okay, I've been digging into all kinds of sequence-related things,
> >> having to suffer the unfortunate pain that is understanding Seth's
> >> godawful code. I was doing some attack stuff today and rememebered
> >> that (obviously) sequences need to store more info than just their
> >> frames (good example being whether a frame's 'special' is set to 1,
> >> meaning that we should smack our bitches up [attack other sprites...]
> >> when that frame is visible). So, we need a format for file's that'll
> >> describe this 'anciliary data' associated with each sequence.
> >>
> >> Any ideas for the format? Should we go for human-readable (caveat:
> >> larger file sizes) or binary-only (caveat: not human-readable,
> >> requires a program to edit in any way)?
> >>
> >> - Francis
> >
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> dink-develop mailing list
> din...@li...
> https://lists.sourceforge.net/lists/listinfo/dink-develop
>

Re: [dink-develop] Sequence file format

[Andrew <ae...@co...>]

I would assume that's what he meant.

I'm going for a sorta-human-readable format:

// User Definable objects
Pack LooseFiles;
Pack Trees /path/to/pack.wgp;
Pack Crap /path/to/crap/pack.wgp /path/to/another/pack.wgp;

LooseFiles:1:1 /path/to/graphics/file.png [parameters here];
LooseFiles:1:2 /path/to/other/graphics/files.png [parameters here];
...
(I think for the pack, you could either include a configure file for the 
first file, or define them yourself)
[If the config file is not included.]
Trees:1:1 [parameters];
Trees:1:2 [parameters];

[If the config file is included, you don't do anything except reference it.]
Trees:: ;
...
Crap:1:1 [parameters];
Crap:1:2 [parameters];
Crap:2:1 [parameters];

The format is:
Object : Pack Definition : Number of file in pack (order of file stored 
in tar);

Where pack definition is, take Pack Crap, 1 is /path/to/crap/pack.wgp 
and 2 is /path/to/another/pack.wgp.

--Andrew


Dan Walma wrote:

> Uh... why not store it into your dink.ini equivalent file, or wherever 
> hard boxes are defined?
>
> Francis Woodhouse wrote:
>
>> Okay, I've been digging into all kinds of sequence-related things, 
>> having to suffer the unfortunate pain that is understanding Seth's 
>> godawful code. I was doing some attack stuff today and rememebered 
>> that (obviously) sequences need to store more info than just their 
>> frames (good example being whether a frame's 'special' is set to 1, 
>> meaning that we should smack our bitches up [attack other sprites...] 
>> when that frame is visible). So, we need a format for file's that'll 
>> describe this 'anciliary data' associated with each sequence.
>>  
>> Any ideas for the format? Should we go for human-readable (caveat: 
>> larger file sizes) or binary-only (caveat: not human-readable, 
>> requires a program to edit in any way)?
>>  
>> - Francis
>

Re: [dink-develop] Sequence file format

[Dan W. <wa...@st...>]

Uh... why not store it into your dink.ini equivalent file, or wherever 
hard boxes are defined?

Francis Woodhouse wrote:
> Okay, I've been digging into all kinds of sequence-related things, 
> having to suffer the unfortunate pain that is understanding Seth's 
> godawful code. I was doing some attack stuff today and rememebered that 
> (obviously) sequences need to store more info than just their frames 
> (good example being whether a frame's 'special' is set to 1, meaning 
> that we should smack our bitches up [attack other sprites...] when that 
> frame is visible). So, we need a format for file's that'll describe this 
> 'anciliary data' associated with each sequence.
>  
> Any ideas for the format? Should we go for human-readable (caveat: 
> larger file sizes) or binary-only (caveat: not human-readable, requires 
> a program to edit in any way)?
>  
> - Francis

[dink-develop] Sequence file format

[Francis W. <dea...@va...>]

Okay, I've been digging into all kinds of sequence-related things, =
having to suffer the unfortunate pain that is understanding Seth's =
godawful code. I was doing some attack stuff today and rememebered that =
(obviously) sequences need to store more info than just their frames =
(good example being whether a frame's 'special' is set to 1, meaning =
that we should smack our bitches up [attack other sprites...] when that =
frame is visible). So, we need a format for file's that'll describe this =
'anciliary data' associated with each sequence.

Any ideas for the format? Should we go for human-readable (caveat: =
larger file sizes) or binary-only (caveat: not human-readable, requires =
a program to edit in any way)?

- Francis

[dink-develop] Improved Collaboration / Project Status

[Andrew <ae...@co...>]

===================
= TODO / SCHEDULE =
===================

All developers have access to this milestone-release schedule. Here it is:

Milestone VI
--------------
Date completed: 28 Feb 2004
Date projected: 29 Feb 2004

* Checkpoint I – FastFile Control. [Completed 28 Feb 2004 by Andrew]
* Checkpoint II – DinkC++ Integration. [Completed 28 Feb 2004 by Francis]

Milestone VII
---------------
Date completed:
Date projected: 14 Mar 2004

* Checkpoint I – Sprite Control. - Assigned to Francis
* Checkpoint II – Sprite Rendering. - Assigned to Francis
* Checkpoint III – Resource ID Organizer. - Assigned to whoever does it.

Milestone VIII
---------------
Date completed:
Date projected: 30 Mar 2004

* Checkpoint I – Artificial Intelligence and Brains. - Assigned to me.
* Checkpoint II – Customizable User Interface. - Assigned to me.
* Checkpoint III – Dink.ini (if it will not be integrated into the map 
file) - Assigned to whoever does it.
* Checkpoint IV – Dink Map -> Windemere Map Converter. - Assigned to Des.
* Checkpoint V – Dink Save -> Windemere Save Converter. - Assigned to Des.

Milestone IX
-----------------
Date completed:
Date projected: 14 Apr 2004

* Checkpoint I – Editor. - Assigned to me and *cough*whoever wants to 
help me with it*cough*.

Milestone X
---------------
Date completed:
Date projected: 25 Apr 2004

* Checkpoint I – Code Improvement and Profiling. - Assigned to me.
* Checkpoint II – Bug Fixing. - Assigned to everybody.
* Checkpoint III – Beta Testing. - Assigned to everybody.
* Checkpoint IV – Packaging. - Assigned to me.

Windemere Estimated Release
------------------------------------
Friday, 30 April 2004. - Yay.


=================
= COLLABORATION =
=================

Developers or anyone subscribed to the dink-cvs mailing list may notice 
I have starting using doxygen to document the code. This allows us to 
document what the code does as we go along, and the best part is I won't 
have to ask anybody what the hell a piece of code does :). If you need 
help over what the various documenting commands do, contact me.

The configuration file can be found in the contrib/ directory, called 
"windemere.dxy". To compile the documentation, type ``doxygen 
windemere.dxy".


=============
= DESPLESDA =
=============

Dude, where are you?


===================
= DESIGN DOCUMENT =
===================

I have been writing a design document to guide the further development 
of Windemere. It is available only on Developer's CVS (It should not be 
present on Anonymous CVS) and in PDF format to prevent DesPlesda from 
editing it. Get to work!


===========
= MEMBERS =
===========

I am pleased to announce a new member on the team, Ric Halliwell. He is 
known as "Ric" on the Dink Network at http://www.dinksmallwood.org, and 
has already designed several new graphics to compliment the new engine.


========
= TODO =
========

BUGS:
------
UNIX Directory Controls - DesPlesda. (Hey, you asked for it).
Cross-Platform itoa() - DesPlesda. (You sort of asked for this too).

FEATURES:
---------
Independent Dink Speed - Francis.
UNIX Build System - DesPlesda (Finish it).
DinkC++ Booleans - DesPlesda (Work builds up if you don't do any of it).
Text Size and Multi-Colored Text - Francis, will you take a look at the 
font resource server? It only serves the most recent request.


=====================
= SEMI-RANDOM QUOTE =
=====================

"I crushed my coke can and noticed Microsoft's stock suddenly dropped 2 
points." -- Andrew


--Andrew

[dink-develop] Dink-Develop Package

[Andrew <ae...@co...>]

To All Developers:

A new develop package has been released containing two new library 
versions, SDL 1.2.7.0 and Freetype 2.1.7.1505.  You may find the updated 
package, Develop-0.5.2, here:   
http://sourceforge.net/project/showfiles.php?group_id=85863&package_id=89484&release_id=220050

Good Luck with Development,
Andrew

Re: Re: [dink-develop] Windemere License v. 1.0

[<ae...@co...>]

Oh, my bad.

> I'm not really concerned with the license that we use, but can I just mention 
> that my name's Jonathon, not Jonathan? Jon's even better :)
> 
> Des

Re: [dink-develop] Windemere License v. 1.0

[Francis W. <dea...@va...>]

My goodness, you're a genius. You really should be a lawyer.

Could you give us a 'gisted overview' of the Windemere license? I can't read
legalese :)

Francis

----- Original Message -----
From: "Andrew" <ae...@co...>
To: "Dink Develop Mailing List" <din...@li...>
Sent: Thursday, February 19, 2004 5:38 AM
Subject: [dink-develop] Windemere License v. 1.0


> Hi all.
>
> If you look at the CVS logs you may notice I updated every single file
> with the BSD license.  That was a mistake as I later discovered SDL had
> the LGPL for a license rather than the GPL.  So, that means, here's what
> we need to do to be able to have our own license:
>
> SDL:
> * Allow the license to provide modification of a work as well as reverse
> engineering for "debugging purposes" as specified in section 6,
> paragraph 1 of the LGPL version 2.1.
> * Supply a copy of the LGPL along with the program.
> * Include the copyright notice for the library on a copyright display
> screen.
>
> FT:
> * Include the FreeType Public License in a file named "FPL.TXT".
> * Include the copyright notice for the library on a copyright display
> screen.
>
> That's it!  That's what the 8 pages of LGPL and 2 pages of FTL said.
>
> Now, I got so tired of looking for a suitable license that I just wrote
> one.  Here it is:
>
>
> Windemere License v. 1.0
> ------------------------
>
> 1. Definitions
>
> "License" - This Windemere License version 1.0.
> "Original Work" - The original work of authorship.
> "Licensor" - The Windemere Team.
> "Licensee" - You, the end-user.
> "Windemere" - The Original Work originally distributed by Andrew
> Reading, Francis Woodhouse,
> and Jonathan Manning.
>
>
> 2. Applications
>
> This License covers the Original Work created by Licensor, copyright (c)
> 2003, 2004 by
> Andrew Reading, Francis Woodhouse, and Jonathan Manning.  All rights
> reserved except as
> specified below.
>
>
> 3. No Warranty
>
> WINDEMERE IS PROVIDED ON AN "AS IS" BASIS WITHOUT WARRANTY OF ANY KIND,
> EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES
> OF MERCHANTABILITY, ASSURANCE THAT THE ORIGINAL WORK IS FREE OF DEFECTS,
> FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING.  BY ACCEPTING THIS
> LICENSE, YOU, THE END-USER, AGREE THE ENTIRE RISK AS TO THE QUALITY AND
> PERFORMANCE OF THE ORIGINAL WORK IS YOURS.
>
> 4. Limitation of Liability
>
> UNDER NO CIRCUMSTANCES NOR LEGAL THEORY, WHETHER TORT (INCLUDING
> NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL LICENSOR BE LIABLE TO ANY
> PERSON FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
> OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF
> GOODWILL, WORK STOPPAGE, AND COMPUTER FAILURE OR MALFUNCTION.
>
>
> 5. The Licensor Grant
>
>   5.1.  The license.
>
>   Licensor hereby grants Licensee a world-wide, non-exclusive,
> royalty-free, perpetual
> license to do the following:
>
>     a) to reproduce, modify, debug, and disassemble or otherwise
> reverse-engineer the Original Work in copies;
>     b) to prepare derivative works (hereafter referred to as "Derivative
> Works") based upon the Original Work;
>     c) to distribute copies of the Original Work and Derivative Works to
> the public, with the proviso that the distributions of the Original Work
> and Derivatave Works that Licensee distributes be licensed under this
> License; and
>     d) to perform and display the Original Work publicly.
>
>   5.2. Termination
>
>   Rights of Licensee as described under 5.1a, 5.1b, 5.1c, and 5.1d above
> are subject to
> termination if the following conditions are not met:
>
>     5.2.1. Attribution
>
>       a) Redistributions of source code must retain the above copyright
> notice, this list of  conditions, this license (in an easily-accessible
> location), and the disclaimers found under sections 3 and 4;
>       b) Redistributions in binary form must reproduce the above
> copyright notice, this list of conditions, and the disclaimers found in
> sections 3 and 4 in the documentation and/or other materials provided
> with the distribution.
>
>     5.2.2. Derivatives
>
>       c) Altered source or binary versions, whether derived directly or
> indirectly, must be plainly marked as such with a prominent statement
> stating the Derivatave Works are based, either in part or in full, of
> the work of the Windemere Team.  Names of "Windemere Engine" and
> "Windemere Project" are recommended, but not required;
>       d) Licensee shall also include a detailed file, to either source
> or binary versions, documenting any and all changes made to the modified
> version along with the date of such change.
>
>     5.2.3. Endorsement
>
>       e) Neither the name of the Windemere Team nor the names of its
> contributors may be used to endorse or promote products derived from
> this software without specific prior written permission.
>
>
> 6. Acceptance
>
> Licensee is not required to accept the terms of this license as he or
> she has not signed it, however any rights granted by this license will
> be forfeited by law.  Licensee agrees to accept these terms
> automatically upon the execution or compilation of the Original Work.
>
>
> 7. U.S. Government End Users
>
> The Covered Code is a "commercial item," as that term is defined in 48
> C.F.R. 2.101 (Oct. 1995), consisting of "commercial computer software"
> and "commercial computer software documentation," as such terms are used
> in 48 C.F.R. 12.212 (Sept. 1995). Consistent with 48 C.F.R. 12.212 and
> 48 C.F.R. 227.7202-1 through 227.7202-4 (June 1995), all U.S. Government
> End Users acquire Covered Code with only those rights set forth herein.
>
>
> 8. License Application
>
> The contents of this file are subject to the Windemere License Version
> 1.0 (the "License"); you may not use this file except in compliance with
> the License. You may obtain a copy of the License in the "LICENSE" file.
>
> Copyright (c) 2003-2004 Andrew Reading
> Copyright (c) 2003-2004 Francis Woodhouse
> Copyright (c) 2003-2004 Jonathan Manning
>
> WINDEMERE IS PROVIDED ON AN "AS IS" BASIS WITHOUT WARRANTY OF ANY KIND,
> EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES
> OF MERCHANTABILITY, ASSURANCE THAT THE ORIGINAL WORK IS FREE OF DEFECTS,
> FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING.  BY ACCEPTING THIS
> LICENSE, YOU, THE END-USER, AGREE THE ENTIRE RISK AS TO THE QUALITY AND
> PERFORMANCE OF THE ORIGINAL WORK IS YOURS.
>
> UNDER NO CIRCUMSTANCES NOR LEGAL THEORY, WHETHER TORT (INCLUDING
> NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL LICENSOR BE LIABLE TO ANY
> PERSON FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
> OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF
> GOODWILL, WORK STOPPAGE, AND COMPUTER FAILURE OR MALFUNCTION.
>
> [END OF LICENSE]
>
>
> What do you think?
>
> --Andrew
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> dink-develop mailing list
> din...@li...
> https://lists.sourceforge.net/lists/listinfo/dink-develop
>

Re: [dink-develop] Windemere License v. 1.0

[Jon M. <des...@de...>]

I'm not really concerned with the license that we use, but can I just mention 
that my name's Jonathon, not Jonathan? Jon's even better :)

Des

[dink-develop] Windemere License v. 1.0

[Andrew <ae...@co...>]

Hi all.

If you look at the CVS logs you may notice I updated every single file 
with the BSD license.  That was a mistake as I later discovered SDL had 
the LGPL for a license rather than the GPL.  So, that means, here's what 
we need to do to be able to have our own license:

SDL:
* Allow the license to provide modification of a work as well as reverse 
engineering for "debugging purposes" as specified in section 6, 
paragraph 1 of the LGPL version 2.1.
* Supply a copy of the LGPL along with the program.
* Include the copyright notice for the library on a copyright display 
screen.

FT:
* Include the FreeType Public License in a file named "FPL.TXT".
* Include the copyright notice for the library on a copyright display 
screen.

That's it!  That's what the 8 pages of LGPL and 2 pages of FTL said.

Now, I got so tired of looking for a suitable license that I just wrote 
one.  Here it is:


Windemere License v. 1.0
------------------------

1. Definitions

"License" - This Windemere License version 1.0.
"Original Work" - The original work of authorship.
"Licensor" - The Windemere Team.
"Licensee" - You, the end-user.
"Windemere" - The Original Work originally distributed by Andrew 
Reading, Francis Woodhouse,
and Jonathan Manning.


2. Applications

This License covers the Original Work created by Licensor, copyright (c) 
2003, 2004 by
Andrew Reading, Francis Woodhouse, and Jonathan Manning.  All rights 
reserved except as
specified below.


3. No Warranty

WINDEMERE IS PROVIDED ON AN "AS IS" BASIS WITHOUT WARRANTY OF ANY KIND, 
EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES 
OF MERCHANTABILITY, ASSURANCE THAT THE ORIGINAL WORK IS FREE OF DEFECTS, 
FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING.  BY ACCEPTING THIS 
LICENSE, YOU, THE END-USER, AGREE THE ENTIRE RISK AS TO THE QUALITY AND 
PERFORMANCE OF THE ORIGINAL WORK IS YOURS.

4. Limitation of Liability

UNDER NO CIRCUMSTANCES NOR LEGAL THEORY, WHETHER TORT (INCLUDING 
NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL LICENSOR BE LIABLE TO ANY 
PERSON FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES 
OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF 
GOODWILL, WORK STOPPAGE, AND COMPUTER FAILURE OR MALFUNCTION.


5. The Licensor Grant

  5.1.  The license.
        
  Licensor hereby grants Licensee a world-wide, non-exclusive, 
royalty-free, perpetual
license to do the following:

    a) to reproduce, modify, debug, and disassemble or otherwise 
reverse-engineer the Original Work in copies;
    b) to prepare derivative works (hereafter referred to as "Derivative 
Works") based upon the Original Work;
    c) to distribute copies of the Original Work and Derivative Works to 
the public, with the proviso that the distributions of the Original Work 
and Derivatave Works that Licensee distributes be licensed under this 
License; and
    d) to perform and display the Original Work publicly.

  5.2. Termination
 
  Rights of Licensee as described under 5.1a, 5.1b, 5.1c, and 5.1d above 
are subject to
termination if the following conditions are not met:
 
    5.2.1. Attribution

      a) Redistributions of source code must retain the above copyright 
notice, this list of  conditions, this license (in an easily-accessible 
location), and the disclaimers found under sections 3 and 4;
      b) Redistributions in binary form must reproduce the above 
copyright notice, this list of conditions, and the disclaimers found in 
sections 3 and 4 in the documentation and/or other materials provided 
with the distribution.

    5.2.2. Derivatives

      c) Altered source or binary versions, whether derived directly or 
indirectly, must be plainly marked as such with a prominent statement 
stating the Derivatave Works are based, either in part or in full, of 
the work of the Windemere Team.  Names of "Windemere Engine" and 
"Windemere Project" are recommended, but not required;
      d) Licensee shall also include a detailed file, to either source 
or binary versions, documenting any and all changes made to the modified 
version along with the date of such change.

    5.2.3. Endorsement

      e) Neither the name of the Windemere Team nor the names of its 
contributors may be used to endorse or promote products derived from 
this software without specific prior written permission.


6. Acceptance

Licensee is not required to accept the terms of this license as he or 
she has not signed it, however any rights granted by this license will 
be forfeited by law.  Licensee agrees to accept these terms 
automatically upon the execution or compilation of the Original Work.


7. U.S. Government End Users

The Covered Code is a "commercial item," as that term is defined in 48 
C.F.R. 2.101 (Oct. 1995), consisting of "commercial computer software" 
and "commercial computer software documentation," as such terms are used 
in 48 C.F.R. 12.212 (Sept. 1995). Consistent with 48 C.F.R. 12.212 and 
48 C.F.R. 227.7202-1 through 227.7202-4 (June 1995), all U.S. Government 
End Users acquire Covered Code with only those rights set forth herein.


8. License Application

The contents of this file are subject to the Windemere License Version 
1.0 (the "License"); you may not use this file except in compliance with 
the License. You may obtain a copy of the License in the "LICENSE" file.

Copyright (c) 2003-2004 Andrew Reading
Copyright (c) 2003-2004 Francis Woodhouse
Copyright (c) 2003-2004 Jonathan Manning

WINDEMERE IS PROVIDED ON AN "AS IS" BASIS WITHOUT WARRANTY OF ANY KIND, 
EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES 
OF MERCHANTABILITY, ASSURANCE THAT THE ORIGINAL WORK IS FREE OF DEFECTS, 
FIT FOR A PARTICULAR PURPOSE OR NON-INFRINGING.  BY ACCEPTING THIS 
LICENSE, YOU, THE END-USER, AGREE THE ENTIRE RISK AS TO THE QUALITY AND 
PERFORMANCE OF THE ORIGINAL WORK IS YOURS.

UNDER NO CIRCUMSTANCES NOR LEGAL THEORY, WHETHER TORT (INCLUDING 
NEGLIGENCE), CONTRACT, OR OTHERWISE, SHALL LICENSOR BE LIABLE TO ANY 
PERSON FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES 
OF ANY CHARACTER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF 
GOODWILL, WORK STOPPAGE, AND COMPUTER FAILURE OR MALFUNCTION.

[END OF LICENSE]


What do you think?

--Andrew

Re: [dink-develop] Project Status Report

[Dan W. <wa...@st...>]

Hiya folks...

>>Merlin
>>#define Tree TreeGraphics.dgp
>>    Tree.16 // References the 16th file in TreeGraphics.dgp.  Perhaps a
>>colon could be used?

> Deathwish
> Okay, I've discussed this with Des before, and we think it's a good thing,
> too. However, being the speed monkey that I am, I'm concerned about how slow
> it would become if we were referencing things by names as opposed to sprite
> indices. An index into an array just needs one addition and you're at the
> memory, but something referenced by a name requires a search through the
> array until the element is found - much slower.
> 
> Idea: Perhaps have the core engine just use frame/seq indices, but DinkC++
> scripts can reference them by names. The names would be defined in the
> dink.ini, and at either compile time or load time these names in the scripts
> can be 'resolved' by the engine into their IDs by referencing the dink.ini.
> Thoughts?

> Desplesda
> A better (or at least simpler) system for accessing sprites is desperately 
> needed, I agree with you there. Your system is workable, but we need to get a 
> system that also is compatible (or at least, can coexist) with the seq/frame 
> system of Dink.

Erm... I think you're trying to create a solution for a problem that 
doesn't exist, and in turn create wholy new problems that would end up 
breaking nearly everything.  heh.

By eliminating sequence numbers, you break:

1) The ability to manipulate sequences numerically.  While not in great 
use, its used in a few instances in the original game (i.e. adding 100 
to Dink's direction to determine the attack sequence).  To try to do it 
another way (if (sp_dir(1,-1) == 2) sp_seq(1,"DINKATTACKUP"); etc) would 
just bring unneeded clutter into things.

2) Base walks/attacks/deaths.  Unless you can think of a simpler way. 
Right now you just do something like sp_base_walk(1,10); and the game 
knows that sequence 11 is lower-left, sequence 12 is down, etc.  And if 
a sequence doesn't exist (such as with a pillbug, which only has two 
sequences) the game copes by choosing one that is 'close' to it.

3) Breaking every D-Mod ever made.  Seriously, unless my mind is 
seriously being bombed with poisons of stupor, trying to automatically 
convert all sequences and frames from D-Mods that heavily rely on new 
graphics (i.e. Pilgrim's Quest, Stone of Balance) and the previous 
seq/frame numbers.

4) All graphics ever used will be loaded into memory, as it doesn't seem 
possible to load sequences over other sequences (freeing the previous 
memory), if you're doing it the way it seems to me.

5) Probably some other things my just-awoke mind cannot think of.

I think the best solution would be to either have some sort of meta 
layer on top of the dink.ini allowing you to organize the graphics in 
any matter you see fit in any categories or groups the author decides, 
on a frame-by-frame basis or a seq-by-seq depending on which sequence it 
is, while still having the sequence and frame numbers in plain view and 
completely ignoring the meta layer when the engine is running.

Note: I have no idea what 'meta' means, but the word seemed to work in 
the above paragraph.  If it doesn't, my apologies, feel free to replace 
it with a friendlier word.

Oh you could just leave it alone.  Plenty of D-Mods have been made under 
the current conditions, I can recall no complaints except those who 
expect someone to make their D-Mods for them, and making it 'simpler' 
could, in fact, be worse.  Only completely change something because of 
what is necessary, not because it sounds good.

Haven't really read into the rest of the update too much, but this just 
stuck out.

Thanks,

Dan Walma
The Dink Network
http://rpgplanet.com