Code golf.

your code in your stuff is really nice and such, but its a very unique style with a lot of.. weird things, like all the % and $ and # and *.. its very confusing, but i kinda like it.. i forgot why i made this comment.. well too late now.. whatever..

Thanks for the compliment. The $, #, and % are type specifiers so SmileBasic knows what kind of data each variable stores. It helps you avoid data type bugs. Hopefully the next SmileBasic will get user defined types. Then I wouldn't need those anymore.

just saying that i used a lot of your platformer code to help make my game work better as my collision was going all wonko. so just making sure your ok with that, also i wanted to add sp collision to it, but i couldnt seem to find out how to.. so maybe you can tell me a simple answer? but i put you in my credits.

i was looking for the sprite values, i usually use like spx, and spy, but i cant tell what name you use for it

Thanks, I was hoping people would use the platform demo code as a basis for new games, so if it helps make you game better, I certainly don't mind. I have some sprite collision in slime bump and slime bump 2 in the same samples folder hopefully that helps. Now a days I like to put sprite handling in a callback function and have it handle itself. I probably just fill a local x%, y% in the handler.

well u

hmm..that was weird..i dont know why that suddenly posted in the middle of my typing.. anyways.. so basically, im trying to make the sprite stay in one location on the map, but when i use spofs it just sticks to the screen, i had learned how to fix this by doing SPOFS 1,SPX-X,SPY-Y but as your code uses different names and stuff i dont know what to put in.. im probably missing the obvious..

It sounds like you may be having problems with world versus screen coordinates. For a single screen game they are the same but when you have a scrolling world you have to map one to the other. In slimebump2 I have bgofsx%, and bgofsy% that are the x, and y pixel offset that the top left corner of the screen is from the top left of the map. To transform from world to screen coordinates subtract

To transform from world to screen subtract the background offset from the world location. Then show/hide depending if its screen coordinates are on screen or not. You have to keep track of world coordinates separately. Same thing goes for the player sprite except set background offset relative to their position (bgofs the background layers when changed too). Then draw at its screen coordinates.

i still dont fully understand what to do.. or what your saying.. so were you saying to use bgofsx%, bgofsy% for the thing, or were you saying something else?

Hopefully the attached helps. You want to show or hide the sprite based on if it should be on screen or not. When it is on screen its location is relative to what part of the background you have moved to.

hey. yeah, me again.. its about the code you gave us (the shooting one). we've been trying to seperate it into just the bullets without the player but have been having trouble doing it. what parts would i use to seperate it into just that, or something that i can put directly into a program without changing or making new variables? its just different code then were used to.

Is that the Throw Shovel one? SECXE2KE

yeah that one.

Ok, so a good part of how this works is SPFUNC. Using that, you can make sprites move themself around. Also you have to put in CALL SPRITE in the game loop. If you look at the code, lines 13 to 20 is the game loop and line 17 says CALL SPRITE. This is the code where you update the game once per frame. Next we have a pair of functions CREATE_SHOVEL (lines 38-56), and UPDATE_SHOVEL (lines 77-92).

When you call CALL SPRITE, in the main loop, it will call UPDATE_SHOVEL for every shovel sprite. UPDATE_SHOVEL is where you put the code to move or delete (SPCLR) your shovel. Note, CALLIDX is your sprite's id/handle here. I use SPVAR to save and load each shovel's unique state information.

CREATE_SHOVEL just creates a new shovel sprite. I return the shovel's id/handle if successful and -1 if we ran out of sprites. Note the SPFUNC call. That says what function you want called. The desired function can't take parameters or return values. If you want to create new shovels without the hero sprite you just need to duplicate line 72's CREATE_SHOVEL call in the hero's update function.

So in summary you need the functions create_shovel, and update_shovel. The main game loop should call CALL SPRITE every frame. Then just call CREATE_SHOVEL whenever you want to make a new one.

ok thanks.

so after an insane amount of trial and error i found my problem. xscreen (2), it seems to mess with the code and i have tried a ton of things so uh whats the solution to this problem, why is xscreen messing with it and what should i do.. anyways its like 4am so goodnight lol (finally found the prob, it only took a lot of hours) thanks again!

There are a couple things xscreen may be doing. The first is are you setting up the number of sprites and background layers for each screen correctly? If you half them between screens you would get 256 sprites and 2 bg layers each. The second thing is I assume that xscreen acts like an ACLS. So I would make sure you only call it one time at the top of your code before you load in graphics.

ok ill try again.

so been getting it all together again and thought bout the bullet collision (cause i assumed it worked differently) anyways i tried the normal spcol but it wasnt working so what would i do to add in the collision or where do i do it? assuming i have to add a new thing in spvar or something idk..

The regular sprite collision functions should work. Just make sure you turned on collision detection on both the player/target and bullets when you set up the sprites. Although if you are scaling and rotating the sprites things may not work as well as expected. You will have to keep track of sprite id/handles when checking collisions too.

yes but with every bullet there are different managements and SPCOL SP% dosent work, though player collision works.. as normal i did a test by SPCOL SP% (tried some others too but none worked) IF SPHITSP(P1,SP%) THEN BEEP 5 i was asking the name it will go under or do i make one cause the ones i tried dident work

btw I did fix that sorry

Hopefully you don't mind me asking a few questions about the shovel game also. One main thing I'm confused about is how CALL SPRITE is linked to UPDATE SHOVEL. Is it something built into SB that does so? The reason I'm confused is because there's no variables or functions that are named SPRITE.

Glad to hear you got things working Person D©

CALL SPRITE is built into SmileBasic. You can actually use CALL to call most any function passed as a string. Anyway, you set up what function to call or line to jump to with SPFUNC. Then CALL SPRITE will look at every sprite. If it has a SPFUNC value it will set CALLIDX to the sprite's handle and call the function. If you set it up right, the sprites move around on their own.

so ive been trying to make it so the bullets shoot opposite of the normal direction when pressing a button (lets say B button), so i got everything but the bullets to fire in that direction but i cant seem to figure out how to make it do this..

actually nm i just switched the sx and sy so i figured it out lol.

So I've been looking through the code several times, referring to your posts on here more times than I can count, and I think I've almost got it all figured out! The last question that I was wondering is what SPCALLIDX (Hopefully that's how it's spelled) does. I've figured pretty much everything else out except for what that function does in the game.

Never mind, I think I've got it all down now, thanks for all your help!

CALLIDX is filled with the id/handle of the sprite you are updating in the function you set up with SPFUNC. In the attached example I have many sprites and they all use the same function. Also note the use of SPVAR and the output version of SPOFS to get information on the sprite it is updating.