+Random Terrain Posted August 6, 2013 Share Posted August 6, 2013 First, here are a few related links in case you want to do your own digging to help improve this information so it can be put on the bB page: http://atariage.com/...d/#entry2764934 http://atariage.com/...l/#entry2707040 http://atariage.com/...-exploitations/ The FRAC stuff still doesn't make much sense to me. Every time I see it, I'm reminded of evil hydrofracking. The following is adapted from a post by Atarius Maximus and has added info from RevEng: The DPC+ kernel is hardware assisted and only works with melody/harmony cartridges and recent versions of Stella. There is support for pfpixel, pfvline and pfhline, but no playfield scrolling and no pfclear. The only variables available are a through z, but you can "push" variables to the stack and reuse them, then "pull" them back off. There are 256 bytes in the stack that can be used in a program. player1 only wraps because values larger than 165 cannot be supported, so to prevent crashes, DPC+ wraps automatically. It is up to the programmer to wrap player0, and the missiles and ball. To fix issues with the harmony cart, put temp1=temp1 right after each bank declaration. vblank needs to go in bank 1. The DPC+ kernel itself uses vblank to do its own setup, so there are only a few free cycles left in vblank for your program. Collisions: The virtual sprites are all player1 so you can't use collision() to detect collisions between them, and when a virtual sprite collides with the playfield you won't know exactly which one did it without coordinate checking. [iesposta says that collision detection is working now, so maybe this part needs to be updated.] Each sprite allows its REFPx and NUSIZx to be set independently I couldn't get player1 to reflect, but player2 thru player9 reflect with their NUSIZx Example: Reflect Player 3 NUSIZ3{3} = 1 (the 3 in curly brackets is bit 3.) Also, bits 6 and 7 control smooth entry of a player (I think it is called masking). It is a subtle effect, but useful if you don't want a player sprite wrapping from the left/right sides of the screen. (On both sides of the screen at the same time.) Bit 7 of NUSIZx turns the masking on: NUSIZ2{7} = 1 will turn on masking for player 2. Bit 6 of NUSIZx sets Left or Right masking (L/R). Once the sprite is off screen, it should be moved to a new location. If you don't change its location as soon as it is off screen, it will appear on the other side of the screen. NUSIZ2{6} = 0 will let the player 2 sprite disappear off the left side of the screen. NUSIZ2{6} = 1 will let the player 2 sprite disappear off the right side of the screen. If you want to disable a sprite, do not set its Y value to zero (it would still be visible on the screen). Set it to around 200 to move it off the screen. Using set kernel_options collision(player1,playfield) will return the y-coordinate where the first such collision occurs, so you can later figure out what sprite it was. Value is returned in temp4 after a drawscreen. Put this at the beginning of your code: set kernel DPC+ The DPC+ kernel goes in bank 1, so there's very little free rom there. It's a good idea to put a "goto" statement in bank 1 to a label in bank 2 and start your code there. Playfield Resolution: Horizontal resolution is 32 across, Vertical can be set up to 255. DF commands must be placed in the main loop before/with drawscreen. DF0FRACINC=<x> DF1FRACINC=<x> DF2FRACINC=<x> DF3FRACINC=<x> Here is a chart of working vertical resolutions. A "*" in the resolution column means that the bottom row isn't full height. The original chart from batari is here: http://www.atariage....00#entry2253460 Scanlines Resolution DF(0-3)FRACINC DF4FRACINC 1 176 255 - 2 88 128 255 3 59 * 86 - 4 44 64 128 5 36 * 52 - 6 30 * 43 86 7 26 * 37 - 8 22 32 64 9 20 * 29 - 10 18 * 26 52 11 16 24 - 12 15 * 22 44 13 14 * 20 - 14 13 * 19 38 15 12 * 18 - 16 11 16 32 18 10 * 15 30 19 10 * 14 - 20 9 * 13 26 22 8 12 24 24 8 * 11 22 26 7 * 10 20 29 7 * 9 - 32 6 * 8 16 37 5 * 7 - 44 4 6 12 52 4 * 5 10 64 3 * 4 8 86 3 * 3 6 128 2 * 2 4 176 1 1 or 0 1 or 0 Assymetrical Playfield Color: DF4FRACINC Changes the asymetrical playfield color. You would think you could set a color for each scan line, but the playfield blocks only change every other line, so you only need half the data. DF4FRACINC = 255 DF6FRACINC Will let you pick a color for each scan line on the background. DF6FRACINC = 0 bkcolors: $45 end The above code will make the background all red. Setting DF6FRACINC to 0 will give you one background color, setting DF4FRACINC to 0 will give you one playfield color. DF commands must be placed in the main loop before/with drawscreen. [We need more examples and more information in this section.] With the DPC+ kernel, the color of each horizontal row of the score is specified using scorecolors:. This allows for interesting visual effects, like gradients. scorecolors: $32 $34 $36 $36 $38 $3a $3c $3e end Missiles: Each missile shares its color with its corresponding player if they are on the same scanline. This is a hardware limitation. If a missile is on a scanline where its player is not present, you can control the color. Sets Missile Colors: COLUM1=<x> COLUM0=<x> Sets Heights for missiles and ball (You must set these before they appear): missile0height=<x> missile1height=<x> ballheight=<x> Sets Background Color (multi-line): bkcolors: <x> end Sets Playfield Color (multi-line): pfcolors: <x> end Sets Player Colors (players 0-9, multi-line): player0color: <x> end Set Playfield (no pfclear): Playfield: ................................ end 4 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 6, 2013 Share Posted August 6, 2013 We definitely need help explaining the stack feature. it sounds like the most useful yet alien feature in DPC+. Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 6, 2013 Share Posted August 6, 2013 Here's what I came up with on the DPC+ stack. Feel free to rewrite and rearrange... The DPC+ Stack can be used to save and restore your bB variables. There are 256 stack locations available, with the top-most location being #0 and the bottom-most being #255. To store variable contents on the stack, you use the "push" command. As you push the values on the stack, the receiving location (aka the stack pointer) automatically changes, bringing it closer to the top of the stack. Similarly, to retrieve previously-stored values from the stack you can use the "pull" command. As you pull the values from the stack, the stack pointer automatically changes, bringing the pointer closer to the bottom of the stack. You may not always want to retrieve values from the stack in the same order that they were stored. To accomplish a less structured kind of access, you can use the bB "stack" command to change the location the stack pointer is pointing at. Example - how to store and retrieve a value to location 200 rem ** position the stack at location 200 and push the value stored in player0x... stack 200 push player0x rem [code that reuses player0x can go here] rem ** position the stack above location 200 and pull off the item below... stack 199 pull player0x The pull and push commands can work with multiple values at once as well. To push a range of variables from "j" to "m", you could use the command "push j-m". To push some arbitrary locations, you can separate them with spaces "push a x missile0x player0y". 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 6, 2013 Share Posted August 6, 2013 Also worth mentioning that pushing or pulling a range seems to be broken, and pulling multiple values puts them in wrong order according to batari's comments. I'll try to fix both up in the 64k bB source. [edit] fixed in the 64k bb. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 6, 2013 Share Posted August 6, 2013 Some updates to the points. Comments/updates in BLUE... The DPC+ kernel is hardware assisted and only works with melody/harmony cartridges, and recent versions of stella. vblank needs to go in bank 1. The DPC+ kernel itself uses vblank to do its own setup, so there are only a few free cycles left in vblank for your program. ERROR: The 1.1d version of the DPCplus_kernel has a timing error if you don't use this option. Always include it for now. [is this still true or has it been fixed?] Its fixed in my 64k bB release. Games must start in bank 2. The DPC+ kernel goes in bank 1, so there's very little free rom there. It's a good idea to put a "goto" statement in bank 1 to a label in bank 2 and start your code there. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 8, 2013 Author Share Posted August 8, 2013 Here's some FRAC stuff from batari's blog: pfcolors: can specify from 1 to 255 colors for the playfield. Use DF4FRACINC to determine when the colors will update (the number of lines is determined by 256/x). For example: to update every 8 lines, use DF4FRACINC=16.) DF4FRACINC=0 will show the whole playfield in a single color, while DF4FRACINC=255 will update every line (but needs a "priming read" - more about that another time.) In a similar fashion, DF0FRACINC-DF3FRACINC control how often each 8-pixel swath of playfield columns gets updated. bkcolors: works like any other color command. It uses DF6FRACINC to determine how often to update. If none of that has changed, it needs to be explained more. How often columns get updated? You mean they aren't always updated with every drawscreen? Why would we need to change when they get updated? Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 8, 2013 Share Posted August 8, 2013 How often columns get updated? You mean they aren't always updated with every drawscreen? Why would we need to change when they get updated? By "How often columns get updated" he means how many scan lines pass by before they change. Ie. its resolution. DPC can give a different resolution to each playfield column. You specify the resolution of each column via its DF#FRACINC variable. Check out this binary, which increments each DF#FRACINC variable from 0-255, but with each column at a different resolution # at any point in time... dpcfrac.bas.bin dpcfrac.bas Also, for the "scorecolors:" entry... With the DPC+ kernel, the color of each horizontal row of the score is specified using scorecolors:. This allows for interesting visual effects, like gradients. scorecolors: $32 $34 $36 $36 $38 $3a $3c $3e end 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 8, 2013 Author Share Posted August 8, 2013 Thanks. I'll probably start adding this stuff to the bB page and add changes that you and anyone else gives me to that page because this forum software is total crap (adding a bunch of blank lines that I have to delete every time I edit and so on). It's more work to delete the blank lines than it is to update the text. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 8, 2013 Author Share Posted August 8, 2013 Since it looks like bB with Native 64k Cart Support is going to be the virtually bug-free semi-official version of bB, the comments with semicolons and C-style comments will work even if the DPC+ stuff isn't used, right? Speaking of C-style comments, can somebody post an example that I can adapt for the bB page? Thanks. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 8, 2013 Author Share Posted August 8, 2013 Here's another question. It might help to know what the parts of DFxFRACINC mean. I'm guessing that it's in three parts? DFx (What does the D and F stand for?) FRAC (Is this short for fraction?) INC (What does this stand for?) Thanks. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 8, 2013 Share Posted August 8, 2013 Many times I fakie C style comments like this: rem /* My !'s under your tonsils */ Maybe this means the whole "rem" part isn't needed? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 8, 2013 Author Share Posted August 8, 2013 Maybe this means the whole "rem" part isn't needed? Yeah, I figured that. You don't need rem when using semicolons either: ;---------------------------------------------------------------- ; ; Add points. ; Points_Roll_Up = Points_Roll_Up + 50 I just wanted to see an example of the C-style comments so I don't screw it up. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 8, 2013 Share Posted August 8, 2013 Yeah, I figured that. You don't need rem when using semicolons either: ;---------------------------------------------------------------- ; ; Add points. ; Points_Roll_Up = Points_Roll_Up + 50 I just wanted to see an example of the C-style comments so I don't screw it up. I found this link to be useful: http://www.jetcafe.org/jim/c-style.html Quote Link to comment Share on other sites More sharing options...
iesposta Posted August 8, 2013 Share Posted August 8, 2013 Here's another question. It might help to know what the parts of DFxFRACINC mean. I'm guessing that it's in three parts? DFx (What does the D and F stand for?) FRAC (Is this short for fraction?) INC (What does this stand for?) Thanks. Data Fetcher [0-8] Fractional Increment 1 Quote Link to comment Share on other sites More sharing options...
iesposta Posted August 9, 2013 Share Posted August 9, 2013 DF0, DF1, DF2, & DF3 value controls the Playfield Pixels vertical amount. There are four 8-pixel playfield columns, making 32 pixel wide assymetrical playfield. Usually the values in the first four data fetchers are the same, but they don't have to be the same. Horizontally there are 40 pixels of Playfield. bB can set and draw 32 playfield pixels. The 1st four & last four can't be drawn. (The 4 pixels on the left and the 4 pixels on the right are not able to be used in bB DPC+, but you can turn the entire playfield columns on or off.) The chart shows what setting DF0, DF1, DF2, & DF3 will give you vertically. A value of 255 will give you 176 single scan line pixels vertically, top to bottom. A value of 32 will give you 11 16-scan line playfield pixels vertically, top to bottom. Single line Playfield (orange, white): Double line Playfield (purple, black, & green): Above you can also see where bB can't program the first and last 4 playfield pixels (Assembly language can.) The value in DF4FRACINC determines how many times the playfield pixels can change color from top to bottom. The value in DF6FRACINC determines how many times the background color can be changed from top to bottom. Since the bB DPC+ kernel is actually a "2 line kernel," you sometimes run into situations where even putting a value of 255 will only change colors every other line. Player0 and Player1 allow single line color changes even in this "2 like kernel." 2 Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 9, 2013 Share Posted August 9, 2013 The bB C style comments don't function the exact same as C comments, so it's probably not a good idea to lean the usage from a C guide. Here's a brief write-up... bB supports C style comments. These are particularly useful when you want to disable a block of code or write a long comment, as you don't need to keep repeating "rem" or ";" over multiple lines. To begin a C style comment, use the "/*" characters on a line. Anything text after those characters is ignored until bB sees the "*/" characters, which marks the end of the comment. The following are all valid bB C style comments... /* comment #1 */ /* comment #2 */ /* comment #3 and some more of #3 */ The following examples are valid C comment syntax, but don't work in bB... a=a+1 /* its invalid to follow a command with a bB C style comment */ /* it's invalid to proceed a command with a bB C style comment */ a=a+1 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 9, 2013 Share Posted August 9, 2013 I think I'll stick with my redundant comment method. Gets me used to C style comments and still sticks out a bit more than normal BASIC REM statements. Also, gives me an excuse to post something juvenile again rem /* My !'s under your tonsils */ Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 9, 2013 Share Posted August 9, 2013 (edited) The FRAC stuff still doesn't make much sense to me. Every time I see it, I'm reminded of evil hydrofracking. It's basically the same as Fixed Point Variables. The normal datafetchers are 32 bit integers and automatically increment by 1 every time you read from them. The fractional data fetchers use the same idea as the Fixed Point Variables. Since we're using 32 bit values in the ARM processor the value is divided up as 24.8 instead of 8.8. Instead of incrementing by 1, they increment by 0.y where y is whatever you assigned DFxFRACINC. Edited August 9, 2013 by SpiceWare 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 9, 2013 Author Share Posted August 9, 2013 In case anyone wants to know, I'm putting this stuff on the bB page offline and trying to figure out what goes where, then I'll upload it and post a link to the section. We can continue to work on it from there, adding text, changing text, moving things around, and so on. Since I'm still adding stuff, I might have missed it in this thread if it was posted already. Does pfread work with the DPC+ kernel? Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 9, 2013 Share Posted August 9, 2013 Does pfread work with the DPC+ kernel? No, I don't see any DPC+ support in the source code for pfread. Just pfvline, pfhline, and pfpixel. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 9, 2013 Author Share Posted August 9, 2013 No, I don't see any DPC+ support in the source code for pfread. Just pfvline, pfhline, and pfpixel. Do you think it will ever be added or will we have to use Bounding Box Collision Detection? http://www.youtube.com/watch?v=evpAErQu2SU Quote Link to comment Share on other sites More sharing options...
Cybearg Posted August 10, 2013 Share Posted August 10, 2013 No pfread? Then how can one do decent collision detection? Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 10, 2013 Share Posted August 10, 2013 Do you think it will ever be added or will we have to use Bounding Box Collision Detection? Looking at the existing ARM code, I don't see a reason why it can't be added. I'm not sure if batari ever voiced an intention to do so or not. No pfread? Then how can one do decent collision detection? Collision detection is easy. It's "about to have a collision" detection that's harder without it. RT's bounding boxes is one method, though it will get expensive for any non-trivial playfield. 1 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted August 10, 2013 Share Posted August 10, 2013 How do other systems like Coleco or NES do it? I assume it doesn't literally define all bounding boxes that the player could hit, right? Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 10, 2013 Share Posted August 10, 2013 How do other systems like Coleco or NES do it? I assume it doesn't literally define all bounding boxes that the player could hit, right? I'm not expert on the subject, but from what I can tell NES and Coleco platformers typically use a memory read analogous to pfread, and check various points under the player's feet to see what tile/character type they're above. Of course it's all up to the programmer. 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.