Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

jbs30000

Members
 View Profile  See their activity

  • Content Count

    486

  • Joined

  • Last visited

Posts posted by jbs30000

  1. Posted

    I just realized that you can use sdata to make a playfield as big as you want. Granted you could only scroll down, and after initially filling the screen, you would need to move all the playfield blocks up by one, and then read the next line of data, but still.

     

    Something like

    sdata myplayfield=a

    -insert data here

    end

     

    for temp1=0 to 47

    playfield[temp1]=sread(myplayfield)

    next

     

    for the initial screen, and then

     

    SUP_Loop

    temp1=4

    for temp2=0 to 3

    temp3=(temp1-4)+temp2

    temp4=temp1+temp2

    playfield[temp3]=playfield[temp4]

    next

    if temp1<12 then temp1=temp1+4: goto SUP_Loop

     

    for scrolling the screen up, and then finally

     

    for temp1=47 to 47

    playfield[temp1]=sread(myplayfield)

    next

    to read the new bottom line of the screen.

     

    Note: I actually haven't tried this myself, it's an educated guess, but it should work.

  4. Posted · Edited by jbs30000

    I noticed in the asm generated that for my 32x32 size screen the color table was four bytes across and 32 bytes down.

     

    Anyway, I'm just curious if there's a simple way to point the playfield colors to a data table. In the asm there's a lot code which I believe is trying to decide what to based on the screen size:

    ; pfcolors:
lda	# $0E
sta	COLUPF
ifconst	pfres
lda	#>(pfcolorlabel13-132+pfres*4)
else
lda	#>(pfcolorlabel13-84)
endif
sta	pfcolortable+1
ifconst	pfres
lda	#<(pfcolorlabel13-132+pfres*4)
else
lda	#<(pfcolorlabel13-84)
endif
sta	pfcolortable

    So I'm just curious how to get rid of checking for pfres and just setting the pointer to the colortable or, if possible, data statements. I've tried pfcolortable=pfcolorlabel13 but that doesn't work. I guess if it can't be done in bB and needs inline asm that's fine too. Thanks.

  5. Posted · Edited by jbs30000

    I discovered that the bB alternative to using the playfield: statement is to read data into the playfield variable doing something like

    for a = 0 to 48

    playfield[a]=datalabel[a]

    next

     

    Does anybody know the bB alternative to using pfcolors?

     

    I've studied the asm and know the two main variables are pfcolortable and the data statements generated by pfcolors are stored under the label pfcolorlabelnumber (I'm not sure how the number is assigned). I know that the pfcolortable somehow points to the pfcolorlabel, but I'm not sure how to do that in bB.

  12. Posted · Edited by jbs30000

    post-12524-1249497432_thumb.png

    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

  15. Posted

    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.

  16. Posted

    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.

  17. Posted

    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.

  18. Posted

    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 :D

     

    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.

     

    post-12524-1249497432_thumb.png

  19. Posted

    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.

  21. Posted

    This might be of some interest to some of you, unless this topic was done before :ponder:

     

    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

  23. Posted

    Wait, I'm confused. I thought that in the standard kernel the playfield was held in ram.

    I thought that the bB statement playfield followed by drawing the playfield with dots and X's translated to data statements in the asm file and that the data was copied into the playfield ram.

  24. Posted

    I'm talking strictly standard kernel, no superchip or pfres.

     

    OK, I think I have it figured out then.

     

    Oh, and searching for playfieldbase brought up a post where you helped me with this before.

    Without the Superchip:

     

    pfres = 1, playfield = $D0 through $D3

    pfres = 2, playfield = $CC through $D3

    pfres = 3, playfield = $C8 through $D3

    etc.

     

    With the Superchip:

     

    pfres = 1, playfield = $10FC through $10FF

    pfres = 2, playfield = $10F8 through $10FF

    pfres = 3, playfield = $10F4 through $10FF

    etc.

     

    Notice that the number of bytes used by the playfield is 4 times pfres, and the last row is always in the same place-- either $D0 through $D3 (without the Superchip), or $10FC through $10FF (with the Superchip). The start of the first row will move depending on pfres.

    Thanks again, and I'm going to make sure to print this info out so I don't forget about it in the future.

  25. Posted

    I use to know how to do this, but not only have I forgotten, but using the search function doesn't help me much either.

    What I would like to know is how to manually set the playfield pointers in a basic 32x12 playfield.

     

    I thought that there was something like a playfield hi and playfield lo pointer, but I can't find them. I did it in a multisprite game I was working on, but deleted it, whoops.

     

    Looking at a list file, I see where I put playfield it has a PF_data0 label and then after the data it puts:

    lda PF_data0,x

    sta playfield,x

     

    So maybe that's it? Just store the data label into the playfield variable?

     

    Thanks in advance.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...