jbs30000

Actually, while I don't know about speed, looking at the list files and looking at the actual machine code, it looks like my way produces less code: My way: 1551 f4c7 .L04 ; temp1 = SWCHA / 16 1552 f4c7 1553 f4c7 ad 80 02 LDA SWCHA 1554 f4ca 4a lsr 1555 f4cb 4a lsr 1556 f4cc 4a lsr 1557 f4cd 4a lsr 1558 f4ce 85 9c STA temp1 1559 f4d0 .L05 ; player0x = player0x + Horizontal[temp1] 1560 f4d0 1561 f4d0 a5 80 LDA player0x 1562 f4d2 a6 9c LDX temp1 1563 f4d4 18 CLC 1564 f4d5 7d 92 f4 ADC Horizontal,x 1565 f4d8 85 80 STA player0x 1566 f4da .L06 ; player0y = player0y + Vertical[temp1] 1567 f4da 1568 f4da a5 85 LDA player0y 1569 f4dc a6 9c LDX temp1 1570 f4de 18 CLC 1571 f4df 7d a5 f4 ADC Vertical,x 1572 f4e2 85 85 STA player0y I count 29 bytes of code (commands and data) Old way: 1534 f4a1 .L02 ; if joy0up then player0y = player0y - 1 1535 f4a1 1536 f4a1 a9 10 lda #$10 1537 f4a3 2c 80 02 bit SWCHA 1538 f4a6 d0 02 BNE .skipL02 1539 f4a8 .condpart0 1540 f4a8 c6 85 DEC player0y 1541 f4aa .skipL02 1542 f4aa .L03 ; if joy0down then player0y = player0y + 1 1543 f4aa 1544 f4aa a9 20 lda #$20 1545 f4ac 2c 80 02 bit SWCHA 1546 f4af d0 02 BNE .skipL03 1547 f4b1 .condpart1 1548 f4b1 e6 85 INC player0y 1549 f4b3 .skipL03 1550 f4b3 .L04 ; if joy0left then player0x = player0x - 1 1551 f4b3 1552 f4b3 2c 80 02 bit SWCHA 1553 f4b6 70 02 BVS .skipL04 1554 f4b8 .condpart2 1555 f4b8 c6 80 DEC player0x 1556 f4ba .skipL04 1557 f4ba .L05 ; if joy0right then player0x = player0x + 1 1558 f4ba 1559 f4ba 2c 80 02 bit SWCHA 1560 f4bd 30 02 BMI .skipL05 1561 f4bf .condpart3 1562 f4bf e6 80 INC player0x 1563 f4c1 .skipL05 I count 32 bytes. Like I said, I don't know about speed, but it seems like like my version produces slightly less machine code. OK, it's only 3 bytes, but I'm curious where you got your 35 byte figure from.

So you're saying that: .L02 ; if joy0up then player0y = player0y - 1 lda #$10 bit SWCHA BNE .skipL02 .condpart0 DEC player0y .skipL02 .L03 ; if joy0down then player0y = player0y + 1 lda #$20 bit SWCHA BNE .skipL03 .condpart1 INC player0y .skipL03 .L04 ; if joy0left then player0x = player0x - 1 bit SWCHA BVS .skipL04 .condpart2 DEC player0x .skipL04 .L05 ; if joy0right then player0x = player0x + 1 bit SWCHA BMI .skipL05 .condpart3 INC player0x .skipL05 is shorter and faster than .L04 ; temp1 = SWCHA / 16 LDA SWCHA lsr lsr lsr lsr STA temp1 .L05 ; player0x = player0x + Horizontal[temp1] LDA player0x LDX temp1 CLC ADC Horizontal,x STA player0x .L06 ; player0y = player0y + Vertical[temp1] LDA player0y LDX temp1 CLC ADC Vertical,x STA player0y Actually, counting the opcodes, there's 16 in my method, and 14 in the regular method. Not that much different in size, but then I know that doesn't mean much when it comes to speed. Oh well, thought I found a good shortcut and wanted to share. My mistake.

I'm making a game where I'm trying to use as little code as possible, and I thought of a great way to cut down on code for using the joystick. Normally, when people check joysticks they use "if-then" statements. Well, from the information I got from the Stella Programmer's Guide I thought of a way to do it with less code. Here's a sample program that shows how to do it. data Horizontal 0,0,0,0,0,1,1,1,0,255,255,255,0,0,0,0 end data Vertical 0,0,0,0,0,1,255,0,0,1,255,0,0,1,255,0 end player0: %11111111 %11111111 %11111111 %11111111 end player0x=30: player0y=30 el temp1=SWCHA/16 player0x=player0x+Horizontal[temp1] : player0y=player0y+Vertical[temp1] COLUP0=206: drawscreen: goto el I'm guessing that everybody can figure out what I did, but just in case you have any questions, here's an explantion: As noted in the above link, SWCHA holds direction(s), if any, that the joystick is being pushed. Since player 0 is bits 4-7 I divide SWCHA by 16. The values for which way the joystick is being pushed are: 0-4 N/A, 5-Down/Right, 6-Up/Right, 7-Right, 8-N/A, 9-Down/Left, 10-Up/Left, 11-Left, 12-N/A, 13-Down, 14-Up, 15-Joystick is not being pushed in any direction. And finally, 255 is the same as -1, so in the horizontal data variable 255 means move left, and in the vertical data variable 255 means move up. I hope that some of you find this useful.

Wow, that sounds great. Actually, after looking at my post again, I'm surprised that you understood what I was asking . "you can independent width control..." should have been "you can have independent width control..."

In a post a few months ago you were talking about new options for working with missiles that might be possible with the next kernel, and you said: In the above, I bolded and underlined the part of your quote I have a question about. Are you saying that if you have a missile that is more than 1 pixel high, then you can independent width control on each row that the missile occupies?

Thanks. The playfield would look a lot nicer if pfcolors was allowed. Also, I'm not crazy about having my sprite transparent, but so far it's only way I can have all the details that I want. But at least the enemy sprites and sprites of the weapons they shoot at you look OK. Anyway, I'm going to have to start from scratch again, but thanks to Random Terrain's help, writing this game should be a whole lot easier.

Thanks, but for this game at least, I won't be using a sprite that big. But for future games I am considering using tall sprites.

Dang! I could have sworn that I deleted all of them. Hmmm....A sprite appears, but it's missing it's bottom half, and there's a shape above its head. Oh, nevermind. I recompiled and checked out the list file, and removing those return otherbanks changed the location of the sprites a little. Although changing the lo pointer to its new value $a0 draws most of the sprite, except for the top of its head. But changing the height to $14 fixed that. Well, I think I can figure out the rest from here. Thank you for all your help.

Hmmm, I thought I had it, but something isn't right. I first tried with multibank, then tried with only 1 bank. For this test code, I only put in the values for the first sprite. The list file listing for the first sprite was this: 1198 f443 a9 a6 LDA #<playerL05_0 1199 f445 1200 f445 85 a2 STA player0pointerlo 1201 f447 a9 f5 LDA #>playerL05_0 1202 f449 1203 f449 85 a3 STA player0pointerhi 1204 f44b a9 12 LDA #18 1205 f44d 85 b0 STA player0height So I put this code to place sprite 4 on the screen and do an endless drawscreen loop. Only thing is, nothing shows on the screen. data LoPointer $a6 end data HiPointer $f5 end data Height $12 end Test player4pointerlo=LoPointer[0]: player4pointerhi=HiPointer[0]: player4height=Height[0] player4x=70: player4y=70: COLUP4=10 el drawscreen: goto el And, here's the whole test program code if you need it: rem includesfile multisprite_bankswitch.inc set kernel multisprite rem set romsize 16k pfheight=1 Space_Harrier rem ****************************Player sprites*************************** rem COLUP0=170 player0: %01000100 %10101010 %10101010 %10101010 %10101010 %01010100 %00111100 %01110110 %10101001 %10101001 %10110110 %10111101 %11000011 %01011010 %00100100 %00100100 %00011000 end Gun_Fire rem COLUP0=62 player0: %00011000 %00111100 %00111100 %00111100 %00111100 %00111100 %00111100 %00011000 end return otherbank Unarmored_Ship rem ***************************Enemy sprites************************** player0: %10011001 %01111110 %00100100 %00011000 end Closed_Ship player0: %00111100 %01011110 %11101101 %11110011 %11110111 %11110111 %01110110 %00101100 end Open_Ship player0: %00011000 %00011000 %00111100 %00100100 %01011010 %01011010 %01100110 %11111111 %11100111 %11000011 end return otherbank Mellon_a rem **********************Weapons fired at Space Harrier********************** player0: %00000000 %00000000 %01111110 %11111111 %11111111 %01111110 %00000000 %00000000 end Mellon_b player0: %01100000 %11110000 %11111000 %01111100 %00111110 %00011111 %00001111 %00000110 end Mellon_c player0: %00011000 %00111100 %00111100 %00111100 %00111100 %00111100 %00111100 %00011000 end Mellon_d player0: %00000110 %00001111 %00011111 %00111110 %01111100 %11111000 %11110000 %01100000 end Blade_a player0: %00000000 %00000000 %00011001 %10100111 %11100101 %10011000 %00001000 %00011100 end Blade_b player0: %00100000 %01000000 %10111000 %00100100 %00100100 %10111101 %01000010 %00100100 end Blade_c player0: %00011100 %00001000 %10011000 %11100100 %10100100 %00011000 %00010000 %00111000 end Blade_d player0: %00100100 %01000010 %10111101 %00100100 %00100100 %10111000 %01000000 %00100000 end Blade_e player0: %00011100 %00001000 %10011000 %11100101 %10100111 %00011001 %00000000 %00000000 end Blade_f player0: %00100100 %01000010 %10111101 %00100100 %00100100 %00011101 %00000010 %00000100 end Blade_g player0: %00111000 %00010000 %00011000 %00100101 %00100111 %00011001 %00010000 %00111000 end Blade_h player0: %00000100 %00000010 %00011101 %00100100 %00100100 %10111101 %01000010 %00100100 end Fireball_a player0: %00111100 %01000010 %11111111 %11111111 %11111111 %11111111 %01111110 %00111100 end Fireball_b player0: %00111100 %00111100 %11000011 %11111111 %11111111 %11111111 %01111110 %00111100 end Fireball_c player0: %00111100 %01111110 %10111101 %11000011 %11111111 %11111111 %01111110 %00111100 end Fireball_d player0: %00111100 %01111110 %01111110 %10111101 %11000011 %11111111 %01111110 %00111100 end Fireball_e player0: %00111100 %01111110 %11111111 %01111110 %10111101 %11000011 %01111110 %00111100 end Fireball_f player0: %00111100 %01111110 %11111111 %11111111 %01111110 %10111101 %01000010 %00111100 end Fireball_g player0: %00111100 %01111110 %11111111 %11111111 %11111111 %01111110 %00111100 %00000000 end Fireball_h player0: %00111100 %01111110 %11111111 %11111111 %11111111 %11111111 %01111110 %00111100 end data LoPointer $a6 end data HiPointer $f5 end data Height $12 end Test player4pointerlo=LoPointer[0]: player4pointerhi=HiPointer[0]: player4height=Height[0] player4x=70: player4y=70: COLUP4=10 el drawscreen: goto el

Thank you Random Terrain, I'll give that a try. The 2600bas.bat I use already outputs assembly listings so I'll make a file with sprites only for player0, and look for the phi values. ETA - I added the -l%1.lst to the .bat file. I think that this will help a lot since I won't have to do GOSUBs or GOTOs to set the sprites. In fact, I think I'll try and see if I can also set the playfield without having to use gosub or goto. I think that this will be a huge help. Thank you again. MausGames, what's choppy? The sprite animations? It's really hard to get them just right.

Wow, somebody is really grouchy. If you move the player away from the rotating objects, the game doesn't freeze. And yes, nothing really happens but I'm showing the animation that I have accomplished so far. I can't show animation in a still picture.

Yes, but right now since there isn't any game play, it isn't necessary. Unless of course, you enjoy watching the, what I call the "mellon" and the blade coming at you over and over again

Well, OK, in all fairness, part of the problem is that I keep wanting to write huge, somewhat complex games instead of simple 4k games. This works fine with the regular kernel, but for the multisprite kernel it doesn't take much code before you start running into "out of range" errors when you try to goto or gosub somewhere, or sometimes the drawscreen command gives it. This time, I'm trying to make a 2600 Space Harrier (yeah, yeah, I know, you're all doing this aren't you?) Part of the problem is that I have a LOT of sprites. If somebody knows how to share sprite data in a multisprite environment, it would help me cut down on the number of sprites I use. I know how to share sprite data in the standard kernel using playerxpointerlo, playerxpointerhi, and playerxheight, but setting those in the multisprite kernel doesn't seem to work. Looking at the memory map on Random Terrain's site, I'm guessing that maybe the spritesort, and spritesort2-5 variables need to be manually set too? Anyway, here's what I have so far. The screen is animated; you can move Space Harrier around and fire the gun; and I put two enemy weapons on the screen. If they touch your player the game freezes (well, the collision routine isn't perfect and the "collision" might not register.) As you can see, the weapons are animated, and I use the NUSIZ register to enlarge them to make the appear as if they're coming towards you. There is no game to play yet because when I started writing the routines to display and move the enemy sprites, even though I didn't get an out of range error when jumping to them, the display got all screwed up, so I'll have to rewrite everything AGAIN ! Space_Harrier.bas.bin

Thanks for the explanation. I enjoy learning the inner workings of the bB kernel. Unfortunately this probably doesn't help Random Terrain though.

Ok, I figured that they were probably used for the stack. I'm glad that there is an extra variable I can use though. Thank you.

I know that the reason that the playscreen is in ROM was to free up RAM for player2-5 x and y positions, COLUP, NUSIZ, and other values. But after all that, are there any RAM locations that aren't used? I know that there are the temp variables, but I want, if possible, something more permanent. I noticed in the memory map here http://www.randomterrain.com/atari-2600-me...html#memorymaps $FA-FF aren't labeled. Are they stack variables also, or are those free to use? Thank you.

Fine, whatever. I didn't post this to be an argument. If my requests are included in the next release, then they're included. If they aren't, then they aren't.

Well yeah, there's always that. It's how I do things now. But being able to use a function directly would mean writing less code and might also free up a variable since you wouldn't need one to capture the output of a function. But anyway, like I said, it's not a big deal if that feature isn't added to the next version of bB.

This is just a wild guess, but, since with no_blank_lines you can't use missile0, I'm wondering if it isn't used to fill in the gaps. If so, then it might be hard to set it to an in-between color if two vertical pixels are different colors. But of course I could be totally wrong about that.

Say I do this: function Test_Function temp1=rand+temp2 return temp1 end on Test_Function(3) goto T1 T2 T3 T1 T2 T3 This is the output I get when I try to compile the program: ---------- Capture Output ---------- > "C:\Program Files\Atari2600\bB\2600bas.bat" C:\PROGRA~1\ATARI2~1\bB\samples\Test.bas (5): Error: Unknown keyword: on Compilation failed. > Terminated with exit code 0.

I hope I'm not bugging you by asking for two things in the next Kernel, but, and I could be wrong, I don't think that they should be that hard to implement. But if they are, or you just don't feel like doing them, that's fine too. Both requests have to do with making functions. The first is allowing multibank functions, or in other words something like: function My_Function <code> return temp1 otherbank end My_Var=My_Function(3) bank2 Or something like that. The second is being able to use them in on goto statements: on My_Function(3) goto 1 2 3 4. Thank you.

That works great. Thank you.

Oh cool, I didn't realize that.

Oh well, sorry I couldn't help. I tried searching for information on the subject but couldn't find anything. Hope someone more knowledgeable comes along soon.

Then this web site I found has a lot of cool links http://www.bjars.com/resources.html