Topic: Petit Computer

Hey guys! I was able to figure out how to make a C note play in the game! Yeah, I've made no progress in my music making. But the fact that playing a C is that rewarding says something.
Also, Petit Farm looks awesome. Keep it up.

I am legit excited for Petit Farm. It's so beautifully Harvest Moon.

@everyone: thanks

@late: All the graphical "layers" (but the console) have 2 "pages".
Page 0 is the top screen
Page 1 is the bottom screen.

For example
GPAGE 0
GFILL 0,0,255,191,COLOR
GPAGE 1
GFILL 0,0,128,191,COLOR

Will fill the top screen with a solid color (stored in the COLOR variable) AND fill half of the touch screen with the same color.

Other graphical layers have their own PAGE commands

So, in a way you can only work with a screen at a time, but it's so fast you won't notice it.

@Morphtroid, @bulbasaurusrex: between the two of you, thanks for the idea — i thought that i had to use the $ after things because it'd been used when I DIM'd the array, so i toggled it on and off depending on what i was fiddling with, and it worked fine up until this point. i'd already tried changing all the 'A's to 'A$'s instead but that didn't work at all, lol ('type mismatch' errors and syntax errors depending on which ones i fiddled with and which ones i didn't) so just now I tried changing all the 'A$'s to 'A's instead (aside from the DIM line) and whaddayaknow, it finally works, and for reals this time. hooray!
_{in the future, would QR codes be better if i'm trying to explain how i'm stuck? lol D:}

@Morphtroid: that makes sense re: only being able to use one screen at a time — i'm wanting to say i remember reading an article where someone being interviewed said they had to work around the same thing with actual 'ware and retail titles, so it's not just a limitation of Petit Computer i don't think.

Well you see,you were trying to store numbers on an alphanumerical variable and comparing them to real numbers without using VAL

QR codes would be nice but it would be a bother for you, so don't worry.

Could someone teach me how to do an input command? I do it like this and I get an error

INPUT "Are you happy?"

Then it turns into an error.

You need a variable to store the input.

Example
INPUT "tell me a number";VAR

INPUT "tell me your name";VAR$

@TheDreamingHawk What are you trying to input? The INPUT command is, as far as I know, used for the user input of variables. As an example, If you wanted the answer to "Are you happy?" as a variable, you could do:
PRINT "Are You Happy?"
INPUT A$
PRINT A$

What that does is ask the user to input a variable called A$. The answer would be in a text form, so I believe you need to do a single letter followed by $ for a numerical variable, you could use just text as a variable name, for example, HISCORE. Then the last PRINT command shows you the variable. I think that would work, but I could be wrong. Ans the first and last lines are unnecessary, you could do it with just INPUT A$. Hopefully that was clear.

Edit: or I guess Morphoid's way is easier.

I'm working on a "petit invaders" but I still can't figure out the best way to update graphics (kinda nooby thing, I guess). I mean, how can I update positions without having that blinking "effect"? I know it might have something to do with "vsync" and all the pages, but I can't undestand exactly how it works. Little help?

How can I get sprites to move from point A to point B with out them teleporting there?

@EmpireIndustries, I have no knowledge of the BASIC language, but your issue seems fairly obvious to me. That is, if I'm thinking correctly. I would say you need to add more than two points. If you only input two points, the program probably believes there are only two points.

@Nintenbro Hmm. I'll see if there's something I can do along those lines. Thanks!

Move them a few pixels at a time. Petit Computer gives you 8 registers for each sprite I believe. You can store whatever you want in these. For example, you could store the current position x, y in registers 0 and 1, and the destination x, y in 2 and 3. Then you can run this simple program to demonstrate:

CLS
CLEAR
SPCLR

FOR I = I TO 99
SPSET I,RND(511),0,0,0,1,16,16

X = RND(255)
Y = RND(191)

SPSETV I,0,X
SPSETV I,1,Y
SPSETV I,2,RND(255)
SPSETV I,3,RND(255)

SPOFS I,X,Y

NEXT

@ANIMATE_START

DONEANIMATING = TRUE
FOR I = 0 TO 99

'Get current sprite location
CURRENTX = SPGETV(I,0)
CURRENTY = SPGETV(I,1)

'Get current sprite destination
DESTX = SPGETV(I,2)
DESTY = SPGETV(I,3)

'Move one pixel to the left or right depending on location of destination
IF DESTX < CURRENTX THEN CURRENTX = CURRENTX - 1
IF DESTX > CURRENTX THEN CURRENTX = CURRENTX + 1

'Move one pixel up or down depending on location of destination
IF DESTY < CURRENTY THEN CURRENTY = CURRENTY - 1
IF DESTY > CURRENTY THEN CURRENTY = CURRENTY + 1

'position the sprite
SPOFS I, CURRENTX, CURRENTY

'store the new position in the sprite registers
SPSETV I,0,CURRENTX
SPSETV I,1,CURRENTY

'check to see if sprite is in final location
IF CURRENTX != DESTX OR CURRENTY != DESTY THEN DONEANIMATING = FALSE
NEXT
VSYNC 1

IF DONEANIMATING == TRUE THEN GOTO @ANIMATE_DONE
GOTO @ANIMATE_START

@ANIMATE_DONE

@DrKarl Ok, Thanks.
I'm almost finished my first really awful game now. Just a few more questions.
Is there a way to remove the sound that plays when you load a sprite or background in-game?
How exactly does GOSUB work? I'm getting an error with sprite collision, and I think it might have something to do with GOSUB, not sure if I'm using it correctly.
Thanks in advance!

I'll get back to you on Gosub soon. To suppress the loading sound & the loading confirmation screen:

SYSBEEP = FALSE
LOAD "SPU0:FILENAME", FALSE
SYSBEEP = TRUE

As you probably know, the SPU0 will be whatever you are loading, I think it is BGU0 and BGU1 for backgrounds. Also, I turn the beep back on after doing the load, which is optional depending if you want it back on or not.

GOSUB is THE most powerful tool in a BASIC programmers toolkit. It will allow you to create a solid foundation on which to build your programs.

At its most simplest, GOSUB can be viewed as a fancy GOTO.

For example, consider this very simple program:

X=5
Y=10

PRINT "X is"

IF X < Y THEN GOTO @LESS ELSE GOTO @GREATER

@RETURNPOINT
PRINT "THAN Y"
END

@LESS
PRINT "LESS"
GOTO @RETURNPOINT

@GREATER
PRINT"GREATER"
GOTO @RETURNPOINT

Using Gosubs, we are able to eliminate the @RETURNPOINT label, and make things a bit more uniform:
X=5
Y=10

PRINT "X is"

IF X < Y THEN GOSUB @LESS ELSE GOSUB @GREATER

PRINT "THAN Y"
END

@LESS
PRINT "LESS"
RETURN

@GREATER
PRINT"GREATER"
RETURN

See the difference? Code reached by a GOSUB must always begin with a @Label and end with a RETURN. When the line with RETURN is reached during the execution of a program, the program automatically does a GOTO to the point where the GOSUB was called. This makes that block of code very reusable. Anywhere in your code, you can do a GOSUB to that code block and know that when it finishes that block of code it will return to the location in code right after the GOSUB was called.

Does this make sense? I will leave it simple like this for now. However, GOSUB is much, much more powerful still. HINT: GOSUBS can be nested. I can provide an example in the future if anyone would like.

@DrKarl Thanks a lot! That makes sense now, I was using GOSUB in the wrong way.

am i the only one around here who can't figure out how to place and move a sprite?

I've updated the code above to help you get started. Here is the QR code:

Make note of these two functions: SPSET & SPOFS

SPSET will link a sprite to a control number. The control number can be 0-99. In the example above, I set a random character to each of the control numbers.

SPOFS will offset a sprite to a location on the screen. For each sprite in the Demo, I placed it at a random location on the upper screen.

I then give each sprite a random destination and run through the animation loop until each sprite has made it to its destination. Then the program ends.

This move sprite stuff is kiling me. I think I'll just do it the long way of using SPOFS and wait a bunch of times. I only have to move 4 sprites on the x axis halfway across the screen. The only issue I can see occuring is that I have to get on of the objects to move forward at a button press and also continue moving forward and then go back at the end of the animation, like a forward stab. Can't wait for that.