jbs30000 Posted August 5, 2009 Share Posted August 5, 2009 This might be of some interest to some of you, unless this topic was done before The program simply demonstrates scrolling through a playfield that's taller than what can be displayed (I drew a playfield 24 pixels high using the standard kernel and the 32x24 pixel playfield). I was going to explain a few things, but then realized I might telling people what they already know, and I hate it when people do that to me, so I'll just post the program and source code and if you have any questions I'll answer them. When you start the program, you'll see 1 displayed on the screen. Push the joystick up, and the one will scroll off screen while the number 2 scrolls onscreen. Of course pressing the joystick down will have the opposite effect. Boring, I know, but again, it's just a scrolling demo. It's pretty fast, so if you decide to use this technique I'd advise adding code to slow things down. Although I've programmed as a hobby for a long time I'm not always good at optimizing my code. If you think I'm using too many commands, or my coding looks sloppy, or if you can think of any way to optimize it, I'd love to hear about it. default.basdefault.bas.bin Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 5, 2009 Author Share Posted August 5, 2009 I made a triple high screen, put three houses and a road, like in Paperboy....well, the actual house graphics turned out to be crap even though they looked good in the batari visual basic playfield editor, but it's a little bit better demo than just two numbers. I also now realize I should have made pushing up scroll up and pushing down scroll down. Oh well. Scroll3.bas scroll3.bas.bin Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 5, 2009 Share Posted August 5, 2009 Can't wait to play with your code. Thanks. Quote Link to comment Share on other sites More sharing options...
jrok Posted August 5, 2009 Share Posted August 5, 2009 I made a triple high screen, put three houses and a road, like in Paperboy....well, the actual house graphics turned out to be crap even though they looked good in the batari visual basic playfield editor, but it's a little bit better demo than just two numbers. I also now realize I should have made pushing up scroll up and pushing down scroll down. Oh well. Scroll3.bas scroll3.bas.bin Neat! Hmm... curious why the below doesn't seem to compile. I was trying to modify your houses to loop when reaching either data limit, but DASM throws an error that it doesn't recognize "Data_Start." In fact, no operation of any kind seems to work in that if-then statement... only a return. Can anyone suss out why? Up_Scroll rem if Data_Start >= 144 then return if Data_Start >= 144 then Data_Start=0 Data_Start = Data_Start + 4 for temp1 = 0 to 47 temp2 = Data_Start + temp1 playfield[temp1] = PF_data0[temp2] next return Down_Scroll rem if Data_Start = 0 then return if Data_Start = 0 then Data_Start=144 Data_Start = Data_Start - 4 for temp1 = 0 to 47 temp2 = Data_Start + temp1 playfield[temp1] = PF_data0[temp2] next return Quote Link to comment Share on other sites More sharing options...
CurtisP Posted August 5, 2009 Share Posted August 5, 2009 Added four lines of code to do smooth scrolling. Since indexes are limited to a single byte (0-255), the most lines you can have in your playfield is 64. Scroll3A.bas Scroll3A.bin Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 5, 2009 Author Share Posted August 5, 2009 I made a triple high screen, put three houses and a road, like in Paperboy....well, the actual house graphics turned out to be crap even though they looked good in the batari visual basic playfield editor, but it's a little bit better demo than just two numbers. I also now realize I should have made pushing up scroll up and pushing down scroll down. Oh well. Scroll3.bas scroll3.bas.bin Neat! Hmm... curious why the below doesn't seem to compile. I was trying to modify your houses to loop when reaching either data limit, but DASM throws an error that it doesn't recognize "Data_Start." In fact, no operation of any kind seems to work in that if-then statement... only a return. Can anyone suss out why? Up_Scroll rem if Data_Start >= 144 then return if Data_Start >= 144 then Data_Start=0 Data_Start = Data_Start + 4 for temp1 = 0 to 47 temp2 = Data_Start + temp1 playfield[temp1] = PF_data0[temp2] next return Down_Scroll rem if Data_Start = 0 then return if Data_Start = 0 then Data_Start=144 Data_Start = Data_Start - 4 for temp1 = 0 to 47 temp2 = Data_Start + temp1 playfield[temp1] = PF_data0[temp2] next return Strange, I put dim Data_Start=a at the beginning of the program so I don't know why Dasm isn't recognizing it. The only thing I can think of right now without trying the changes you made is that the error is actually something else but it's telling you that it's with the variable. Also, one minor thing. You probably want to make pressing the joystick up do this: if Data_Start >= 144 then Data_Start=0 else Data_Start = Data_Start + 4 And pressing the joystick down go: if Data_Start = 0 then Data_Start=144 else Data_Start = Data_Start - 4 Because right now, if you reach the end and start over, if you're pressing up you reset to 0, and then immediately jump to the second row, or if you're pressing down you reset to the last 12 rows, and then immediately jump up a row. Anyway, I'll make the changes on my computer later and see if I get the same error. Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 5, 2009 Author Share Posted August 5, 2009 Added four lines of code to do smooth scrolling. Since indexes are limited to a single byte (0-255), the most lines you can have in your playfield is 64. Yeah, slowing down the scrolling is easy, I was just being lazy I do find your code interesting. It looks like something I can learn from. Oh, and since the "houses" are unrecognizable, here's a picture of how they showed up on the Visual Batari Basic playfield editor. They still don't look that great, but they look a lot better than what the program displays. Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 5, 2009 Author Share Posted August 5, 2009 Oh, and jrok, I just changed my code to loop, and it works for me Up_Scroll rem if Data_Start >= 144 then return rem Data_Start = Data_Start + 4 if Data_Start >= 144 then Data_Start = 0 else Data_Start = Data_Start + 4 for temp1 = 0 to 47 temp2 = Data_Start + temp1 playfield[temp1] = PF_data0[temp2] next return Down_Scroll rem if Data_Start = 0 then return rem Data_Start = Data_Start - 4 if Data_Start = 0 then Data_Start = 144 else Data_Start = Data_Start - 4 for temp1 = 0 to 47 temp2 = Data_Start + temp1 playfield[temp1] = PF_data0[temp2] next return And of course, if you can get it to work, adding CurtisP's code to smooth the scrolling would make it look nicer still. Quote Link to comment Share on other sites More sharing options...
jrok Posted August 5, 2009 Share Posted August 5, 2009 Also, one minor thing. You probably want to make pressing the joystick up do this:if Data_Start >= 144 then Data_Start=0 else Data_Start = Data_Start + 4 And pressing the joystick down go: if Data_Start = 0 then Data_Start=144 else Data_Start = Data_Start - 4 Because right now, if you reach the end and start over, if you're pressing up you reset to 0, and then immediately jump to the second row, or if you're pressing down you reset to the last 12 rows, and then immediately jump up a row. Ah, right. Good point. Anyway, I'll make the changes on my computer later and see if I get the same error. For me, it's throwing exactly the same sort of error I'd expect if Data_Start was an undefined variable or Jump Label. But it doesn't seem to be a problem with the named variable itself. In fact, you could put anything in that statement (like "if Data_Start = 0 then b=5") and it wouldn't be able to resolve "b" either. Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 5, 2009 Author Share Posted August 5, 2009 For me, it's throwing exactly the same sort of error I'd expect if Data_Start was an undefined variable or Jump Label. But it doesn't seem to be a problem with the named variable itself. In fact, you could put anything in that statement (like "if Data_Start = 0 then b=5") and it wouldn't be able to resolve "b" either. I hesitate to ask, but have you made sure that there's a space before "if"? That's the only things that springs to mind. Quote Link to comment Share on other sites More sharing options...
bongomeno Posted August 5, 2009 Share Posted August 5, 2009 holycrap! that looks like zaxxon! maby I should make a zaxxon clone! Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted August 5, 2009 Share Posted August 5, 2009 (edited) You know, if you create two playfields, use two different playfield colors, use two different as well as two different background colors, and flicker between them, you could get four colors in all, which could make it possible to have green grass, red brick houses, and two other colors-- maybe brown for the roofs, and gray for the pavement. It would depend on how you picked your colors. And there would definitely be flickering-- although, depending on the colors you pick (as well as the TV used), it might not be *too* bad! You might also be able to create a scrolling pfcolors table (or two of them) to go with the scrolling playfield. Michael Edited August 5, 2009 by SeaGtGruff Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 5, 2009 Author Share Posted August 5, 2009 holycrap! that looks like zaxxon! maby I should make a zaxxon clone! There you go. I'm glad my contribution may help people create good games. Some info for anybody who wants to use this method. Since a variable can only hold a value up to 255 then you can only create a single playfield that's 72 pixels high, or 6 times the height that can be displayed on the screen (for a standard 32x12 playfield display). I'll show some numbers below to show what I mean. A single standard 32x12 screen (only 11 pixels high are visible, I know) is 48 bytes; 4 bytes per row, 12 rows per screen. 1X Rows 0 - 12 start at offset 0, so Data_Start (or whatever you name your variable) starts at 0. 2X Rows 13 - 24 Data_Start = 48 3X Rows 25 - 36 Data_Start = 96 4X Rows 37 - 48 Data_Start = 144 5X Rows 49 - 60 Data_Start = 192 6X Rows 61 - 72 Data_Start = 250 So if you want a playfield over 6X high, just simply do another playfield: statement and remember this if you don't already know it. The first playfield: statement creates a label in asm PF_data0, which is why you see that variable in my program. The second playfield: statement creates PF_data1, and so on. Quote Link to comment Share on other sites More sharing options...
Animan Posted August 5, 2009 Share Posted August 5, 2009 You, sir, have quite possibly may have become a reason many more batari games come out. Thanks you, it will be a help to us all. Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 6, 2009 Author Share Posted August 6, 2009 You, sir, have quite possibly may have become a reason many more batari games come out. Thanks you, it will be a help to us all. I don't know if my discovery is THAT big, but thank you for the praise. Quote Link to comment Share on other sites More sharing options...
Animan Posted August 6, 2009 Share Posted August 6, 2009 You, sir, have quite possibly may have become a reason many more batari games come out. Thanks you, it will be a help to us all. I don't know if my discovery is THAT big, but thank you for the praise. You welcome. Quote Link to comment Share on other sites More sharing options...
yuppicide Posted August 6, 2009 Share Posted August 6, 2009 This looks amazing! I feel bad when I come out with a puzzle game based on colored squares moving around, and you guys come out with all the cool looking stuff.. Quote Link to comment Share on other sites More sharing options...
+Allan Posted August 6, 2009 Share Posted August 6, 2009 It reminds me of Paperboy. Allan Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 6, 2009 Author Share Posted August 6, 2009 (edited) You know, if you create two playfields, use two different playfield colors, use two different as well as two different background colors, and flicker between them, you could get four colors in all, which could make it possible to have green grass, red brick houses, and two other colors-- maybe brown for the roofs, and gray for the pavement. It would depend on how you picked your colors. And there would definitely be flickering-- although, depending on the colors you pick (as well as the TV used), it might not be *too* bad! You might also be able to create a scrolling pfcolors table (or two of them) to go with the scrolling playfield. Michael I've tried switching between two playfields and the flicker was absolutely horrible. Although maybe manually filling the playfield ram with the value of data statements might work. And as for scrolling colors, I don't know how coloring the screen works. You probably do, so if you could show me that would be great. Otherwise, I guess I'll need to study asm output. OK, as I'm typing this, I have decided to try two screens. I took my first example of a playfield with 1 and a playfield of 2 and flicker between them. Since I think that pfcolor might be slower than COLUPF, I'm using COLUPF. The 1 is red, and the 2 is green. I'm using the playfield[offset] variable to draw the screen. Apparently green and red overlapping make orange. And it seems that the flicker isn't as bad as I remember. Flicker.basFlicker.bas.bin Edited August 6, 2009 by jbs30000 Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 6, 2009 Author Share Posted August 6, 2009 2X Rows 13 - 24 Data_Start = 483X Rows 25 - 36 Data_Start = 96 4X Rows 37 - 48 Data_Start = 144 5X Rows 49 - 60 Data_Start = 192 6X Rows 61 - 72 Data_Start = 250 Oops, that should be 2X Rows 12 - 23 Data_Start = 48 3X Rows 24 - 35 Data_Start = 96 4X Rows 36 - 47 Data_Start = 144 5X Rows 48 - 50 Data_Start = 192 6X Rows 60 - 71 Data_Start = 250 Quote Link to comment Share on other sites More sharing options...
jrok Posted August 6, 2009 Share Posted August 6, 2009 You know, if you create two playfields, use two different playfield colors, use two different as well as two different background colors, and flicker between them, you could get four colors in all, which could make it possible to have green grass, red brick houses, and two other colors-- maybe brown for the roofs, and gray for the pavement. It would depend on how you picked your colors. And there would definitely be flickering-- although, depending on the colors you pick (as well as the TV used), it might not be *too* bad! You might also be able to create a scrolling pfcolors table (or two of them) to go with the scrolling playfield. Michael I've tried switching between two playfields and the flicker was absolutely horrible. Although maybe manually filling the playfield ram with the value of data statements might work. And as for scrolling colors, I don't know how coloring the screen works. You probably do, so if you could show me that would be great. Otherwise, I guess I'll need to study asm output. OK, as I'm typing this, I have decided to try two screens. I took my first example of a playfield with 1 and a playfield of 2 and flicker between them. Since I think that pfcolor might be slower than COLUPF, I'm using COLUPF. The 1 is red, and the 2 is green. I'm using the playfield[offset] variable to draw the screen. Apparently green and red overlapping make orange. And it seems that the flicker isn't as bad as I remember. Flicker.basFlicker.bas.bin I think the flicker here is totally acceptable, especially with brighter colors. I'm looking at it in z26 with 77 phosphor and it looks quite good. Experimenting with pfheights and pfcolors now, and with a bit of planning it seems like you could create some very detailed and interesting pictures. Quote Link to comment Share on other sites More sharing options...
+Propane13 Posted August 6, 2009 Share Posted August 6, 2009 It reminds me of Paperboy. Allan Me too! -John Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted August 6, 2009 Author Share Posted August 6, 2009 It reminds me of Paperboy. Allan Me too! -John That's what I was going for. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted August 7, 2009 Share Posted August 7, 2009 Will someone tell me why this won't work? I'm trying to create a Mario-type level where a character falls down (like H.E.R.O.), but it keeps saying it doesn't like COLUP0 for some reason. drop.bas Quote Link to comment Share on other sites More sharing options...
jwierer Posted August 7, 2009 Share Posted August 7, 2009 Will someone tell me why this won't work? I'm trying to create a Mario-type level where a character falls down (like H.E.R.O.), but it keeps saying it doesn't like COLUP0 for some reason. I am using batari Basic v1.01 ©2005-2007 and it is reporting (83): Error: Unknown keyword: COLUP0=68. Putting spaces between before and after the = fixes it, but then complains for all the other instances. Once those are fixed, then it doesn't like the bank statement at the end. This compiles, but just shows a circle on the screen. drop.bas -Jeff 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.