Sonic Action is the first SRB2 Town related game. Anywhere, instead of the standard story that you read everyday, this time the viewpoint is more orientated to Sonic.

But Im not saying that well not appear in the game, nothing of that kind. Im planning to get we appear in the game. So dont ask me about that.

The engine of Sonic Action is incredibly good: you can think that Sega made it. Thats because six months of developing can do wonderful things. And this is not developed using programs such as Game Maker, MFF or TGF, normally used for make fangames, its programmed in C++ with Allegro.

And is more: Tails92 will port the different versions of Sonic Action to other OS like Linux or FreeBSD (Sonic Action is orignally programmed for Windows).

The story is very original, as far as the fangames stories that I know.. But you can get more info in the Sonic Action sections (scroll down the menu).

Whats New in This Release:

· New levels: Badnik City and Eggman Base (the last is incomplete).

sonic-snap is a project with you can use your sn9c102 based camera under linux. You need to get the kernel driver at linux-projects.org.

sonic-snap has some distinguishing features which include histogram analysis, normalization, ppm captures and realtime mpeg encoding.

sonic-snap was tested with this really cute little webcam, called Sweex Minicam. The Sweex Minicam is really cheap (10 to 15 euros), and has the size of a 50 eurocent coin. Due to its size, it should be a suitable robotics camera.

The sonic-snap application will most likely work with any webcam, based on the sn9c102 chip from Sonix. (Sweex 100k and Genius NB work as well). If you get it to work on your cam, why not send me a snapshot? You can reach me at bram at sara.nl

Fan/Temp Karamba Theme is a simple Karamba theme that shows:

· CPU Temp
· Fan Speed
· Chassis Temp
· HDD Temp (max 3 hdds)

I hope you like it like me.

Feedback is welcome.

No liability is assumed for damages to hard and software !!

Sonic Visualiser is an application for viewing and analysing the contents of music audio files.

The aim of Sonic Visualiser is to be the program you reach for when you find a musical recording you want to study rather than simply hear.

As well as a number of features designed to make exploring audio data as revealing and fun as possible, Sonic Visualiser also has powerful annotation capabilities to help you to describe what you find, and the ability to run automated annotation and analysis plugins in the new Vamp analysis plugin format.

We hope Sonic Visualiser will be of particular interest to musicologists, archivists, signal-processing researchers and anyone else looking for a friendly way to take a look at what lies inside the audio file.

Here are some key features of "Sonic Visualiser":

· Load audio files in WAV, Ogg and MP3 formats, and view their waveforms.
· Look at audio visualisations such as spectrogram views, with interactive adjustment of display parameters.
· Annotate audio data by adding labelled time points and defining segments, point values and curves.
· Overlay annotations on top of one another with aligned scales, and overlay annotations on top of waveform or spectrogram views.
· View the same data at multiple time resolutions simultaneously (for close-up and overview).
· Run feature-extraction plugins to calculate annotations automatically, using algorithms such as beat trackers, pitch detectors and so on.
· Import annotation layers from various text file formats.
· Import note data from MIDI files, view it alongside other frequency scales, and play it with the original audio.
· Play back the audio plus synthesised annotations, taking care to synchronise playback with display.
· Select areas of interest, optionally snapping to nearby feature locations, and audition individual and comparative selections in seamless loops.
· Time-stretch playback, slowing it down to as little as 10% of the original speed while retaining a synchronised display.
· Export audio regions and annotation layers to external files.

The design goals for Sonic Visualiser are:
· To provide the best available core waveform and spectrogram audio visualisations for use with substantial files of music audio data.
· To facilitate ready comparisons between different kinds of data, for example by making it easy to overlay one set of data on another, or display the same data in more than one way at the same time.
· To be straightforward. The user interface should be simpler to learn and to explain than the internal data structures. In this respect, Sonic Visualiser aims to resemble a consumer audio application.
· To be responsive, slick, and enjoyable. Even if you have to wait for your results to be calculated, you should be able to do something else with the audio data while you wait. Sonic Visualiser is pervasively multithreaded, loves multiprocessor and multicore systems, and can make good use of fast processors with plenty of memory.
· To handle large data sets. The work Sonic Visualiser does is intrinsically processor-hungry and (often) memory-hungry, but the aim is to allow you to work with long audio files on machines with modest CPU and memory where reasonable. (Disk space is another matter. Sonic Visualiser eats that.)

Sonic-Rainbow is a graphical multi-media player for Linux systems. It provides an Easy to Use complete GUI interface that will run on most Linux based Window Managers such as KDE, ICEWM, XFCE, GNOME etc....

[CONFIGURE=1]
./configure
make
make install

Here are some key features of "SonicRainbow":

· CD Player
· CD AutoPlay
· Ogg File Player
· MP3 File Player
· WAV File Player
· MP3, Ogg, Wav fast foward and rewind capability for playing files
· Sound Mixer
· m3u (xmms) playlist compatible
· Track Shuffle for Playlists
· Drag and Drop adding of Tracks
· DVD Player
· VCD Player
· Video File Player
· Displays MP3 Track and artist info
· PlayList Editor
· Default Playlist
· MP3 file Tag Editor
· Ogg file Tag Editor
· Autoplay of Default Playlist
· HTTP CD Title/Track Lookup
· Local HTTP CD Database
· Rip CDs to Ogg Format Files
· Rip CDs to MP3 Format Files
· Rip CDs to Wav Format Files
· HTTP Lookup to tag Ogg Files
· Volume control
· FM Radio Player if Card installed
· FM Radio Record
· GPL License

Games::Goban is a board for playing go, renju, othello, etc.

SYNOPSIS

use Games::Goban;
my $board = new Games::Goban (
size => 19,
game => "go",
white => "Seigen, Go",
black => "Minoru, Kitani",
referee => &Games::Goban::Rules::Go,
);

$board->move("pd"); $board->move("dd");
print $board->as_sgf;

This is a generic module for handling goban-based board games. Theoretically, it can be used to handle many of the other games which can use Smart Game Format (SGF) but I want to keep it reasonably restricted in order to keep it simple.

Games::3D is a package containing an object system for (not only) 3D games.

SYNOPSIS

use Games::3D::World;

my $world = Games::3D::World->new();

$world->save_to_file( $filename );

my $loaded = Games::3D::world->load_from_file( $filename );

my $thing1 = $world->add ( Games::3D::Thingy->new( ... ) );
my $thing2 = $world->add ( Games::3D::Thingy->new( ... ) );

$world->link($thing1, $thing2);

Games::3D::World provides you with a container class that will contain every object in your game object system. This are primarily objects that have states, change these states and need to announce the states to other objects.

The Games::3D::World container also enables you to save and restore snapshots of your objects system.

Basic things that you object system contains are derived from a class called Games::3D::Thingy. These can represent physical objects (buttons, levers, doors, lights etc) as well as virtual objects (trigger, sensors, links, markers, sound sources etc).

You can link Thingys together, either directly or via Games::3D::Links. The links have some more features than direct linking, which are explained below.

This package also provides you with Games::3D::Sensor, a class for objects that sense state changes and act upon them. Or not, depending on the sensor. Sensors are primarily used to watch for certain conditions and then act when they are met. Examples are the death of an object, values that go below a certain threshold etc.

State changes are transported in the object system with signals.

Games::Othello is a Perl extension for modelling a game of Othello.

SYNOPSIS

use Games::Othello;

my $game = Games::Othello->new();

while( !game->over ) {
printf "It is presently %ss move",
($game->whos_move eq b) ? black, white;
my @possible_moves = values $game->possible_moves();

if ( ! @possible_moves ) {
print "You have no moves available, you must pass.
$game->pass_to_opponent;
} else {
foreach ( my $move ) @possible_moves ) {
printf
"You will take %d of your opponents chips if you place your chip on %d,%d",
scalar @{ $move->{chips} }, $move->{x}, $move->{y};
}
my ($locx, $locy) = get_move();
my $flipped = $game->place_chip( $locx, $locy );
}

my $layout = $game->chip_layout();
foreach my $row ( @$layout ) {
foreach my $pos ( @$row ) {
printf %3s,
($pos eq b) ? B # Black occupied square.
: ($pos eq w) ? W # White occupied square.
: # Un-occupied square.
}
print "nn";
}
}
my ($black_score, $white_score) = $game->score;

Games::GuessWord is a guess the letters in a word (ie Hangman).

SYNOPSIS

use Games::GuessWord;

my $g = Games::GuessWord->new(file => "/path/to/wordlist");
print "Score: " . $g->score . "n";
print "Chances: " . $g->chances . "n";
print "Answer: " . $g->answer . "n";
my @guesses = $g->guesses;
$g->guess("t");
# ...
if ($g->won) {
print "You won!n";
$g->new_word;
}

This module is a simple wrapper around a word guessing game. You have to guess the word by guessing letters in the word, and is otherwise known as Hangman.

Games::Alak is a simple game-tree implementation of a gomoku-like game.

SYNOPSIS

% perl -MGames::Alak -e Games::Alak::play
...Or just run Alak.pm as if it were a program...
...Program responds with output, and a prompt:

Lookahead set to 3. I am X, you are O.
Enter h for help
X moves from 1 to 5, yielding .xxxx..oooo
alak>
...and now you enter the commands to play.

This module implements a simple game-tree system for the computer to play against the user in a game of Alak. You can just play the game for fun; or you can use this module as a starting point for understanding game trees (and implementing smarter strategy -- the modules current logic is fairly simple-minded), particularly after reading my Perl Journal #18 article on trees, which discusses this modules implementation of game trees as an example of general tree-shaped data structures.

Games::GoogleWhack is a Perl module that finds, verifies, and/or submits GoogleWhacks.

SYNOPSIS

use Games::GoogleWhack;

my $googlewhack = Games::GoogleWhack->new();
my $is_googlewhack = $googlewhack->is_googlewhack(foo, bar);

die $googlewhack->errstr if $googlewhack->errstr;

print "Youve found a GoogleWhack! Congrats! :-)n" if $is_googlewhack;

NOTE: THIS MODULE MAKES EXTERNAL CONNECTIONS TO GOOGLE.COM, DICTIONARY.COM, and/or GOOGLEWHACK.COM. IT IS THE USERS RESPONSIBILITY TO ENSURE THAT THEY ARE IN COMPLIANCE WITH ANY RESPECTIVE TERMS OF USE CLAUSES FOR SITE USAGE. THE AUTHOR ASSUMES NO LIABILITY FOR THE USE OR MISUSE OF THIS MODULE.

Games::Lineofsight is a Perl module.

Many games (Ultima, Nethack) use two-dimensional maps that consists of the squares of the same size in a grid. Line-of-sight means that some of the squares may represent the items that block the vision of the player from seeing squares behind them. With this module you can add that behaviour to your games.

SYNOPSIS

use Games::Lineofsight qw(lineofsight);

# The map has to be a two-dimensional array. Each member (or "cell") of the array represents one
# square in the map. In this example each cell contains only one character but you can put strings
# to the cells also - practical with the graphical games.

my @map=(
[split //,"..:..::........."], # this is the map
[split //,".......:..X....:"], # . and : represents the ground
[split //,"...X.....:...:.."], # X is the barrier for the sight
[split //,".:...:....:....."],
[split //,"..X....:..X....."],
[split //,"..X..:........:."],
);

my($width)=scalar(@{@map[0]}); # the width of the map
my($height)=scalar(@map); # the height of the map
my($barrier_str)="X"; # string that represents the barrier
my($hidden_str)="*"; # string that represents a cell behind a barrier
my($man_str)="@"; # string that represents the viewer
my($man_x,$man_y)=(7,3); # view point coordinates - the player is here

# recreate the map with line-of-sight

@map=lineofsight(@map,$man_x,$man_y,$barrier_str,$hidden_str);

# draw the map

for(my $i=0;$i < $height;$i++){
for(my $j=0;$j < $width;$j++){
print $man_x == $j && $man_y == $i ? $man_str : $map[$i][$j];
}
print "n";
}
or
# The lineofsight() calls get_barriers() and analyze_map() each time its called. If the viewer
# moves around the map a lot, its much faster to read in the barriers once and call only
# analyze_map() each time before drawing it.

use Games::Lineofsight qw(get_barriers analyze_map);

# The map has to be a two-dimensional array. Each member (or "cell") of the array represents one
# square in the map. In this example each cell contains only one character but you can put strings
# to the cells also - practical with the graphical games.

my @map=(
[split //,"..:..::........."], # this is the map
[split //,".......:..X....:"], # . and : represents the ground
[split //,"...X.....:...:.."], # X is the barrier for the sight
[split //,".:...:....:....."],
[split //,"..X....:..X....."],
[split //,"..X..:........:."],
);

my($width)=scalar(@{@map[0]}); # the width of the map
my($height)=scalar(@map); # the height of the map
my($barrier_str)="X"; # string that represents the barrier
my($hidden_str)="*"; # string that represents a cell behind a barrier
my($man_str)="@"; # string that represents the viewer
my($man_x,$man_y)=(7,3); # view point coordinates - the player is here

# get_barriers() returns a hash with the information about barriers in the map. In this example we
# declare the "X"-character as a barrier. As well you can declare it to be a string in the graphical
# games; for example "barrier.jpg".

my %barrier=get_barriers($width,$height,@map,$barrier_str);

# analyze_map() returns an array containing the original map looked from the view point. The cells
# behind the barriers are replaced with given strings. The barriers should be told to the subroutine
# calling first get_barriers()-subroutine as we already did.

my @map2=analyze_map($width,$height,@map,%barrier,$man_x,$man_y,$hidden_str);

#draw the map with the lineofsight

print "nOriginal map:n";

draw($width,$height,$man_x,$man_y,@map2,$man_str);

# move the viewer two squares right

$man_x+=2;

# refresh the map

my @map2=analyze_map($width,$height,@map,%barrier,$man_x,$man_y,$hidden_str);

#draw the map again

print "nViewer has moved:n";

draw($width,$height,$man_x,$man_y,@map2,$man_str);

sub draw{
my($width,$height,$man_x,$man_y,$map,$man_str)=@_;
for(my $i=0;$i < $height;$i++){
for(my $j=0;$j < $width;$j++){
print $man_x == $j && $man_y == $i ? $man_str : $$map[$i][$j];
}
print "n";
}

}

Games::PerlWar is a Perl variant of the classic Corewar game.

This is a sparring program, similar to the programmed reality of the Matrix.
It has the same basic rules, rules like gravity. What you must learn is that
these rules are no different than the rules of a computer system. Some of
them can be bent, others can be broken. - Morpheus

PerlWar is inspired by the classic http://www.corewar.info/|Corewar game. In this game, players pit snippets of Perl code (called agents) against each other in order to gain control of the vicious virtual battlefield known as... the Array.

GAME PARAMETERS

Size of the Array

The number of cells that the Array possesses. Each cell can hold one agent.

Agent Maximal Size

The maximal length, in characters, of an agent. If an agent is or becomes larger than this limit, it automatically segfaults upon execution.

Game Maximal Number of Iterations

The maximal number of rounds that can be played before a game is declared over.

Games::Irrlicht is a Perl module that use the Irrlicht 3D Engine in Perl.

SYNOPSIS

package MyGame;
use strict;

use base Games::Irrlicht;

use Games::Irrlicht::Constants; get EDT_SOFTWARE etc

# override methods:

The Why

When building a game or screensaver displaying some continously running animation, a couple of basics need to be done to get a smooth animation and to care of copying with varying speeds of the system. Ideally, the animation displayed should be always the same, no matter how fast the system is.

This not only includes different systems (a PS/2 for instance would be slower than a 3 Ghz PC system), but also changes in the speed of the system over time, for instance when a background process uses some CPU time or the complexity of the scene changes.

In many old (especial DOS) games, like the famous Wing Commander series, the animation would be drawn simple as fast as the system could, meaning that if you would try to play such a game on a modern machine it we end before you had the chance to click a button, simple because it wizzes a couple 10,000 frames per second past your screen.

While it is quite simple to restrict the maximum framerate possible, care must be taken to not just "burn" surplus CPU cycles. Instead the application should free the CPU whenever possible and give other applications/thread a chance to run. This is especially important for low-priority applications like screensavers.

Games::Irrlicht makes this possible for you without you needing to worry about how this is done. It will restrict the frame rate to a possible maximum and tries to achive the average framerate as close as possible to this maximum.

Games::Irrlicht also monitors the average framerate and gives you access to this value, so that you can, for instance, adjust the scene complexity based on the current framerate. You can access the current framerate, averaged over the last second (1000 ms) by calling current_fps.

Frame-rate Independend Clock

Now that our application is drawing frames (via the method draw_frame, which you should override in a subclass), we need a method to decouple the animation speed from the framerate.
If we would simple put put an animation step every frame, we would get some sort of Death of the Fast Machine" effect ala Wing Commander. E.g. if the system manages only 10 FPS, the animation would be slower than when we do 60 FPS.

To achive this, SDL::App::FPS features a clock, which runs independed of the current frame rate (and actually, independend of the systems clock, but more on this in the next section).
You can access it via a call to current_time, and it will return the ticks e.g. the number of milliseconds elapsed since the start of the application.

To effectively decouple animation speed from FPS, get at each frame the current time, then move all objects (or animation sequences) according to their speed and display them at the location that matches the time at the start of the frame. See examples/ for an example on how to do this.

Note that it is better to draw all objects according to the time at the start of the frame, and not according to the time when you draw a particular object. Or in other words, treat the time like it is standing still when drawing a complete frame. Thus each frame becomes a snapshot in time, and you dont get nasty sideeffects like one object beeing always "behind" the others just because it gets drawn earlier.

Time Warp

Now that we have a constant animation speed independend from framerate or system speed, lets have some fun.

Since all our animation steps are coupled to the current time, we can play tricks with the current time.

The function time_warp lets you access a time warp factor. The default is 1.0, but you can set it to any value you like. If you set it, for instance to 0.5, the time will pass only half as fast as it used to be. This means instant slow motion! And when you really based all your animation on the current time, as you should, then it will really slow down your entire game to a crawl.

Likewise a time warp of 2 lets the time pass twice as fast. There are virtually no restrictions to the time warp.

For instance, a time warp greater than one lets the player pass boring moments in a game, for instance when you need to wait for certain events in a strategy game, like your factory beeing completed.

Try to press the left (fast forward), right (slow motion) and middle (normal) mousebuttons in the example application and watch the effect.

If you are very bored, press the b key and see that even negative time warps are possible...

Ramping Time Warp

Now, setting the time war to factor of N is nice, but sometimes you want to make dramatic effects, like slowly freezing the time into ultra slow motion or speeding it up again.

For this, ramp_time_warp can be used. You give it a time warp factor you want to reach, and a time (based on real time, not the warped, but you can of course change this). Over the course of the time you specified, the time warp factor will be adapted until it reaches the new value. This means it is possible to slowly speeding up or down.

You can also check whether the time warp is constant or currently ramping by using time_is_ramping. When a ramp is in effect, call ramp_time_warp without arguments to get the current parameters. See below for details.

The example application uses the ramping effect instead instant time warp.

Event handlers

This section describes events as external events that typically happen due to user intervention.
Such events are keypresses, mouse movement, mouse button presses, or just the flipping of the power switch. Of course the last event cannot be handled in a sane way by our framework.

All the events are checked and handled by Games::Irrlicht automatically. The event QUIT (which denotes that the application should shut down) is also carried out automatically. If you want to do some tidying up when this happens, override the method quit_handler.

The event checking and handling is done at the start of each frame. This means no event will happen while you draw the current frame. Well, it will happen, but the action caused by that event will delayed until the next frame starts. This simplifies the frame drawing routine tremendously, since you know that your world will be static until the next frame.

Games::Go::Dg2TkPs is a Perl extension to convert Games::Go::Diagrams to Postscript.

SYNOPSIS

use Games::Go::Dg2TkPs
my $dg2ps = B