jrok

I don't think I can do what you are saying. I have WAAAAY too many pixels on to make each one a variable. I have most of the screen filled using pfvlines. I can't possibly set variables for 100 or 200 locations. Let's say I have the following as a playfield ********************* *** ***** ** * * *** * You can use your imagination and pretend that it's 32 wide x 11 tall. You can use your imagination and pretend that it's 32 wide x 11 tall. I want to randomly take a number between 1 and 128 (because in that example the tallest piece is 4 tall multiplied by 32 wide is 128) and then see if that pixel is on. Oh, okay. Well then you can just use pfread to determine the state. That evalutes to true if the pixel is on: So... if pfread(20,46) then gosub do_some_stuff ...would mean "if the playfield pixel at x position 20, y position 46 is on, then do my subroutine." Does that make sense? Cheers, Jarod

I don't think you can do it like that. As far as I know, "pfpixel [x] [y] on" is actually performing an operation, not testing the state of the pixel. But what you could do is set a variable when the pixel is turned on or off, like: dim pixel_state = a gameloop if [some set of conditions] then pfpixel [x] [y] on : pixel_state=1 if [some other set of conditions] then pfpixel [x] [y] off : pixel_state=0 if pixel_state = 1 then gosub do_some_other_things goto gameloop

THANK YOU SIR. I've noticed that certain Atari games carry constant scanline rates above 262. Am I wrong to think that they use similiar technique to balance the number of scanlines?

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

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

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

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.

*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

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

(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

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

First of all, thanks for your help with this. You are a generous man. 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.

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.

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.

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

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

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.

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

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.

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

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

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?

(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

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?

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