Wow, thank you the helpful response!

I haven't run into any significant speed issues yet. I don't know if this is because my project is relatively small or because my computer is more powerful, but... well, I suppose I'll find out.

"For example, don't use the layout object. Just don't."

Thanks. Are there any other here-and-there broken features in CC? I've also read that the OR condition can be a bit iffy, and that XAudio2 is screwy for a lot of people, though I'm not sure how true these are yet. I'm looking mainly for these specific issues that do not come up in a "general list of problems".

"Don't delete variables. Especially family variables."

Ack, too late. How... big of a deal is it if I did?

As for C2: I'm not one to shy away from change (I've tried the C2 trial--the editor is indeed vastly superior) and I have no problems with investing in software, but I have a need for CC's performance, its larger effects library (does C2 even do shaders yet?), its ability to export to a desktop runtime, and python scripting (my project involves some complex logic which is not feasible with events). Also, this may be an irrational sentiment but HTML5's browser-bound setup has always seemed a bit "flimsy" to me for some reason. Anyway, I will be watching its development, and I will certainly use C2 for lighter future projects, but I'm sticking with the CC for now.

Also: I've read that the only reason for the August-2008 DirectX requirement is because it has something that XAudio2 needs. Assuming that this is true, and if I don't use XAudio2, could I possibly bypass this requirement and save players from having to download the redistributable?

Hello.

I am in the process of making a fairly large project in CC, and it is starting to become very complex and difficult to follow due to the sheer number of objects and events being created. It appears to me that CC lacks effective organization tools, and proper naming schemes and object folders only get you so far (and it doesn't help that everything is stuck inside one .cap file). Do any old-timers have tricks or off-manual tips for managing large projects while staying sane? Are there alternative or accessory editors available? How would I best prevent .cap files from becoming corrupted and lost forever?

Hello!

I'm kind of floored that there isn't a topic on this yet! Maybe I just couldn't find it? Anyway:

I've run into a problem where, while controlling a sprite with 8-dir behavior, if I collide with a solid area and I continue to move (push) against it, the sprite's behavior will rapidly alternate between moving and not moving.

Note that I'm not talking about its actual movement in space--that part is fine. I'm talking about the sprite's states of "moving"(which satisfies "is moving" in the event sheet) and "not moving".

At first, I figured that's just how that particular behavior works (kind of crappy, but what are you going to do?) and was prepared to either come up with my own custom movement or devise a workaround. Then I noticed that this weird jittering actually doesn't happen with the platform behavior. If a platform sprite is controlled to push against solid space, it maintains its "not walking" state.

Why do the two behaviors act so differently? Aren't they, barring a few cosmetic details, fundamentally the same (i.e.: based on the same collision handling)? Am I just being dumb and doing something horribly wrong?

Here's a .cap:

http://www.mediafire.com/?i8pt6062yka8vae

I'd really appreciate any help or insight!

Ah. Well, until then, either the time expression or the every-x-milliseconds thing will work just fine. :)

Fabulous. Thank you.

I just released 1.4 on the first post. I switched to using a higher precision floating point number type so most of those rounding errors should be eliminated.

Ah, thanks for looking at it! I just tested it out and... well, it's mostly fixed, like you said. :p

Adding exactly 1 per tick makes the volume go up to and stop at 28 this time, but setting volume seems to work now. Adding values lower than 1 (e.g. with TimeDelta) is still, I'm guessing, out of the question, but I suppose that's easily circumvented by setting volume only every N milliseconds.

Also, how is the limiter (or equivalent) set up within this plugin? Is there even a limiter? I'm sort of detecting that there's no automatic volume normalizing (a good thing, in my opinion), but I'm wondering if I still have a ceiling.

I love cellular automatons! Binary states producing seemingly organic patterns in order and chaos over discrete space... there's a bit of a sublime personality to just watching these little dots warp and grow.

You should include some presets! People have come up with some seriously amazing models over the years--entire systems, in fact.

Anyway, sorry. Tangent. Good work. :p

Thank you for bringing Audiere to Construct. This is great! It seems way more flexible and more intuitively set up than the default XAudio2 plugin. Plus, I don't run into weird "leftover" buffer glitches when interrupting channels and playing new ones (and thank god for not having to mess about with channels in the first place). :p

A question: I'm running into a very odd problem with setting the volume. If I add any value of 1 and below to the music's volume every tick (for a fade-in effect), the volume remains unchanged in value. Adding exactly 1.000001 to the volume per tick gets it to 31, where it mysteriously stops despite repeated addition, and adding 1.000002 per tick gets it to 63, where it similarly stops. I'm setting the volume this way: Audiere.GetMasterVolume+1.000002

Another example is: if you set volume to N, then the plugin will return that the volume was set to N-1, unless N is greater than approximately 96, in which case it will just return N. This sort of strange behavior makes me think that there are some strange math and/or datatype related hangups about the process used to convert the 0~100 volume value to decibels... or maybe the problem is with only the function used to return volume value?

Anyway, um... it would be totally super if you could look into this! I noticed that you stopped paying attention months ago, but I'd like to use this plugin if I possibly can. :p

This plugin has a conditions "autoplay" like in XAudio2??

Repeated sounds overlap each other in duration, so I assume that sounds are "autoplayed" by default.

Okay, as promised:

example exe

Arrow keys to move. Press Z to jump.

Instead of using the system zoom, which breaks a lot of stuff, I used a top-most "magnifying" layer to do it. There are no noticeable problems as far as I can see. I think that this is the solution I will go with.

And again, if anyone can tell me whether or not MagiCam works on fullscreen...

I considered that, and in fact, made half a game using that method back when I was working with another game engine. It is not an enjoyable process: working on the game starts to feel cumbersome and "hacky", not to mention that it allows for sub-pixel movement which, in my book, defeats the whole point of making a game in this so-dated-that-modern-cards-don't-support-it resolution.

I admit that it's not a very practical matter. Yes, the player probably won't notice or care if a sprite is off by half a pixel. I just have an obstinate love affair with genuine retro visuals in a game, so I'm not very willing to make any compromises on that front.

I'm also not one to try to lock a player into a fullscreen prison for no good reason. The nature of this particular project really calls for it, which is why I'm going through all this trouble in the first place. :P

Yes, I've set the window to be always-on-top. While testing, I found that certain elements of the Windows 7 GUI shows through at times. I don't know why, and I can't seem to replicate it, but fact that it happened at all is a source of hesitance for me. I may try to identify the cause later.

Anyway, your tutorial file doesn't have any display resolution related events and visibly suffers from scaling distortions. I'm assuming that you just left that out for whatever reason, but I think that I understand what you meant to do. I suppose you could change the display resolution based on the screen size, but changing the actual content (viewspace) of the game based on the user's screensize seems a little suboptimal for me!

This is a good solution, but I'm not yet convinced that it's the best-possible solution for what I want to do. I've done a bit of screwing around in my test project file and I think that I'm ready to suggest another workaround for a true-320x240 and true-fullscreen mode. It's pretty much just like regular zooming, but without its esoteric (how does system zoom work anyway?) parallax-breaking properties and without allowing "post-zoom" rendered things like particles and gradients to disobey the 320x240 grid. As far as I can tell so far, it works perfectly. There may be some problems with memory... I don't know. I'll clobber together an exe later if anyone is interested.

On a side note, does MagiCam not work in fullscreen? I just get a frozen white screen if I switch to fullscreen view while using the plugin...

"- The most obvious workaround is simply emulating 320x240 in 640x480 resolution with 200% zoom. This is not an optimal solution as it fucks up layer scrolling of layers with 0% scrollrates and allows for "subpixel" graphics on things rendered post-zoom (like particles)."

Unfortunately that's the best you're gonna get. I've been messing with this for a long time.

To work around the 0% scrollrate issue, you'll have to position your objects relative to scrollx, scrolly. If you're using Ashley's fullscreen w/ aspect ratio example, then they must be relative to the UI_Origin or

(scrollx+barL.width)+n

(scrolly+barT.width)+n

If you really don't care about blurriness on certain PCs or maintaining aspect ratio, you can try the built-in fullscreen or maybe the window object.

Yeah, I've read your posts in an older related topic that came up in a search. Construct is a total majesty in pretty much every other aspect so far, so it really is a pain to have to come up with workarounds for something as seemingly simple as screen modes.

To be honest, zooming will probably be my very last resort. I'm still pretty new to Construct, so all of these workarounds seem a little overwhelming, not to mention the "sub-pixel" thing being a bit of a turn-off.

If I want to use the built-in fullscreen, all I have to do is get the game to at least 640x480... but then again, that's the challenging part, isn't it? ;)

I just put up an example on how to do an easy to set up retro style fullscreen in the Tutorials forum.

http://www.scirra.com/forum/topic47220_post295684.html#295684

Hope it helps you out!

Thank you for the tutorial, though you may notice that this is the same solution that I considered in the second bullet point of my original post. :P

It does seem like the best method so far, even if it's a "fake" fullscreen. The "fake" part bothers me a little, as I'm afraid that graphics from external programs (like instant messengers) will pop through the game screen during gameplay as the windows 7 start icon sometimes does, ruining the effect altogether. The other concern is the distortion that happens on certain screens--I'll comment on your tutorial topic.

I may look into writing a plugin or something that does this for you without workarounds if I decide that it's worth it (and if I can figure it out!), though I'm a little reluctant to look at code since the reason I moved to Construct from building my own engine in the first place is because I was sick of programming. :P

Hi!

I'm making a game in 320x240 resolution. As probably discussed to death around here already, this is not possible because modern machines do not support fullscreen in resolutions below 640x480. Okay.

After extensive research on google and this site, I've identified a few attempts at a solution:

• The most obvious workaround is simply emulating 320x240 in 640x480 resolution with 200% zoom. This is not an optimal solution as it fucks up layer scrolling of layers with 0% scrollrates and allows for "subpixel" graphics on things rendered post-zoom (like particles).

• There is a way to emulate fullscreenedness by stripping the game of its window borders (apparently called "captions"), setting window to be "always-on-top", and maximizing window. This seemed to be the ideal solution, until I realized that the game looks extremely distorted on monitors of a certain resolution.

• I've attempted setting window size to 640x480 via event and THEN fullscreening the game. I no longer get an error, but the game automatically changes to 640x480 resolution upon fullscreening. To be honest, this is a pretty silly attempt and I didn't expect it to work at all. :p

So is there any hope left for me? I don't care about keeping aspect ratios or a little blurriness. I just need a true 320x240 game that can run in fullscreen. I've read past topics on this. I just want to see if there's been a new development or if anyone has new ideas (or if I'm just missing something really obvious, which is a possibility as I am new to Construct!).

Edit: The second method would work (assuming that there aren't some other hidden problems) if the contents of the window would scale smoothly instead of with nearest-neighbor distortions when the window is resized. Is this possible?

Editx2: Another possible workaround would be running the game in 640x480, saving a 320x240 chunk of the screen to buffer, and then drawing it 2x onto the screen in real-time, but it doesn't look like Construct is capable of doing something like that...