15 replies to this topic

[disjaukifa]

Hey Guys,

Trying to work with the DPC+ kernel at the moment and I can make heads or tails of some of it but other pieces are confusing to me. So far I've figured out the following and REMEMBER this could be wrong, this is just want I'm seeing on my machine:

1st. You can't use an of the var variables, meaning var0 ~ var47, just returns a compilation error.
2nd. It seems that pfclear do not work on the DPC+ kernel as well.

How do you clear the playfield? Also how to you define var0 ~ var47? Are they just not available or am I missing something? Does anyone have a reference page to DPC+ kernel (Random I'm thinking of you at the moment )

Thanks

[Random Terrain]

There are random things mentioned in batari's blog and in this thread:

http://www.atariage....-version-of-bb/

When batari has everything figured out and has the time, I assume he'll send me a bunch of new text to add to the bB page.

[disjaukifa]

Ok I read most of that and it did answer one of my questions about the variable. How do I draw the playfield and how do I clear the playfield? I'd like to use this kernel because of the increase in graphics and the stack is awesome, but it seems . . . picky I guess would be the correct term. Trying to just add something small to the code seem to cause un-expected things.

Edited by disjaukifa, Mon Sep 12, 2011 5:20 PM.

[Random Terrain]

disjaukifa, on Mon Sep 12, 2011 5:18 PM, said:

Trying to just add something small to the code seem to cause un-expected things.

That's why I'm waiting until the official release before I use it. Trying to make a program that works without going over 262 scanlines is hard enough with the regular version of bB. I don't need more mysterious errors and unexpected things happening to make it even harder.

[disjaukifa]

Random Terrain, on Mon Sep 12, 2011 6:16 PM, said:

disjaukifa, on Mon Sep 12, 2011 5:18 PM, said:

Trying to just add something small to the code seem to cause un-expected things.

That's why I'm waiting until the official release before I use it. Trying to make a program that works without going over 262 scanlines is hard enough with the regular version of bB. I don't need more mysterious errors and unexpected things happening to make it even harder.

Then I think I'll stick with the other kernel till this on has been hammer out some more. Thanks for the information Random! Other question for you Random. If I used lets say var47 and dim it 8 times, can I use it for 8 booleans? I know a nibble is for if you only need to go to 15, then you can have one variable act as two, I just wanted to be sure that I could use a on variable as 8 separate ones.


Thanks

[Random Terrain]

disjaukifa, on Mon Sep 12, 2011 6:23 PM, said:

If I used lets say var47 and dim it 8 times, can I use it for 8 booleans? I know a nibble is for if you only need to go to 15, then you can have one variable act as two, I just wanted to be sure that I could use a on variable as 8 separate ones.

If you mean you want to use 8 different aliases for 8 bits of one variable, then yes. Here's an example:

   rem  ================================================================
   rem  -
   rem  -  Player0/Player1 direction bits.
   rem  -
   rem  ----------------------------------------------------------------

   dim BitOp_P0_P1_Direction = u
   dim Bit0_Player0_Direction_Up = u
   dim Bit1_Player0_Direction_Down = u
   dim Bit2_Player0_Direction_Left = u
   dim Bit3_Player0_Direction_Right = u
   dim Bit4_Player1_Direction_Up = u
   dim Bit5_Player1_Direction_Down = u
   dim Bit6_Player1_Direction_Left = u
   dim Bit7_Player1_Direction_Right = u



   if Bit0_Player0_Direction_Up{0} then blah blah blah

   if Bit2_Player0_Direction_Left{2} then blah blah blah

Check out the code for this example program:

http://www.randomter...html#maze_32x23

Edited by Random Terrain, Mon Sep 12, 2011 6:35 PM.

[disjaukifa]

Random Terrain, on Mon Sep 12, 2011 6:34 PM, said:

disjaukifa, on Mon Sep 12, 2011 6:23 PM, said:

If I used lets say var47 and dim it 8 times, can I use it for 8 booleans? I know a nibble is for if you only need to go to 15, then you can have one variable act as two, I just wanted to be sure that I could use a on variable as 8 separate ones.

If you mean you want to use 8 different aliases for 8 bits of one variable, then yes. Here's an example:

   rem  ================================================================
   rem  -
   rem  -  Player0/Player1 direction bits.
   rem  -
   rem  ----------------------------------------------------------------

   dim BitOp_P0_P1_Direction = u
   dim Bit0_Player0_Direction_Up = u
   dim Bit1_Player0_Direction_Down = u
   dim Bit2_Player0_Direction_Left = u
   dim Bit3_Player0_Direction_Right = u
   dim Bit4_Player1_Direction_Up = u
   dim Bit5_Player1_Direction_Down = u
   dim Bit6_Player1_Direction_Left = u
   dim Bit7_Player1_Direction_Right = u



   if Bit0_Player0_Direction_Up{0} then blah blah blah

   if Bit2_Player0_Direction_Left{2} then blah blah blah

Check out the code for this example program:

http://www.randomter...html#maze_32x23

That answer my question! Ok one more question though, when you have the following:

if Bit0_Player0_Direction_Up{0} then blah blah blah, what is the value of that bit to be true? 1 or 0? My guess is 1, but I want to be sure.

Thanks

[Random Terrain]

disjaukifa, on Mon Sep 12, 2011 6:39 PM, said:

That answer my question! Ok one more question though, when you have the following:

if Bit0_Player0_Direction_Up{0} then blah blah blah, what is the value of that bit to be true? 1 or 0? My guess is 1, but I want to be sure.

Right. Check out the Did You Know? box here for more information:

http://www.randomter...mmands.html#bit

[ScumSoft]

disjaukifa, on Mon Sep 12, 2011 4:22 PM, said:

1st. You can't use an of the var variables, meaning var0 ~ var47, just returns a compilation error.
2nd. It seems that pfclear do not work on the DPC+ kernel as well.

How do you clear the playfield? Also how to you define var0 ~ var47? Are they just not available or am I missing something? Does anyone have a reference page to DPC+ kernel (Random I'm thinking of you at the moment )

1) Nope can't use them, they existed in the original to keep the playfield in ram and are now used for the virtual sprites stuff.
2) pfread, pfclear and pfscroll aren't implemented yet. To define a playfield either build it with pfpixel, pfvline x(start) y x(end), pfhline x(start) y x(end) or:

 rem always set the DF#FRACINC at least once before attempting to draw
 rem the playfields or backgrounds
  DF0FRACINC     = 16 ;16 = 11 rows of playfield, 32 is 22 ect
  DF1FRACINC     = 16 
  DF2FRACINC     = 16
  DF3FRACINC     = 16
  DF4FRACINC     = 32 ;PFcolors table, Always double the playfields
  DF6FRACINC     = 32 ;BKcolors table
 
 bkcolors:
 $1E
 $2E
 $3E
 $4E
 $5E
 $6E
 $7E
 $8E
 $9E
 $AE
 $BE
end
 pfcolors:
 $02
 $04
 $06
 $08
 $02
 $04
 $06
 $08
 $02
 $04
 $06
end
 playfield:
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

  rem and to clear the playfield just define an empty playfield:
 playfield:
 ...............................
end

For defining multiple things to a variable for bit operations it's as easy as:

 dim MULTIVAR = a

 def Switch7=MULTIVAR{7}
 def Switch6=MULTIVAR{6}
 def Switch5=MULTIVAR{5}
 def Switch4=MULTIVAR{4}
 def Switch3=MULTIVAR{3}
 def Switch2=MULTIVAR{2}
 def Switch1=MULTIVAR{1}
 def Switch0=MULTIVAR{0}

 rem then to test if the switch is on
 if switch1 then goto SWITCH1_is_on 
 
 rem to test if a switch is off
 if !switch1 then goto SWITCH1_is_off

 rem be sure to watch your capitals, because a label with the same
 rem spelling in it as a variable will confuse the compiler

SWITCH1_is_on ;is different then Switch1 and switch1

 rem however
Switch1_is_on ;Will confuse the compiler since Switch1 is the same as the var Switch1
              ;and it will try to convert the label into an invalid instruction

Hope this helped.

Edited by ScumSoft, Mon Sep 12, 2011 7:42 PM.

[disjaukifa]

ScumSoft, on Mon Sep 12, 2011 7:38 PM, said:

disjaukifa, on Mon Sep 12, 2011 4:22 PM, said:

1st. You can't use an of the var variables, meaning var0 ~ var47, just returns a compilation error.
2nd. It seems that pfclear do not work on the DPC+ kernel as well.

How do you clear the playfield? Also how to you define var0 ~ var47? Are they just not available or am I missing something? Does anyone have a reference page to DPC+ kernel (Random I'm thinking of you at the moment )

1) Nope can't use them, they existed in the original to keep the playfield in ram and are now used for the virtual sprites stuff.
2) pfread, pfclear and pfscroll aren't implemented yet. To define a playfield either build it with pfpixel, pfvline x(start) y x(end), pfhline x(start) y x(end) or:

 rem always set the DF#FRACINC at least once before attempting to draw
 rem the playfields or backgrounds
  DF0FRACINC     = 16 ;16 = 11 rows of playfield, 32 is 22 ect
  DF1FRACINC     = 16 
  DF2FRACINC     = 16
  DF3FRACINC     = 16
  DF4FRACINC     = 32 ;PFcolors table, Always double the playfields
  DF6FRACINC     = 32 ;BKcolors table
 
 bkcolors:
 $1E
 $2E
 $3E
 $4E
 $5E
 $6E
 $7E
 $8E
 $9E
 $AE
 $BE
end
 pfcolors:
 $02
 $04
 $06
 $08
 $02
 $04
 $06
 $08
 $02
 $04
 $06
end
 playfield:
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

  rem and to clear the playfield just define an empty playfield:
 playfield:
 ...............................
end

For defining multiple things to a variable for bit operations it's as easy as:

 dim MULTIVAR = a

 def Switch7=MULTIVAR{7}
 def Switch6=MULTIVAR{6}
 def Switch5=MULTIVAR{5}
 def Switch4=MULTIVAR{4}
 def Switch3=MULTIVAR{3}
 def Switch2=MULTIVAR{2}
 def Switch1=MULTIVAR{1}
 def Switch0=MULTIVAR{0}

 rem then to test if the switch is on
 if switch1 then goto SWITCH1_is_on 
 
 rem to test if a switch is off
 if !switch1 then goto SWITCH1_is_off

 rem be sure to watch your capitals, because a label with the same
 rem spelling in it as a variable will confuse the compiler

SWITCH1_is_on ;is different then Switch1 and switch1

 rem however
Switch1_is_on ;Will confuse the compiler since Switch1 is the same as the var Switch1
              ;and it will try to convert the label into an invalid instruction

Hope this helped.

Scumsoft thank you for the example of how to get the playfield to appear on the screen. I'll mess with it tonight to see if I can get it working. Question for you guys, unlike a sprite that has to be in your main game loop, once a playfield has been drawn, you don't need to have it draw again in the main loop right? You only need to call it once from what I'm seeing in testing. Thanks!

Edited by disjaukifa, Tue Sep 13, 2011 8:12 AM.

[ScumSoft]

Yup unlike the normal kernals the DPC+ remembers what your objects and playfield are.

Edited by ScumSoft, Tue Sep 13, 2011 4:15 PM.

[disjaukifa]

ScumSoft, on Tue Sep 13, 2011 4:15 PM, said:

Yup unlike the normal kernals the DPC+ remembers what your objects and playfield are.

!!!!!! You mean I don't have to have the sprite data in the main loop?

[Random Terrain]

disjaukifa, on Tue Sep 13, 2011 4:17 PM, said:

ScumSoft, on Tue Sep 13, 2011 4:15 PM, said:

Yup unlike the normal kernals the DPC+ remembers what your objects and playfield are.

!!!!!! You mean I don't have to have the sprite data in the main loop?

The regular kernel doesn't need to have playfield data or sprite data in the main loop. Whatever you tell the playfield or sprites to look like before the main loop starts is what they'll look like forever until you tell them to look differently.

[disjaukifa]

Random Terrain, on Tue Sep 13, 2011 5:17 PM, said:

disjaukifa, on Tue Sep 13, 2011 4:17 PM, said:

ScumSoft, on Tue Sep 13, 2011 4:15 PM, said:

Yup unlike the normal kernals the DPC+ remembers what your objects and playfield are.

!!!!!! You mean I don't have to have the sprite data in the main loop?

The regular kernel doesn't need to have playfield data or sprite data in the main loop. Whatever you tell the playfield or sprites to look like before the main loop starts is what they'll look like forever until you tell them to look differently.

. . . . Somehow . . . somehow . . . . I completely missed that fact when I started all of this . . .

Lets just say this . . . this is a major game changer for me. Major!

[Random Terrain]

disjaukifa, on Tue Sep 13, 2011 5:22 PM, said:

. . . . Somehow . . . somehow . . . . I completely missed that fact when I started all of this . . .

Next time I go to edit the bB page, I'll try to remember to add a Did You Know? box that mentions that.

[disjaukifa]

Random Terrain, on Tue Sep 13, 2011 5:52 PM, said:

disjaukifa, on Tue Sep 13, 2011 5:22 PM, said:

. . . . Somehow . . . somehow . . . . I completely missed that fact when I started all of this . . .

Next time I go to edit the bB page, I'll try to remember to add a Did You Know? box that mentions that.

Now your just trying to make me feel special