It's not exactly a 'right' to port a game using the original characters and everything without permission from their original owners...

If you want, not I'd you want...

Just replace display page with whatever graphic page you want the user to see at the time. I'd you want it to use the page already in display, use 'GPAGE OUT VP,WP' then replace the <displayPage> part in the command I gave you with VP.

Next time you go into the editor, the copied region should show up on the destination page. For example, if you wanted to copy everything from X=0, Y=0, to X=16 and Y=32, copying from page 2 to page 4 with the top left corner being at 128,96, it'd be somewhat like this: GPAGE <displayPage>,2 GCOPY 4,0,0,16,32,128,96

Are you trying to combine these sprites with those already existing on another page? If so, you can't use LOAD because that will erase everything already on the destination page; you'll have to find the top-left coordinate of the region you want to copy, then the bottom-right, put those in GCOPY, and set a different destination page and the X and Y coordinates of where you want it.

Yeah, unfortunately you can't copy between layers directly anymore. You have to load it into another sheet, or use GCOPY, which would be very tedious to work with without seeing what you're doing...

MATCH will also only use enabled enemy types, and VANISH will stop Pointers from tracking you. A few enemies were slowed down too. Whew, that was a lot! :P

When using circle pad controls, use the A button to select an option, and hold to use sliders like spawn rate and color. When the JUMP power-up is enabled you need to use the touch screen. As for better power-ups, you can no longer get PUSH if Reflectors and Translucents are disabled, FLIP if Pointers are disabled, and MATCH if only one enemy is enabled.

POLYGON Update 1.0.1 is now available! The key is B2KXCW3E. Notable features included in this update are as follows: - Added an enemy indicator, points to next enemy before it reaches game screen. - Gameplay screen option (Upper/Lower) - Controls option - Option saving, loading, and reset to defaults - Balanced some difficulty - Better power-ups

Yes, a lot of the code is wrong. "SPRITE HIT" isn't a real command, and the use of END is wrong too, to end an IF statement you use ENDIF all as one statement. You might want to start small with things like text display before moving onto Sprites, they are more complicated and require some more knowledge about SmileBASIC.

I think he means the original FNaF content, which is indeed essentially stolen from Scott Cawthon...

This looks really cool. Also appears to be a pretty good graphics editor too! That's a lot of options... I especially like the color bar design, and a gradient option is awesome too!

'but I barely any programming'? Sorry for bugging you about that... :P Well, I'm not sure if I'd really like to do a collaborative project, it's kind of tricky to do that too. You'd have to publish and take it down repetitively to share the code and everything, unless one were to do graphics creation and the other programming. Thanks for the *kind of?* offer though! :D

For example, although it was intended to be a SPRITE file, LOAD"GRP2:SYS/DEFSP.GRP" works perfectly fine and will load the default sprite sheet into the second GRP page.

Like V360 is saying, all a GRP file really is is a data (DAT) file, so it can actually be used on any page, regardless of which page it was on when it was saved. The page number is only specified when saving so SmileBASIC knows which page to use as the source for the saved file.

Oh, and because you can set height and width of the hitbox as separate parameters, you can make rectangular hitboxes as well.

Even trying something similar to raycasting would use 24 sprites for each enemy, and then you'd have to designate their height to what you want, and where they are in relation to other sprites. I think I could try the sprite sheet method though. For now I'll leave them with slightly smaller hitboxes.

Yeah, if you really wanted to you could maybe make it check where on the sprite it collided, then check the sprite sheet to see if that was a non-transparent pixel, other than that I don't see a solution. Except maybe several invisible sprites used for collision, which would require a lot more mapping for each pixel of collision.

Thanks. Yeah, I'm having troubles figuring out how to fix the title screen button collisions, as for the Pointer's (green triangle) hitbox, I think it seems like it has an extended range because of its rotation behaviour, so if it were at like a 45° angle it'd still use a square at its normal orientation. I'll shrink the enemy hitboxes a bit in this update too, shouldn't be too hard! :D

Thanks! I think it feels kind of empty when there's no music and limited sound effects, but the next update focuses on that and also will introduce two new enemies, power-ups, and visual effects to this music, which I plan to make myself ;)