Ah, okay. Forgive me, as my work recording for our auditorium crew has me conditioned to think of frequency as the quality of an audio file, not its audible length. But then again, I shouldn't have expected DirectSound to be resampling high level audio on the fly.

Both sound files play just fine for me.

Hey Ashley, would it be worth your time to add pitch variation to Directsound? Doesn't have to be great.

-Play sound from file with pitch 0.8+(random 0.4);

Animations are handled through the animator tab, which are accessed by turning them on in the ribbon and, if you want, pinned to the side of your workspace.

Welcome to the party, man! Please stop by sometime to show us what you end up making - no matter if it's in Construct or not.

We have a few interesting projects going on at the moment - most notably Ashley's recent computer-busting tech demo. Also of interest is Deadeye's "Hitler in Toyland" (So sorry if that title is incorrect) and Ssbfalcon's marble physics test with 3d backgrounds. Those and every other project in the "Your Creations" forum are in need of critique and creative input if you have the time to spare.

Good point.

*stands aside*

Deadeye, you're only getting ~30 fps at VGA on a 6200? Are you sure you don't have any driver issues? That card's a generation or two above my X600m.

Radeon Mobility X600:

Supports shader model 2.

Game A:

640x480: 16 fps lowest, 41 fps highest, 32 fps average

800x600: 11 fps lowest, 27 fps highest, 22 fps average

1024x768: 5 fps lowest, 18 fps highest, 14 fps average

Game B:

640x480: 18 fps lowest, 41 fps highest, 40 fps average

800x600: 10 fps lowest, 28 fps highest, 25 fps average

1024x768: 8 fps lowest, 18 fps highest, 17 fps average

OBSERVATIONS:

On this card, there is a small overall improvement at all resolutions.

The biggest performance difference is the full screen shader that activates when the player is hit. In Demo A, this can cause slowdown very near the minimum recorded speeds. In Demo B at 768p, this shader only causes a 5-fps dip.

Both demos are entirely playable at VGA resolution. Demo B is tolerable at 600p.

Seeing this old p.o.s. pull all this off at about 30fps makes me smile. This laptop's video card is far below even the lowest you can buy preinstalled in store shelf systems. I feel on even the lowest modern computer Construct should run at a steady, playable clip as high as 720p widescreen.

After a while, you'll get better at predicting swings of the market. If you suck at Poker, though, perhaps you should consider making money through retail instead.

A simple unique program ID would solve importability. Load event sheet / ini, check ID against internal ID.

And although this COULD be used for patching, I'm really thinking more of a level editor thing. Like Smash Bros Brawl, where users can use existing objects with a small choice of backgrounds and place them how they please. Or in my case, much the same with a little more flexibility within my own custom encounter scripting. No objects or textures need be added.

After all, you're right about patching tools. And yes you're right that python is better for mods... but I'm aiming for the end user, not the master modder. Construct event structure is far easier to understand and incorporate into an existing project.

Let's not get our hopes up just yet. Until we have word from Ashley on the feasibility of any of this, it's just a nice dream.

Custom levels, or add-ons later if a major version change is not necessary. But really, I'd be excited about user content. So long as I build functions within my game to support it, I wouldn't mind allowing the player to load his own "encounters" into a blank level, complete with enemies, dialog, and a small amount of predetermined layout options.

Or how about this argument, Doppel: Why NOT have this functionality? No need to stifle creative potential for the sake of it being useless to your specific needs.

We currently have tons of great tools for using outside scripting in our construct projects, but why not consider another? External event sheets, used at runtime. Here's why.

Construct's event sheets are already incredibly modular. The only limitation I can see so far is that they are internal-only. I'm no developer, so I don't know how deep of a hole I'm digging here... but I ask, how easy would it be to load and integrate external event sheets in compiled executables?

I would speculate there would be some limitations. I can't imagine doing it on the fly, but what about before a new layout is loaded? This would greatly open up expandability without the need for prior experience in python scripting. Want to let your users create custom levels? Define your major functions in the original event structure and allow them to be called through variables externally. Because construct's event system is easy to understand - even in pure text form - all you'd need to do is create an example expansion file for a user to modify.

This all comes on the heels of a discussion between me and Deadeye in the Help/Tech forum. Are we on to something, or is this simply impossible?