Jump to content
IGNORED

Need help compiling and updating DPC+ information


Random Terrain

Recommended Posts

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:

 

 

:idea: The DPC+ kernel is hardware assisted and only works with melody/harmony cartridges and recent versions of Stella.

 

 

:idea: There is support for pfpixel, pfvline and pfhline, but no playfield scrolling and no pfclear.

 

 

:idea: 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.

 

 

:idea: 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.

 

 

:idea: To fix issues with the harmony cart, put temp1=temp1 right after each bank declaration.

 

 

:idea: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.

 

 

:idea: 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.]

 

 

:idea: 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.

 

 

:idea: 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.

 

 

:idea: 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.

 

 

:idea: Put this at the beginning of your code:

 

set kernel DPC+

 

 

:idea: 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.

 

 

 

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

 

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

 

 

:idea: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.]

 

 

icon_arrow.gif 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

 

 

icon_arrow.gifMissiles: 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>

 

 

icon_arrow.gif Sets Heights for missiles and ball (You must set these before they appear):

 

missile0height=<x>

missile1height=<x>

ballheight=<x>

 

 

icon_arrow.gif Sets Background Color (multi-line):

 

bkcolors:

<x>

end

 

 

icon_arrow.gif Sets Playfield Color (multi-line):

 

pfcolors:

<x>

end

 

 

icon_arrow.gif Sets Player Colors (players 0-9, multi-line):

 

player0color:

<x>

end

 

 

icon_arrow.gif Set Playfield (no pfclear):

 

Playfield:

................................

end
  • Like 4
Link to comment
Share on other sites

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".

  • Like 1
Link to comment
Share on other sites

Some updates to the points. Comments/updates in BLUE...

 

 

:idea: The DPC+ kernel is hardware assisted and only works with melody/harmony cartridges, and recent versions of stella.

 

 

:idea: 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.

 

 

:idea: 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.

 

 

:idea: 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.

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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

post-29575-0-85880500-1376006940_thumb.png

Double line Playfield (purple, black, & green):

post-29575-0-75123300-1376007009_thumb.jpg

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."

  • Like 2
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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 by SpiceWare
  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...