Random position on playfield?

[Rabbit 2600]

How do I make the ball object have a random position on the screen?

[+Gemintronic]

ballx = rand&127

bally = rand&63

 

I mean, you could spruce that up by better fitting it within the viewable screens range. That's the basics though (I think)

 

I did the rand&127 thing because I think the viewable horizontal pixels is 150+ something. I did the rand&63 thing because I think the viewable vertical pixel range is 88+ something.

 

A horrible answer but I'm a bit sick right now. Not thinking straight

[Rabbit 2600]

Thanks for taking your time even though your sick. I greatly appreciate it. I got it up and running now perfectly =)

 

I have another question about pixels. I've read that pixels can be used pretty much like objects. How do I set up pixels? And can they be used in collisions or are they just for show?

Edited May 30, 2013 by Rabbit 2600

[SeaGtGruff]

I have another question about pixels. I've read that pixels can be used pretty much like objects. How do I set up pixels? And can they be used in collisions or are they just for show?

Yes, you can detect collisions between the playfield and the sprites (players, missiles, and ball). The only things you *can't* detect collisions with (using the collision registers) are the background and the blanking (should you ever try using the blanking to "draw" in black on the screen display).

 

Playfield pixels can sort of be used like sprites, but they're immobile, so the only way to "move" an object drawn with playfield pixels is by erasing certain playfield pixels and turning on other playfield pixels-- or, if applicable, by scrolling the playfield.

 

Given the horizontal resolution of playfield pixels, that doesn't usually work so great for horizontal "motion." But if you're drawing the playfield with a reasonably high vertical resolution then you can move a playfield pixel object vertically without it looking too horrible. For example, if you're writing a platformer game, you could use playfield pixels to draw elevators that go up and down, similar to Infiltrate.

Edited May 30, 2013 by SeaGtGruff

[Rabbit 2600]

Ah, okay. Cool! Sounds like pixels is something I want to use then! I have an experimental project where I wish to have pixels randomly placed on the screen. I'm guessing the "=rand&" command can be used for pixels? But how would I go about creating a pixel?

[SeaGtGruff]

Ah, okay. Cool! Sounds like pixels is something I want to use then! I have an experimental project where I wish to have pixels randomly placed on the screen. I'm guessing the "=rand&" command can be used for pixels? But how would I go about creating a pixel?

(1) Use the standard kernel, because the multisprite and DPC+ kernels don't support turning individual playfield pixels on and off.

 

(2) The command to draw or erase an individual playfield pixel is pfpixel. The syntax is pfpixel xpos ypos function, where xpos is the column number or horizontal coordinate (must be between 0 and 31), ypos is the row number or vertical coordinate (0 to 11 in the standard kernel, or more than 11 if you're using the Superchip option), and function is either on, off, or flip (flip will toggle it on if it's off, or toggle it off if it's on). Some examples are as follows:

 

pfpixel 14 5 on

pfpixel 21 7 off

pfpixel 3 10 flip

 

(3) You can also use pfhline to draw a horizontal line of pfpixels, or pfvline to draw a vertical line. The syntax is pfhline xstart ypos xstop and pfvline xpos ystart ystop. For example:

 

pfhline 3 4 20 - draws a horizontal line from pfpixel coordinates (3, 4) to (20, 4) - since ypos is the same in both sets of coordinates you don't list it twice

pfvline 12 3 8 - draws a vertical line from pfpixel coordinates (12, 3) to (12, 8 ) - since xpos is the same in both sets of coordinates you don't list it twice

 

(4) Be warned that it can take up more cycles to draw lines with pfhline and pfvline, or to use a large number of pfpixel statements on one frame. If you're drawing a large object with playfield pixels and moving it around, it might cost fewer cycles to just use the playfield statement to redraw the entire playfield at once-- although then you need more ROM for storing all the possible playfields. On the other hand, ROM is cheaper than cycles, since you can use bankswitching to get more ROM, whereas there's a fixed number of cycles per frame.

Edited May 31, 2013 by SeaGtGruff

[Rabbit 2600]

Ahh, now pixels don't seem so mysterious anymore! Let's say I want pixels at random location on my playfield. Then I would do this?

pfpixel rand rand on

 

Standard kernel, what is that?

[+Random Terrain]

Ahh, now pixels don't seem so mysterious anymore! Let's say I want pixels at random location on my playfield. Then I would do this?

pfpixel rand rand on

 

You'd do something similar to what theloon said:

 

  temp5 = (rand&31) : temp6 = (rand&7) + (rand/64)

  pfpixel temp5 temp6 on

 

 

ex_random_pixels_2013y_05m_31d_0931t.bin

 

ex_random_pixels_2013y_05m_31d_0931t.bas

 

In case you're wondering, I mixed in division to help make the pixels come up more randomly. Using all division or all ANDs seems to create visible patterns. Mixing it up seems to get rid of the patterns.

 

 

 

 

Standard kernel, what is that?

 

This might answer your question:

 

http://www.randomter...l#displaykernel

[Rabbit 2600]

Ahh, now I understand! Thanks everyone! And that example program you made RandomTerrain made perfect sense!

 

I got it up and running in one of my programs now =)

 

One more question! How do I set up so that when player0 touches a pixel it gets destroyed?

Edited May 31, 2013 by Rabbit 2600

[SeaGtGruff]

One more question! How do I set up so that when player0 touches a pixel it gets destroyed?

Assuming you mean the player gets destroyed, something like:

  if collision(player0,playfield) then player0:
  %00000000
end

 

Assuming you mean the pfpixel gets destroyed, something like:

  if collision(player0,playfield) then pfpixel xpos ypos off

where xpos and ypos are the coordinates of the specific playfield pixel you want to turn off. You'll probably need/want to convert the player0 coordinates to equivalent playfield coordinates to help you figure out which playfield pixel was collided with.

[Rabbit 2600]

Ah, I was a bit unclear. My apologies =)

Good thing you covered both =D I meant that i wanted the pixel to get destroyed^^

 

Hm, to convert to the player0 position would this be correct?

if collision(player0,playfield) then pfpixel player0x player0y off

Edited May 31, 2013 by Rabbit 2600

[iesposta]

pfpixel (on / off / flip) works just fine in the DPC+ Kernel.

Actually almost everything works just fine. There are some commands not implemented like pfscroll.

It is not "buggy." It doesn't produce bad code. Compiled code will run on every Atari 2600.

We're missing out on games because of misinformation, misunderstanding, and fear of using the DPC+ kernel.

(More rant accidentally deleted by mistake.)

[Rabbit 2600]

I'll check the DPC+ Kernel out =)

 

EDIT:

Wow, I think DPC+ is way out of my league at the moment. But maybe I'll be able to use it in the future.

 

Source of my game for anyone willing to take a closer look and tell me how to set up player0 collision with pfpixels.

 

 rem Generated 2013-05-31 20:37:14 by Visual bB Version 1.0.0.554
 rem **********************************
 rem *                      *
 rem *                   *
 rem *                        *
 rem *                  *
 rem *                       *
 rem **********************************
       set kernel_options player1colors playercolors pfcolors

 set kernel DPC+

     set smartbranching on

     dim rand16 = z

     dim Master_Counter = a

 scorecolor = $20

   player0x = 50
   player0y = 50
main
   f=f+1
   rem POSSIBLY INEFFICIENT CODE, SEPARATE COLOR INFO FOR EACH FRAME...
   if f = 10 then player0:
               %00100110
               %00000110
               %00110010
               %00110010
               %01100100
               %00000100
               %00111000
               %01001000
               %00100000
               %01110000
               %01010000
               %01110000
               %11000000
               %11000000
               %00000000
               %00000000
end
     if f = 10 then player0color:
       $F4;
       $F4;
       $0E;
       $0E;
       $0E;
       $0E;
       $2E;
       $2E;
       $2E;
       $2E;
       $2E;
       $06;
       $06;
       $06;
       $0E;
       $0E;
end
   if f = 20 then player0:
               %10010111
               %01000001
               %00110001
               %00110001
               %01100010
               %00000010
               %00011100
               %00100100
               %00010000
               %00111000
               %00101000
               %00111000
               %01100000
               %01100000
               %00000000
               %00000000
end
     if f = 20 then player0color:
       $F4;
       $F4;
       $0E;
       $0E;
       $0E;
       $0E;
       $2E;
       $2E;
       $2E;
       $2E;
       $2E;
       $06;
       $06;
       $06;
       $0E;
       $0E;
end

   pfcolors:
     $CE
     $CC
     $CC
     $CA
     $CA
     $C8
     $C8
     $C6
     $C6
     $C4
     $C4
     $C4
end
 

   if f=20 then f=0

   if joy0right then REFP0 = 0
   if joy0left then REFP0 = 8



   drawscreen

   if joy0right then player0x = player0x + 1
   if joy0left then player0x = player0x - 1
   if joy0up then player0y = player0y - 1
   if joy0down then player0y = player0y + 1

     temp5 = (rand&31) : temp6 = (rand&7) + (rand/64)
     pfpixel temp5 temp6 on
Skip_Pixel

   goto main

Edited May 31, 2013 by Rabbit 2600

[+Random Terrain]

pfpixel (on / off / flip) works just fine in the DPC+ Kernel.

Actually almost everything works just fine. There are some commands not implemented like pfscroll.

It is not "buggy." It doesn't produce bad code. Compiled code will run on every Atari 2600.

We're missing out on games because of misinformation, misunderstanding, and fear of using the DPC+ kernel.

(More rant accidentally deleted by mistake.)

 

Are you saying that this isn't true anymore:

 

http://atariage.com/forums/topic/73160-bug-report-thread/page__st__175#entry2248471

 

 

Are you also saying that none of this is true:

 

http://atariage.com/forums/topic/208958-collisions/

 

 

And are you saying that batari was lying when he said there were bugs:

 

http://atariage.com/forums/topic/176401-next-version-of-bb/page__st__100#entry2258509

 

 

I had to go back to the version of bB in bBWin7_64bit.zip for the standard kernel to work properly. Weird hair-pulling things can happen if you try to use the standard kernel with the DPC+ version of bB.

[iesposta]

 

 

Are you saying that this isn't true anymore:

 

http://atariage.com/forums/topic/73160-bug-report-thread/page__st__175#entry2248471

 

 

Are you also saying that none of this is true:

 

http://atariage.com/forums/topic/208958-collisions/

 

 

And are you saying that batari was lying when he said there were bugs:

 

http://atariage.com/forums/topic/176401-next-version-of-bb/page__st__100#entry2258509

 

 

I had to go back to the version of bB in bBWin7_64bit.zip for the standard kernel to work properly. Weird hair-pulling things can happen if you try to use the standard kernel with the DPC+ version of bB.

 

1. Fixed. Set DECFRACINC before every drawscreen.

2. Fixed. Also before 1.1c

3. He said there are bugs, which were fixed thru 1.1d

1.1d includes playfield commands and collision detection.

Since Cybearg joined the one missile color being black above the player has been fixed, and RevEng also fixed another bug.

[SeaGtGruff]

pfpixel (on / off / flip) works just fine in the DPC+ Kernel.

Actually almost everything works just fine. There are some commands not implemented like pfscroll.

My mistake-- obviously I'm grossly ignorant about the DPC+ kernel. I think I must have been confusing pfpixel with pfscroll, because I've seen posts from people asking whether or not pfsomethingorother works in the DPC+, and if it does then how do you use it correctly, and if it doesn't then could somebody please try to figure out how to make it work. But it makes sense that pfpixel should work since the DPC+ playfield is in RAM.

 

From now on I'll avoid saying anything about the DPC+ kernel unless I know it to be a fact-- which sadly means I might not be saying much of anything about the DPC+ kernel for a while. I'll try to remedy that.

[+Random Terrain]

1. Fixed. Set DECFRACINC before every drawscreen.

2. Fixed. Also before 1.1c

3. He said there are bugs, which were fixed thru 1.1d

1.1d includes playfield commands and collision detection.

Since Cybearg joined the one missile color being black above the player has been fixed, and RevEng also fixed another bug.

 

Thanks. Do you know where the latest fixed version can be downloaded? Adding collision detection seems like a huge fix. You'd think there would have been a new thread about it with party balloons and ice cream.

[SeaGtGruff]

Thanks. Do you know where the latest fixed version can be downloaded? Adding collision detection seems like a huge fix. You'd think there would have been a new thread about it with party balloons and ice cream.

I hate to sound any more ignorant than my recent posts have already made me sound but is there a bB installation package, or is everything still just compressed into zip files? IIRC, a while back Fred/batari had asked if anyone could help work on getting together a proper installation package (especially for Windows since he doesn't use Windows? or does he?). Did anyone ever step up and offer to help with that?

[iesposta]

Sorry Rabbit, it wasn't my intention to hijack your thread!

No, everything isn't packaged.

I get mad when it goes unrealized how great a tool we have been given.

You need the download on page 9 post 224 for 1.1d, then an exe on page 11 post 254.

To fix a timing error, an edit is shown in post 274, and the 2 edits in 275 fix the missile0 color bug.

I barely use Windows except for this and Pinball (Future and pinMAME).

 

[Rabbit 2600]

No problem. I ask so much so it's only right others get a chance to get heard

I didn't even know this kernel existed. But it seems very interesting yet daunting. When I get the hang of the "ordinary" things. I'm gonna experiment with it.

[+Random Terrain]

You may have noticed that I will create a new thread to make people aware of a new bB related tool or something. Maybe someone could do a similar thing and create a new thread with a zip file containing everything they need to use the latest non-buggy version and talk about all of the improvements. If you're a fan of something, it helps to hype it so people will know what you know. Don't get mad, get motivated.

[Rabbit 2600]

That sounds like an excellent idea =) Makes it easier to get started with it.

[iesposta]

This thread was recently started, although Atarius Maximus and myself are too busy currently.

http://atariage.com/forums/topic/209496-getting-started-with-the-dpc-kernel/

 

Don't you stop being helpful SeaGtGruff! You and RT are awesome helpful!

[bogax]

Source of my game for anyone willing to take a closer look and tell me how to set up player0 collision with pfpixels.

 

I rearranged your code

I doubt this is what you

want.

 

r_pixel.bas

[Rabbit 2600]

Hm, what a clever code! It does contain what I'm looking for. The collision detection! Thanks for doing it, now I can see how collision detection with pixels works =)

I looked through other sources with pixel collision but I could never understand it. But now I do =D

 

Now, another question. How do I set up a counter so that the pixels dosn't scramble about? So that every 1 second a pixel is placed randomly on the screen. I really don't understand counters either.

Edited June 1, 2013 by Rabbit 2600