Starting a fighting game

[wizardlife]

I'd like to say thank you before I begin with my post. Wiz, your the best. I mean I can't believe you actually sat down and wrote code for me. Second I'd like to apoligize for not replying right away. Don't take it as insult. It turned out I had quite a few tests, and project due today. I've been trying very hard to get back to qb but simply didn't manage. So thank you all for understanding and don't take think your posts went to waste for my long silence at the forums.

No problem at all.

Sadly I didn't understand all of it. So I decided to number all the lines in your code wiz and try to ask very specific questions.

That's the best way. Good plan.

Line 3 - The Dim Statement

I know how the dim statement is used in arrays, and I thought before I had a general understanding of it. It has become aparent to me that I need further understanding in order to use properly all the time. The dim statement sets dimentions and in this case to (I assume) an array called sprite? What are the values for exactly, and how do they work?

The awkwardness here is partly due to the fact that the Basic language has no data type for a single byte. So a 16x16 image takes 256 bytes, but that's 128 integers... since an integer is two bytes. Now there's an extra two integers that store the height and width, and that's why the dimension is 0..129.

The other dimension is simply the number of the sprite. I'm illustrating for you the maximum possible number of sprites that can be stored in a single array.

So a single-dimensional array is like a long chain of values, whereas a multidimensional one is like a plane or a cube. In this case we have 253 sprites that each require 260 bytes to store them.

Line 7 - The OPEN Command

In a previous program, I used the OPEN command in order to load a .txt file and save information onto it. The normal way of using it I suppose. In this case I see the WORD binary and it's used to load an image. I have a few questions here.

There's no 'normal' way to access data files. Text mode is more appropriate in some cases, and Binary is in others. Basically Text access pampers you with lots of help like the ability to read a single line easily and to break up a string of values separated by commas, etc.

Binary access lets you jump to an exact byte in the file and read x number of bytes into whatever variable you want. QB only allows me to read however many bytes are in the variable. Pascal has the more powerful BlockRead command that let me copy as many as I wanted at once (exactly 258 bytes), so it doesn't have the loop.

Can you use the OPEN command to load in any graphic or other file format? For example a gif, jpg, or an avi?

Ultimately, yes, but it's not a single-statement deal. I'm not familar with those formats, but I know AVI is an absolute nightmare to decode because it incorporates other formats into it.

Line 11 - I guess I'm just dumb

Well I'm sorry but I really don't understand this part. I know what LOF(1) is. Your taking the size of the image loaded and subtracting 768. I don't get it. Why do you subtract 768?

768 is the length of the palette. I'll get into that more farther down. I could have simply hardcoded a number of sprites for the loop to load up, but it's more elegant to have a loop that simply loads however many are there. So I subtract the palette info, and then divide the remaining number of bytes by 258, the 'bytes-per-sprite', and that gives me the number of sprites in the file.

Line 13-17 - I don't understand the logic here

Next you've launched a for loop which I assume takes the sprites and loads them into the sprite array, am I right? Simple enough I understand the Get command, is used to store everything into that little array you dimentionalized earlier and Put of coarse displays the sprite saved in umm sprite(num1 ,num2 ). Once again what does the num1, and num2 stand for?

Next your setting, according to your comments, the width and height. I don't quite follow this logic here. If it should be 16x16. Then why would you set the first one to 128 (16*8). Now besides that point I don't quite understand this. Your setting all 0s to be the width, and all heights to be 1s. Obviously it works becuase the program ran perfectly and your a genious but I miss the logic here. So your setting things to certain numbers, and playing around with width and height in a way I really don't understand.

I don't actually get it either. I got so frustrated playing with those values that I eventually just used a GET statement to cap a blank 16x16 block and then examined the first couple bytes in it. Those were the values there, so clearly if your sprites are 8x8, those lines will need to look like this:

Code:

sprite%(0, ctr) = 64
sprite%(1, ctr) = 8

Line 20-24 - The important loop I assume

Before I go on, I didn't get the translation for your variables. What does ctr stand for and what does word stand for and imply.

Now umm I assume this loop does the importand work becuase it actually stores the sprites. I'll keep this short and simple, I don't understand the proccess.

I'm not going to ask the same question on the PUT command which is further down because it will probably be answered in part with the rest of them.

As stated above, if we had a BlockRead command, this would all be a lot more intuitive. As it is, the goal of the exercise is to simply transfer the 256 bytes of raw for each sprite from the file into memory.

ctr -> the number of the sprite we're currently loading in.
word -> the current 'pair' of bytes we're copying.

In other languages, 'word' is the term for a two-byte unsigned variable. All variables in QB are signed... another gripe.

Now I've never played around with pallets before. Ever. I need someone to explain to me how the proccess works. What are palletes used for? How are they implented? And how the code in the end works?

Basically there are two ways to represent the colours in an image. The original way that programmers came up with was the indexed palette. The way it's done nowadays is by non-indexed palette. A non-indexed palette means that for every pixel on the screen, there is a red, green, and blue value stored in your memory. (prolly on the gfx card, since it ends up being like 3MBs)

But the way Indexed colour works is that instead of having RGB values for every pixel, you simply have a 'colour number', and then you have a big list elsewhere that defines for each colour number (or index) what the Red, Green, Blue intensities are.

So the palette is 768 bytes long because there's 3 bytes for each colour: R G B. 3 * 256 = 768.

Now again, the way I load it in is awkward because I need to load in a pair of bytes, grab the first little bit, backstep one, grab the next pair... etc... That's what the AND 63 does. Say we load two bytes out of the file and they look like this:

10110100 01000110

We're only interested in the first byte, and moreover, only in the 0-63 part, since that's the range for the RGB values. So we do a binary AND operation, with 63 being the other value:

10110100 01000110 AND
11111110 00000000 =
10110100 00000000

What happens is that the AND operation neatly clips off the other byte and leaves up with the value we need for our Palette statement.

As far as the syntax for that, look it up in the help, or better yet, use the OUT formula... Run a search for an old thread about it.

I have to apolize for this extremly long post and my stupidity in the subject. I'm simply not aware and a little in experienced. I'm more than willing to learn. I want to learn. I need to learn. But someone please talk, for me to listen.

No problem at all. I enjoy it.

I love this community and when I one day move onto the next language I so wish this community follows.

Heh. Not likely. But there's always the 'General Programming' board.