Starting a fighting game

[Kofman]

That's an intresting trick, I suppose. I haven't completely understood the logic in my mind yet but I do understand how or why it works. Thanks nathan.

[Kofman]

Any idea why I'm getting a subscript out of range on line

Code:

sprite%(byte, sprt) = temp%

[wizardlife]

Any idea why I'm getting a subscript out of range on line

Code:

sprite%(byte, sprt) = temp%

Well, it means that either the byte value or the sprt value are outside the bounds that you set in the array at the top of the program. Most likely it's SPRT, and it's because the proggie is miscalculating how many sprites are in the file. I suggest putting in a breakpoint right after the statement with the LOF(1) and then manually checking the value of length. Divide it by 66 with a calculator and make sure that that logic is correct.

[Kofman]

Code:

SCREEN 13
CLS

DIM sprite(65, 38)

OPEN "NARUTO2.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

CLOSE #1

Apperantly program breaks when sprite%(byte,0)=tempt% is equal to sprite%(11,0) or it's 9th loop. Which makes very little sense. I looked at it a few more times but I see no real mistake in the code. I checked the logic of how and why things worked and why that should follow those numbers and it makes sense. I don't see a problem.

I have to ask my friend to upload the new .TIL file to the server on his site so i'll get that in later. If you can notice any potential problems from simply looking at the code please tell me.

[wizardlife]

The only thing I can see there that could possibly cause a problem is the dim statement. It might be better to specifically define the sprite array as being integers. (even though that's the default and nothing tells it otherwise)

DIM sprite%(65, 38)

Apart from that possible problem, I'd need to see the new til file to debug it.

[Glenn]

It's SINGLE.

[wizardlife]

Um, QB's default variable type isn't INTEGER...
It's SINGLE.

Ah hah. That might explain it then...

[Glenn]

Kofman, try the following experiment. Before making byte integer (but you should eventually do that), in the FOR/NEXT loop that uses byte for the array index, do

PRINT byte - INT(byte)

and see if you ever get anything but 0. (That will confirm that it's a SINGLE precision storage problem and that you need to use an INTEGER array index.) And you might want to do the same thing with your sprt variable.

[Kofman]

Just got home from work. Thanks allot I hope that's the problem. Although I did look at wiz's old code with water.til and wiz didn't specify the dim as an integer. Either way i'll try it now and see what happens

------------

Just checked it and I did get zero.
I changed the DIM to an integer. I still got the same error message. So I'll upload the new .til ASAP

[Glenn]

I'll try to download your .TIL file and your program tomorrow/later tonight. This just can't be a big problem.


Well, I clicked on your "here" link, above, to download your .TIL file and nothing useful happened.