Jump to content



1

Weird question about screwing up the playfield on purpose


4 replies to this topic

#1 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 20,910 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Apr 12, 2008 1:03 AM

I've done some strange things on other computers while playing around that caused the graphics to be screwed up and I used it as an effect.

Is there a way to screw up the playfield pixels so they no longer look like smooth blocks (each playfield pixel would look like it is made up of scrambled crap)?


Thanks.

#2 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,236 posts
  • begin 644 contest

Posted Sat Apr 12, 2008 1:56 AM

View PostRandom Terrain, on Sat Apr 12, 2008 2:03 AM, said:

I've done some strange things on other computers while playing around that caused the graphics to be screwed up and I used it as an effect.

Is there a way to screw up the playfield pixels so they no longer look like smooth blocks (each playfield pixel would look like it is made up of scrambled crap)?


Thanks.
Anything that causes the kernel to take an extra cycle would have that effect. There are several ways to do this, but probably the easiest is to define a player object, position it onscreen then change its pointer to something that will cause an extra cycle in the kernel, for example: player0pointer=255. bB's kernel is somewhat tolerant of such things, as they normally won't cause extra scanlines in the frame unless the distortion is really bad.

#3 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 20,910 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Apr 12, 2008 2:20 AM

View Postbatari, on Sat Apr 12, 2008 3:56 AM, said:

Anything that causes the kernel to take an extra cycle would have that effect. There are several ways to do this, but probably the easiest is to define a player object, position it onscreen then change its pointer to something that will cause an extra cycle in the kernel, for example: player0pointer=255. bB's kernel is somewhat tolerant of such things, as they normally won't cause extra scanlines in the frame unless the distortion is really bad.
Thanks. That seems to be working, but is there a way to do it without wasting a sprite? I'd love to mangle those playfield pixels and keep my sprites.

#4 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,236 posts
  • begin 644 contest

Posted Sat Apr 12, 2008 2:44 AM

View PostRandom Terrain, on Sat Apr 12, 2008 3:20 AM, said:

View Postbatari, on Sat Apr 12, 2008 3:56 AM, said:

Anything that causes the kernel to take an extra cycle would have that effect. There are several ways to do this, but probably the easiest is to define a player object, position it onscreen then change its pointer to something that will cause an extra cycle in the kernel, for example: player0pointer=255. bB's kernel is somewhat tolerant of such things, as they normally won't cause extra scanlines in the frame unless the distortion is really bad.
Thanks. That seems to be working, but is there a way to do it without wasting a sprite? I'd love to mangle those playfield pixels and keep my sprites.
The only way I can think of is to use the pfcolors kernel option and set pfcolortable=255 or a smaller value if you don't want to distort the whole playfield. The only problem I see with this method is the actual playfield colors will be hard to predict, and are likely to be all zero (black) so a non-black background may be needed to see the playfield.

#5 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 20,910 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Apr 12, 2008 2:47 AM

View Postbatari, on Sat Apr 12, 2008 4:44 AM, said:

The only way I can think of is to use the pfcolors kernel option and set pfcolortable=255 or a smaller value if you don't want to distort the whole playfield. The only problem I see with this method is the actual playfield colors will be hard to predict, and are likely to be all zero (black) so a non-black background may be needed to see the playfield.
Thanks. I'll see what kind of a mess I can make with that.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users