yuppicide Posted August 5, 2008 Share Posted August 5, 2008 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? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 5, 2008 Share Posted August 5, 2008 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.com/forums/index.php?showtopic=129467 Quote Link to comment Share on other sites More sharing options...
yuppicide Posted August 5, 2008 Author Share Posted August 5, 2008 That's exactly the thread I was looking for, thanks. I'll have a looksee at some code. Quote Link to comment Share on other sites More sharing options...
yuppicide Posted August 5, 2008 Author Share Posted August 5, 2008 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 5, 2008 Share Posted August 5, 2008 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 justthat 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. Quote Link to comment Share on other sites More sharing options...
yuppicide Posted August 5, 2008 Author Share Posted August 5, 2008 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. 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 5, 2008 Share Posted August 5, 2008 Read the following thread for more info: http://www.atariage.com/forums/index.php?showtopic=105089 Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted August 5, 2008 Share Posted August 5, 2008 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 Quote Link to comment Share on other sites More sharing options...
Impaler_26 Posted August 6, 2008 Share Posted August 6, 2008 (edited) 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 August 6, 2008 by Impaler_26 Quote Link to comment Share on other sites More sharing options...
yuppicide Posted August 6, 2008 Author Share Posted August 6, 2008 @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. Quote Link to comment Share on other sites More sharing options...
Impaler_26 Posted August 6, 2008 Share Posted August 6, 2008 (edited) @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 August 6, 2008 by Impaler_26 Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted August 6, 2008 Share Posted August 6, 2008 @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 Quote Link to comment Share on other sites More sharing options...
yuppicide Posted August 6, 2008 Author Share Posted August 6, 2008 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: 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? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 6, 2008 Share Posted August 6, 2008 (edited) 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 August 6, 2008 by Random Terrain Quote Link to comment Share on other sites More sharing options...
Impaler_26 Posted August 6, 2008 Share Posted August 6, 2008 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! 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... Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted August 7, 2008 Share Posted August 7, 2008 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.