Maemo Wiki Mirror - User contributions [en]

Game development

2008-06-11T16:42:49Z

70.242.115.107: /* External Links */

This page contains tips on game development and SDL library usage for internet tablets.

=Useful Tips=

==Hardware notes==

* Internet tablets use a touchscreen, which enables new ways to implement game-features, such as on-screen buttons, in-game drawing, moving * character by tapping screen. etc.
* Since the device does not have any buttons on right side, implement those in software!
* Avoid using the 4 way rocker for fast and complex movements. It's not well suited for gaming.
* When using screen's vertical orientation (as in tetris) think other use for esc button than exiting game. It's so close to the rocker that accidental presses will happen.

==SDL specific notes==

Things to remember:
* The screen is natively 800x480. No resolution changes are supported. Maybe in the future we might have support for 400x240 res for faster graphics but this is quite unlikely. If trying to set fullscreen window smaller than the native screen size, you will just have black borders.
* In windowed mode matchbox will force the window to certain size (you should look at the UI specifications to see the actual window size). If your requested window is smaller than this, your window will be aligned to the upper-left and have black borders on the lower-right.
Generally SDL windows (not fullscreen) look quite bad with the theme if nothing for the theme is done inside the SDL window, but it's up to you to decide.
* Avoid full 800x480 screen updates. Memory bandwidth is limited. If you still have to do these for some reason, you should make the area smaller (eg having some statusbar or any GUI elements which doesn't need to be updated each time). Also do not use SDL_Flip(), since it will update whole screen. Use rect updating functions instead. Thank you.
* 32 bit mode doesn't work. The reason was that there was a bug that caused SDL to segfault when you had 32 bit window and you recreated the window. Since the display is only 16 bit, there is no reason to support 32 bit mode, which would just give extra round of pixel conversion and therefore slow things down. Convert your images on loading to native 16-bit with SDL.
* Mouse events. There is touchscreen, and you can't assume average end user Billy-Bob would hack the device to USB host mode and use the USB mouse. So use absolute coordinates as much as possible. One example where relative coordinates are used is scummvm. If you use keypad to move the cursor, and then use the touchscreen, the actuall cursor will be at offset from original touchpadpress. Think absolutely, not relatively ;)

===Utilizing pixel doubling inside SDL===

As there is support for pixel-doubled drawing to the screen inside the HW, there is implementations to utilize that up to X. So if you want to use it you have to do some xlib code, therefore it might be a good idea to put this small piece of code to switch pixel doubling mode to a separate file.

====What is pixel doubling?====

Pixel doubling is a feature of the Xsp extension of the tablet's X server. When enabled, all draws to the display are doubled in size with a smoothing filter. This reduces required bandwidth for screen updates by a factor of 4, making full-motion fullscreen animation possible. This also allows lower-quality graphics to be drawn to portions of the screen (for example a low-res game area and a high-res status bar).

====Pixel doubling problems and workarounds====

* Be aware that Xsp pixel doubling feature was designed for scaling video-player videos (drawn by dsp, not X) and is not officially supported.
* Don't update areas which would exceed doubled coordinates 400x240.
* If possible, disable doubling when not drawing, because if another process draws to screen (like infoprints) while the Xsp doubling is active, results can be quite "artistic".
* If mouse pointer is enabled, it will break pixel doubling. Disable it before turning on doubling with SDL_ShowCursor(0);.
* Many SDL games that draw several small updaterects will break Xsp pixel doubling, causing flicker. This has been discussed at length on the maemo-developer list without a resolution. If pixel doubling is causing areas to flicker, change the code from individual updated rectangles for sprites to one updaterect for your entire game screen, for example region (0,0,320,240).
* If your game crashes or exits before disabling pixel doubling, it will be left on until some application switches it off. This means that you will have 'artistic desktop' or a white screen or reboot. This can be avoided by reacting to SDL active events, if somebody else gets active status, immediately switch doubling off.

====Howto use it====

There exists one X extension (Xsp), which can be used for that. Sample piece of code with SDL:

<pre>
#include <X11/Xlib.h>
#include <X11/extensions/Xsp.h>

#include <SDL/SDL.h>
#include <SDL/SDL_syswm.h>

void set_doubling(unsigned char enable)
{
SDL_SysWMinfo wminfo;
SDL_VERSION(&wminfo.version);
SDL_GetWMInfo(&wminfo);
XSPSetPixelDoubling(wminfo.info.x11.display, 0, enable);
}
</pre>

Note that when you compile it you have to include X include path and link this with libXsp (-lXsp).

===Application name (for the Task Navigator)===

Set the window title using

<pre>
SDL_WM_SetCaption("title", NULL);
</pre>

Maemo Task Navigator (list of open programs) identifies non-Maemo programs (like pure SDL apps) by matching StartupWMClass-variable in .desktop-file and the application "window manager class" name. By default all SDL apps have the name "SDL_App". This can be changed with environment variable SDL_VIDEO_X11_WMCLASS.

* Alternative 1: Here's an example: app.bin is the binary executable. app is the startup script, printed here:

<pre>
#!/bin/sh
BASENAME=`basename $0`
export SDL_VIDEO_X11_WMCLASS=${BASENAME}
exec ${0}.bin "$@"
</pre>

app.desktop is the desktop file:

<pre>
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Name=The Application
Exec=/var/lib/install/usr/bin/app
Icon=app
X-Window-Icon=tn-bookmarks-link
X-Osso-Type=application/x-executable
StartupWMClass=app
Terminal=false
</pre>

Notice that StartupWMClass == SDL_VIDEO_X11_WMCLASS, and that Exec points to the script, not binary.

* Alternative 2: An other possibility that doesn't need a script is the following. Put the line

<pre>
putenv("SDL_VIDEO_X11_WMCLASS=appexename");
</pre>

in your code. A good position is directly after the main() function. In this case your control file should directly point to the application name. So there's no need for a helper script.

=External Links=

[http://www.libsdl.org/ Simple DirectMedia Layer Homepage]

[http://www.gamedev.net/ Game Development Resources]

Game development

2008-06-11T16:36:01Z

70.242.115.107: New page: This page contains tips on game development and SDL library usage for internet tablets. ==Useful Tips== ===Hardware notes=== * Internet tablets use a touchscreen, which enables new ways...

This page contains tips on game development and SDL library usage for internet tablets.

==Useful Tips==

===Hardware notes===

* Internet tablets use a touchscreen, which enables new ways to implement game-features, such as on-screen buttons, in-game drawing, moving * character by tapping screen. etc.
* Since the device does not have any buttons on right side, implement those in software!
* Avoid using the 4 way rocker for fast and complex movements. It's not well suited for gaming.
* When using screen's vertical orientation (as in tetris) think other use for esc button than exiting game. It's so close to the rocker that accidental presses will happen.

===SDL specific notes===

Things to remember:
* The screen is natively 800x480. No resolution changes are supported. Maybe in the future we might have support for 400x240 res for faster graphics but this is quite unlikely. If trying to set fullscreen window smaller than the native screen size, you will just have black borders.
* In windowed mode matchbox will force the window to certain size (you should look at the UI specifications to see the actual window size). If your requested window is smaller than this, your window will be aligned to the upper-left and have black borders on the lower-right.
Generally SDL windows (not fullscreen) look quite bad with the theme if nothing for the theme is done inside the SDL window, but it's up to you to decide.
* Avoid full 800x480 screen updates. Memory bandwidth is limited. If you still have to do these for some reason, you should make the area smaller (eg having some statusbar or any GUI elements which doesn't need to be updated each time). Also do not use SDL_Flip(), since it will update whole screen. Use rect updating functions instead. Thank you.
* 32 bit mode doesn't work. The reason was that there was a bug that caused SDL to segfault when you had 32 bit window and you recreated the window. Since the display is only 16 bit, there is no reason to support 32 bit mode, which would just give extra round of pixel conversion and therefore slow things down. Convert your images on loading to native 16-bit with SDL.
* Mouse events. There is touchscreen, and you can't assume average end user Billy-Bob would hack the device to USB host mode and use the USB mouse. So use absolute coordinates as much as possible. One example where relative coordinates are used is scummvm. If you use keypad to move the cursor, and then use the touchscreen, the actuall cursor will be at offset from original touchpadpress. Think absolutely, not relatively ;)

====Utilizing pixel doubling inside SDL====

As there is support for pixel-doubled drawing to the screen inside the HW, there is implementations to utilize that up to X. So if you want to use it you have to do some xlib code, therefore it might be a good idea to put this small piece of code to switch pixel doubling mode to a separate file.

=====What is pixel doubling?=====

Pixel doubling is a feature of the Xsp extension of the tablet's X server. When enabled, all draws to the display are doubled in size with a smoothing filter. This reduces required bandwidth for screen updates by a factor of 4, making full-motion fullscreen animation possible. This also allows lower-quality graphics to be drawn to portions of the screen (for example a low-res game area and a high-res status bar).

=====Pixel doubling problems and workarounds=====

* Be aware that Xsp pixel doubling feature was designed for scaling video-player videos (drawn by dsp, not X) and is not officially supported.
* Don't update areas which would exceed doubled coordinates 400x240.
* If possible, disable doubling when not drawing, because if another process draws to screen (like infoprints) while the Xsp doubling is active, results can be quite "artistic".
* If mouse pointer is enabled, it will break pixel doubling. Disable it before turning on doubling with SDL_ShowCursor(0);.
* Many SDL games that draw several small updaterects will break Xsp pixel doubling, causing flicker. This has been discussed at length on the maemo-developer list without a resolution. If pixel doubling is causing areas to flicker, change the code from individual updated rectangles for sprites to one updaterect for your entire game screen, for example region (0,0,320,240).
* If your game crashes or exits before disabling pixel doubling, it will be left on until some application switches it off. This means that you will have 'artistic desktop' or a white screen or reboot. This can be avoided by reacting to SDL active events, if somebody else gets active status, immediately switch doubling off.

=====Howto use it=====

There exists one X extension (Xsp), which can be used for that. Sample piece of code with SDL:

<pre>
#include <X11/Xlib.h>
#include <X11/extensions/Xsp.h>

#include <SDL/SDL.h>
#include <SDL/SDL_syswm.h>

void set_doubling(unsigned char enable)
{
SDL_SysWMinfo wminfo;
SDL_VERSION(&wminfo.version);
SDL_GetWMInfo(&wminfo);
XSPSetPixelDoubling(wminfo.info.x11.display, 0, enable);
}
</pre>

Note that when you compile it you have to include X include path and link this with libXsp (-lXsp).

====Application name (for the Task Navigator)====

Set the window title using

<pre>
SDL_WM_SetCaption("title", NULL);
</pre>

Maemo Task Navigator (list of open programs) identifies non-Maemo programs (like pure SDL apps) by matching StartupWMClass-variable in .desktop-file and the application "window manager class" name. By default all SDL apps have the name "SDL_App". This can be changed with environment variable SDL_VIDEO_X11_WMCLASS.

* Alternative 1: Here's an example: app.bin is the binary executable. app is the startup script, printed here:

<pre>
#!/bin/sh
BASENAME=`basename $0`
export SDL_VIDEO_X11_WMCLASS=${BASENAME}
exec ${0}.bin "$@"
</pre>

app.desktop is the desktop file:

<pre>
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Name=The Application
Exec=/var/lib/install/usr/bin/app
Icon=app
X-Window-Icon=tn-bookmarks-link
X-Osso-Type=application/x-executable
StartupWMClass=app
Terminal=false
</pre>

Notice that StartupWMClass == SDL_VIDEO_X11_WMCLASS, and that Exec points to the script, not binary.

* Alternative 2: An other possibility that doesn't need a script is the following. Put the line

<pre>
putenv("SDL_VIDEO_X11_WMCLASS=appexename");
</pre>

in your code. A good position is directly after the main() function. In this case your control file should directly point to the application name. So there's no need for a helper script.

==Internet Tablet game projects==

===platform game engine===

Simple 2D platform game engine containing tilemap and sprite-handling, bounding-box collision detection + other stuff. (Will have some simple light effects, which can be preblitted on top of tilemap/background picture.)

==INDT Game Ports & development Screenshots==

Those are small ports & developments made for maemo. All of them will be available for download to serve as reference for game development. Dbus integration, SDL or GTK games, Multiplayer features using wifi and bluetooth, optimization techs and some documentation will be also available.

===Doom Port(SDL BASED)===

After fixing some bugs related to texture loading ( on Arm it fails ) and creating a custom GUI for pen based gaming it's ready. Playing it full screen is FAST! REALLY FAST. Sounds effects are fine, better with headphone.

===Battle Gweled===

Wifi multiplayer gweled game ( base on bejeweled classic ) User must do 3 or more stone sequences to increase powerbar, after some seconds idle a strike is done on the enemy.
 
===Crazy Parking===

Based on the famous rushour game, you must move cars away to make the way out clear for you machine!

===Maemo Blocks===

Classic blocks game, no explanations needed =). A must have for any platform.

you can play with the 4-way rocker or grabbing the pieces with the stylus

===Maemo Sweeper===

Ported from SDLMINE http://www.libsdl.org. another Classic!

===Ice Breaker===

Ported to maemo! http://www.libsdl.org. really fun to play with the stylus. 

==Pupnik's SDL game ports for ITOS==

A large collection of SDL games and emulators in various stages of development [http://www.pupnik.de/software.html].

A SDL demo game illustrating Xsp pixel doubling workarounds.

http://www.pupnik.de/aliens-1.0.2_Nokia.tgz

==External Links==

[http://www.libsdl.org/ Simple DirectMedia Layer Homepage]

[http://www.gamedev.net/ Game Development Resources]

X11 Extension tutorial

2008-06-11T15:47:33Z

70.242.115.107: /* Function wrapping */

This tutorial briefly explains what is X11 extension and how to implement one. Extensibility is one of the requirements for a windowing system. X extension interface can be used to add new functionality to X server, it also requires additional functionality from the DDX (driver) itself.

==Programming extensions==

X extension code can be logically divided in 3 parts :
* protocol definition
* server side functional implementation
* library offering API for client programs

(+ additions to driver code to use extension)

===Extension file structure in Kdrive===

Directory 'mi' contains the machine-independent library which is a set of common DDX routines. Initialization of server extensions is made by 'InitExtensions()' function found at 'xserver_root/mi/miinitext.c'. This file has to be changed in order to initialize extension on server startup. Other files that have to be changed in order to build and link the extension with X server are 'xserver_root/Makefile.am' and 'xserver_root/configure.ac'.

Extension itself should be located in a directory of it's own, for example 'xserver_root/sample'. This directory should be added to 'xserver_root/Makefile.am' SUBDIRS section. Figure below shows an example of extension directory structure. The client interface can be compiled anywhere else. Client interface is usually put in it's own directory under libs directory, which contains all other libraries X uses.

<pre>
<xlibs_root>
|
|_ Sampleext (protocol header)
|
|_ Xsample (client interface)

<xserver_root> (Makefile.am, configure.ac)
|
|_ mi (miinitext.c)
|
|_ sample (extension files)
</pre>

===Protocol===

Protocol consists of requests, events, replies and error messages. These are sent between client and server. Example : client sends a request for server using the library provided by extension, extension-code on serverside processes this request and performs required action + sends a reply to client.

The basic structure of request packet is predefined and every request must contain this 4-byte header information. After the header data, request can contain any amount of optional data limited only by the max packet size of the transport protocol.

<pre>
typedef struct _xReq {
CARD8 reqType; /* major opcode of request, allocated by server on extension initialization */
CARD8 data; /* undefined, usually used as 'minor opcode' by the extension to differiate requests */
CARD16 length; /* total length of request (including header) in 4 byte quantities */
...
} xReq;

The structure skeleton of a request packet. All request structures must be multiple of 4 bytes long.
</pre>

<pre>
typedef struct _xRep {
CARD8 type; /* X_Reply */
CARD8 pad1; /* can be anything, used for padding here */
CARD16 sequenceNumber B16; /* last sequence number */
CARD32 length B32; /* length of the reply */

/* now the actual content ... */

CARD16 data B16; /* data */
CARD16 moredata B16; /* some more data */

CARD32 pad2 B32; /* padding just to have 32B */
CARD32 pad3 B32;
CARD32 pad4 B32;
CARD32 pad5 B32;
CARD32 pad6 B32;

} sample_data_reply;
#define sz_sample_data_reply 32

An example structure for reply packet returning data in form of 2 CARD16 variables.
All reply packages must be at least 32 bytes.
You also have to define a macro for returning size of the structure as 'sz_<struct_name>'.
Server will use this macro to check package sizes (using macro REQUEST_SIZE_MATCH).
</pre>

Every X extension has a Dispatch() function, which works as a request-handler. When X-server receives a request package, it will check the major opcode. If major opcode belongs to some extension it calls extension's Dispatch routine. Dispatch checks the minor opcode of request and returns a pointer to appropriate function to call or BadRequest in error situation. If protocol requires a reply packet, function will send a reply packet.

===Function wrapping===

When adding and modifying functionality of normal DDX functions, extension has to wrap those functions. This means that extension will replace existing function with it's own version containing needed new functionality. X server calls all DDX functions through a function pointer and wrapping means switching of these pointers. Different extensions can wrap same functions, and depending on the order of extension initialization, they wrap each others functions. This will create a function chain. Wrapper function can call down to this function chain (it is recommended way, so that other extensions can do their work as well ''unless'' you plan to replace larger part of the functionality but in this case you really have to know what you are doing).

to be continued ... will contain more examples etc. (please send comments to [mailto:tapani.palli@nokia.com Tapani Palli] )

X11 Extension tutorial

2008-06-11T15:45:58Z

70.242.115.107: /* Function wrapping */

This tutorial briefly explains what is X11 extension and how to implement one. Extensibility is one of the requirements for a windowing system. X extension interface can be used to add new functionality to X server, it also requires additional functionality from the DDX (driver) itself.

==Programming extensions==

X extension code can be logically divided in 3 parts :
* protocol definition
* server side functional implementation
* library offering API for client programs

(+ additions to driver code to use extension)

===Extension file structure in Kdrive===

Directory 'mi' contains the machine-independent library which is a set of common DDX routines. Initialization of server extensions is made by 'InitExtensions()' function found at 'xserver_root/mi/miinitext.c'. This file has to be changed in order to initialize extension on server startup. Other files that have to be changed in order to build and link the extension with X server are 'xserver_root/Makefile.am' and 'xserver_root/configure.ac'.

Extension itself should be located in a directory of it's own, for example 'xserver_root/sample'. This directory should be added to 'xserver_root/Makefile.am' SUBDIRS section. Figure below shows an example of extension directory structure. The client interface can be compiled anywhere else. Client interface is usually put in it's own directory under libs directory, which contains all other libraries X uses.

<pre>
<xlibs_root>
|
|_ Sampleext (protocol header)
|
|_ Xsample (client interface)

<xserver_root> (Makefile.am, configure.ac)
|
|_ mi (miinitext.c)
|
|_ sample (extension files)
</pre>

===Protocol===

Protocol consists of requests, events, replies and error messages. These are sent between client and server. Example : client sends a request for server using the library provided by extension, extension-code on serverside processes this request and performs required action + sends a reply to client.

The basic structure of request packet is predefined and every request must contain this 4-byte header information. After the header data, request can contain any amount of optional data limited only by the max packet size of the transport protocol.

<pre>
typedef struct _xReq {
CARD8 reqType; /* major opcode of request, allocated by server on extension initialization */
CARD8 data; /* undefined, usually used as 'minor opcode' by the extension to differiate requests */
CARD16 length; /* total length of request (including header) in 4 byte quantities */
...
} xReq;

The structure skeleton of a request packet. All request structures must be multiple of 4 bytes long.
</pre>

<pre>
typedef struct _xRep {
CARD8 type; /* X_Reply */
CARD8 pad1; /* can be anything, used for padding here */
CARD16 sequenceNumber B16; /* last sequence number */
CARD32 length B32; /* length of the reply */

/* now the actual content ... */

CARD16 data B16; /* data */
CARD16 moredata B16; /* some more data */

CARD32 pad2 B32; /* padding just to have 32B */
CARD32 pad3 B32;
CARD32 pad4 B32;
CARD32 pad5 B32;
CARD32 pad6 B32;

} sample_data_reply;
#define sz_sample_data_reply 32

An example structure for reply packet returning data in form of 2 CARD16 variables.
All reply packages must be at least 32 bytes.
You also have to define a macro for returning size of the structure as 'sz_<struct_name>'.
Server will use this macro to check package sizes (using macro REQUEST_SIZE_MATCH).
</pre>

Every X extension has a Dispatch() function, which works as a request-handler. When X-server receives a request package, it will check the major opcode. If major opcode belongs to some extension it calls extension's Dispatch routine. Dispatch checks the minor opcode of request and returns a pointer to appropriate function to call or BadRequest in error situation. If protocol requires a reply packet, function will send a reply packet.

===Function wrapping===

When adding and modifying functionality of normal DDX functions, extension has to wrap those functions. This means that extension will replace existing function with it's own version containing needed new functionality. X server calls all DDX functions through a function pointer and wrapping means switching of these pointers. Different extensions can wrap same functions, and depending on the order of extension initialization, they wrap each others functions. This will create a function chain. Wrapper function can call down to this function chain (it is recommended way, so that other extensions can do their work aswell unless you plan to replace larger part of the functionality but in this case you really have to know what you are doing).

to be continued ... will contain more examples etc. (please send comments to [mailto:tapani.palli@nokia.com Tapani Palli] )

X11 Extension tutorial

2008-06-11T15:44:52Z

70.242.115.107: New page: This tutorial briefly explains what is X11 extension and how to implement one. Extensibility is one of the requirements for a windowing system. X extension interface can be used to add new...

This tutorial briefly explains what is X11 extension and how to implement one. Extensibility is one of the requirements for a windowing system. X extension interface can be used to add new functionality to X server, it also requires additional functionality from the DDX (driver) itself.

==Programming extensions==

X extension code can be logically divided in 3 parts :
* protocol definition
* server side functional implementation
* library offering API for client programs

(+ additions to driver code to use extension)

===Extension file structure in Kdrive===

Directory 'mi' contains the machine-independent library which is a set of common DDX routines. Initialization of server extensions is made by 'InitExtensions()' function found at 'xserver_root/mi/miinitext.c'. This file has to be changed in order to initialize extension on server startup. Other files that have to be changed in order to build and link the extension with X server are 'xserver_root/Makefile.am' and 'xserver_root/configure.ac'.

Extension itself should be located in a directory of it's own, for example 'xserver_root/sample'. This directory should be added to 'xserver_root/Makefile.am' SUBDIRS section. Figure below shows an example of extension directory structure. The client interface can be compiled anywhere else. Client interface is usually put in it's own directory under libs directory, which contains all other libraries X uses.

<pre>
<xlibs_root>
|
|_ Sampleext (protocol header)
|
|_ Xsample (client interface)

<xserver_root> (Makefile.am, configure.ac)
|
|_ mi (miinitext.c)
|
|_ sample (extension files)
</pre>

===Protocol===

Protocol consists of requests, events, replies and error messages. These are sent between client and server. Example : client sends a request for server using the library provided by extension, extension-code on serverside processes this request and performs required action + sends a reply to client.

The basic structure of request packet is predefined and every request must contain this 4-byte header information. After the header data, request can contain any amount of optional data limited only by the max packet size of the transport protocol.

<pre>
typedef struct _xReq {
CARD8 reqType; /* major opcode of request, allocated by server on extension initialization */
CARD8 data; /* undefined, usually used as 'minor opcode' by the extension to differiate requests */
CARD16 length; /* total length of request (including header) in 4 byte quantities */
...
} xReq;

The structure skeleton of a request packet. All request structures must be multiple of 4 bytes long.
</pre>

<pre>
typedef struct _xRep {
CARD8 type; /* X_Reply */
CARD8 pad1; /* can be anything, used for padding here */
CARD16 sequenceNumber B16; /* last sequence number */
CARD32 length B32; /* length of the reply */

/* now the actual content ... */

CARD16 data B16; /* data */
CARD16 moredata B16; /* some more data */

CARD32 pad2 B32; /* padding just to have 32B */
CARD32 pad3 B32;
CARD32 pad4 B32;
CARD32 pad5 B32;
CARD32 pad6 B32;

} sample_data_reply;
#define sz_sample_data_reply 32

An example structure for reply packet returning data in form of 2 CARD16 variables.
All reply packages must be at least 32 bytes.
You also have to define a macro for returning size of the structure as 'sz_<struct_name>'.
Server will use this macro to check package sizes (using macro REQUEST_SIZE_MATCH).
</pre>

Every X extension has a Dispatch() function, which works as a request-handler. When X-server receives a request package, it will check the major opcode. If major opcode belongs to some extension it calls extension's Dispatch routine. Dispatch checks the minor opcode of request and returns a pointer to appropriate function to call or BadRequest in error situation. If protocol requires a reply packet, function will send a reply packet.

===Function wrapping===

When adding and modifying functionality of normal DDX functions, extension has to wrap those functions. This means that extension will replace existing function with it's own version containing needed new functionality. X server calls all DDX functions through a function pointer and wrapping means switching of these pointers. Different extensions can wrap same functions, and depending on the order of extension initialization, they wrap each others functions. This will create a function chain. Wrapper function can call down to this function chain (it is recommended way, so that other extensions can do their work aswell unless you plan to replace larger part of the functionality but in this case you really have to know what you are doing).

to be continued ... will contain more examples etc. (please send comments to [mailto:tapani.palli@nokia.com] Tapani Palli)