Search the Community

I am trying to do infinite scrolling in text mode. The idea is that screen is larger (twice) MAXWIDTH = 96 This is my DLI definition: dl_start dta DL_BLANK8 + DL_DLI dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 1)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 2)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 3)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 4)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 5)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 6)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 7)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 8)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 9)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 10)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 11)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 12)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 13)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 14)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 15)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 16)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 17)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 18)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 19)) dta DL_MODE_40x24T2 + DL_HSCROLL + DL_LMS, a(SCREEN_GAME + (MAXWIDTH * 20)) dta DL_BLANK8 dta DL_BLANK8 + DL_DLI dta DL_MODE_40x24T2 + DL_LMS, a(SCREEN_BOTTOM) dta DL_JVB, a(dl_start) If I want to put character in visible part of the screen (while I am not scrolling the screen) I am having trouble. I have determined that I can put character within X position between 4 and 43. That leads to the problem to write a procedure to calculate sprite collision. cx:=43; cy:=20; addresscalc:=SCREEN_GAME + row_max[cy] + cx; // addresscalc:=SCREEN_GAME + cy * 96 + cx; Poke(addresscalc, SWARN); SWARN is a const for character #. As you can see cx=43 draws almost to the right. There is 1 character to the right, same situation is on left when I draw at cx=4. That is problematic when I try to understand and modify playfield after sprite and playfield collision. The question is how should I organize screen and calculate position from pixels to character position in playfield? I was trying to calculate cx and cy with cx:= ((missle_x - 48) div 4); cy:= ((missle_y - 48 ) div 4);

So I've been toying around with the idea of using an animated playfield as a game mechanic. In this concept art, I'm using the playfield to represent a waterbed (dark green) with physics that interact with the player sprites to dip when landed on and propel player sprites where it swells. I'm not aware of any games that have this sort of physics simulation, but it could make for some unique gameplay. Think Circus meets Frogger meets waterbed. As a non-developer, I'm wondering: if this is even feasible if I have false expectations of what can be achieved with missile sprites (see non-player sprites layer) if there's anyone crazy enough to collaborate with me to make this into a real game Also open to any feedback or suggestions.

Hi guys, wanted to get feedback on this bedroom regarding the vertical walls on the side! They are (in this case) missiles. I read that missile0 assumes the color of player0, but since the main char is multi-color, what color from the character does the missile assume in this particular scene? Else, is there a way around getting the side walls to be the same color as the room walls? (blue) or will I have to ditch the multi colored player sprite and make it the same color as the wall (blue) in order for the side walls to be blue? thanks

Hello. Using batari basic, I pfscroll down for a graphical effect. Number of scrolls down is random and varies according to input. On a new screen I attempt to draw a new playfield, but now it is mis-aligned because I scrolled it previously. How can I reset the starting playfield blocks to their default position without having to know the exact number of times they were scrolled? Is this possible to do in batari? Please help.

Hi, I want to know what you guys think about the current title screen layout. Out of 5, 1 being terrible and 5 being excellent vote in the poll above and let me know what you think. I know it's basic with a single color but, I'm not good at making insane title screens like you guys. Also this is must a rough draft then the final build. I may add colors latter.

Hi, I am working on updating some of the sprite graphics for the 2600 hack Dig Dug Arcade. One of the more significant changes that I have made is to the shape of the rocks that Dig Dug can drop on the enemies. The new rocks look more natural and have a shape closer to the arcade once Dig Dug loosens them and they fall, but they are still perfect squares when stationary because they are playfield graphics instead of sprites. Is there a way to alter the shape of the playfield rocks to match the first frame of the new sprite rock that I made? My thanks in advance to anyone who can help.

Hi This is a bit of a strange question. I am attempting to make a vertical scrolling play field and I have managed to get something very similar to what I need but I am not 100% sure how I have done it. In my code below I can not work out why the play field is scrolling. I would expect it to be static, the same in every frame based on my current understanding. Can anyone tell me why this is rolling and point me in the direction as to how I may control the speed of this scrolling. Maybe I have miss understood the cycle count and so I am on multiple scan lines? I do see a little glitch in the debugger. Here is my sample code: processor 6502 include "vcs.h" include "macro.h" PATTERN1 = #%00110000 PATTERN2 = #%01111000 StartCount = 0 CURRPF = 1 SEG ORG $F000 Reset ldx #0 lda #0 Clear sta 0,x inx bne Clear ;one time set up lda CURRPF ;set up the PF to mirror sta CTRLPF ;set up the PF to mirror ldy StartCount ; set to 0 lda PATTERN1 ;load part one of the patern. sta PF0 ;load part one of the patern. lda #$55 ;set the colour sta COLUPF ; set the colour StartOfFrame lda #0 ;2 sta VBLANK ;3 lda #2 ;2 sta VSYNC ;3 sta WSYNC ;3 sta WSYNC ;3 sta WSYNC ;3 ldx #0 ;2 VerticalBlank sta WSYNC ;3 inx ;2 cpx #37 ;3 bne VerticalBlank ;3 Picture sta WSYNC ;3 3 cpy #20 ;3 8 bcc ShowPathern2 ;2 10 lda PATTERN1 ;3 13 sta PF0 ;3 16 cpy #40 ;3 19 beq ResetPFDraw ;2 21 iny inx ;2 23 cpx #192 ;2 25 bne Picture ;2 26 sta VBLANK ;3 29 ldx #0 ;2 31 ldy #0 ;2 33 ShowPathern2 iny lda PATTERN2 ;3 3 sta PF0 ;3 6 inx ;3 9 cpx #192 ;2 11 bne Picture ;2 13 sta VBLANK ;3 ldx #0 ;2 ldy #0 ;2 ResetPFDraw ldy StartCount ;3 3 inx ;2 5 nop ;2 7 cpx #192 ;2 9 bne Picture ;2 12 sta VBLANK ;3 ldx #0 ;2 ldy #0 ;2 Overscan sta WSYNC inx cpx #30 bne Overscan jmp StartOfFrame ORG $FFFA InterruptVectors .word Reset .word Reset .word Reset END I have attached the bin file also. pftest.asm.bin

OK, here is another, you probably can't do that, question. 1st off, I am writing this program (Parsec 2600) in the standard 8k kernel because I want to flash the ROMS myself just to see if I can. never did that before so i thought i start off simple. Now back to the question. I have set up a multicolored playfield with pfcolors: What I want to do is change the color of one line at a time without having to do another pfcolors: since I have no idea what the color change will be on the various lines. If i had to use pfcolors: every time I would have to have about a dozen different pfcolors and choose which one to use every game cycle. my theory is i can POKE a value into the one line I want to change the color. but i don't know where to POKE or if batari will override the value. any ideas or am i totally off base. thx, HLO

I'm building an Adventure-ish game in Batari BASIC. How do you add multiple screens?

The title speaks for itself. I'm having trouble creating a play field in a multi-sprite kernel. I code in the first half of the field, but it compiles into a confusing mess of play field blocks - no apparent rhyme or reason to it.

The title speaks for itself. I'm having trouble creating a play field in a multi-sprite kernel. I code in the first half of the field, but it compiles into a confusing mess of play field blocks - no apparent rhyme or reason to it.

Can anybody help me make my player0, and player1 collide with the playfield in Batari? I will attach my code. If you can help me, that would be great! Editing my code, would be even better! Thank you very much! fnafmusic.bas

I need help making my Playfield walls solid so my two sprites (player0 and player1) can not go through them, just like in Pac-Man and Maze Craze. That would be awesome. I will leave my current code so anybody can help. Thank you so much! P.S I'm new to batari basic. default.bas

Hi everyone! First of all let me explain what I'm trying to do. I have already posted under the 2600 Programming for Newbies section a game idea I'm working on. And without giving too much specifics I managed to create one maze (with no working player graphics yet) on the 2600. I have stopped that one for a bit because the "call" to program on an Atari 8-bit computer was bugging me. So, while that is on hold for a bit, I decided to work the maze out on an Atari 8-bit. In theory I guess you could say that the game is being programmed, side-by-side, on both systems. And while I am doing this in Atari BASIC on the 8-bit I am using PM Graphics for player graphics. And thanks to ANTIC magazine I am understanding this aspect of the Atari computers, and Display Lists too, much better. Since I am using BASIC I understand that the Playfield is not part of PM Graphics. With that being said are there ways to create a maze-like playfield in BASIC using something similar to what would be used in Assembly Language for testing purposes? If it makes a difference I'm on an Atari XEGM with a 810 disk drive and using ATARI DOS 2.5. Thanks In Advance!

Thanks to Andrew's 2600 Programming Tutorials I have a better understanding of not only the 2600's mediocre but cool architecture but in Assembly as well (for the most part). And I have three game designs down on paper already that I am eager to bring to life on the console originally designed for pong-style games. I figure if others could make games for a console that wasn't intended to play those kinds of games then I should be able to as well. I am currently working on the basis for my game but have a playfield question. In one section (somewhere close to the beginning of the code) I have this: ;--------------------------------------- ; Playfield Data ;--------------------------------------- PF_Data1 = #%11111111 ;Top and Bottom Bar PF_Data2 = #%10000001 ;Side Bar PF_Data3 = #%10111101 ;Side Bar with Top Bottom Middle Box PF_Data4 = #%10100101 ;Side Bar with Middle Box Sides And then when I want to send the data to TIA, I have this: ;---------------------------------------- ; Draw Our Playfield ;---------------------------------------- Playfield lda BGDColor ;Get stored color sta COLUBK ;set the BG Color lda PFColor1 ;Get PF Color sta COLUPF ;set PF Color lda PF_Data1 ;Get PFDATA1 Set sta COLUPF ;Store it! lda PF_Data2 ;Get PFDATA2 Set sta COLUPF ;Store it! lda PF_Data3 ;Get PFDATA3 Set sta COLUPF ;Store it! lda PF_Data4 ;Get PFDATA4 Set sta COLUPF ;Store it! lda PF_Data5 ;Get PFDATA5 Set sta COLUPF ;Store it! What I am trying to achieve is a maze playfield similar to what might be seen in Maze Craze. Am I on the right track? I know I still need to count my cycles and I might need to place a few cycle "pauses" to have some sections repeated. I have not finished the code enough yet to try it out but I wanted make sure I'm doing it right. I plan to add at least 3 enemy sprites and one player sprite to the code once I get a working maze.

•This thread is to discuss Playfield data in batari Basic DPC+ to benefit very detailed and lots of playfields in a single game. (The assembly programmers have tools, but I wanted to develop ones for batari Basic.) •This thread is to discuss playfield compression. Is it really worth it? Does it save space? •Creation of guides or scripts or apps to compress playfield data. •Creation of code to decompress data. Beyond the normal defining of playfield, I needed to store playfield screens in the rom banks, apart from the area DPC+ puts playfields. I have 2 highest resolution playfields in the DPC+ data area by defining the normal "playfield:" command. I also have 3 other highest resolution playfields as data in the usable DPC+ banks, bank2, bank3, bank4, bank5, or bank6. • Procedurally drawing a playfield. Bogax coded a routine to turn pixels on and off using data. <routine will go here> • Regular Playfield. Storing 8 pixels in a single byte is already quite a good storage technique. There are 8 bits in a byte and each bank only has around 4,000 bytes, so to get the most in a program, every byte counts! For one line of playfield, batari Basic has 32 pixels and this works out to 4 bytes: 00000000, 00111101, 00001111, 00000000 Here is the top 1/4 of my DKbB playfield: %00000111,%11111111,%11111111,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%10000000,%00001000,%00000000 %00001001,%00000000,%00000100,%10000000 %00000000,%00000000,%00000000,%00000000 %00000010,%00000000,%00000010,%00000000 %00001111,%11111111,%11111111,%10000000 %00001010,%10101010,%10101010,%10000000 %00001010,%10101010,%10101010,%10000000 %00001010,%10101010,%10101010,%10000000 %00001111,%11111111,%11111111,%10000000 %00000000,%00000000,%00000000,%00000000 %00000000,%00000000,%00000000,%00000000 %00001001,%00000000,%00000100,%10000000 %00000000,%00000000,%00000000,%00000000 %00000000,%00000000,%00000000,%00000000 %00000000,%00000000,%00000000,%00000000 %00001001,%00000000,%00000100,%10000000 %00000000,%00000000,%00000000,%00000000 That 1/4 takes 176 bytes. All 4 playfield data chunks takes 704 bytes to make one highest resolution playfield. That's almost three quarters of 1K of the 4K bytes. There sure are a LOT of 0's, each "0" holding one bit in the ROM. I have searched for compression in the "Basic" language here and on the web, and I have not found much. Here's what I have found / developed so far. Can compression gain space? • RLE Compression. RLE or Run Length Encoding is a simple compression that takes data and says 5 zeros, 19 ones, 16 zeros, 1 one, 11 zeros, etc. The above 1/4 playfield would RLE compress to this: ; 105 bytes compressed play field %00000101, %10001001, %00010000, %10000001, %00001011, %10000001 %00110011, %10000001, %00001011, %10000001, %00110011, %10000001 %00001011, %10000001, %00001011, %10000001, %00001011, %10000001 %00110011, %10000001, %00001011, %10000001, %00110011, %10000001 %00001011, %10000001, %00001011, %10000001, %00001011, %10000001 %00110011, %10000001, %00001011, %10000001, %00110011, %10000001 %00001011, %10000001, %00001011, %10000001, %00001011, %10000001 %00110011, %10000001, %00001011, %10000001, %00110011, %10000001 %00001011, %10000001, %00001011, %10000001, %00001011, %10000001 %00110011, %10000001, %00001011, %10000001, %00110011, %10000001 %00000010, %10000001, %00001101, %10000001, %00000010, %10000001 %00101101, %10000001, %00001111, %10000001, %00001101, %10010101 %00001011, %11111111, %10101010, %10101010, %10101000, %00000000 %10101010, %10101010, %10101000, %00000000, %10101010, %10101010 %10101000, %00000000, %10000000, %10010101, %01001011, %10000001 %00000010, %10000001, %00001101, %10000001, %00000010, %10000001 %01101011, %10000001, %00000010, %10000001, %00001101, $10000001 %00000010, %10000001, %00100111 That is 105 bytes, a savings of 71 bytes, but routines are still needed to expand the data. (Note: the bottom of the above data is incorrect, as I have begun to add "flag" bytes.) I used a python script, and hand typed the above table with the 1st bit in each section showing if the number is ones or zeros. The decimal for the data that starts with "%0" is how many zeros. The first line says 5 zeros. The data that starts with "%1" is data for on bits. The byte converted to decimal, minus 128, would be the number of 1's. The fourth byte, "%10000001" says 1 ones. <- I noticed this is wasteful. A whole byte to say one 1? Looking at the above data, I began to see more patterns. Notice it alternates zeros data, ones data, etc. Also notice it alternates a lot with: data, one 1, data, one 1, data, one 1, etc. More waste: %10101010 just doesn't gain anything from this compression, it actually goes from one byte to 16 bytes! This is the point where I came up with Conditions. • Compressed Playfield with Conditions. It makes sense to set a byte to tell the playfield plotting routine to just use every bit as playfield data - it is not compressed. I came up with three Conditions: Condition0 128 means normal RLE operation. 128 = %10000000 Condition1 192 means every other operation is 1 on pixel. 192 = %11000000 Condition2 256 means plot every byte. 256 = %11111111 The playfield data with Conditions would be this: %10000000 ; Condition0 %00000101, %10001001 %11000000 ; Condition1 %00010000, %00001011 %00110011, %00001011, %00110011 %00001011, %00001011, %00001011 %00110011, %00001011, %00110011 %00001011, %00001011, %00001011 %00110011, %00001011, %00110011 %00001011, %00001011, %00001011 %00110011, %00001011, %00110011 %00001011, %00001011, %00001011 %00110011, %00001011, %00110011 %00000010, %00001101, %00000010 %00101101, %00001111 %10000000 ; Condition0 %00001101, %10010101, %00001011 %11111111 ; Condition2 %10101010, %10101010, %10101000, %00000000 %10101010, %10101010, %10101000, %00000000, %10101010, %10101010 %10101000, %00000000 %10000000 ; Condition0 %10010101 %11000000 ; Condition1 %01001011, %00000010, %00001101, %00000010 %01101011, %00000010, %00001101 %00000010, %00100111 Now the data takes 67 bytes from the original 176. A savings of 109 bytes. This is as far as I got today. The above still has patterns, like the 10 "%00001011"'s in the center column. I can't think of a Condition for that. Times 4 playfield parts that would save around 435 bytes. Is that enough to make compression/decoding worth it?

I have a game that utilizes the pfcolors kernel. I cannot get the entire playfield to flash the "chalice" colors unless I disable the pfcolors kernal. For example, if I have this inside my loop: y=y+2 COLUPF = y with the pfcolor kernal activated, the playfield will not cycle through the colors except for a very thin line at the very top of my playfield. That thin line will cycle through the colors at the top of the screen. Then if I put the variable 'y' in the spots that specify colors for each playfield row like this: pfcolors: y y y y y y y y y y y y y y end ... Everything is turned one solid color Is there some way to get the flashing colors on the entire playfield while using the pfcolors kernal?

Right now im trying to figure out why my scrolling field doesnt include the entire playfield? I have the pixles at 88 high, but when I use scrolling. Only the first screen scrolls over and over? not the entire playfield? 2, without a multikernel sprite option. How can i make my playfield a little more detailed? I tried using pfcolors, but it still isnt what I want? Thanks for any help.