Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Starting a fighting game
#31
Quote: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.
Quote: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.

Quote: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.
Quote: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.
Quote: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.

Quote: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.

Quote: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
Quote: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.

Quote: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.

Quote: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.
Quote: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.
Reply
#32
If I followed your reply correctly it seems like this is just one way of dozens of how to load in bytes from an image into memory. Then again it could just be me. I think I understand the whole byte system allot better now. For example the pallate makes almost perfect sense to me. Still I see some gray in the code that doesn't quite make sense to me yet. But not allot this time.

Going back to the DIM statement, the second value is the amount of sprites we can store. Now how exactly do we know how many sprites to store, and are we limited by anything. In other words how did you know to decide on 252 sprites.

Concerning the first variable in the DIM statememnt. I think you explained that so clearly that 5th grader could understand. So if I had 8x8 sprites, my dim would look like the following:

Code:
DIM sprite(65, ???)

I have a visual understanding of multidimentional arrays. Yet I'm slightly confused where the numbers 253, 260 came from.

Quote: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.

Next you've explained to me the width and the height. While I could memorize the general formula behind it which isn't hard. It still makes me wonder why a little bit.

Quote: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.
How did you decide on each sprite being 258 bytes? The closest thing I can think of here is 256 which I thought it should have been? What's with the extra two bytes per sprite? Width and Height?

That's pretty much it. My major concern is what do the two variables sprite( , ) stand for. I didn't get that part. And the second part is some, just a few of the numbers don't make sense to me yet.

Lastly in the pallates, why 63? Could it be any number or umm?

Once again thanks allot for all this help.
·····································LINEAR INC·····································
Ø-----------------------------------------------------------------------O
From Problem to Solution - We take the shortest distance
Reply
#33
Quote:If I followed your reply correctly it seems like this is just one way of dozens of how to load in bytes from an image into memory. Then again it could just be me. I think I understand the whole byte system allot better now. For example the pallate makes almost perfect sense to me. Still I see some gray in the code that doesn't quite make sense to me yet. But not allot this time.
It's simply data that you need to get from the file into memory, and ultimately onto the screen. There are lots of way you could do it, and when you get into compressed files, dozens of ways to could decode the info.

Quote:Going back to the DIM statement, the second value is the amount of sprites we can store. Now how exactly do we know how many sprites to store, and are we limited by anything. In other words how did you know to decide on 252 sprites.
Memory is divided into Segments. Within each segment is 64000 bytes. So a memory address is the segment and the offset. But a single data type (read: array) can't be larger than 64k.

Quote:Concerning the first variable in the DIM statememnt. I think you explained that so clearly that 5th grader could understand. So if I had 8x8 sprites, my dim would look like the following:

Code:
DIM sprite(65, ???)
That is correct. Save the code into a separate file, and make some dummy sprites with the Spriter program to be sure, tho.
Quote:I have a visual understanding of multidimentional arrays. Yet I'm slightly confused where the numbers 253, 260 came from.
what numbers?
Quote:Next you've explained to me the width and the height. While I could memorize the general formula behind it which isn't hard. It still makes me wonder why a little bit.

How did you decide on each sprite being 258 bytes? The closest thing I can think of here is 256 which I thought it should have been? What's with the extra two bytes per sprite? Width and Height?
That is correct. In my file, there is just one byte for the height and width, whereas in the QB format, there are two bytes for each...
Quote:Lastly in the pallates, why 63? Could it be any number or umm?
The range for mode 13h is 0..63 for each colour.
Reply
#34
Oh, thank you. Now it's time to experiement and read up a few sources.
·····································LINEAR INC·····································
Ø-----------------------------------------------------------------------O
From Problem to Solution - We take the shortest distance
Reply
#35
Today I finally began to understand your code. Really understand it.
·····································LINEAR INC·····································
Ø-----------------------------------------------------------------------O
From Problem to Solution - We take the shortest distance
Reply
#36
I'm getting an error from my code can you see what's wrong with it.

Code:
SCREEN 13
CLS

DIM sprite(65, 43)

OPEN "SASUKE.TIL" FOR BINARY AS #1

length = LOF(1) - 768

FOR sprt = 0 TO length / 258 - 1

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

        FOR byte = 2 TO 65
                GET #1, (sprt * 258) = (byte * 2), temp%
                sprite%(byte, sprt) = temp%
        NEXT
        PUT (sprt * 18 + 1, 150), sprite(0, sprt), PSET
NEXT

You can get the .TIL file here

Thank You for Your help
·····································LINEAR INC·····································
Ø-----------------------------------------------------------------------O
From Problem to Solution - We take the shortest distance
Reply
#37
I don't have time to d/l the code right now and make it work, but right off the bat, this line confuses me:
Code:
GET #1, (sprt * 258) = (byte * 2), temp%
If your sprites are 8x8, then there's 64 bytes for each, which means it should be 32 words, plus two for the height and width. Shouldn't that section be more like:
Code:
FOR sprt = 0 TO (length / 66) - 1

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

        FOR word = 2 TO 33
                GET #1, (sprt * 66) + (word * 2), temp%
                sprite%(word, sprt) = temp%
        NEXT
        PUT (sprt * 18 + 1, 150), sprite(0, sprt), PSET
NEXT
Reply
#38
Oh Hehehe, thanks. Stupid, stupid stupid.
·····································LINEAR INC·····································
Ø-----------------------------------------------------------------------O
From Problem to Solution - We take the shortest distance
Reply
#39
I'm getting a subscript out of range error

Code:
SCREEN 13
CLS

DIM sprite(65, 43)

OPEN "SASUKE.TIL" FOR BINARY AS #1

length = LOF(1) - 768

FOR sprt = 0 TO (length / 66) - 1

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

        FOR byte = 2 TO 33
                GET #1, (sprt * 66) + (byte * 2), temp%
                sprite%(byte, sprt) = temp%
        NEXT
        PUT (sprt * 18 + 1, 150), sprite(0, sprt), PSET
NEXT

I made 44 tiles in your program all of them weir 8x8.
I included the link to the file just in case you needed to make sure. I didn't think you'd actually run it.

One more thing just make sure, becuase I'm just a tad bit unclear on the subject of how you insert the sprite.

PUT (x,y),sprite(0,whatever sprite needed), PSET

What puzzles me, is the zero. Will it always be a constant zero whenever I call up a sprite?
·····································LINEAR INC·····································
Ø-----------------------------------------------------------------------O
From Problem to Solution - We take the shortest distance
Reply
#40
That constant zero is 'cause QB orders its arrays in columns and not in files. In C, for example, if you have a 4x4 array you have in fact a 4 files array of 4 columns.

When you have an array a%(10,10), C stores it in files, so you have in memory (1,1), (1,2), (1,3)...(2,1),(2,2)...(10,10). QB stores it in columns, so you have (1,1), (2,1), (3,1), ...,(1,2), (2,2), ... (10,10).

A sprite is just a list of numbers stored one after another in memory. When you set up an array that contains several sprites, you have data for the first sprite, then data for the second, then data for the third and so on, allocated in memory one right after the previous. When you PUT a sprite, the last parameter is, in fact, some kind of pointer that tells QB where the data it has to plot starts. As QB stores the data in columns and not in rows, you have to point your nth sprite as (0,n) and not as (n,0).

I know this is VERY confusing Tongue
SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)