"no_blank_lines" and scanline count

["no_blank_lines" and scanline count]

From what I can grasp, if the number of scanlines goes over 262, Atari is unable to execute all of the program's operations before the next screen is drawn, and that the screen will roll.

That's not worded quite right. You make it sound like the vertical sync will occur at the same time regardless, and that if the program tries to do too much between vertical syncs, it won't have time to do everything, so some of the things don't get done.

 

What actually happens is that the Atari will do everything you tell it to do, regardless of whether it takes 10 scan lines or 100 scan lines to perform all of the commands.

 

After the Atari finishes performing your code, it falls into a little loop that keeps checking the timer's value (or maybe the value of the timer interrupt flag) until it's time to do the vertical sync.

 

When your program tries to do too much and takes too long, usually the timer has already finished counting down to 0, so the vertical sync will occur later than usual. It could be just 1 scan line later, or it could be a great many scan lines later, depending on how the timer got set and how that little "wait loop" is constructed.

 

Anyway, the screen rolls because the TV ends up drawing too many scan lines before the Atari tells it to do a vertical sync. The screen can also roll if the TV draws too few scan lines before the Atari tells it to do a vertical sync.

 

Michael

 

 

Yes I think it makes much more sense the way you put it. But when you say "depending on how the timer got set and how that little 'wait loop' is constructed," do you mean that one could set these manually with batari? In other words, I guess I'm not exactly sure what "the timer" is in Atari parlance... is it hardware or software? When and how is it set?

 

Thanks again.

 

Jarod

["no_blank_lines" and scanline count]

That's weird. bB uses the Atari's interval timer to keep track of when it needs to perform the vertical sync routine or start drawing the active portion of the screen, so you'd think the scan line count should be the same regardless of which kernel options you've selected. However, setting the timer to a particular value-- say, LDA #35, STA TIM64T-- can give slightly different results depending on (1) how far into the scan line the Atari happens to be when the timer is set, and (2) how far into the scan line the Atari happens to be when it detects that the timer has finished counting down. It's possible that when the no_blank_lines option is used, it's causing a slight difference in the timing of the first factor. (The timing of the second factor normally varies a great deal depending on your code.) If that's the case, it might be necessary to nudge the value that bB's setting the timer to, in order to get a steady line count regardless of whether the no_blank_lines option is used. I'll check it out and see.

 

By the way, what are the dates on your std_kernel.asm and std_overscan.asm files? I want to make sure I check out the ones you're using.

 

Michael

 

Thanks, man. My files only give me the local installation dates, and I don't see and versioning information in their comments. I've attached both of them below.

std_kernel_and_overscan.zip

["no_blank_lines" and scanline count]

I'm looking for a little guidance to understanding timing in Atari. In the attached file, I'm getting a scanline count that jumps between 261 and 262 when I include the "no_blank_lines" option.

 

From what I can grasp, if the number of scanlines goes over 262, Atari is unable to execute all of the program's operations before the next screen is drawn, and that the screen will roll. But what does it mean when the scanline count drops below 262? In cases where I've gone over, I've been able to resolve it by optimizing my routines. But how would one go about troubleshooting a scanline count that is dropping below 262?

 

Thanks in advance,

Jarod.

Shooter.bas

Shooter.bin

[Playfield Death Ray]

EDT: One other quick question that's been bugging me. Has anyone noticed that when you use the vblank in a bankswitched game that DASM doesn't report how the ROM usage of your last bank? For instance, the only output I get for bank 4 in this game is "-->vblk2f5fb."

I'm using vblank in that maze game I'm working on and VbB is showing space left for the last bank in the Information Pane.

 

Weird. Now I am getting a report. But I'm not sure which change I made in my code that caused it to come back... I just looked down after my last compile and it was there. If I figure out what was causing that to happen before, I'll post it in a separate thread.

 

Jarod.

[Playfield Death Ray]

*UPDATE:

 

I've resolved my scanline "bump" problem by jamming some of the pfreading into my vblank. I still think that I should be functionalizing some of my beam routines to conserve space, but at least everything is constant now.

 

I added a player2 with his own beam. I'm liking the way this experiment is turning out so much that I've decided to turn it into a fully-fledged game. I'm thinking of calling it "Circus Galacticus." It will be a sort of futuristic gladiatorial contest, with lots of different playfields and configurable options like "Combat". Hopefully, I can use lessons learned from it to continue my work on Armageddon Complex.

 

For my next build, I'm going to try to increase the hit area of the players. As it stands, your aim has to be pretty exact to hit the opposing player (exact same playfield x or y coordinates). I'll also try to implement Curtis P's 2-score mini-kernel (though I haven't had a luck with it so far, perhaps because I'm using superchip.)

 

One thing that's frustating is that I can't seem to incorporate "no_blank_lines." It just blows my scanline count all to hell. Does anyone know why? How many scanlines does no_blank_lines use per frame?

 

EDT: One other quick question that's been bugging me. Has anyone noticed that when you use the vblank in a bankswitched game that DASM doesn't report how the ROM usage of your last bank? For instance, the only output I get for bank 4 in this game is "-->vblk2f5fb."

 

Cheers,

Jarod.

Circus_Galacticus_m11_d9_y08.bin

[Playfield Death Ray]

I know nothing yet of programming for the 2600..and I hope to learn one day..

 

But i like it so far...

 

adding some color to the beam would be nice..as it progress`s its length

 

Great work so far

 

Paulie ( GINNIDOG )

 

 

Thanks Paulie. I'm pretty new to Atari programming too. Batari Basic seems like a very nice entry point, and everyone here seems awfully helpful.

 

I think your idea of a different colored beam is a good one, but I'm not sure if something like that would be possible in bB. My instinct would be to flicker the playfield across two frames, resetting it to blank lines before the shot is fired, then setting it back to the the room definition in the second frame. But that would create three major limitations:

 

1) The playfield missile would no longer resemble a "laser beam", but would rather appear to be a single 8x8 "bullet" moving across the screen.

 

2) The environment would no longer be destructible, since I'd be redefining the playfield every other frame.

 

3) The scanline count would go wildly out of control.

 

I've attached an example of my best effort to change the color of the playfield missile, but I think its pretty unusable. Another way to approach the problem might be to create variables that would store the states of the playfield pixel, but that sounds like a LOT of variables... that might be equally implausible.

Playfield_Death_Ray_m11_d10_y08_flicker.bin

[Playfield Death Ray]

(or "How I Learned to Stop Worrying and Love the Playfield")

 

So, I've been working on designing some routines that use the playfield to draw laser beams that can destroy playfield-drawn terrain. Enclosed is my first effort, which I think could do with a lot of improvement. It its current state, my death ray does the following:

 

• Calculates the playfield position of the sprite from which it originated.
  
• Draws a progressive line in one of eight directions depending on the player's direction when the fire button is released.
  
• When the laser reaches it's full range or hits a playfield pixel, the line progressively erases (also erasing the pfpixel at its endpoint.)
  

 

Ultimately, I'll want to add a second player, and vary the length of the death ray depending on how long the button was held down. But there are many things that i'd like to improve about this code before I can take this to the next stage. Hoping a few of you could take a crack at optimizing down this code... I've been staring at it all weekend and it seems to be begging for a clever function or two to tidy it up. Also, there is a small bump in the scanline count that happens during beam collisions that I can't seem to nail down.

 

Here's a quick rundown of my variables and routines:

 

 

VARS:

 

sprite1dir = One of eight possible directions( 0-7 ) that player0 is facing/moving in

sprite1ydir = One of 2 possible vertical directions( 0 or 8 ) that player0 is facing/moving in.

sprite1xdir = One of 2 possible horizontal directions( 0 or 8 ) that player0 is facing/moving in.

sprite1lastX = player0's last known x position

sprite1lastY = player0's last known y position

sprite1PFX = player0's current playfield pixel x position

sprite1PFY = player0's current playfield pixel y position

sprite1nextPFX = the next playfield pixel x position in the direction player0 is moving

sprite1nextPFY = the next playfield pixel y position in the direction player0 is moving

 

beamlength = the length of an active beam

beampos = the progression of an active beam.

shotnum = the firing state of the beam. (0=no active beams, 1=beam is being drawn, 2=beam is erasing, 3=beam erased)

shotdir = One of eight possible directions the beam can be shot in.

beamTipX = The horizontal tip of an active beam

beamTipY = The vertical tip of an active beam

beamrange = the maximum range of the player's death ray.

rangevar = a variable used to shorten diagonal beams for a more realistic beam range.

 

 

SUBROUTINES

 

Beam: Draws a beam based on the range, direction and progression of the shot.

BeamOff: Erases a beam after its hit it's maximum range or a pfpixel.

Inputs: Uses SWCHA / 16 to determine the direction of player0 and draw the appropriate shape.

 

Thanks in advance for your help and improvements. Hopefully, this can be a weapon of mass destruction we can all enjoy.

 

Cheers,

Jarod.

Playfield_Death_Ray_m11_d10_y08.bas

Playfield_Death_Ray_m11_d10_y08.bin

[Armageddon Complex]

Thanks a lot.

 

I haven't given up on the project at all. I'm just re-tooling something, and tinkering with some new ideas and game mechanics.

 

I haven't posted a new version in a while, mainly because I'm trying to make some decisions. One of the big ones is whether to make this a sideways platformer or an eight directional "bird's eye" format. I've also been expermenting with palette-swapping techniques to preserve more space in my graphics banks, and with useing the playfield to draw missiles. I'll post the BIN and BAS to the latter later today, since I'd really like some advice on improving it.

 

I have also been busy rigging up a basic level editor in Flash to help me draw and connect my game rooms. I'll post a version of that here on on my blog soon, to get ideas on how to further feature it out. I think it could be a pretty useful tool for designing bB gameworlds, or even creating complex playfield animations.

 

I've attached a file below containing some of my experiments with palette-swapping and a top-down view, but I wouldn't consider it a real "version" since I still might decide to go platform.

 

Cheers,

Jarod.

AC_8dir.bin

[Palette-swapping Player Colors?]

First of all, thanks for your help with this. You are a generous man.

 

(1) It *is* possible to put the player1color table in RAM, so that each row of color is a variable and can be set/changed at will. However,

 

(2) doing it that way uses up several RAM variables that could be used for other things. Also,

 

(3) if you need to set each of the color variables to define it, then that means your code has to have the colors defined in ROM anyway, either in a ROM table or embedded within the assignment statements-- so if you're going to have to define the colors in ROM anyway, then why not just use ROM color tables?

 

This all makes sense to me, and so does your example. I guess I should've clarified my methods and my goal a bit.

 

I'm using bankswitching and supercharger RAM in my game. So the RAM isn't as much of a concern right now to me as the ROM is - particluarly the ROM available in bank 8 which, if I understand correctly, stores the all sprite shapes and color tables. There is one multicolor critter in my game that is currently using up 3064 bytes of bank8 :!:

 

Leaving aside that ridiculous statement for a moment, let's say that this critter and all his myriad animations are important to the game design, and that he'll be mainly battling creatures who look and act exactly like him, except they have different color outfits. Sort of like an Atari version of Wall Street. It would seem to me to be an uphill battle to define "playercolor1:" and if-then to define every single outfit for every frame of animation, and I could probably only get in a few different colors of clothing before bank8 ran out of bytes.

 

So what I assume what I would need would be to go ahead and reserve some additional variables, like:

 

   set kernel_options player1colors

  dim p1color = a
  dim p1color_row1 = a
  dim p1color_row2 = b
  dim p1color_row3 = c
  dim p1color_row4 = d
  dim p1color_row5 = e
  dim p1color_row6 = f
  dim p1color_row7 = g

  dim shoe_color = h
  dim pants_color = i
  dim jacket_color = j
  dim face_color = k
  dim hair_color = l

 

Then, if I had an animation of an investment banker counting his money, or running from the cops, or getting frogmarched into a courtroom, I could change the values of the player rows to equal the color of the applicable garment every time the shape is drawn. The idea would be that this would preserve space to draw more kinds of shapes, like bags of cash, foreclosure signs and prison cells, since I wouldn't be writing a new color table for every combination of outfit and sprite frame.

 

This may still not make any sense. I'll try to work up a small sample and post it.

 

Thanks again,

Jarod.

[Palette-swapping Player Colors?]

Actually, I remember now where I thought I saw pfcolors used as variables:

 

http://www.atariage.com/forums/index.php?s...t=#entry1486518

 

Batari had customized a version of 2600basic.h to allow Random Terrain to access colors in the pf color table independently. This seems a bit what like I need, except for a player's color table.

 

I'm going to try to tinker with it, but I sure would appreciate a clue if someone has one.

 

Cheers,

Jarod.

[Palette-swapping Player Colors?]

Unless there is some hidden feature in bB, the only way I know to change color is by using numbers, not variables:

 

  player1color:
 $f5
 $f5
 $f5
 $43
 $f5
end

 

I think the best you can do without having a special file created for you is to have a different set of colors for each character.

You don't need to redefine the player shape again if it's always the same, you can just redefine the colors. I'll have to look at the .bas file to see what you're doing.

 

Michael

 

 

Thank you, Michael. I have them pointing to the same shape in both examples. Its just that in the first file, I tried to substitute the tia colors with variables in the "player1color:" definition. I had also tried defining all the colors I wanted to use in a data set, then using the array position in the definition, but that wouldn't even compile.

 

The weird thing is, the variable version is "almost" doing what I want it to do. The variance in the shades of green seem to correspond to the different colors I'm defining (except they are green.) Could this be a cycle count issue maybe?

 

Thanks again for your help.

Jarod.

[Palette-swapping Player Colors?]

Unless there is some hidden feature in bB, the only way I know to change color is by using numbers, not variables:

 

  player1color:
 $f5
 $f5
 $f5
 $43
 $f5
end

 

I think the best you can do without having a special file created for you is to have a different set of colors for each character.

 

For some reason, I though I saw an example once where the playfield colors used variables in its definition. I could be mistaken.

 

Another way I was going to approach this was to define the player1colors twice, then do an if-then statement in the middle of the sprite definition to determine which palette to use (example attached). Is that what you mean? I could still do this, but I thought it would be much less of a bank-gobbler to define the colors as variables before the bankswitch, then just define player1colors once in the sprite bank.

player1color_if_then.bas

[Palette-swapping Player Colors?]

I have a player sprite in my game that's has lots of animations. It's a huge ROM hog, so I want to reuse these shapes to draw enemies, changing the colors to distinguish them.

 

I went ahead and reserved 12 variables that I would use to apply color to each flickered, 16 pixel tall sprite:

 

 dim boot_col = a
dim leg1_col = b
dim leg2_col = c
dim leg3_col= d
dim leg4_col= e
dim shirt1_col = f
dim shirt2_col  = g
dim shirt3_col = h
dim shirt4_col  = i
dim head1_col  = j
dim head2_col = k
dim head3_col= l

 

The idea would be that I'd then define the player1 colors as vars, such as:

 

 player1color:
boot_col
boot_col
leg1_col
leg2_col
leg3_col
leg3_col
leg4_col
shirt1_col
shirt2_col
shirt3_col
shirt4_col
head1_col
head1_col
head3_col
head3_col
head3_col
end

 

However, when I attempt to redefine colors this way, I get a sprite with different shades of green, rather then the colors I set the variables too. The result is the same whether I try hex or decimal color values. I've attached a simplified example of this.

 

Is what I'm trying to do even possible? If so, what am I doing wrong. Any help would be much appreciated.

 

Thanks,

Jarod.

 

EDT: Just realized the BAS I attached didn't make any sense (the routines were pointing to two different sprites - duh). Attached correct BAS.

player1color_vars.bas

[Expanding Playfield definition for tile games?]

You can define the characters that mean "on" and "off," as described in the batari Basic help documentation, but right now there's no special compiler feature that lets you use different characters to mean different things than "on" and "off." It sounds like an interesting idea, but I'm not sure how that functionality could be added to the compiler.

 

Michael

 

Thanks for the info, Michael. I assumed this was pretty set in stone.

 

I've already begun work on a web-based level editor for my game that outputs bB formatted code. I will go ahead and incorporate this functionality into it. I'll try to generalize it as much as possible and shoot out a link when it feels like its reached a good place. I think it could be useful for certain types of Adventure-style games, and probably even for games like Combat with lots of selectable screens.

 

Cheers,

Jarod.

[Using the score for a game title or inventory strip]

This looks incredible! I can't wait to experiment with this. Thanks Michael!

[Expanding Playfield definition for tile games?]

I'm trying to write a tile-based adventure game, and was curious if there was any way in bB to use the "playfield:" definition to define the x,y positions of something other than a pfpixel.

 

For example, right now the playfield definitions use "X" and "." to define the on/off state of a pfpixel.

 

 playfield:
XXXXXXXXXXXXXX....XXXXXXXXXXXXXX
X..............................X
X..............................X
XXXXXXX........XXX.............X
..............X...X............X
..............X...X............X
..............X...X............X
XXXXXXX........XXX.............X
X...............................
X...............................
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
................................
end

 

But I noticed that you could use just about any alpha-numeric symbol to determine value of the pixel, which will automatically be defined as "off" when compiled. For Example:

 playfield:
XXXXXXXXXXXXXX....XXXXXXXXXXXXXX
X..............................X
X......................a.......X
XXXXXXX...1....XXX.............X
..............X...X............X
..............X...X............X
..............X...X............X
XXXXXXX........XXX........b....X
X........2......................
X...............................
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
................................
end

 

So my question is, would a superchip kernel be possible that would allow us to include user defined variables in playfield definitions? For instance, typing letter between a-z on a playfield could determine the starting location of a certain sprite or missile? I imagine such a kernel would have to use up two adjacent variables to perform that sort of function, but if you aren't using pfcolors or pfheights, could those vars be used? Or maybe I'm just thinking about this in the wrong way.

[PF pixels-to-Sprite pixels?]

The standard playfield pixels are 8 lines tall. These are actually double lines, so they're really 15 lines tall-- the 16th line of each playfield is blank-- but they correspond to 8 player lines.

 

This means we can use the following conversions:

 

playfield Y position = (player0y - 1) / 8

player0y = 8 * (playfield Y position) + 1

 

You might need to adjust these numbers based upon how many lines tall your player is.

 

Would the adjustment be 1-to-1? In other words, if I have a 16 pixel player sprite and wanted to determine his exact y playfield position, would it be:

playfield Y position = (player0y - 9) / 8

 

Also, what if you are doing subpixeling with fixed point variables? I assume that this simply would not work if you wanted to, say, do collision detection using pfread, such as:

 spritePFX = (spriteX-17)/4
spritePFY = (spriteY-1)/8

if spriteXdir = [right] then spriteNextPFX = spritePFX + 0.5 else spriteNextPFX = spritePFX - 0.5
if spriteYdir = [down] then spriteNextPFY = spritePFY + 0.5 else spriteNextPFY = spritePFY - 0.5

if pfread(spriteNextPFX,spritePFY) then spriteX = spriteLastX
if pfread(spritePFX,spriteNextPFY) then spriteY = spriteLastY

if pfread(spriteNextPFX,spriteNextPFY) then spriteX = spriteLastX : spriteY = spriteLastY
if pfread(spriteNextPFX,spriteNextPFY) then spriteY = spriteLastY : spriteX = spriteLastX

 

Unfortunately, that's exactly what I want to do. But logic tells me it's not possible, since the playfield variables are whole integers. But is there a way to round fractions up or down?

 

Thanks again for the explanation.

 

Jarod

[Armageddon Complex]

I updated this project, but it might be the last update for a long time. I've been rethinking this project in a lot of ways, trying to figure out how to put the fun in it, and I get the feeling I'm in for a total redesign. I've been thinking this would be an carefully plotted-out adventure cart, but I realized that that isn't really the sort of Atari game I'd like to play.

 

In any case, this might be the final incarantion of this project as a "platform adventure."

 

Changes:

- Restored Hero colors

- Added a jetpack using the ball

- Added a player bullet using missile0

- Altered collision detection (no climbing)

- Altered teleport routine.

 

Thanks again for the help and encouragement.

 

Cheers,

Jarod.

AC_a0_9.bas.bin

[Should this work?]

-- I can never seem to get background working. It always gives me an error on compiling and highlights that line as the error.

 

Same here. I'm not really sure what is meant by "Change background color instead of playfield color." How do you define background lines? And since it says "instead of playfield color", how is it possible to that some valid kernel options contain both pfcolors and background?

[Bug Report Thread]

(I originally posted this problem in a different thread, but this seems like the more appropriate forum)

 

I noticed there seems to be some sort of problem with using fixed point math and batari 1.0 bankswitching. When you include either bankswitch.inc (or the supercharger version), DASM fails on the following for fixed-point subtractions:

 

Sub44from88			  0000 ????		 (R )
bs_mask				  0000 ????		 (R )

 

...and the following for fixed-point additions:

 

Add44fto88			  0000 ????		 (R )
bs_mask				  0000 ????		 (R )

 

I've tested this with both the original set of Batari includes and the most recent updates.

 

EDT: I attached a sample file demonstrating the issue.

jumping_bs.bas

[Check out this random maze demo]

If the number of scanlines is not a constant 262 (or so), then the TV may lose vertical sync for a frame or two and the image on the screen will jump or roll. Its not a great thing to do, but I have seen many commercial releases that jump/roll at the start of each level.

 

Cheers!

 

Ah, thanks. I think I get it. So basically, if my scanlines leap while the display is cleared (sprites and playfield not visible), then the roll will probably not be noticeable?

[PFCOLORS with Superchip?]

What happens when you run the .bin file I posted? Does it still look screwed up? If so, maybe something is wrong with your emulator.

I have no trouble with your BIN. The colors look correct. But, when I recompile your BAS file with DASM, I get the same error as yuppicide (rainbow effect).

Whenever I had a similar problem, it was because I didn't have all of the updated files that are strewn throughout this forum. SeaGtGruff collected most of them:

 

http://www.atariage.com/forums/index.php?s...t&p=1517363

 

Certain files ones are newer than others, so if you don't add them in order, you'll be using an older version and it still won't work.

 

It seems batari gets so busy that he forgets to add each updated file to his official download as each file is created.

 

Aha! Thanks for that. I found it and it compiles just fine now. Mighty fine lookin' skull.

 

Yuppicide - here is the exact link to the updated includes you need:

http://www.atariage.com/forums/index.php?s...=0#entry1490744

[PFCOLORS with Superchip?]

What happens when you run the .bin file I posted? Does it still look screwed up? If so, maybe something is wrong with your emulator.

 

I have no trouble with your BIN. The colors look correct. But, when I recompile your BAS file with DASM, I get the same error as yuppicide (rainbow effect).

[Armageddon Complex]

I liked the original plain, teleportation pads and how the guy looked when he teleported.

 

Yeah, I liked that too. The thing is, I tried it that way at first, but it didn't look as good to me in without the multicolor shades of green.

 

Those strobing ball thingies hurt my eyes. If the animation was slower, it might not be as bad.

 

Heh I never thought about it that way, but I guess they are a little grating. Besides which, I doubt I would want to step on something like that if I had never seen it before. I'll try going back to a simple platform, and maybe save the headache-inducing thingee for something else, like an electrical fire.

 

I know you needed the missile, but I still miss the multicolored guy.

 

Yeah, me too. One thing I'm thinking of doing to get it back is having joy0 control player1. Then I could flicker a multicolor hero and one multicolor monster/item per screen. It would just mean that a lot of monsters and items would have to be monocolor, but I might be able to live with that.

 

Thanks for the feedback, man.

[Armageddon Complex]

I have a new update to this. I'll post more about the changes on my blog, since they are fairly radical, but here's an overview:

 

• Abandoned my "persistant monsters" dream (for now). It had it working okay, but implementing it in a fun game just started to seem daunting. Monsters stay in their assigned rooms now.
  
• Adandoned "playercolors." Not only do I know I'll want that darn missile back, but defining 16 colors for nearly every sprite was a real ROM hog. The hero's new look is a sleek white spacesuit, which I'll probably add some details to at a later date. I am only using multicolor with player1 sprites now.
  
• Added a room-to-room teleportation pad. I worked pretty hard on this sprite, so I hope its effective. I also added a psychdelic color effect for when you are teleporting, which I hope to improve upon later. You activate it by standing on it and press the fire button.
  
• Revised player movement and collisions. I'm at the phase in design now where I'm really thinking hard about how to make the gameplay innovative and fun. I'm going to ditch "jumping" for a jetpack (move joystick up) with limited fuel. I also added the ability to "climb" walls by running into them, rather than just having them stop you. My thoughts are that, when combined with a gun and a jetpack, there could be opportunities for some real slam-bang monster fights.
  

 

Thanks for all the help and well wishes so far. I'm really excited about finishing this project!

 

Jarod.

Armageddon_Complex_teleport_and_climb.bin