New Ideas

[Graeli]

Could someone provide me with some ideas for a program? I'm only a mid level BASIC programmer, so nothing really hard. Thanks.

[Delnar_Ersike]

Do you know how to use xLib?

[baorder54]

Whenever I am thinking about a game to make, I just go to a game website like addictinggames.com or miniclip.com They normally have some simple yet fun games to recreate.

[frenchcalc1]

[Graeli]

If xLib is grayscale then no. I guess I can try to make a tetris clone...not saying that I can make a good one, but I can at least try. Thanks again frenchy

[IAmACalculator]

Click here for xLib info.

[frenchcalc1]

[WikiGuru]

XLib doesn't have a normal grayscale function yet, but you can make things greyscale by switching 2 sprites back and forth quickly (ironic, it's TI-Basic :biggrin: )

[Arcane Wizard]

This could use some help: http://www.unitedti.org/index.php?showtopic=3746

[Graeli]

Well, Arcane Wizard's game thingy gave me an idea for Fighter 3 ( I've already made Fighters 1&2, and I'll post them if anyone wants them) It will be mostly made in matrices, and you can move around unlike in the first two. You can also pick what type of attack you want to use, unlike in the others bcause I didn't understand getKey back then. I'll post some screen shots as the game moves along.

[Delnar_Ersike]

[Graeli]

Could somone post a link to a good Xlib? I got all the stuff from on link, but it lookd preeetty complicated,and it didn't have any tutorials.

[Harrierfalcon]

Read the readme.

[Graeli]

I did

Spr_X = Sprite X location(Where it is or where you want it?)
Spr_Y = Sprite Y location(same)
Spr_Width = Sprite width in BYTES (so a 16 pixel wide sprite would have a width of 2)
Spr_Height = Sprite height in pixels
sPIC_Num = The PIC in which the sprite is located PIC0 - PIC9
sPIC_X = X offset to sprite in PIC, must be ALIGNED. Can be a value from 0-11(do not get)
sPIC_Y = Y offset to sprite in PIC
Spr_Method = The copy method 0 = Overwrite, 1 = AND, 2 = OR, 3 = XOR(don't get)
Spr_Flip = Flip Sprite 0 = No Flip, 1 = Horizontal Flip (don't get)
Spr_UpdateLCD = Toggle LCD update 0 = No, 1 = Yes (don't get)

As you can see I'm ither slow or dumb. Could someone shed some light?

[nitacku]

Ok what you have is the Sprite command.

Spr_X is the x coordinate output location. So 23 means that the sprite will be displayed 23 pixels to the right of pixel 0. Pixel 0 is just the top left of the screen.

Spr_Y is the y coordinate ouput location. It is the same thing as Spr_X except this controls how far the the top of the screen the sprite is displayed.

Spr_Width is simply the width of the sprite. Since assembly does most of everything in bytes (I think), this value is going to be in bytes. One byte is equal to 8 bits or in other words 8 pixels. This means that a width of 1 is actually 8 pixels wide. 16 pixels is 2*8, so 16 pixels has a width of 2.

Spr_Height is the height of the sprite in individual pixels. So a sprite with a height of 1 is 1 pixel in height. Since the Spr_Width is already in bytes, for each pixel the sprite is taller, the number of pixels within the area of the sprite is increasing by 8. 8=byte so therefore this number does not have to be in bytes. Make sense?

sPIC_Num is the picture from which the sprite will be taken from.

sPIC_X is the x coordinate location of the sprite in the picture. Since sprites are always at least 8 pixels wide, it would make sense that the most sprites you could fit in a row is 12. Anymore and you would go off the screen. Starting from the left, the first sprite would have an x coordinate value of 0. The rightmost would therefore be 11.

sPIC_Y is the y coordinate location of the sprite in the picture. Just like the Spr_Height, this value is not by units of 8. If you have a sprite that is 15 pixels from the top of the screen, its y coordinate would be 14. It is not 15 since the numbering starts at 0 instead of 1.

Spr_Method is the method of which the sprite will be copied to the screen. It is rather difficult to explain what each of the 4 methods do so I will just tell you that the methods are either 0, 1, 2, 3. If all you want to do is paste the sprite on the screen without concern with what lies beneath the sprite, then use 0.

Spr_Flip simply 1 for flip, or 0 to not flip. Lets say you have a sprite of an arrow pointing left. If were to flip the sprite, the arrow would now point to the right.

Spr_UpdateLCD is the part that is the most important in this whole thing. If you don't get anything else, then at least make sure you understand what this does. Ok so when xLIB copies the sprite to the screen, the sprite isn't initially displayed. It is sort of "underneath" the screen. When you set this value to 1, you tell xLIB to update the screen. By updating, you simply reveal what was hidden "underneath" the screen. The update function becomes extremely useful when you are displaying overlapping graphics and lots of sprites. Instead of updating the screen every time you copy a sprite to it, you would wait until all the sprites are copied and then use the update function with the last sprite in order to reveal all of the sprites at the same time. This is not only faster, but it makes the program generally look and run smoother.

Make sure to experiment around with the other functions of xLIB as well. Try pasting a few sprites on your own and find out exactly what you need to do to make your program run fast and smooth. True knowledge only comes through practice.

[Graeli]

What does it mean when it says must be ALIGNED? Also whenever I try to use it, it copies the whole pic onto the screen.

[Harrierfalcon]

It just means that the distance from the pixel (0,0) must be evenly divisible by 8. 0 means the sprite starts at pixel (0,0), 1 means that it must be at (0,8), etc.

Disable emoticons. –Goose

[Graeli]

It is still displaying the whole pic, and I can't figure out how to clear the screen.

[Harrierfalcon]

Code?

OK

[DarkerLine]

Here's an explanation of "Spr_method":

0 = Overwrite. Drawing a sprite with this method will draw the sprite exactly as it is in the source picture: the black parts will be black, the white parts will be white.

1 = AND. This is rarely used. ANDing a sprite somewhere can only clear pixels, but can never set them (so if you ANDed any sprite whatsoever to a white background, nothing would show up - that's why people rarely use this). It makes the pixels that were white in the sprite white on the screen, and leaves the pixels that were black in the sprite as they were. You might use this when you're drawing in white on a black background, for example.

2 = OR. This is how RecallPic instructions work. They draw the black pixels of the sprite on the screen, but don't clear the white pixels of the sprite, so if there was something under the sprite, it appears as though you've drawn the sprite "on top" of it. You can think of OR sprites as sprites in which all the white pixels are actually transparent.

3 = XOR. This is the simple one - where there's a black pixel in the sprite, it switches the screen pixels from black to white and vice versa. This is simple, because if the background is white, then it draws the sprite the way it looks, and you can erase the sprite by XORing it to the same place again. The last part is true even if part of the sprite were to intersect with part of another sprite. This makes XOR sprites very useful in cases where you don't clear the screen every time you move something (which is the case in most Basic games, to save time).