don't think it will help. just wanted to make sure it wasn't the problem :)

so when you say you tried removing objects and such

did you try removing everything from that layout? and as a blank layout still has problems?

also you say drivers "should be ok"

just be sure, and download the latest driver. it's a likely source of such a problem, if it's not just cap corruption or the like. new pc's are rarely up to date with drivers if you don't do it manually

the new version was released just yesterday

if you click the about button (the little button with the 'i' just under the close button on the top right of the construct classic editor screen)

there it should say r1.2 or r2. r2 is the new version

Is the new pc using the new version, and the old pc not?, if so would it be possible to install the new version on the old pc(without overwriting) and see if it causes the same problem?

yeah, what newt said. I still say there might be bloom, but it's so subtly it could also just be crappy video compression.

Also, it has a vignette(cc vignette effect).

I can't tell from the still frame if anything special is going on with the light. At first glance I thought it was just nicely colored sprites, and alpha. Though it looks like there might be some additive blending(one of the built-in effects), saturation, or a tiny bit of bloom(CC bloom effect by Davioware, here) on that blueish sky back there.

if those boxes at the bottom are bumpmapped or something I can't tell without video either.

Do you have a link to a video, or the game title?

...Just wondering, but if I start using this for a project I'm well into, will certain things not work correctly like how you see in much older builds of Classic?

—, in the unlikely scenario that your project depends on line object collision being bounding box. The general consensus was that this was mostly useless for the line object, so it's not an option, the only collision type now is angled_box.   The panel, box, and sprite objects still have the option for bounding box collision.

The only other problem I can see is if you had panel objects that you purposefully misplaced because of the old bug, so they would appear in the right place, you'll have to move them to where they are actually supposed to be.

I seems intuitive that it would add two.

First, one would assume that On Collision is a triggered condition, as most conditions begin with the word "On" are.

A green arrow appears before the condition name on the event sheet for triggered conditions:

<img src="http://dl.dropbox.com/u/1013446/forumhelp/trigger.PNG" border="0" />

in the screenshot below you can see this is not present on the On Collision condition.

Since the condition is not triggered by each collision, and instead is evaluated once in the order it appears in the event sheet. Those actions are carried out one time, regardless of the number of colliding instances, and all instances are picked at the same time. This is useful, because you can do things like make a sound play once even in the event of multiple collisions, instead of playing twice at the same time, etc,

If you need an action for each collision, you can still use a 'System: For Each Object' subevent to loop through each of the objects that are picked in the collision event - which results in the behavior you originally intended:

<img src="http://dl.dropbox.com/u/1013446/forumhelp/bricks.PNG" border="0" />

Sorry for the lack of updates. Had about 2 1/2 weeks of unforeseen delays. Back on track, and things are progressing steadily again. I'll report back soon with a more complete status report and some screenshots. Thanks for your patience. I'll try my best to make sure this update is worth the wait.

is there anything specific anyone knows about when the crash happens? are there a specific set of circumstances that cause it to crash? is it only with transitions, etc. I'm not sure if I'll be able to figure out what's wrong with it, but I'll definitely take a look when I get a chance. Also, if someone could make a barebones cap that causes the crash, even if it's just a few events, it would be helpful.

hmmm... no, those are about the same results I'm getting now regardless of the texture, must've made a mistake somewhere. I definitely was using 640x480 in my original which runs at just under 40fps for me now. Same here as well, not making a difference with or without sine behavior not sure what I did. either way. moot point with all the rest discussed.

On a side note, I'm running AMD as well, 3.4 phenom2 x4 965 deneb BE. Sometimes when testing caps, repeated runs get 40 fps less than the usual run, maybe I got lucky and had it work backwards that time?

more likely I forgot a 0 at the end of something <img src="http://dl.dropbox.com/u/1013446/forumhelp/twiembarassed.jpg" border="0" /> on my first test

Lucid, can you give any sort of feature/fix previews? Since I'm deep in a project right now, knowing what changes might concern or benefit me would be nice so I can plan accordingly.omething seems weird/premature about posting the actual changelog before the release, but I'll give a general overview. a few runtime/plugin performance/memory-leak fixes, some nonperformance related fixes to several plugins like shadowcaster, drag-and-drop, panel, xbox360controls, platform behavior(i think that's all of them), a few system expression/plugin expression fixes. one addition/one fix to the sdk, and a handful of new additions to various plugins and the runtime - one or two of which may be a big deal to some users, as they've been requested for a couple of years. personally, these last ones are the ones I'm most eager to see released, having been one of those who requested them. :)

lso unrelatedly but since we're posting about bugs in CC, what steps can I take to prevent crashes when switching layouts? I remember reading a lot on the topic but can't quite find any. Those are a set of problems I'd like to stamp out.this I can't comment on. all the projects I've ever worked on used a single layout. but I have heard a reoccurring theme with regards to not crashing while switching layouts, which is : don't use transitions.

> interesting. I'm getting about 15fps with the sine behavior on all of them, and about 30 without it. I have no idea why one png would render slower than another, especially that much slower, but perhaps one of the more knowledgeable folk around here can enlighten us.I'm getting 15 fps, too. It's not a matter of png rendering (the textures are on the graphic card's VRAM in a simple RGBA format, no png/jpg/etc anymore), it's a matter of different test settings. A graphic card has much more work to do if the viewport is larger. If you just half the width of the window from 1280 to 640, you will see that the framerate will instantly go up. Also, the hardware may differ. While my GTX460 Hawk is relatively powerful, a GT7600 is not. This will also result in different framerates.

oh right, I meant because I had done a test with a different png of the same size, and got a much higher framerate. not sure if there's some optimization done for unvaried textures on my card(hd6970), but in the faster test I was using a solid red square of 4096x4096. I even tried lowering the resolution of qwary's test, but it didn't come close to matching my original test