15 replies to this topic

[yuppicide]

I recall reading somewhere that PFVLINE is very slow. Is this true?

My work-in-progress game uses scrolling PFHLINE just fine, but the PFVLINE is slow for some reason.

The reason I want to know if the PFVLINE is slow is because I want to know if I should be looking for a coding error or if I should just not use PFVLINE at all. If PFVLINE is slow can it be made quicker?

[Random Terrain]

If you take a look at the following thread, Impaler_26 shows how slow using that stuff is compared to dealing directly with playfield variables:

http://www.atariage....howtopic=129467

[yuppicide]

That's exactly the thread I was looking for, thanks. I'll have a looksee at some code.

[yuppicide]

So, is using PFVLINE slower than using PFHLINE? I got confused with the code for Impaler's program, so I stopped reading it. I want to know if it's just
that PFVLINE routine that is slow or if I should be looking for coding errors on my part.

See, with my current code the PFHLINE comes down the screen nicely. Has a good speed to it.. let's say for example the line moves down the screen once every
half second until it reaches the bottom. With PFVLINE the line moves across my screen maybe once every 3 seconds! It's that much slower for me.

[Random Terrain]

yuppicide, on Tue Aug 5, 2008 9:06 AM, said:

So, is using PFVLINE slower than using PFHLINE? I got confused with the code for Impaler's program, so I stopped reading it. I want to know if it's just
that PFVLINE routine that is slow or if I should be looking for coding errors on my part.

See, with my current code the PFHLINE comes down the screen nicely. Has a good speed to it.. let's say for example the line moves down the screen once every
half second until it reaches the bottom. With PFVLINE the line moves across my screen maybe once every 3 seconds! It's that much slower for me.

pfhline uses 250 to 1500 processor cycles every frame depending on length (Approx 210+42*length).

pfvline uses 230 to 600 processor cycles every frame depending on length (Approx 200+34*length).

Playfield variables are faster. For example, if I wanted to make a line down part of the screen, I could do something like this:

var0=%00010000
var4=%00010000
var8=%00010000
var12=%00010000
var16=%00010000
var20=%00010000
var24=%00010000

Or I could do this:

var0{4}=1
var4{4}=1
var8{4}=1
var12{4}=1
var16{4}=1
var20{4}=1
var24{4}=1

Messing around with the playfield variables is a lot faster and you can have more control. Until the next version of bB comes out which might make pfvline and pfhline a lot faster, it's best to avoid them.

[yuppicide]

Okay, I understand. Why do you use 0, 4, 8, 12, 16, 20, and 24? I notice they are color coded on the command reference website. Why not use 0, 1, 2, 3, etc? I have Superchip enabled, so my pfres is higher.

Using that var method, how would I randomly make two sections next to eachother missing? For example right now I have it so it displays a line with two blocks missing for the player to scoot through. It's randomly done.

Random Terrain, on Tue Aug 5, 2008 10:39 AM, said:

Playfield variables are faster. For example, if I wanted to make a line down part of the screen, I could do something like this:

var0=%00010000
var4=%00010000
var8=%00010000
var12=%00010000
var16=%00010000
var20=%00010000
var24=%00010000

Or I could do this:

var0{4}=1
var4{4}=1
var8{4}=1
var12{4}=1
var16{4}=1
var20{4}=1
var24{4}=1

Messing around with the playfield variables is a lot faster and you can have more control. Until the next version of bB comes out which might make pfvline and pfhline a lot faster, it's best to avoid them.

[Random Terrain]

Read the following thread for more info:

http://www.atariage....howtopic=105089

[SeaGtGruff]

yuppicide, on Tue Aug 5, 2008 11:06 AM, said:

Okay, I understand. Why do you use 0, 4, 8, 12, 16, 20, and 24? I notice they are color coded on the command reference website. Why not use 0, 1, 2, 3, etc? I have Superchip enabled, so my pfres is higher.

The reason he used 0, 4, 8, 12, etc., is because there are four bytes for each row of the playfield. So the topmost row is made up of bytes 0, 1, 2, and 3 (i.e., var0, var1, var2, and var3), and then the next row is 4, 5, 6, 7, etc. So if you want to draw a vertical line with playfield pixels, let's say in the very first column (y position of 0), then you would want to use var0, var4, var8, var12, etc., because those are the first bytes of the playfield rows. On the other hand, if you're trying to do a horizontal line, you would use var0, var1, var2, and var3, because those bytes go across the screen.

Michael

[Impaler_26]

Random Terrain, on Tue Aug 5, 2008 4:39 PM, said:

Messing around with the playfield variables is a lot faster and you can have more control. Until the next version of bB comes out which might make pfvline and pfhline a lot faster, it's best to avoid them.

Yep, for a game like mine or yuppicide's pfhline is not really suitable but i wouldn't completely avoid it because it also has one advantage - it takes less bytes to draw a few lines with pfhline than with the playfield command.

Let's say you make a pong-style game and only need 2 lines on the screen as your playfield....

When i compile this example i have 2755 bytes of ROM space left:

start 
 COLUPF=148 

 playfield:
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 ................................
 ................................
 ................................
 ................................
 ................................
 ................................
 ................................
 ................................
 ................................
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

display
 drawscreen
 if !joy0fire then goto display
 goto start

When i compile this example, which does exactly the same just with pfhline, i have 2786 bytes of ROM space left:

start 
 COLUPF=148 

 pfhline 0 0 31 on
 pfhline 0 10 31 on

display
 drawscreen
 if !joy0fire then goto display
 goto start

So pfhline can be useful when ROM space is tight in your game and you just need a simple static playfield...

Edited by Impaler_26, Tue Aug 5, 2008 8:13 PM.

[yuppicide]

@Impaler: I already have PFHLINE's coming at you and the speed gets faster as you go along. You get points for every one that is avoided. I need PFVLINE's (or something just like it) so they come at you now. That's what I am trying to get working.

@Sea: Yeah, Random pointed me to another thread that cleared up about the 0, 4, 8, etc. Because the playfield line is broke up into 4 sections of 8.

[Impaler_26]

yuppicide, on Wed Aug 6, 2008 3:51 AM, said:

@Impaler: I already have PFHLINE's coming at you and the speed gets faster as you go along. You get points for every one that is avoided. I need PFVLINE's (or something just like it) so they come at you now. That's what I am trying to get working.

Could you post your code? I don't quite get what you mean with "so they come at you now"...
Do you mean the left and right border of the playfield should be closing in on the player?

Edited by Impaler_26, Tue Aug 5, 2008 8:48 PM.

[SeaGtGruff]

yuppicide, on Tue Aug 5, 2008 9:51 PM, said:

@Sea: Yeah, Random pointed me to another thread that cleared up about the 0, 4, 8, etc. Because the playfield line is broke up into 4 sections of 8.

I just posted an example of poking the Superchip playfield to modify it directly, but it's kind of a complicated subject, so I hope you can follow my brief explanation and example. I would have posted a longer explanation, but I'm getting ready to go to the midnight showing of "Pineapple Express"!

Michael

[yuppicide]

What I have right now is a PFHLINE that scrolls down the screen at your player.. you must dodge it. I'm trying to accomplish the same thing with PFVLINE.

Impaler_26, on Tue Aug 5, 2008 9:24 PM, said:

yuppicide, on Wed Aug 6, 2008 3:51 AM, said:

@Impaler: I already have PFHLINE's coming at you and the speed gets faster as you go along. You get points for every one that is avoided. I need PFVLINE's (or something just like it) so they come at you now. That's what I am trying to get working.

Could you post your code? I don't quite get what you mean with "so they come at you now"...
Do you mean the left and right border of the playfield should be closing in on the player?

[Random Terrain]

Impaler_26, on Tue Aug 5, 2008 7:13 PM, said:

Random Terrain, on Tue Aug 5, 2008 4:39 PM, said:

Messing around with the playfield variables is a lot faster and you can have more control. Until the next version of bB comes out which might make pfvline and pfhline a lot faster, it's best to avoid them.

Yep, for a game like mine or yuppicide's pfhline is not really suitable but i wouldn't completely avoid it because it also has one advantage - it takes less bytes to draw a few lines with pfhline than with the playfield command.

Let's say you make a pong-style game and only need 2 lines on the screen as your playfield....

When i compile this example i have 2755 bytes of ROM space left:

. . .

When i compile this example, which does exactly the same just with pfhline, i have 2786 bytes of ROM space left:

. . .

So pfhline can be useful when ROM space is tight in your game and you just need a simple static playfield...

So you have 2755 bytes left the first way and 2786 bytes left the second way, but you have 2792 bytes left if you use playfield variables to do the same thing:

start
  COLUPF=148

  var0=255:var1=255:var2=255:var3=255
  var40=255:var41=255:var42=255:var43=255

display
  drawscreen
  if !joy0fire then goto display
  goto start

Playfield variables win in this case. Not helpful if you're using Superchip RAM, though.

Edited by Random Terrain, Tue Aug 5, 2008 9:54 PM.

[Impaler_26]

yuppicide, on Wed Aug 6, 2008 5:46 AM, said:

What I have right now is a PFHLINE that scrolls down the screen at your player.. you must dodge it. I'm trying to accomplish the same thing with PFVLINE.

Ok got it now!

Random Terrain, on Wed Aug 6, 2008 5:51 AM, said:

So you have 2755 bytes left the first way and 2786 bytes left the second way, but you have 2792 bytes left if you use playfield variables to do the same thing:

start
  COLUPF=148

  var0=255:var1=255:var2=255:var3=255
  var40=255:var41=255:var42=255:var43=255

display
  drawscreen
  if !joy0fire then goto display
  goto start

Playfield variables win in this case. Not helpful if you're using Superchip RAM, though.

Yep, you're right. I'll have to play around a bit more with playfield variables then, this comes in handy for a few other ideas i have...

[SeaGtGruff]

Random Terrain, on Tue Aug 5, 2008 11:51 PM, said:

So you have 2755 bytes left the first way and 2786 bytes left the second way, but you have 2792 bytes left if you use playfield variables to do the same thing:

start
  COLUPF=148

  var0=255:var1=255:var2=255:var3=255
  var40=255:var41=255:var42=255:var43=255

display
  drawscreen
  if !joy0fire then goto display
  goto start

Playfield variables win in this case. Not helpful if you're using Superchip RAM, though.

Yes it is, except you wouldn't be able to use those variable names (var0, var1, var2, etc.). Instead, you would need to use variable names that have been defined for the Superchip RAM. I had created a Superchip include file for bB that defined 128 new Superchip RAM variable names, although each variable had two names-- a read name and a write name. These names were simply the letter r for read, or w for write, followed by the 3-digit number of the variable, from 000 to 127. For example, r010 is read variable 10, and w010 is write variable 10. However, the starting address of the Superchip playfield will vary depending on what pfres you set, so you need to figure it out for yourself. To do that, just keep in mind that the Superchip playfield always occupies the last portion of the Superchip RAM. For example, if you use a Superchip playfield that has a pfres of 12 (i.e., 12 pfrows), then that means the playfield uses 48 bytes (4*pfres=4*12=48), so that means the playfield starts at w080 and r080 (128-48=80). Or, if your Superchip playfield has a pfres of 24, that would be 96 bytes (4*pfres=4*24=96), so the playfield starts as w032 and r032 (128-96=32). Note that batari forgot to include the Superchip file with bB v1.0 when he first released it, so if you compile a bB game using the Superchip but then find that the variable names w000, w001, etc. are undefined or unknown, that means your copy of bB doesn't have the Superchip header file, or isn't using it. Fortunately, it's very simple to add it.

Anyway, assuming you're using a Superchip playfield with pfres 12, your example would be as follows:

   set romsize 8kSC
   const pfres = 12
   pfclear

start
   COLUPF=148

   w080=255:w081=255:w082=255:w083=255
   w120=255:w121=255:w122=255:w123=255

display
   drawscreen
   if !joy0fire then goto display
   goto start

Michael