latin-1 is a macintosh based encoding, construct probably uses UTF-8 if it supports unicode

I suggested UTF8 for the specific purpose that ASCII is by far the most commonly used encoding or character set being used for text blitting purposes, and therefore it would defeat the purpose of a text blitter to force double-byte unicode. UTF-8 solves this by being backwards compatible with ASCII.

It shouldn't be that much harder to implement UTF-8 than it would be to implement UTF-16. A few bits in each byte of UTF-8 are reserved for character control which would allow you to properly map them to an extended graphical glyph set should you choose, which is what we'd want for input that would require (for example) displaying Japanese or another language with a non-roman character set. See here for details: http://en.wikipedia.org/wiki/UTF-8#Description

Hi again, thanks for listening to my suggestions :3

What I meant by an EOF character is basically inside a text file a way to signify "this is the end of a single block of text". For example, in an RPG when you do have control characters to prompt for the next string in a block, the "EOF" control character signifies not only another prompt, but that the string has terminated and the text window can be closed. You would want it to be separate from a prompt control character because it could be used to tokenize strings into blocks of text when parsing it in. That way, each block of text can be iterated through in a manner that doesn't require every string to be in a "flat space" in the file. Let me try a visual example.

What the heck are you doing?

Get out of here!

I said, get lost.

Now in our text file with "EOF" control characters, those characters would be used to separate block1 from block2 without having to have a flat space of 3 strings, and would be easier to parse and read/write inside a text editor. It doesn't have to be in some weird INI style format, it could be as simple as an escape code (like "\n" for newline could be analogous to "\p" to pause for input, and "\b" to indicate the end of a block of text), or more symbolic like a pipe ("|"). These are just some ideas I'm tossing out there to make formatting the string for various applications and purposes easier.

Also, if you think importing straight from a plaintext file is too easy for spoilers, you could give people a generic rot-13 string manipulation function or something like that which could be used before passing that onto the object

(A pleasant side-effect of this would be that we could also send unencrypted strings through rot13() from within construct and export our text the same way using a standard text object)

Hi!

Awesome work with this object, I'm pretty excited by it. If there were features I'd request, it would be that we can have functions to manipulate any character in the character array by index, as well as the "for each". This way, we can use the index value as an offset for certain effects. I'd like to be able to sinescroll the characters, but also maybe adjust their width/height/rotation too. I imagine this could mean that every character in the array could have a subproperty for x/y/width/height/rotation which could be accessed/stored in the object, unless you think that's too feature specific or memory intensive or something.

For a wishlist feature, it would be cool to have UTF-8 support, so we can for example have a separate character set for another language, or special symbols in-game. Control characters would be nice, too, such as to force newline, print one character over another, prompt for the next block of text and display a symbol (think RPG dialog boxes), or signify EOF.

I agree with others that in the future a tile blitter would be really neat (especially for making tile engines with the data and graphics separate, such as for changing seasons or time of day; or "layered" top-down engines which have different collision maps depending on the z height), but that would widen the scope for an object like this too much, especially when there are features specific to text blitting and features specific to tile blitting.

Anyway, here's where I get all my graphical fonts: http://www.algonet.se/~guld1/freefont.htm

EDIT: Also since I'm new to construct, I don't know if this would be possible, but are you able to use the SDK to clip a layer using your graphical font as a mask? If that were possible, we could make really cool "paint behind" effects, such as fake "copper", palette shifting backgrounds, stuff like that.

breakthrough

http://sharebee.com/bc8e1f08

It works!!!!! This uses python's standard wave library to output a mod file to wave. With proper access to a Construct sound buffer, the output could easily be routed to our games as well

However, I don't know why, but the writing function is pretty slow! It probably has to do with all the appending of sample_data in the read looping function. When the file's played in real-time, it probably won't be much of a problem. However, please give this script 20-30 seconds to process a 3-5 minute song before the wave file is written.

I guess I can say now this is my first functional Python program, I hope it is helpful to anyone here �3

hmm, the work is still incomplete; it apparently relies on some types from sndfile.h, which I haven't been able to convert to python using gccxml yet due to errors. I was informed of this on another forum, so I guess more research is necessary before this can be made useful just yet...

oh, for anyone who wants to help, it might be of assistance to post the corresponding C++ header file, which is much much much better commented:

modplug.h

/*
 * This source code is public domain.
 *
 * Authors: Kenton Varda <
<>mpf@gauge3d.org> (C interface wrapper)
 */

#ifndef MODPLUG_H__INCLUDED
#define MODPLUG_H__INCLUDED

#ifdef __cplusplus
extern "C" {
#endif

struct _ModPlugFile;
typedef struct _ModPlugFile ModPlugFile;

/* Load a mod file.  [data] should point to a block of memory containing the complete
 * file, and [size] should be the size of that block.
 * Return the loaded mod file on success, or NULL on failure. */
ModPlugFile* ModPlug_Load(const void* data, int size);
/* Unload a mod file. */
void ModPlug_Unload(ModPlugFile* file);

/* Read sample data into the buffer.  Returns the number of bytes read.  If the end
 * of the mod has been reached, zero is returned. */
int  ModPlug_Read(ModPlugFile* file, void* buffer, int size);

/* Get the name of the mod.  The returned buffer is stored within the ModPlugFile
 * structure and will remain valid until you unload the file. */
const char* ModPlug_GetName(ModPlugFile* file);

/* Get the length of the mod, in milliseconds.  Note that this result is not always
 * accurate, especially in the case of mods with loops. */
int ModPlug_GetLength(ModPlugFile* file);

/* Seek to a particular position in the song.  Note that seeking and MODs don't mix very
 * well.  Some mods will be missing instruments for a short time after a seek, as ModPlug
 * does not scan the sequence backwards to find out which instruments were supposed to be
 * playing at that time.  (Doing so would be difficult and not very reliable.)  Also,
 * note that seeking is not very exact in some mods -- especially those for which
 * ModPlug_GetLength() does not report the full length. */
void ModPlug_Seek(ModPlugFile* file, int millisecond);

enum _ModPlug_Flags
{
	MODPLUG_ENABLE_OVERSAMPLING     = 1 << 0,  /* Enable oversampling (*highly* recommended) */
	MODPLUG_ENABLE_NOISE_REDUCTION  = 1 << 1,  /* Enable noise reduction */
	MODPLUG_ENABLE_REVERB           = 1 << 2,  /* Enable reverb */
	MODPLUG_ENABLE_MEGABASS         = 1 << 3,  /* Enable megabass */
	MODPLUG_ENABLE_SURROUND         = 1 << 4   /* Enable surround sound. */
};

enum _ModPlug_ResamplingMode
{
	MODPLUG_RESAMPLE_NEAREST = 0,  /* No interpolation (very fast, extremely bad sound quality) */
	MODPLUG_RESAMPLE_LINEAR  = 1,  /* Linear interpolation (fast, good quality) */
	MODPLUG_RESAMPLE_SPLINE  = 2,  /* Cubic spline interpolation (high quality) */
	MODPLUG_RESAMPLE_FIR     = 3   /* 8-tap fir filter (extremely high quality) */
};

typedef struct _ModPlug_Settings
{
	int mFlags;  /* One or more of the MODPLUG_ENABLE_* flags above, bitwise-OR'ed */
	
	/* Note that ModPlug always decodes sound at 44100kHz, 32 bit, stereo and then
	 * down-mixes to the settings you choose. */
	int mChannels;       /* Number of channels - 1 for mono or 2 for stereo */
	int mBits;           /* Bits per sample - 8, 16, or 32 */
	int mFrequency;      /* Sampling rate - 11025, 22050, or 44100 */
	int mResamplingMode; /* One of MODPLUG_RESAMPLE_*, above */
	
	int mReverbDepth;    /* Reverb level 0(quiet)-100(loud)      */
	int mReverbDelay;    /* Reverb delay in ms, usually 40-200ms */
	int mBassAmount;     /* XBass level 0(quiet)-100(loud)       */
	int mBassRange;      /* XBass cutoff in Hz 10-100            */
	int mSurroundDepth;  /* Surround level 0(quiet)-100(heavy)   */
	int mSurroundDelay;  /* Surround delay in ms, usually 5-40ms */
	int mLoopCount;      /* Number of times to loop.  Zero prevents looping.
	                        -1 loops forever. */
} ModPlug_Settings;

/* Get and set the mod decoder settings.  All options, except for channels, bits-per-sample,
 * sampling rate, and loop count, will take effect immediately.  Those options which don't
 * take effect immediately will take effect the next time you load a mod. */
void ModPlug_GetSettings(ModPlug_Settings* settings);
void ModPlug_SetSettings(const ModPlug_Settings* settings);

#ifdef __cplusplus
} /* extern "C" */
#endif

#endif
[/code:2os8heku]

Heya everybody.

In anticipation of support for Python returning to Construct 1.0, I was looking for creating some bindings for modplug.dll, aka libmodplug, a GPL mod replayer engine which is probably better than libmikmod (although maybe not as well-documented)..... I appreciate all the work Rich and Ashley did (especially granting my request for mod support in Construct), however, the solution which was implemented ended up being less than ideal for handling Impulse Tracker files

Since I am kinda new to python (and know little to no C++), getting this far was a pain in the butt, but I think using some specific tools (gccxml + xml2py from Python's ctypeslib), I got the beginnings of the proper bindings. This was all based on the source headers available with libmodplug, specifically, modplug.h. I'm not sure how to plug it into an audio output quite yet, but I'll let you guys know if I do! Here is what I have so far:

modplug.py

from ctypes import *

_libraries = {}
_libraries['C:\\python26\\scripts\\modplug\\modplug.dll'] = CDLL('C:\\python26\\scripts\\modplug\\modplug.dll')
STRING = c_char_p

MODPLUG_ENABLE_NOISE_REDUCTION = 2
MODPLUG_RESAMPLE_NEAREST = 0
MODPLUG_RESAMPLE_SPLINE = 2
MODPLUG_ENABLE_SURROUND = 16
MODPLUG_ENABLE_MEGABASS = 8
MODPLUG_ENABLE_REVERB = 4
MODPLUG_ENABLE_OVERSAMPLING = 1
MODPLUG_RESAMPLE_FIR = 3
MODPLUG_RESAMPLE_LINEAR = 1
class _ModPlugFile(Structure):
    pass
_ModPlugFile._fields_ = [
]
ModPlugFile = _ModPlugFile
ModPlug_Load = _libraries['C:\\python26\\scripts\\modplug\\modplug.dll'].ModPlug_Load
ModPlug_Load.restype = POINTER(ModPlugFile)
ModPlug_Load.argtypes = [c_void_p, c_int]
ModPlug_Unload = _libraries['C:\\python26\\scripts\\modplug\\modplug.dll'].ModPlug_Unload
ModPlug_Unload.restype = None
ModPlug_Unload.argtypes = [POINTER(ModPlugFile)]
ModPlug_Read = _libraries['C:\\python26\\scripts\\modplug\\modplug.dll'].ModPlug_Read
ModPlug_Read.restype = c_int
ModPlug_Read.argtypes = [POINTER(ModPlugFile), c_void_p, c_int]
ModPlug_GetName = _libraries['C:\\python26\\scripts\\modplug\\modplug.dll'].ModPlug_GetName
ModPlug_GetName.restype = STRING
ModPlug_GetName.argtypes = [POINTER(ModPlugFile)]
ModPlug_GetLength = _libraries['C:\\python26\\scripts\\modplug\\modplug.dll'].ModPlug_GetLength
ModPlug_GetLength.restype = c_int
ModPlug_GetLength.argtypes = [POINTER(ModPlugFile)]
ModPlug_Seek = _libraries['C:\\python26\\scripts\\modplug\\modplug.dll'].ModPlug_Seek
ModPlug_Seek.restype = None
ModPlug_Seek.argtypes = [POINTER(ModPlugFile), c_int]

# values for enumeration '_ModPlug_Flags'
_ModPlug_Flags = c_int # enum

# values for enumeration '_ModPlug_ResamplingMode'
_ModPlug_ResamplingMode = c_int # enum
class _ModPlug_Settings(Structure):
    pass
_ModPlug_Settings._fields_ = [
    ('mFlags', c_int),
    ('mChannels', c_int),
    ('mBits', c_int),
    ('mFrequency', c_int),
    ('mResamplingMode', c_int),
    ('mReverbDepth', c_int),
    ('mReverbDelay', c_int),
    ('mBassAmount', c_int),
    ('mBassRange', c_int),
    ('mSurroundDepth', c_int),
    ('mSurroundDelay', c_int),
    ('mLoopCount', c_int),
]
ModPlug_Settings = _ModPlug_Settings
ModPlug_GetSettings = _libraries['C:\\python26\\scripts\\modplug\\modplug.dll'].ModPlug_GetSettings
ModPlug_GetSettings.restype = None
ModPlug_GetSettings.argtypes = [POINTER(ModPlug_Settings)]
ModPlug_SetSettings = _libraries['C:\\python26\\scripts\\modplug\\modplug.dll'].ModPlug_SetSettings
ModPlug_SetSettings.restype = None
ModPlug_SetSettings.argtypes = [POINTER(ModPlug_Settings)]
__all__ = ['_ModPlug_Flags', 'MODPLUG_RESAMPLE_LINEAR',
           'MODPLUG_ENABLE_OVERSAMPLING', 'MODPLUG_ENABLE_MEGABASS',
           'MODPLUG_ENABLE_REVERB', '_ModPlug_Settings',
           'ModPlug_Settings', 'ModPlug_SetSettings',
           'ModPlug_GetName', 'MODPLUG_ENABLE_NOISE_REDUCTION',
           'MODPLUG_RESAMPLE_NEAREST', 'ModPlug_Load',
           '_ModPlug_ResamplingMode', 'ModPlug_Read',
           'ModPlug_Unload', 'MODPLUG_ENABLE_SURROUND', 'ModPlugFile',
           'MODPLUG_RESAMPLE_FIR', 'ModPlug_GetLength',
           '_ModPlugFile', 'MODPLUG_RESAMPLE_SPLINE', 'ModPlug_Seek',
           'ModPlug_GetSettings']
[/code:ahony2oi]

You'll probably need to replace the hardcoded paths to a dynamic path, replacing with modplug.dll for windows, and libmodplug.so for Linux.  What's not finished yet is the code to call the proper function to play the song.  I'm hoping someone smarter than me might be able to figure that out!

You can get Modplug.dll by downloading [url=http://alister.eu/jazz/oj/download.php]OpenJazz[/url] (an open source Jazz Jackrabbit clone).  From there, this source file can presumably be called to load the functions.  Whew....

cairo is slow as dirt. Its implimentation in tests with Mono were that it performed slower than GDI+, which I have a little bit of experience with -- I can tell you that it's way too slow to be using for any serious games processing, especially with large amounts of vector or very large bitmap surfaces.

yup, that's the one. My tile making skills suck, but last thing I did was make a thingy that converted a 1-bit image into a nice big tilemap, which was a start towards a level maker :V

http://www.gpknow.com/nobuyuki/blog/rai ... l_test.png

Helloo,

This is an open letter to ashley/tigerworks/whatever you go by nowadays. I just wanted to say THANKS for all the hard work you put into Scirra. Thanks for making it open source. Thanks for listening to people's concerns on the forums and THANKS for being so quick to fix bugs and address people's feature requests! Edit: and thanks to all the other people who are working on Scirra now, too. Rich, are you still around?

I know the last time I was on this forum was like a year ago or something, and I was waiting for Construct to become relatively stable before I'd attempt making a game with it, but I kinda got sidetracked while promoting and selling the soundtrack to said game I wanted to create and stuff and kinda forgot about scirra for a while because I got another job offer in the process xD

Yesterday, I gave Construct a spin just as a little distraction and I must say it's come a very long way. I see the mod plugin's still very simple, but holy crap I didn't even realize I hadn't really tried it after hearing what engine it was using for playback. I made a mistake in that. The output is very crisp, and while it still doesn't support IT resonance filters, I think that can be worked around if what it gives in return is a trouble-free and low cpu cost implementation of MOD playback. It took me all of 2-3 minutes to figure out how to place a MOD object, open the event sheet editor, and test out some of the songs I wrote for my game in it. Very awesome! (By the way, is there a variable for application path?)

When I last left Construct, you guys were just beginning to implement Python. Has it become the dominant way to write games for it now? After Gamemaker's scripting language became full-featured, the non-scripting parts of it kinda withered on the vine. I hope that's not been the case for Construct, because so far what I've seen is that the system is rapidly becoming more exiting to me than when I last checked out MMF2. (To any clickteam folk reading this, that's not a slam on MMF2, it's just a compliment to Construct!)

Anyway, keep up the good work. After I finish this current job, I want to give Construct and Scirra another shot, and maybe finish the game I had started more than a year ago in MMF. The new python engine seems very exciting potential for a custom tile engine, and having not finished a game since 2003 I think I've been getting a little rusty B:

Thanks again

Nobuyuki

Remember Metalstorm?

for a game which I've halted development on for a while while I consider Construct or straight Python to develop in. Originally for Total Klik mascot competition