My name is Darryl and I run a small photography/design studio in rural British Columbia. You can see some of my work on the SointulArt website or my FB page. ice crystal images- also the long time exposures are neat.

Thanks Ashley <img src="smileys/smiley17.gif" border="0" align="middle" />

The main thing I am missing compared to regular programming is a search/replace function. If I copy behavior from one condition to another and then have to double-click 10 lines just to change the class name that sucks. In an editor that would be a 3 second fix.

I have pretty much stripped the project down to its basics- this should be debuggable.

The basic behavior is similar to what you've got in SpaceBlaster. Once an enemy spawn point becomes visible the enemy will start moving and it does just that the first time through. When leaving the layout and coming back to it later the code acts as though there was an additional spawn point on screen. Based on the location of that extra enemy my guess is that for the first tick isOnScreen is still using the scroll coordinates from the previous level, notices the spawn point near the end of the level and creates the enemy. Then in the next tick we are at the correct position and everything procedes as before.

Traditionally that would be done with an animation. In this particular example you'd need just a single arrow animation and could place three next to each other.

There are ways to do it with events and some extra sprites but that would be more work and harder to debug.

What's the point of using scale mode then? In this case scale and crop mode yield identical results- a player with a larger screen will see more of the playfield (leading to an unfair advantage).

Based on this:

caling mode zooms according to the aspect ratio. If your window size is square and you resize the window to a rectangle, the game will scale to fit a square in the middle of the window, with extra space at the sides.

If my window aspect ratio is set to 2:1 I would expect it to remain 2:1 with "extra space at the sides". That's not the behavior I am seeing though.

>

> Anti Cheat Protection

> Simple Anti Cheat protection

> http://dl.dropbox.com/u/45711709/anticheat.capx

>

This one, I do not understand <img src="smileys/smiley5.gif" border="0" align="middle">

The idea is that he's keeping the score in two variables instead of one. If somebody uses a cheating tool and modifies the score in one, the game would detect that it's now different from the other one and take some action.

To be honest though that is rather pointless- if you take the time to develop a cheat then fixing two variables will not be more work than just fixing a single one.

In case this was too confusing. Try this:

open SpaceBlaster, set Project Properties to Full Screen: on (scaled) and window size to your screen width but make the height only half your screen height, e.g. 1280x500. Change the game layout to your screen width, and make the background tiles wider as well. Run game. It's now filling the entire screen despite the weird window size we picked.

Subtract 90 degrees from angle- this should cover most cases

Outside of range? add 360 degrees

Using expression you could do this:

set var= angle(x1,y1,x2,y2) - 90

set var= (var<-180) ? var : var+360

I have set window size in project properties to 1680x945 (yes that size is intentional!) and full screen is set to Scaled.

Previews run in fullscreen mode at a 1680x1050 resolution. According to the manual I should be seeing isotropic scaling with parts of the screen being blank (since project window height is ca. 100 pixels too small).

scirra.com/tutorials/73/supporting-multiple-screen-sizes/page-1

However, I am using a SpaceBlaster like vertical layout that's much larger than 1680x945 and when previewing the game Construct2 actually fills the entire screen- there is no black border. Is that intended behavior?

I was going back & forth with kyatric and there might be a bug in isOnScreen. Capx has been PM'ed to Ashley.

When starting the game notice that there are two grey planes criss-crossing, followed by two tan ones. Wait for the Game Over screen to show up and click its button. This resets all global variables and sends us back to the game layout. At this point there is an additional plane showing up at the beginning. When replacing the IsOnScreen function with a calculation based on current scroll value this problem can be worked around.

It looks to me like isOnScren is using the value from the previous run when we switch layouts ..