jbs30000

When I played around I finally had to just check the X and Y locations of each sprite to determine a collision. Unless there was an update, and I haven't seen any posts saying there was, then detecting collisions with sprites 2 - 9 isn't completed yet. This works in the "d" version. However, you have to assign colors for each player separately. They can share the same bit data, but not the same color data. Let me know if that's not clear. Of course it's clear.

Thank you! May I ask you some questions? 1. Is it too difficult (i.e. is it challenging or frustrating)? If so, which part(s) did you find too difficult? 2. Did you play all three levels? 1. I didn't try very long. I downloaded it shortly before I had to go to bed. But for now I'm thinking it's probably the right level of difficulty and it won't take too long to get use to it. 2. No, I only made it up the stairs on the first level.

Wow, that's really, really good. Very difficult too.

Yeah, something like Battlezone shouldn't be too difficult. Psudo 3D vector graphics. You'll just need to know how to calculate object rotations. I've never mastered that sort of thing myself so unfortunately I won't be able to help. Kind of related; A few years ago I tried studying raycasting techniques for making DOS (or console) type games. Even the simplest of tutorials had code that made me scratch my head. Hopefully a Battlefield type game will be easier to make.

Thank you very much. I'll fix that and see what happens.

Have you seen this post in Atari 2600 Programming? http://www.atariage.com/forums/topic/191764-plotcube-a-quick-little-3d-experiment/

Oh, and I feel like an idiot now. Since I posted the source code, I should have also posted the playfield picture file TPic.asm

Sorry, let me try to explain this way. The sprites are 8 lines high. Interlaced_C alternates between two frames. Frame 1 should be reading the even lines of sprites line 2 line 4 line 6 line 8 and displaying the pixels on even numbered scanlines. And frame 2 should be reading the odd lines and displaying them on odd scalines, so that the sprites interlace, and (with a lot of flickering ) appear to be solidly drawn. This isn't a problem for the playfield. It does this just fine. Right. But this is an interlaced kernel. I'm clearing every other line because, as stated above, the even and odd numbered scanlines are supposed to interlace together. Sorry, I'm not quiet catching what you're saying. Would you mind explaining a little bit more? Thank you.

OK, because I haven't quiet figured out how to do a two line, asymmetrical kernel I did the next best thing. I made an interlaced kernel. It works, except for one thing; The sprites. What I did was make a kernel that draws sprites on the first line, and then every other line after that, with sprites being drawn on the second line, and every other line after that. File Interlaced_A. I then made a kernel that did the opposite, drawing sprites on the first line and every other line, and then drawing the screen on the second line and every other line. File Interlaced_B. Something I noticed was the sprites turned out the same in both programs. Seeing as how one program should have been reading every odd line and the program should have been reading every even line this shouldn't have happened, but for whatever reason, it did. Anyway, I combined the two programs, Interlace_C and sure enough, while the playfield pixels (and background) are just fine, the sprites aren't whole. They still display every other scanline. I try my best to solve my own problems, but this has me stumped. If anybody can help I'd really appreciate it. Thank you. P.S. The joystick moves the smiley face. Interlaced_A.asmInterlaced_B.asmInterlaced_C.asm Interlaced_A.asm.binInterlaced_B.asm.binInterlaced_C.asm.bin

Good info. Once I eventually master 4K (hey, it'll happen ) this will be good for studying up on bank switching.

I get it now. But out of curiosity, what did you mean when you said, ?

I was just in the middle of editing that post because I thought I figured it out, but I guess I didn't. Thank you for the maps.

Ouch, I think my head exploded trying to read that. . Let me ask two questions that may help me understand better. Does a change in one location make a change in all the mirror locations (including the original if you change a mirror value)? Is only one location active at a time, or is the original and all its mirrors active at the same time?

Thank you all very much. And I see my question was answered fully in your thread jdrose. I'm kind of embarrassed now. Oops.

Out of curiosity, looking at a memory map of the 2600, what are the mirrored addresses for? Thank you.

Well, if anybody knows the read addresses for the playfield then we could make our own pfread routines as a temporary measure until an official routine is made.

OK, after studying the code I finally figured out how it works. Thank you. I also add the sprite height to the variable I'm using for "SpriteEnd" so that I can place the sprite at position 1 and still display the whole sprite.

OK, let's take this: TXA ; 2 A-> Current scannline SEC ; 2 Set Carry SBC slowP1YCoordFromBottom+1 ; 3 ADC #SPRITEHEIGHT+1 ; 2 calc if sprite is drawn BCC skipDrawRight ; 2/3 To skip or not to skip? TAY ; 2 lda P1Graphic,y ; 4 continueRight: STA GRP0 ;----- this part outside of kernel skipDrawRight ; 3 from BCC LDA #0 ; 2 BEQ continueRight ; 3 Return... What do I replace with the lda #SPRITEHEIGHT ; 2 dcp SpriteEnd ; 5 initial value has to be adjusted bcx .skipDraw ; 2 = 9 It may be obvious, but I'm totally missing it.

Actually, what I'm doing should be the skipdraw routine. Actually, it's confusing because in the Andrew Davie tutorials it's listed as skipdraw, but searching these forums and Googling there's also some version which has variables like YPosFromBot, but the only examples I can find use Subpixel positioning, but I'm not interested in that. The pixel drawing routine is fixed at 18 cycles, which is cool, but I don't think it works with lda (sprite ptr),y. Or if it does I don't know how to change the code. Adding sec to both draw routines does fix the problem, but of course adds cycles. In a post about skipdraw there's using an illegal opcode to save two cycles, but it doesn't show how to really use it. ; Thomas Jentzsch Skipdraw ;======================================================================== ;The best way, I knew until now, was (if y contains linecounter): tya ; 2 ; sec ; 2 <- this can sometimes be avoided sbc SpriteEnd ; 3 adc #SPRITEHEIGHT ; 2 bcx .skipDraw ; 2 = 9-11 cycles ; ... ; --------- or ------------ ;If you like using illegal opcodes, you can use dcp (dec,cmp) here: lda #SPRITEHEIGHT ; 2 dcp SpriteEnd ; 5 initial value has to be adjusted bcx .skipDraw ; 2 = 9 ; ... ;Advantages: ;- state of carry flag doesn't matter anymore (may save 2 cycles) ;- a remains constant, could be useful for a 2nd sprite ;- you could use the content of SpriteEnd instead of y for accessing sprite data ;- ??? ;======================================================================== ;An Example: ; ; skipDraw routine for right player TXA ; 2 A-> Current scannline SEC ; 2 Set Carry SBC slowP1YCoordFromBottom+1 ; 3 ADC #SPRITEHEIGHT+1 ; 2 calc if sprite is drawn BCC skipDrawRight ; 2/3 To skip or not to skip? TAY ; 2 lda P1Graphic,y ; 4 continueRight: STA GRP0 ;----- this part outside of kernel skipDrawRight ; 3 from BCC LDA #0 ; 2 BEQ continueRight ; 3 Return... I'm pretty much already doing the example code, +1 cycle because I'm using indirect addressing with Y instead of absolute. But I've tried changing the routine to the shorter illegal opcode version, but have no clue how to make it work.

Wow, those are great sprites. Thanks you two.

OK, one last question. I try to find answers myself for any problems I run into, but for the last one, and this one, I'm not sure what to search for. The code I have puts both players on the screen. So far so good. Player 0 is the movable face and player 1 is a stick figure. Everything is fine until I move player 0 up or down on the same scanlines as player 1. This messes up both players. BlankC.asm.binBlankC.asm

I already knew that one. It's an animated player 0.

SeaGTGruff, I always have Dasm create a list file. Thank you for the advice of deleting commented out code. I definitely will do that. For some reason I was thinking I'd have to write to it every scan-line. I thought that maybe it was like a strobe register. And I'll check out that link. Thank you.

Well, so far, (without looking at Combat or bB kernel*) I know how to put in code to display two sprites (single color) and both missiles, with no code left over to display the ball. I even figured that I have enough cycles left over to write to the VDELP1 register as suggested in post 6. And still being a beginner at 2600 asm programming** reading disassembled programs or even Batari kernels isn't easy. I've decided that I'll have to make notes, and probably even charts, on all of the code before I can decipher what's going on. * I tried looking at the bB standard kernel. It was hard to make out. ** I'm not new to asm, I've studied Intel asm. I'm just new to the 2600 registers and timing issues and so on.

Well, I played around with the timing and found I could use two sprite display routines and two simple routines to display missiles 0 and 1, but not the ball. But if I have to time when to turn on the displays...this will be interesting.