Free irrlicht 0.04 software for linux

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.

The Irrlicht Engine is an open source high performance realtime 3D engine written and usable in C++ and also available for .NET languages.
Irrlicht Engine is completely cross-platform, using D3D, OpenGL and its own software renderer, and has all of the state-of-the-art features which can be found in commercial 3d engines.
Weve got a huge active community, and there are lots of projects in development that use the engine.
You can find enhancements for Irrlicht all over the web, like alternative terrain renderers, portal renderers, exporters, world layers, tutorials, editors, language bindings for java, perl, ruby, basic, python, lua, and so on. And best of all: Its completely free.
Main features:
- High performance realtime 3D rendering using Direct3D and OpenGL [more]
- Platform independent. Runs on Windows95, 98, NT, 2000, XP and Linux.[more]
- Huge built-in and extensible material library with vertex and pixel shader support [more].
- Seamless indoor and outdoor mixing through highly customizeable scene mangagment. [more]
- Character animation system with skeletal and morph target animation. [more]
- Particle effects, billboards, light maps, environment mapping, stencil buffer shadows, and lots of other special effects. [more]
- .NET language binding which makes the engine available to all .NET languages like C#, VisualBasic, and Delphi.NET.
- Platform and driver independent fast software renderer included. It features z-buffer, gouraud shading, alpha-blending and transparency, fast 2D drawing.
- Powerful, customizeable and easy to use 2D GUI System with Buttons, Lists, Edit boxes, ..
- 2D drawing functions like alpha blending, color key based blitting, font drawing and mixing 3D with 2D graphics.
- Clean, easy to understand and well documentated API with lots of examples and tutorials.
- Written in pure C++ and totally object orientated.
- Direct import of common mesh file formats: Maya (.obj), 3DStudio (.3ds), COLLADA (.dae), DeleD (.dmf), Milkshape (.ms3d), Quake 3 levels (.bsp), Quake2 models (.md2), Microsoft DirectX (.X)... [more]
- Direct import of Textures: Windows Bitmap (.bmp), Portable Network Graphics (.png), Adobe Photoshop (.psd), JPEG File Interchange Format (.jpg), Truevision Targa (.tga), ZSoft Painbrush (.pcx)... [more]
- Fast and easy collision detection and response.
- Optimized fast 3D math and container template libraries.
- Directly reading from (compressed) archives. (.zip)
- Integrated fast XML parser.
- Unicode support for easy localisation.
- Works with Microsofts VisualStudio6.0?, VisualStudio.NET 7.0-8.0?, Metrowerks Codewarrior, and Bloodshed Dev-C++ with g++3.2-4.0.
- The engine is open source and totally free. You can debug it, fix bugs and even change things you do not like. And you do not have to publish your changes: The engine is licensed under the zlib licence, not the GPL or the LGPL.

Preppi is a simple graphical EPP client for Unix and Linux systems. Preppi is written in Perl and makes use of the GTK+ and GNOME bindings for Perl, and our own EPP libraries.

SWISH::HiLiter is a simple Perl interface to SWISH::API and HTML::HiLiter.

SYNOPSIS

my $query = "foo OR bar";

require SWISH::API;
my $swish = SWISH::API->new( my_index );

require SWISH::HiLiter;

# create an object

my $hiliter = SWISH::HiLiter->new( swish=>$swish, query=>$query );

# search and display highlighted results

my $results = $swish->Query( $query );

while ( my $result = $results->NextResult ) {

my $path = $result->Property( "swishdocpath" );
my $title = $hiliter->light(
$result->Property( "swishtitle" )
);
my $snip = $hiliter->light(
$hiliter->snip(
$result->Property( "swishdescription" )
)
);
my $rank = $result->Property( "swishrank" );
my $file = $result->Property( "swishreccount" );

print join("n", $file, $path, $title, $rank, $snip );

}

SWISH::HiLiter is a simple interface to the HTML::HiLiter module. It is designed to work specifically with the SWISH::API module for searching SWISH indexes and displaying snippets of highlighted text from the stored SWISH properties.

SWISH::HiLiter is NOT a drop-in replacement for the highlighting modules that come with the SWISH-E distribution. Instead, it is intended to be used when programming with SWISH::API.

Inline::Lua is a Perl extension for embedding Lua scripts into Perl code.

SYNOPSIS

use Inline Lua;
print "The answer to life, the universe and everything is ", answer(6, 7), "n";

__END__
__Lua__
function answer (a, b)
return a*b
end

Inline::Lua allows you to write functions in Lua. Those of you who are not yet familiar with Lua should have a cursory glance at http://www.lua.org/ to get a taste of this language. In short:

Lua was designed to be embedded into other applications and not so much as a language on its own. However, despite its small set of language features, it is an extremely powerful and expressive language. Its strong areas are an elegant and yet concise syntax, good overall performance and a beautiful implementation of some concepts from the world of functional programming.

B::LintSubs is a Perl compiler backend to check sub linkage.

SYNOPSIS

perl -MO=LintSubs [FILE] [-e PROGRAM]

When using use strict, subroutine names are not checked at the callsite; this makes the following a perfectly valid program at compiletime, that only blows up at runtime

use strict;
foobar();

When using the B::LintSubs checker instead, this is detected:

$ perl -MO=LintSubs -e use strict;
foobar();
Undefined subroutine foobar called at -e line 2

Imported functions from other modules are of course detected:

$ perl -MO=LintSubs -e use strict;
use List::Util qw( max );
$_ = max( 1, 2, 3 )
-e syntax OK

In order to handle situations where external code is conditionally referenced at runtime, any fully-qualified references to other functions are printed with a warning, but not considered fatal. The programmer is assumed to Know What He Is Doing in this case:

$ perl -MO=LintSubs -e if( 1 ) { require Data::Dumper;
Data::Dumper::Dump( "Hello" ) }

Unable to check call to Data::Dumper::Dump in foreign package at -e line 1

-e syntax OK

Kwiki::Yahoo is a Wafl Phrase for including RSS feeds in a Kwiki Page.

{yahoo-doc < query > |args}

Kwiki::Yahoo uses the Yahoo::Search module to use the Yahoo API for web, video, image, news, local, spelling, and related searches.

This is a simple proof of concept that probably has many roads for improvement. A lot of flexibility would be gained by accessing the Results directly rather than using the generated HTML.

DEMONSTRATION

Theres a demonstration, with some explanatory text at http://www.burningchrome.com/wiki/index.cgi?KwikiYahoo

RenderMan is a RenderMan binding as a Perl 5.6 module.

SYNOPSIS

use RenderMan;

This RenderMan module implements a Perl 5.6 binding for the BMRT client library (libribout). It fully supports the client library. Therefore, this module has the following limitations: Error Handling callbacks are not implemented, Filter function callbacks are not implemented, and the TransformPoints function does nothing. Also, Blobby is not yet supported by BMRT 2.5.0.8.

The full RenderMan specification is way beyond the scope of this man page. Please refer to the documents below for more information about RenderMan. The Perl binding is identical to the C binding except a few minor points: All "parameterlist"s are passed as a reference to a hash (i.e. %params).

Anywhere that a functions arguments can be terminated by RI_NULL, you can simply choose to not include that RI_NULL argument, which is incredibly nice.
All array, matrix, and basis types are single-dimension arrays of doubles in this Perl binding. The order for 2-dimension types is first-row followed by second-row, etc.

You will typically want to run your RenderMan Perl script and pipe the results into any RenderMan-compliant renderer, such as "rgl", "rendribv", or "rendrib", which all come with the excellent BMRT backage by Larry Gritz.

If using the WinNT version of BMRT, you can specify a filename, "rgl" or "rendrib" as the argument to Begin(); and the output will be sent to a file or automatically piped to "rgl" or "rendrib" since the piping mechanism (and general functionality) of WinNTs command line parser is, uh, limited.