Please login or register.

Login with username, password and session length
Advanced search  


This forum provides RSS feed. To query recent posts use this url. More...

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - sychron

Pages: [1]
Software and games / Google Sketchup 7 released
« on: November 21, 2008, 12:28:48 AM »
Google just released Sketchup 7, a tool merely for 3D drawing.

This tool is great to layout 2D backgrounds for the artists to work out or to create models for rendering. The free version does not support DXF and 3DS for export, but it supports collada, which can be read by some renderrers like maya and IMHO autodesk. The Pro version can export DXF and 3DS files.

This tool tries to use 2D techniques to model 3D. You don't have to fiddle around with meshes, nurbs etc (and you can't), instead you do everything by extruding 2D shapes. Have a look at the videos google provides on their site to grasp the concept. It's great for 3D noobs like me ;-)

Won't implement / "Always interactive"
« on: November 20, 2008, 04:06:07 PM »
Can you please add an "always interactive" property to GUI element definitions so theese elements stay clickable even if the game is set to noninteractive mode?

Feature requests, suggestions / Support for Collada
« on: November 18, 2008, 11:31:16 PM »
Something you should definitely add to the next engine version: Support for collada object exchange.
This is a file format built for collaborative 3D content creation, so if you can parse theese doms, the format and export hazzle for 3d stuff will should reduce.

collada is open source and encourages communities and majors to adopt the format. AFAIK some industry leaders already support it, for example Autodesk and Maya.

Google Sketchup can write it (and only collada in the free version), and Blender should know it, too.

Feature requests, suggestions / Progress indicator image?
« on: November 10, 2008, 11:39:49 AM »

would it be possible to use an image for the loading progress indicator?
This would enable indicators with rounded edges etc.

To display the image, there could be two modes: "stretch" and "reveal". "stretch" takes the image and stretches it according to the current percentage, "reveal" just reveals the image according to the percentege.
The artist should be responsible for fitting the progress indicator image into the progress indicator area of the loading screen ... it should just replace the colorfill.

So much for the basic request, while writing it, I got another idea:

Solution to some "problems" or wishes while loading could be a sprite progress indicator. This ist just a simple sprite, except it is NOT animated normally. Instead, you calculate the current frame based on the load percentage. so if the sprite has 100 frames, each percent will display another frame. if the sprite has just 10 frames, every 10 percent share one frame.  Artists should be aware that there is no guarantee that a frame is shown at all, for it might get skipped by fast loading progress.

This would make some special effects possible, ranging from switching loading screen images (as requested sometimes) to alternative loading indicators, perhaps a simulated console printing status messages.

From other threads I know that the loading image will only be updated from time to time when the indicator changes, so (ab)using the indicator itself to create theese effects could be a way to "enhance loading experience" without much engine reprogramming ;-)

Community bulletin board / I'm back ...
« on: November 02, 2008, 11:54:49 PM »
After a few months of circumstance-inflicted computer abstinence I finally made it back here ...  ::wave

Feature requests, suggestions / MIDI and MOD support made easy ...
« on: November 12, 2007, 11:58:43 PM »
I just discovered that the good old Timidity is continued as open source software called Timidity++.

Timidity is able to playback mod files using soundfonts or gravis patches for the instruments. This enables many designers to add their favored midi music into the game without rendering it to ogg first, to keep down the filesize.

There is an .dll version of it around on that page, using this may be an option.

(Tip if this is not an option: you can use Timidity++ to render midi files into ogg.)

Feature requests, suggestions / A52 PAssthrough
« on: October 29, 2007, 11:35:01 AM »

this is NOT a request for enhanced EAX Stuff ... Just a Question/Request for Theora Videos.

Can you Init something like VLC's enhanced waveout, enabling digital data to be decoded on the Soundcard or even enable a A52 Passthrough to external decoders (soundcard setup, not wme-stuff) ?

The only thing Wintermute must do for this is a) play back multichannel theoras and hand over A52 digital stream to the soundcard and b) NOT mix anything in the streams, for it is digital data.

This would enable 5.1 or even 7.1 mixes for the cutscenes and modern sound systems (and, using the entity.playtheora on an invisible entity, surround sound effects somewhere inside the game ... ;-) )

Game announcements / The White Chamber re-released with more languages
« on: October 21, 2007, 12:42:42 AM »
Just saw the White Chamber re-release beeing online, called the "1.7 definitive edition", featuring some minor bugfixes and much more languages:
9 subtitle languages (English, Czech, French, German, Greek, Italian, Polish, Portugese and Russian) and 2 voiceover languages (german and english)

Just have a look at ;-)

Fixed / Little Bug in SceneEdit
« on: September 30, 2007, 04:43:05 AM »

we found a strange "mini-bug" in the path name handling in sceneedit. We discovered it in Jynx Package Demo Project recently.

Given this directory structure:


data contains the usual stuff, LocationPak and Data are the same level.
LocationPak ist promoted to a package.
All Paths in NextLocation.scene are set like "LocationPak/NextLocation/background.bmp"

You cannot fix this in sceneedit. When reselecting the background.bmp, it doesn't recognize the package and leaves the "LocationPak", which IS part of the path, still in.

The game runs happily in the Project Manager, but the compiled game does not show the background.bmp. It does show the scene, so if you manage to click right, you can get back out of the scene again.

Fixing the path names in NextLocation.scene by hand in a text editor restores the usual behaviour, that is: after doing this, projectman recognizes the new paths as right and does not add the LocationPak again.

I think this may be because if you do not change the filename, SceneEdit does nothing to the stored filename ... for special cases like this, the path should maybe always checked for packages and cut accordingly.

Done / #region and #endregion in wintermute script?
« on: September 29, 2007, 02:47:15 PM »

could you make the script engine(s) ignore #region and #endregion directives, so that one could use advanced code structure and collapsing features some IDE's offer?

Doesn't make much sense for short scripts, but it can bring some light into the big ones ;-)

And ... I think making an interpreter/compiler ignore something isn't less work than making him recognize something ;-)

One more feature request to optimize localisation:

For now, you can switch string tables ingame, and your can switch the speech directories.

If you want to switch localized graphics, you would have to go to every script and definition involved and add a path variable for the graphics.
This approach has two major drawbacks:

First. It is unintuitive. You have to figure out where SceneEdit and the other tools store the filenames, add the variable, test it etc.

Second. You may have to change scripts during localisation. This should be avoided, for changing the scripts should start a new testing cycle, which costs valuable production time.

My idea is a quite simple Approach getting rid of all this at once.

Implement a method Game.addLocalDir(string dir) which functions similar to Game.addSpeechDir(). Implement all its co-functions as well.
You can also define a default local dir, called "local", which defaults to the main package.

Then modify your graphics loader routines to look for filenames without paths not only in the current directory, but in the assigned local dir(s) as well.

Result: runtime-switchable Graphics/Sound/Sprite/Anything-You-Want directories with nearly no programming efford on the project builders side.

The Game designers can move any local-specific content such as graphic text, wall graffities or even traffic signs to this folder instead of keeping it in the scene to make it localisable.

The localisers just have to work over the graphics in this folder, leaving the rest of the game untouched.

Effect: Noone has to touch the script code, and there are no missed localised graphics, for noone has to search the project for specific graphic.

Perhaps you can also modify the Project Properties Sidebar to show an entry for this default local dir. (maybe even for the default speech dir)

----- NO SUGGESTION --------------------------------------------------
It may be an idea to use the local folder to "override" normal scene graphics, but this approach would contradict the gathering of stuff to be localised in one folder. And it is prone to produce errors hard to locate, for you have to know where in your project the graphic comes from. I Would not use this approach.
----- NO SUGGESTION --------------------------------------------------

Done / Suggestion: Subtitle Handling
« on: September 14, 2007, 09:02:50 PM »
To make localisation of cutscenes easier, it would be great if you would to add two features to the Theora Playback:

a) subtitle string expansion

If subtitles use the talk format ("/CUTSCENE_01_01/Hello, I'm a subtitle"), the string gets expanded using the active string table.
This bundles all translations to a single file,, which makes handling easier for translation management.
And, multilingual games can change the, but they cannot change the .sub files, so the subtitles in theora would be in the original language even if another language is selected.

This leads to:

b) explicit subtitle file parameter

Please add a fourth parameter to PlayTheora(), "subtitle file". If this is not given, the default filename is used (for example, "theora.sub" for "theora.ogg")
This can be a standalone solution to the translation problem, not as elegant as a), but working.

If you combine a) and b), it is possible for the developers to have their translated and switch them at startup. If, and only if a language needs other cue points, another subtitle file can be selected, not changing any strings, but changing the cue points.
This adds more flexibility for developers using string tables in languages they do not understand themselves, for they cannot shorten the lines in this files. Well, they could, but ... they shouldn't ;-)

Done / WMEIntegrator does not recognize UEStudio
« on: August 24, 2007, 10:48:37 AM »
Hi  MNenomic,

first of all: your Integrator is a a great tool for Programmers, who are used to certain editors.

Well, this ist not a real "bug", just a little problem:
I bought Ultraedit's big brother, UEStudio. Since UEStudio works like an enhanced version of UltraEdit, the Integrator should not only look for UEdit32.exe, but for uestudio.exe as well, for adding WME support to the big brother, too.

Technical forum / item caption translation problem
« on: August 24, 2007, 03:39:56 AM »

I'm doing a translation for a game. This game uses different string tables for everything including the item captions, for example:

 CAPTION = "/ITEMIS0001/Axe"

Theese Strings are defined in each string table. The string table used is selected at startup in a language selection screen.
After language selection, the game takes every string from the new string table, exept for the item names, which still come from the original

I checked this -- changing the names in does affect the game, changing them in other languages does not.

The code for loading the new string table is:


So the LoadItems function should load the new item captions, but it doesn't.

How can I fix this? Or is this an engine bug?

Pages: [1]

Page created in 0.518 seconds with 21 queries.