Lillapojkenpåön

I would really appreciate some help, I can get the second ball to show up on the left and dissapear on the right side instead, or show up on both sides and dissapear in the middle, depending on where I place the wsync, but why?

I got a stable display by moving some stuff back to PosObject but the other little things remain I did this in bB but if you would like to compile then define these variables.. bally ballx ballheight missile0y missile0x missile0height temp2 temp3 temp4 lda #10 sta bally sta ballx sta ballheight lda #50 sta missile0y sta missile0x sta missile0height Main: jsr VerticalSync ; Jump to SubRoutine VerticalSync jsr VerticalBlank ; Jump to SubRoutine VerticalBlank jsr Kernel ; Jump to SubRoutine Kernel jsr OverScan ; Jump to SubRoutine OverScan jmp Main ; JuMP to Main VerticalSync: lda #2 ; LoaD Accumulator with 2 so D1=1 ldx #49 ; LoaD X with 49 sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) sta VSYNC ; Accumulator D1=1, turns on Vertical Sync signal stx TIM64T ; set timer to go off in 41 scanlines (49 * 64) / 76 sta WSYNC ; Wait for Sync - halts CPU until end of 1st scanline of VSYNC sta WSYNC ; wait until end of 2nd scanline of VSYNC lda #0 ; LoaD Accumulator with 0 so D1=0 sta WSYNC ; wait until end of 3rd scanline of VSYNC sta VSYNC ; Accumulator D1=0, turns off Vertical Sync signal rts ; ReTurn from Subroutine VerticalBlank: lda ballx ;sta HMCLR jsr PosObject lda $00 sta CTRLPF rts ; ReTurn from Subroutine ;The Kernel is the section of code that draws the screen. Kernel: sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) lda INTIM ; check the timer bne Kernel ; Branch if its Not Equal to 0 ; turn on the display sta VBLANK ; Accumulator D1=0, turns off Vertical Blank signal (image output on) ldx #0 ; Load X with 192 stx temp2 lda bally adc ballheight sta temp3 lda missile0y adc missile0height sta temp4 ;sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) ; draw the screen KernelLoop: ldy #1 ; 2 2 - D1=0, so ball will be off LDA $0E sta COLUBK ; STore X into TIA's background color register LDA temp2 ;cmp #31 ;bcs skipEnabl ;enables ball if line counter is bigger then bally and smaller then bally+ballheight cmp bally ; bcc skipEnabl ; cmp temp3 bcc DoEnabl ;falls through when first instance of ball has been drawn ;sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) ;updates ballx and finepos on line 30 cmp #30 bne skipEnabl ;inc linecounter two times because two WSYNC below ; INC temp2 INC temp2 lda missile0x ; second ballx ;sta HMCLR jsr PosObject jmp skiprepos ; DoEnabl: ; 12 - from bcs DoEnablPre iny ; 2 14 - D1=1, so ball will be on skipEnabl sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) skiprepos INC temp2 sty ENABL ; 3 17 ;enables ball second time if line counter is bigger then missile0y and smaller then missile0y+missile0height LDA temp2 cmp missile0y ; bcc skipEnabl2 ; cmp temp4 bcc DoEnabl2 ;falls through when second instance of ball has been drawn jmp skipEnabl2 DoEnabl2: lda $21 sta CTRLPF iny ; 2 14 - D1=1, so ball will be on skipEnabl2 sty ENABL ; 3 17 ;LDA temp2 CMP #192 bcc KernelLoop rts ; ReTurn from Subroutine PosObject sec sta WSYNC DivideLoop88 sbc #15 ; 2 2 - each time thru this loop takes 5 cycles, which is bcs DivideLoop88 ; 2 4 - the same amount of time it takes to draw 15 pixels eor #7 ; 2 6 - The EOR & ASL statements convert the remainder asl ; 2 8 - of position/15 to the value needed to fine tune asl ; 2 10 - the X position asl ; 2 12 asl ; 2 14 sta HMBL ; 5 19 - store fine tuning of X ;sta.wx HMBL ; 5 19 - store fine tuning of X sta RESBL ; 4 23 - set coarse X position of object sta WSYNC sta HMOVE rts ; 6 29 OverScan: sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) lda #2 ; LoaD Accumulator with 2 so D1=1 sta VBLANK ; STore Accumulator to VBLANK, D1=1 turns image output off lda #32 ; set timer for 27 scanlines, 32 = ((27 * 76) / 64) sta TIM64T ; set timer to go off in 27 scanlines ; game logic will go here ;dec bally inc ballx inc missile0x inc missile0x lda ballx ;inc SpriteXPosition; increment the desired position by 1 pixel ; ldx SpriteXPosition cmp #160 ; has it reached 160? bcc LT1606 ; this is equivalent to branch if less than lda #0 ; otherwise reload with 0 sta ballx LT1606 lda missile0x ;inc SpriteXPosition; increment the desired position by 1 pixel ; ldx SpriteXPosition cmp #160 ; has it reached 160? bcc LT16066 ; this is equivalent to branch if less than lda #0 ; otherwise reload with 0 sta missile0x LT16066 OSwait: sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) lda INTIM ; Check the timer bne OSwait ; Branch if its Not Equal to 0 rts ; ReTurn from Subroutine

I'm trying to get used to assembly by doing some cool things I couldn't do in bB like repositioning the ball in this case I'm shure someone can spot what's wrong right away A. Why is the 160 to 0 transition so unsmooth? B. Why does the second instance of the ball show up so late horisontally? (it also starts at 0) That would probably solve the jitter to C. Am I uing hmclr right? do I even need to use it? Main: jsr VerticalSync ; Jump to SubRoutine VerticalSync jsr VerticalBlank ; Jump to SubRoutine VerticalBlank jsr Kernel ; Jump to SubRoutine Kernel jsr OverScan ; Jump to SubRoutine OverScan jmp Main ; JuMP to Main VerticalSync: lda #2 ; LoaD Accumulator with 2 so D1=1 ldx #49 ; LoaD X with 49 sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) sta VSYNC ; Accumulator D1=1, turns on Vertical Sync signal stx TIM64T ; set timer to go off in 41 scanlines (49 * 64) / 76 sta WSYNC ; Wait for Sync - halts CPU until end of 1st scanline of VSYNC sta WSYNC ; wait until end of 2nd scanline of VSYNC lda #0 ; LoaD Accumulator with 0 so D1=0 sta WSYNC ; wait until end of 3rd scanline of VSYNC sta VSYNC ; Accumulator D1=0, turns off Vertical Sync signal rts ; ReTurn from Subroutine VerticalBlank: lda ballx sta HMCLR jsr PosObject sta HMBL ; 5 19 - store fine tuning of X ;sta.wx HMBL ; 5 19 - store fine tuning of X sta RESBL ; 4 23 - set coarse X position of object sta WSYNC sta HMOVE lda $00 sta CTRLPF rts ; ReTurn from Subroutine ;The Kernel is the section of code that draws the screen. Kernel: sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) lda INTIM ; check the timer bne Kernel ; Branch if its Not Equal to 0 ; turn on the display sta VBLANK ; Accumulator D1=0, turns off Vertical Blank signal (image output on) ldx #0 ; Load X with 192 stx temp2 lda bally adc ballheight sta temp3 lda missile0y adc missile0height sta temp4 ;sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) ; draw the screen KernelLoop: ldy #1 ; 2 2 - D1=0, so ball will be off LDA $0E sta COLUBK ; STore X into TIA's background color register LDA temp2 ;enables ball if line counter is bigger then bally and smaller then bally+ballheight cmp bally ; bcc skipEnabl ; cmp temp3 bcc DoEnabl ;falls through when first instance of ball has been drawn sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) ;updates ballx and finepos on line 30 cmp #30 bne skiprepos ;inc linecounter two times because two WSYNC below ; INC temp2 INC temp2 lda missile0x ; second ballx sta HMCLR jsr PosObject sta HMBL ; 5 19 - store fine tuning of X ;sta.wx HMBL ; 5 19 - store fine tuning of X sta RESBL ; 4 23 - set coarse X position of object sta WSYNC sta HMOVE jmp skiprepos ; 3 14 - $24 = BIT with zero page addressing, trick that DoEnabl: ; 12 - from bcs DoEnablPre iny ; 2 14 - D1=1, so ball will be on skipEnabl sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) skiprepos INC temp2 sty ENABL ; 3 17 ;enables ball second time if line counter is bigger then missile0y and smaller then missile0y+missile0height LDA temp2 cmp missile0y ; bcc skipEnabl2 ; cmp temp4 bcc DoEnabl2 ;falls through when second instance of ball has been drawn jmp skipEnabl2 DoEnabl2: lda $21 sta CTRLPF iny ; 2 14 - D1=1, so ball will be on skipEnabl2 sty ENABL ; 3 17 ;LDA temp2 CMP #191 bcc KernelLoop rts ; ReTurn from Subroutine PosObject sec sta WSYNC DivideLoop88 sbc #15 ; 2 2 - each time thru this loop takes 5 cycles, which is bcs DivideLoop88 ; 2 4 - the same amount of time it takes to draw 15 pixels eor #7 ; 2 6 - The EOR & ASL statements convert the remainder asl ; 2 8 - of position/15 to the value needed to fine tune asl ; 2 10 - the X position asl ; 2 12 asl ; 2 14 rts ; 6 29 OverScan: sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) lda #2 ; LoaD Accumulator with 2 so D1=1 sta VBLANK ; STore Accumulator to VBLANK, D1=1 turns image output off lda #32 ; set timer for 27 scanlines, 32 = ((27 * 76) / 64) sta TIM64T ; set timer to go off in 27 scanlines ; game logic will go here ;dec bally inc ballx inc missile0x inc missile0x lda ballx ;inc SpriteXPosition; increment the desired position by 1 pixel ; ldx SpriteXPosition cmp #160 ; has it reached 160? bcc LT1606 ; this is equivalent to branch if less than lda #0 ; otherwise reload with 0 sta ballx LT1606 lda missile0x ;inc SpriteXPosition; increment the desired position by 1 pixel ; ldx SpriteXPosition cmp #160 ; has it reached 160? bcc LT16066 ; this is equivalent to branch if less than lda #0 ; otherwise reload with 0 sta missile0x LT16066 OSwait: sta WSYNC ; Wait for SYNC (halts CPU until end of scanline) lda INTIM ; Check the timer bne OSwait ; Branch if its Not Equal to 0 rts ; ReTurn from Subroutine

Two player tetris?? Are you kidding me?! Looking forward to following the development. I think the pictures with scanlines looks perfect, and cool effect without to.

I tried making both the borders and six squares between with pf and it was a little to tight I thought making the ball eight pixels wide and putting it halway of the screen to the right would make it wrap around and be the border on both sides but skipping them and giving the enemies an extra missile might be best?

collision example.bas Here's a working example, couldn't get player0 to display right so might have found some bug 10 creates a 1 pixel gap, increase it if you like

It resets to titlescreen as soon as you finish sometimes, because your pressing the button for speed, something with the restrainer the button feels gooood, and mapping up and down to left and right in stella feels even better! Seriously, everybody has more precision left and right with a joystick and feels just as intuitive.

I would like to try and make something in assembly, including the kernel, but in Visual bB. I can do that but it's wrapped inside the standard kernel after compiling. What would be the easiest way to not have bB include anything or do anything else for me?

yup

In an experimental control build you might as well also try right=down, left=up, I would like to try that

Do you mean that when there's two sets of.. ferrets? on screen (four ferrets) then that's two different virtual sprites and not just one long? Did not expect that, but that's gonna be the easiest way to create the gaps If you use player1 player2 and player3 if player0y+6 > player1y + player1height then _skipcollisioncheck_P1 if collision(player0,player1) then... _skipcollisioncheck_P1 if player0y+6 > player2y + player2height then _skipcollisioncheck_P2 if collision(player0,player1) then... _skipcollisioncheck_P2 if player0y+6 > player3y + player3height then _skipcollisioncheck_P3 if collision(player0,player1) then... _skipcollisioncheck_P3 But unnecessary to repeat all the code, this would do the same thing I think for temp5 = 0 to 2 if player0y+6 > player1y[temp5] + player1height[temp5] then _skipcollisioncheck if collision(player0,player1) then... _skipcollisioncheck next

I have a suggestion you could try because of the perspective it would make sense if about the the top half of you could overlap with the bottom of the obstacle without getting hit I'm not shure if the obstacles are one virtual sprite or many? If it's just one, you can just do this if player0y+6 > player?y + player?height then _skipcollisioncheck if collision(player0,player1) then... _skipcollisioncheck if it's many you can use iesposta's trick dim trick = ? when you put the player on the screen just change the trick variable to one less then the player number, if player1 then set it to 0, if it's player9 then 8 if player0y+6 > player1y[trick] + player1height[trick] then _skipcollisioncheck ; skips collision if only the top 6 pixels (or less) of player0 is above the bottom of the obstacle if collision(player0,player1) then... _skipcollisioncheck if the trick variable is set to 4 then that will check player5y+player5height since player5y is the fourth byte following player1y in ram and player5height is the fourth byte after player1height. You would still hit your head when passing thru an opening in the middle but that's also fixable, this is just a way to ease into that, and possibly adding very narrow openings between stuff that you can take a chance on getting thru when panicing.

I still think that, first post updated

There are some variables that are reserved for minikernels that you can use if you're out of variables aux3 aux4 aux5 aux6 pfscorecolor scorecolor stack1 stack2 stack3 stack4 and some more that I don't know how safe they would be to use. You can also make ballheight, missile0height and missile1height constant or change it with assembly in the game and save those variables For example comment out this in the kernel ; ball ;lda #<(P1GFX-1) ;clc ;adc bally ;sta DF3TOP ;sec ;adc ballheight ;sta DF3BOT And change ballheight like this in bB asm ; ball lda #<(P1GFX-1) clc adc bally sta DF3TOP sec adc #2 ;two pixels high sta DF3BOT end it needs to be set every frame tho I think so not just in a sub where you set things, but the ballheight var is now free to use for anything, RevEng showed me that when I was in desperate need of two bytes.

Oh it's intended then I only noticed it on the snowy level That looks very activisiony, but maybe keep the green color changes to a minimum? so it looks like the score and line is just an overlay and you see the grass behind Also changed the green colors at the bottom to the same as above

This feels really good to play! Please don't rush this, you got something special going here Some stuff I noticed One of the trophies is the same color as the background of level 1 When you go full speed the objects starts looking as if they are appearing allmost in the middle of the screen, so I guess you do this.. place object all the way to the left move object at the speed your riding drawscreen so you never see it all the way to the left I would try this move object at the speed your riding place object all the way to the left drawscreen or this place object all the way to the left drawscreen move object at the speed your riding It's the exact same thing, just making it extra pedagogical Maybe try making the objects appear halfway on the screen by starting with the x position 156? and turning on the NUSIZ bits 7 and 6 for that player, could just keep them on. also wanna call attention to the black line https://youtu.be/nbinkHyWde8?t=616

What are the odds of two Swedish guys encountering this at the same time?? I moved my titlescreen font to the left so it would line up with the score in my game .byte %00111111 ; STOCK .byte %00100001 ; STOCK .byte %00100001 ; STOCK .byte %00100001 ; STOCK .byte %00100001 ; STOCK .byte %00100001 ; STOCK .byte %00100001 ; STOCK .byte %00111111 ; STOCK That's suppose to be a one and doesn't happen all the time but every time with that number, allmost looks like the first row of the two is being duplicated there. I'm using the DPC+ Kernel option with the titlescreen if that matters.

The first and last are my favourites (green and purple)

It's Futura SH Bold, the picture you posted is not a good refererence as it's reproduction labels and looks like he uses another font on some of them, the original doesn't have a space between the legs on the R.

Should say MUDDYVISION presents

Variable saving if alot of things use the same speed, I was using 16 variables for the x & y for 8 players before I came up with this If you just want to slow down the players you don't need to use the a and b variables, just replace .._fraction_counter + b with .._fraction_counter + (number between 1 and 255) and .._speed = a + 1 else _speed = a with .._speed = 1 else _speed = 0 8.8 with one variable.bas

That happens to me all the time, didn't know it was contagious, sorry

Yes it can be called anything, I made an example you can play around with, it uses playerheight instead of deathbits example.bas press up down left or right to blow the robots up, and fire to reset them

I can only speak for the DPC+ kernel, I have quite a bit of animation in my game and before I was using "on goto" to jump to the sprites and "goto" to jump back to the loop again, and the regular way to load a sprite in bB like this.. (that I was jumping to and from..) player0: %11000000 %11000000 %11000000 %11000000 end outputs something like this when assembled, except the automaticly generated name playerL02841_0 will be different LDX #<playerL02841_0 STX player0pointerlo LDA #((>playerL02841_0) & $0f) | (((>playerL02841_0) / 2) & $70) STA player0pointerhi LDA #5 STA player0height and it puts the graphic in the graphics bank playerL02841_0 .byte %11000000 .byte %11000000 .byte %11000000 .byte %11000000 .byte %11000000 That's alot of duplicate code when the animation frames start adding up, if you can just use the same code and a tall sprite and a counter that make it works more like a filmstrip. I saved cycles and 3000 bytes (not counting the graphics bank) so it was very beneficial. It looks complicated to me to i have no Idea what #((>playerL02841_0) & $0f) | (((>playerL02841_0) / 2) & $70) does or even what pointers do exactly, the nice thing is that you don't have to to still get it to work.

nevermind, this worked asm LDA #<mytext1 STA temp5 end player0pointerlo = temp5 + f asm LDA #((>mytext1) & $0f) | (((>mytext1) / 2) & $70) STA player0pointerhi end