The Mana World - User contributions [en]

User:Doener

2008-03-19T21:45:46Z

Doener: Update my jid

== About ==
Uhm, where to start? Well, my real name is BjÃ¶rn Steinbrink, I'm from Germany and born in 1982 (well, I could just say I'm 23 years old, but that would be outdated so soon ;) ). I got to know about The Mana World in May 2005, when I've been (once again) searching for a nice SNES-style RPG that runs on Linux. I wasn't that much impressed by the game itself, but kept a bookmark as it was the most promising i had seen. Time passed by and I stumbled over a new tmw release, tried it, hit a well known bug and asked on irc about it (just to find the solution in the forums before anyone could answer ;) ). And you know how irc works, right? You start talking to folks who got ideas or find bugs and all of a sudden you find yourself submitting patches... Well, that's how i got into working on tmw...

== Contact ==
Mail: B.Steinbrink@gmx.de<br />
Jabber: B.Steinbrink@gmx.de

== Questions ==
Well, nobody asked any questions, yet. Feel free to do add some, maybe I'll feel free to ignore them, maybe not... ;)

Development:Animations

2006-03-18T16:52:27Z

Doener: /* Implementation proposal by Doener */

{{Status_red}}
After a mini-meeting between me and Doener we refined the model.
Each animation will be defined by an xml document, here follows an example:

<pre>
<?xml version="1.0"?>
<animation name="player">
<spritemap name="misc" src="player-male-misc.png" width="64" height="64" />
<spritemap name="stab" src="player-male-stab.png" width="64" height="64" />
<spritemap name="bow" src="player-male-bow.png" width="64" height="64" />

<action name="stand">
<frame spritemap="misc" index="0" delay="0" />
</action>

<action name="walk">
<frame spritemap="misc" index="0" delay="20" />
<frame spritemap="misc" index="1" delay="20" />
</action>

<action name="bow-attack">
<sequence spritemap="bow" start="0" end="5" delay="20" />
</action>
</animation>
</pre>

So if you want to load the playerset you just load player.xml and it takes care of loading all related images. Of course delays are defined in milliseconds.

== Some attempt by BjÃ¸rn ==

A sprite is an object which can carry several animations, hence I call the root element the <code>sprite</code>. Also, I think we should seperately define animations in several directions. For now this example is based on the current playerset image, but by using multiple imagesets this could of course be split up.

Each <code>frame</code> and <code>frames</code> element can optionally have attributes <code>x</code> and <code>y</code> to specify an offset from the default drawing position for that frame. This will allow the animation of for example the hairset (or any equipment) to reuse the same frames with different offsets, and be defined exactly like below.

In the bow animation I've chosen a shortcut to specify different delays for different frames. I am undecided yet whether this is a nice feature or whether it'll be better to require multiple <code>frame</code> elements in such cases.

For the dead frame I have specified no direction attribute, which makes this animation independent of direction. Also, it includes an experimental suggestion on specifying that a random frame should be chosen.

<pre>
<sprite name="player">
<imageset name="base" src="player-male-base.png" width="64" height="64" />

<animation name="stand" direction="down">
<frame imageset="base" index="0" />
</animation>
<animation name="stand" direction="left">
<frame imageset="base" index="18" />
</animation>
<animation name="stand" direction="up">
<frame imageset="base" index="36" />
</animation>
<animation name="stand" direction="right">
<frame imageset="base" index="54" />
</animation>

<animation name="walk" direction="down">
<frames imageset="base" start="1" end="6" delay="10" />
</animation>
...

<animation name="sit" direction="down">
<frame imageset="base" index="7" />
</animation>
...

<animation name="bow-attack" direction="down">
<frames imageset="base" start="13" end="17" delays="5,5,5,10,50" />
</animation>
...

<animation name="dead">
<random>
<frame imageset="base" index="8" />
<frame imageset="base" index="26" />
<frame imageset="base" index="44" />
<frame imageset="base" index="62" />
</random>
</animation>
</sprite>
</pre>

After reflecting on this idea (and the above suggestion) I think a first issue to solve is to reduce the amount of duplicated definitions. For example, at the moment every monster uses the exact same frame size and animation frames. Hence, it would be interesting if the defined sprite could take the actual imageset it uses as a parameter instead of specifying this on its own. This way we can define a monster like:

<pre>
<sprite name="monster-walking-default">
<imageset name="base" />
...
</sprite>

<being name="Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-base.png" width="60" height="60" />
</sprite>
</being>

<being name="Red Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-red-base.png" width="60" height="60" />
</sprite>
</being>
</pre>

Defining an empty imageset (without <code>src</code> attribute) will make the engine require this imageset to be passed as a parameter whenever the spriteset is referenced.

I'm not convinced yet that the <code>name</code> attribute of the <code>sprite</code> element is really necessary. I think I would prefer each sprite to be defined in its own file. However it could be attractive to define multiple things in the same file, but in that case I think we will have to read everything when the client is launched, and only graphics and imagesets can be created lazily (only when necessary). Because the other data consists of just numbers and strings, this should not be really a problem.

== An implementation idea by Peoro ==

An idea to manage the animations should be a class based on a timer which choose automatically the current frame.
Who needs animations (players, monsters and npcs) has only to start the animanion and to request the frame to draw it.
Each instance of Animation class keep its own start-time (or a personal timer), its total time, number of frames, and the time of every frame.
The Animation class has to provide at least a function to start the animation and another one to get the current frame; other usefull functions should pause and restart the animation and allow to jump to a random frame.

Here a simple example of a prototype of an Animation class:
(I mutilated my original Animation class to simplify and summarize it cutting a lot of other functions and vars and using the most possible of standard items)

<pre>
class Animation
{
int nframes;
Img **frames;
int *times;
int totalTime;
int startTime;

public:
Animation ( int n, Img **i, int *t )
{
int c;

nframes = n;
frames = new Img* [n];
times = new int [n];
totalTime = 0;

for ( c = 0; c < n; c ++ ) {
frames[c] = i[c];
times[c] = t[c];
totalTime += t[c];
}
}

inline void start ( int t = clock() )
{
startTime = t;
}

Img *getFrame ( int t = clock() )
{
int i;
int it

if ( ! totalTime ) {
t = 0;
} else {
t = (t-startTime) % totalTime;
}

// searches the current frame
for ( i = 0, it = 0; (it + times[i]) < t; i ++, it += times[i] );

return frames[i];
}

};
</pre>

And here how to use this class:

<pre>
Img * imgs [] = { img1, img2, img3 };
int times [] = { 20, 20, 30 };

Animation a ( 3, imgs, times );

a.start ( );

while ( 1 ) {
draw ( a.getFrame() );
}
</pre>

An advantage of this class is that the animation speed is indipendent to FPS and it's very easy to use.

This is a simple way to manage a lot of animations for who needs more than one:

<pre>
class AnimationsList
{
// ltstr is only a const char* comparison function
map<const char*, Animation*, ltstr> animations;
int startTime; // now Animation::startTime is no more usefull
Animation *currentAnimation;

public:
AnimationsList ( ) : currentAnimation(0) { }

inline void addAnimation ( const char *n, Animation *a )
{
animations[n] = a;
}

int setAnimation ( const char *n, int t = clock() )
{
map<const char*, Animation*, ltstr>::iterator ai;
Animation *a;

ai = animations.find ( n );

if ( ai == animations.end() ) {
// error... animation not found
return 0;
}
a = ai->second;

if ( currentAnimation != a ) {
a->start ( );
currentAnimation = a;
startTime = t;
}

return 1;
}

Img * getFrame ( )
{
if ( currentAnimation ) {
return currentAnimation->getFrame ( );
}
return 0;
}
};
</pre>

Using a multimap instead the map it's possible to keep more than an animation bind to the same string. This would be a good way to make AnimationsList choose a random animation.

And here how to use AnimationsList class:

<pre>
AnimationsList al;

al.addAnimation ( "walking" "south", anim1 );
al.addAnimation ( "walking" "north", anim2 );
al.addAnimation ( "anim3", anim3 );

al.setAnimation ( "walking" "south" );

while ( 1 ) {
draw ( al.getFrame() );
}
</pre>

I hope not to had make a mistake writing... Anyway these are only theorical bases.

== Implementation proposal by Doener ==

This proposal is incomplete regarding how new sequences are added to the
Animation (which is not the right name for this type of class *g*)... Anyway,
you should get the idea...
The Frame class encapsulates images and are used to create a single linked list that
creates an animation. The idea behind the linked list is that you can easily create loops,
by having the last element of the animation pointing to the first one. Also, you can easily
prepend a "starting animation" before the loop, like in an animation of a running player.
He starts out with one animation and then loops the real running... The Animation class is
responsible for mapping animation names to their starting frame and for disposing the encapsulating
Frame objects, thus a std::map and a std::list is used to keep track of those objects.
The next frame is simply calculated from the time that has passed since the last run of the
logic method. The case that a whole animation loop can be skipped is not taken into consideration,
because a) we cannot do this with frames linked together arbitrarily and b) animations will probably
take around 100ms or longer, ie. we'd have less than 10fps for that case to happen and then
there's nothing left to gain by that simple optimization anymore anyway ;)

For the linked list features, of course the xml format needs to be adjusted to support that.

<pre>
/*
* Frame class, stored information about frames in an animation
*/
struct Frame
{
Image *mImg; // Image for this frame
int mDelay; // Time in ms for how long this frame is shown
Frame *mNext; // Next frame in sequence
};

class Animation
{
public:
Animation():mCurrentFrame(0);
~Animation();

void setSequence(const std::string &);

void logic(int timePassed);

Image* getCurrentImage()
{ return mCurrentFrame ? mCurrentFrame->mImg : 0; }

private:
Frame *mCurrentFrame;
typedef std::map<std::string,Frame*> FrameMap;
typedef FrameMap::iterator FrameMapIterator;
FrameMap mStartFrames;
std::list<Frame*> mFrames;
int mRemain;
}

Animation::~Animation()
{
for_each(mFrames.begin(), mFrames.end(), make_dtor(mFrames));
}

void Animation::setSequence(const std::string &name)
{
FrameMapIterator i = mStartFrames.find(name);
mCurrentFrame = (i == mStartFrames.end()) ? 0 : i->second;
mRemain = 0;
}

void Animation::logic(int timePassed)
{
mRemain += timePassed;
while (mRemain >= mCurrentFrame->mDelay) {
mRemain -= mCurrentFrame->mDelay;
mCurrentFrame = mCurrentFrame->mNext;
}
};
</pre>

Development:Animations

2006-03-18T16:50:53Z

Doener: Added implementation proposal

{{Status_red}}
After a mini-meeting between me and Doener we refined the model.
Each animation will be defined by an xml document, here follows an example:

<pre>
<?xml version="1.0"?>
<animation name="player">
<spritemap name="misc" src="player-male-misc.png" width="64" height="64" />
<spritemap name="stab" src="player-male-stab.png" width="64" height="64" />
<spritemap name="bow" src="player-male-bow.png" width="64" height="64" />

<action name="stand">
<frame spritemap="misc" index="0" delay="0" />
</action>

<action name="walk">
<frame spritemap="misc" index="0" delay="20" />
<frame spritemap="misc" index="1" delay="20" />
</action>

<action name="bow-attack">
<sequence spritemap="bow" start="0" end="5" delay="20" />
</action>
</animation>
</pre>

So if you want to load the playerset you just load player.xml and it takes care of loading all related images. Of course delays are defined in milliseconds.

== Some attempt by BjÃ¸rn ==

A sprite is an object which can carry several animations, hence I call the root element the <code>sprite</code>. Also, I think we should seperately define animations in several directions. For now this example is based on the current playerset image, but by using multiple imagesets this could of course be split up.

Each <code>frame</code> and <code>frames</code> element can optionally have attributes <code>x</code> and <code>y</code> to specify an offset from the default drawing position for that frame. This will allow the animation of for example the hairset (or any equipment) to reuse the same frames with different offsets, and be defined exactly like below.

In the bow animation I've chosen a shortcut to specify different delays for different frames. I am undecided yet whether this is a nice feature or whether it'll be better to require multiple <code>frame</code> elements in such cases.

For the dead frame I have specified no direction attribute, which makes this animation independent of direction. Also, it includes an experimental suggestion on specifying that a random frame should be chosen.

<pre>
<sprite name="player">
<imageset name="base" src="player-male-base.png" width="64" height="64" />

<animation name="stand" direction="down">
<frame imageset="base" index="0" />
</animation>
<animation name="stand" direction="left">
<frame imageset="base" index="18" />
</animation>
<animation name="stand" direction="up">
<frame imageset="base" index="36" />
</animation>
<animation name="stand" direction="right">
<frame imageset="base" index="54" />
</animation>

<animation name="walk" direction="down">
<frames imageset="base" start="1" end="6" delay="10" />
</animation>
...

<animation name="sit" direction="down">
<frame imageset="base" index="7" />
</animation>
...

<animation name="bow-attack" direction="down">
<frames imageset="base" start="13" end="17" delays="5,5,5,10,50" />
</animation>
...

<animation name="dead">
<random>
<frame imageset="base" index="8" />
<frame imageset="base" index="26" />
<frame imageset="base" index="44" />
<frame imageset="base" index="62" />
</random>
</animation>
</sprite>
</pre>

After reflecting on this idea (and the above suggestion) I think a first issue to solve is to reduce the amount of duplicated definitions. For example, at the moment every monster uses the exact same frame size and animation frames. Hence, it would be interesting if the defined sprite could take the actual imageset it uses as a parameter instead of specifying this on its own. This way we can define a monster like:

<pre>
<sprite name="monster-walking-default">
<imageset name="base" />
...
</sprite>

<being name="Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-base.png" width="60" height="60" />
</sprite>
</being>

<being name="Red Scorpion">
<sprite ref="monster-walking-default">
<with-imageset name="base" src="scorpion-red-base.png" width="60" height="60" />
</sprite>
</being>
</pre>

Defining an empty imageset (without <code>src</code> attribute) will make the engine require this imageset to be passed as a parameter whenever the spriteset is referenced.

I'm not convinced yet that the <code>name</code> attribute of the <code>sprite</code> element is really necessary. I think I would prefer each sprite to be defined in its own file. However it could be attractive to define multiple things in the same file, but in that case I think we will have to read everything when the client is launched, and only graphics and imagesets can be created lazily (only when necessary). Because the other data consists of just numbers and strings, this should not be really a problem.

== An implementation idea by Peoro ==

An idea to manage the animations should be a class based on a timer which choose automatically the current frame.
Who needs animations (players, monsters and npcs) has only to start the animanion and to request the frame to draw it.
Each instance of Animation class keep its own start-time (or a personal timer), its total time, number of frames, and the time of every frame.
The Animation class has to provide at least a function to start the animation and another one to get the current frame; other usefull functions should pause and restart the animation and allow to jump to a random frame.

Here a simple example of a prototype of an Animation class:
(I mutilated my original Animation class to simplify and summarize it cutting a lot of other functions and vars and using the most possible of standard items)

<pre>
class Animation
{
int nframes;
Img **frames;
int *times;
int totalTime;
int startTime;

public:
Animation ( int n, Img **i, int *t )
{
int c;

nframes = n;
frames = new Img* [n];
times = new int [n];
totalTime = 0;

for ( c = 0; c < n; c ++ ) {
frames[c] = i[c];
times[c] = t[c];
totalTime += t[c];
}
}

inline void start ( int t = clock() )
{
startTime = t;
}

Img *getFrame ( int t = clock() )
{
int i;
int it

if ( ! totalTime ) {
t = 0;
} else {
t = (t-startTime) % totalTime;
}

// searches the current frame
for ( i = 0, it = 0; (it + times[i]) < t; i ++, it += times[i] );

return frames[i];
}

};
</pre>

And here how to use this class:

<pre>
Img * imgs [] = { img1, img2, img3 };
int times [] = { 20, 20, 30 };

Animation a ( 3, imgs, times );

a.start ( );

while ( 1 ) {
draw ( a.getFrame() );
}
</pre>

An advantage of this class is that the animation speed is indipendent to FPS and it's very easy to use.

This is a simple way to manage a lot of animations for who needs more than one:

<pre>
class AnimationsList
{
// ltstr is only a const char* comparison function
map<const char*, Animation*, ltstr> animations;
int startTime; // now Animation::startTime is no more usefull
Animation *currentAnimation;

public:
AnimationsList ( ) : currentAnimation(0) { }

inline void addAnimation ( const char *n, Animation *a )
{
animations[n] = a;
}

int setAnimation ( const char *n, int t = clock() )
{
map<const char*, Animation*, ltstr>::iterator ai;
Animation *a;

ai = animations.find ( n );

if ( ai == animations.end() ) {
// error... animation not found
return 0;
}
a = ai->second;

if ( currentAnimation != a ) {
a->start ( );
currentAnimation = a;
startTime = t;
}

return 1;
}

Img * getFrame ( )
{
if ( currentAnimation ) {
return currentAnimation->getFrame ( );
}
return 0;
}
};
</pre>

Using a multimap instead the map it's possible to keep more than an animation bind to the same string. This would be a good way to make AnimationsList choose a random animation.

And here how to use AnimationsList class:

<pre>
AnimationsList al;

al.addAnimation ( "walking" "south", anim1 );
al.addAnimation ( "walking" "north", anim2 );
al.addAnimation ( "anim3", anim3 );

al.setAnimation ( "walking" "south" );

while ( 1 ) {
draw ( al.getFrame() );
}
</pre>

I hope not to had make a mistake writing... Anyway these are only theorical bases.

== Implementation proposal by Doener ==

This proposal is incomplete regarding how new sequences are added to the
Animation (which is not the right name for this type of class *g*)... Anyway,
you should get the idea...
The Frame class encapsulates images and are used to create a single linked list that
creates an animation. The idea behind the linked list is that you can easily create loops,
by having the last element of the animation pointing to the first one. Also, you can easily
prepend a "starting animation" before the loop, like in an animation of a running player.
He starts out with one animation and then loops the real running... The Animation class is
responsible for mapping animation names to their starting frame and for disposing the encapsulating
Frame objects, thus a std::map and a std::list is used to keep track of those objects.
The next frame is simply calculated from the time that has passed since the last run of the
logic method. The case that a whole animation loop can be skipped is not taken into consideration,
because a) we cannot do this with frames linked together arbitrarily and b) animations will probably
take around 100ms or longer, ie. we'd have less than 10fps for that case to happen and then
there's nothing left to gain by that simple optimization anymore anyway ;)

For the linked list features, of course the xml format needs to be adjusted to support that.

<pre>
/*
* Frame class, stored information about frames in an animation
*/
struct Frame
{
Image *mImg; // Image for this frame
int mDelay; // Time in ms for how long this frame is shown
Frame *mNext; // Next frame in sequence
};

class Animation
{
public:
Animation():mCurrentFrame(0);
~Animation();

void setSequence(const std::string &);

void logic(int timePassed);

Image* getCurrentImage()
{ return mCurrentFrame ? mCurrentFrame->mImg : 0; }

private:
Frame *mCurrentFrame;
typedef std::map<std::string,Frame*> FrameMap;
typedef FrameMap::iterator FrameMapIterator;
FrameMap mStartFrames;
std::list<Frame*> mFrames;
int mRemain;
}

Animation::~Animation()
{
for_each(mFrames.begin(), mFrames.end(), make_dtor(mFrames));
}

void Animation::setSequence(const std::string &name)
{
FrameMapIterator i = mStartFrames.find(name);
mCurrentFrame = (i == mStartFrames.end()) ? 0 : i->second;
}

void Animation::logic(int timePassed)
{
mRemain += timePassed;
while (mRemain >= mCurrentFrame->mDelay) {
mRemain -= mCurrentFrame->mDelay;
mCurrentFrame = mCurrentFrame->mNext;
}
};
</pre>

Archive:System requirements

2006-01-20T17:43:49Z

Doener: /* Performance chart */

== General guideline ==

The system requirements of TMW, as with any game, hugely depend on the kind of framerate you want. In general, you should be fine with a more or less recent (year 2001 and later) 3D accelerator card when running the OpenGL version. The software/SDL version probably heavily depends on your processor speed.

* '''Processor:''' 1 Ghz
* '''Memory:''' 64 MB
* '''Hard disk:''' ~25 MB
* '''Operating system:''' Windows, GNU/Linux or MacOS X

== Performance chart ==

Here is a list of systems and the respective framerate with TMW. Feel free to add a line of your own, add comments if you like or necessary. We need especially more data about FPS on lower end machines, and it would also be nice to see changes in framerate on the same machine with different versions of TMW.

{| border="1" cellspacing="0" cellpadding="5" width="100%" align="center"
! style="background:#efdead;" | Name
! style="background:#efdead;" | Processor
! style="background:#efdead;" | Memory
! style="background:#efdead;" | Video Card
! style="background:#efdead;" | OS
! style="background:#efdead;" | TMW Version
! style="background:#efdead;" | Frame Rate
! style="background:#efdead;" | Comments
|-
| align="center" | DeveloperX
| align="center" | AMD K6-2 550 Mhz
| align="center" | 640 MB
| align="center" | GF 2MX 32 MB
| align="center" | WinXP Pro
| align="center" | 0.0.13
| align="center" | 3 to 7
|
|-
| align="center" rowspan="3" | [[User:BjÃ¸rn|BjÃ¸rn]]
| align="center" rowspan="3" | AthlonXP 1.6
| align="center" rowspan="3" | 512 MB
| align="center" | GF 2MX 64 MB
| align="center" rowspan="3" | ArchLinux/2.6
| align="center" | 04/07/2005-OpenGL
| align="center" | 50
| align="center" rowspan="3" | Windowed
|-
| align="center" | Radeon 8500 (fglrx)
| align="center" | 07/14/2005-OpenGL
| align="center" | 200+
|-
| align="center" | Radeon 8500 (ati)
| align="center" | 10/26/2005-OpenGL
| align="center" | 170
|-
| align="center" | [[User:ampersand|ampersand]]
| align="center" | Pentium III 1GHz
| align="center" | 256 MB
| align="center" | ATI Mobility
| align="center" | SuSE 9.2
| align="center" | 0.0.13
| align="center" | 26-45
|
|-
| align="center" | Shura
| align="center" | AthlonXP 1.8
| align="center" | 512 MB
| align="center" | GF FX5200 64 MB
| align="center" | ArchLinux/2.6
| align="center" | 12/20/2004
| align="center" | 52
| makefile.static (performance CXXFLAGS) / GCC 3.4.3 - Allegro 4.1.17
|-
| align="center" | Sull
| align="center" | AthlonXP 1.5
| align="center" | 386 MB
| align="center" | GF TI4200 64 MB
| align="center" | Gentoo-2.6
| align="center" | 12/17/2004
| align="center" | 40
|
|-
| align="center" | Neko-mon
| align="center" | Athlon64 3
| align="center" | 512 MB
| align="center" | GF 4 440 MX 64 MB
| align="center" | WinXP Prof.
| align="center" | 12/17/2004
| align="center" | 67
|
|-
| align="center" rowspan="2"| [[User:ElvenProgrammer|ElvenProgrammer]]
| align="center" | Pentium4 2.53
| align="center" | 512 MB
| align="center" | ATI 9200se 128 MB
| align="center" | WinXP Home SP2
| align="center" | 8/21/2005
| align="center" | 76
| align="center" | 67 to 76 thanks to Doener's patch
|-
| align="center" | AthlonXP
| align="center" | 256 MB
| align="center" | ATI 9200gp 64 MB
| align="center" | WinXP Home SP2
| align="center" | 5/30/2005
| align="center" | 52
| align="center" | Up to 60 fps with OpenGL
|-
| align="center" rowspan="4" | [[User:Javila|Javila]]
| align="center" rowspan="4" | Duron 800MHz
| align="center" rowspan="4" | 640 MB
| align="center" rowspan="4" | nVidia TNT2 32 MB
| align="center" rowspan="4" | Slackware 10.0
| align="center" | 0.0.12-SDL
| align="center" | 07
|
|-
| align="center" | 0.0.12-OpenGL
| align="center" | 30
|
|-
| align="center" | 05/05/2005-OpenGL
| align="center" | 33
| align="center" | Windowed (up to 35 fps in fullscreen)
|-
| align="center" | 07/15/2005-OpenGL
| align="center" | 40
| align="center" | Windowed (up to 45 fps in fullscreen)
|-
| align="center" | [[User:Maci|maci]]
| align="center" | AMD Athlon(tm) XP 2400+
| align="center" | 1024 MB DDR 400
| align="center" | nVidia GeForce 6600GT
| align="center" | GNU/Linux
| align="center" | 13/7/2005-OpenGL
| align="center" | 560+
| align="center" | Windowed
|-
| align="center" | [[User:Modanung|Modanung]]
| align="center" | AthlonXP 1.6
| align="center" | 512 MB
| align="center" | ATI Radeon 9800 Pro
| align="center" | WinXP Prof.
| align="center" | 5/1/2005-OpenGL
| align="center" | 300+
| align="center" | Windowed
|-
| align="center" | [[User:Kaxero|Kaxero]]
| align="center" | Pentium4 Mobile 1.7Ghz
| align="center" | 512 MB
| align="center" | GeForce4 440Go 32Mb
| align="center" | WinXP Prof. SP2
| align="center" | 0.0.13
| align="center" | 45-50
| align="center" | Windowed
|-
| align="center" | hStorm
| align="center" | AMD K6-2 550Mhz
| align="center" | 320 MB
| align="center" | GeForce2 MX400 64Mb
| align="center" | Windows 98
| align="center" | 0.0.13-OpenGL
| align="center" | 10-23
|
|-
| align="center" | [[User:Lunpa|Lunpa]]
| align="center" | AMD Athlon MP 1Ghz
| align="center" | 512 MB (+ 8GB swap)
| align="center" | Nvidia FX5200 256Mb
| align="center" | Gentoo GNU/linux (don't look at me!)
| align="center" | 0.0.14.1
| align="center" | 50ish
| align="center" | Windowed, running with two monitors.
|-
| align="center" | [[User:Crush|Crush]]
| align="center" | AMD Athlon XP 2400+
| align="center" | 256 MB
| align="center" | nVidia GeForce2 MX400 32MB
| align="center" | Windows XP Prof
| align="center" | 0.0.16
| align="center" | 75
| align="center" | Windowed, OpenGL enabled
|-
| align="center" | [[User:KaTSuo|KaTSuo]]
| align="center" | AMD Athlon XP 2000+
| align="center" | 512 MB
| align="center" | Radeon 8500 64MB
| align="center" | Windows XP, SP-2
| align="center" | 0.0.15
| align="center" | 80
| align="center" | Windowed
|-
| align="center" | [[User:Maniac|Maniac]]
| align="center" | AMD Athlon XP 1600+
| align="center" | 768 MB
| align="center" | nVidia GeForce4 TI4200 64MB
| align="center" | Windows 2000
| align="center" | 0.0.17
| align="center" | 350+
| align="center" | Windowed, OpenGL enabled
|-
| align="center" rowspan="2"| [[User:Burger|Burger]]
| align="center" rowspan="2"| AMD Athlon 64 3200+
| align="center" rowspan="2"| 1024 MB
| align="center" rowspan="2"| nVidia GeForce 6800GT 256MB
| align="center" rowspan="2"| Windows XP, SP-2
| align="center" rowspan="2"| 0.0.17
| align="center" | 85
| align="center" | Windowed, OpenGL enabled, 85Hz
|-
| align="center" | 700+
| align="center" | Windowed, OpenGL enabled, without vsync
|-
| align="center" rowspan="2"| [[User:Doener|Doener]]
| align="center" rowspan="2"| AMD Athlon 64 X2 4400+
| align="center" rowspan="2"| 2048 MB
| align="center" rowspan="2"| nVidia GeForce 6600 256MB
| align="center" rowspan="2"| Gentoo Linux - Kernel 2.6.15
| align="center" rowspan="2"| 0.0.18.1+ (cvs)
| align="center" | 300-600 (depends on number of in-game windows)
| align="center" | Windowed, OpenGL enabled
|}

User:Doener

2005-07-30T12:26:41Z

Doener: /* Contact */

== About ==
Uhm, where to start? Well, my real name is BjÃ¶rn Steinbrink, I'm from Germany and born in 1982 (well, I could just say I'm 23 years old, but that would be outdated so soon ;) ). I got to know about The Mana World in May 2005, when I've been (once again) searching for a nice SNES-style RPG that runs on Linux. I wasn't that much impressed by the game itself, but kept a bookmark as it was the most promising i had seen. Time passed by and I stumbled over a new tmw release, tried it, hit a well known bug and asked on irc about it (just to find the solution in the forums before anyone could answer ;) ). And you know how irc works, right? You start talking to folks who got ideas or find bugs and all of a sudden you find yourself submitting patches... Well, that's how i got into working on tmw...

== Contact ==
Mail: B.Steinbrink@gmx.de<br />
Jabber: doener@jabber.ccc.de

== Questions ==
Well, nobody asked any questions, yet. Feel free to do add some, maybe I'll feel free to ignore them, maybe not... ;)

User:Doener

2005-07-30T12:25:39Z

Doener:

== About ==
Uhm, where to start? Well, my real name is BjÃ¶rn Steinbrink, I'm from Germany and born in 1982 (well, I could just say I'm 23 years old, but that would be outdated so soon ;) ). I got to know about The Mana World in May 2005, when I've been (once again) searching for a nice SNES-style RPG that runs on Linux. I wasn't that much impressed by the game itself, but kept a bookmark as it was the most promising i had seen. Time passed by and I stumbled over a new tmw release, tried it, hit a well known bug and asked on irc about it (just to find the solution in the forums before anyone could answer ;) ). And you know how irc works, right? You start talking to folks who got ideas or find bugs and all of a sudden you find yourself submitting patches... Well, that's how i got into working on tmw...

== Contact ==
Mail: B.Steinbrink@gmx.de
Jabber: doener@jabber.ccc.de

== Questions ==
Well, nobody asked any questions, yet. Feel free to do add some, maybe I'll feel free to ignore them, maybe not... ;)

Archive:Rendering

2005-07-12T17:23:22Z

Doener:

I'm not sure if i got the current rendering approach right, so feel free to
correct (or flame) me ;)

Currently, all rendering happens in Image::draw(), this is a simple approach
that works, but it has some drawbacks. Model and view are combined in the same
class, this makes it hard to implement different approaches for different
graphic libraries (SDL vs. OpenGL in this case). There's also a tight coupling
between the Image class and various other classes that could be avoided.

Actually the SubImage class just abstracts from drawing a part of a bigger image,
it does not really contain a SubImage. This is used to simplify the drawing code in
other places, but places an important constraint on the way how rendering can be done.
As the drawing code is in the (Sub)Image class, rendering happens on a image-by-image
basis. OpenGL suffers a lot from this, as the repeated glBegin()/glEnd() calls cause
some overhead, one should always try to send as much data at once as possible.

To improve the situation, especially with OpenGL, I'd suggest the following, based on
how the Map would handle the new stuff.

Tilesets are indexed like this:
<pre>
1 2 3 4
5 6 7 8
9 x x x
x x x x
</pre>

Instead of having a lot of Images in the Map, it is associated with a tileset and has
a set of indices into the tileset.

That way, a rendering class could get the right x,y values inside the tileset with a
simple calculation based on tileset's tile-width, tile-height, row-width and the index
into the tileset.

For a SDLRenderer, this would probably just end up in copying the SubImage::draw()
code and having the above calculation, as the 'draw a part of a larger image' code is
already there.

For a OpenGLRenderer, it would like a little different, a vertex array could be prepared
beforehand, as the vertex positions will never change, only the textures. For the texture,
there would be a prepared array of coordinates into the tileset texture for each tileset that
is being used. That way the indices stored in the map could probably directly be sent to opengl
to render the map (I need to read up on glDrawElements to actually confirm that).

So the rendering code for the SDL part would just be moved around a little and separated from the
data structures (i.e. quite a trivial change). The OpenGL code would get quite some change for the
better, as the separation of image and map data allows a quite better handling of this stuff.

PS: I hope anyone understands what I'm trying to say, I feel like unable to speak english today...

Main Page

2005-07-12T16:51:59Z

Doener: Added RFC section under development

<div style="text-align: center; margin: 20px; font-style: italic;">Welcome to The Mana World wiki! This wiki is meant to provide information to our players, to provide an easy way to contribute to the development of certain parts of the game and to improve collaboration between people on the development team. We hope you will find what you are looking for. To be able to edit you have to login, but signing up is free and requires no activation.</div>

{| cellspacing="3" cellpadding="5" width="100%"
|- valign="top"
|width="50%" style="border: 1px solid #e0c8b8; color: #000; background-color: #faeee6"|
<h2>Project information</h2>
* [[Project description]]
* [[Developers]]
* [[FAQ]]
* [[Dependencies]]
* [[System requirements]]
* [[Roadmap]]
* [[Ports]]
* [http://cvs.sourceforge.net/viewcvs.py/themanaworld/tmw/ChangeLog?rev=HEAD&view=markup Change log]

<h4>References</h4>

* [[Guilds]]
* [[Monster reference]]
* [[Item reference]]

<h4>Organization</h4>

* [[Suggestions]]
* [http://themanaworld.org/archive/galerie.php Gallery]
* [[Developer meetings]]
* [[Quotes]]
* '''[[Summer 2005 real life developer meeting]]'''

|width="50%" style="border: 1px solid #c9c9ff; color: #000; background-color: #f3f3ff"|
<h2>Development</h2>

'''World'''
:[[World development]], [[World backstory]], [[Map development]], [[Landmarks]], [[Kingdoms]], [[Important NPCs]], [[Finished NPCs]], [[Quest development|Quests]], [[Calendar]]

'''Graphics'''
:[[Guidelines]], [[Concept art]], [[Tileset development|Tilesets]], [[Playerset development|Playerset]], [[NPC development|NPCs]], [[Monsterset development|Monsters]], [[Hairset development|Hairsets]], [[Itemset development|Itemsets]], [[Equipment development|Equipment]], [[:Special:Newimages|New images gallery]]

'''GUI'''
:[[GUI development]]

'''Sound'''
:[[SFX]], [[Music]]

'''Game'''
:[[Game systems]], [[Update system]]

'''Server'''
:[[Server development]]

'''RFCs'''
:[[Rendering]]
|}