CapitanClassic

It does mention that you can use labels in the breakpoints (I assume with conditional breaks too), so something like ... breakif {pc==__endofScanline && _scycles<20} breakif program counter is at your label, and the cycle count is greater than 76 (or if it automatically makes cycle count =0 when it overflows, then some low number that shouldn’t be possible

It lists them under Pseudo-Registers https://stella-emu.github.io/docs/debugger.html#PseudoRegisters Not sure if you can check if you have exceeded 76 cycles. I think the emulator is mimicking the behavior of a TV, and if you exceed 76 cycles, the beam has already started moving back to the left side of the screen. There are some games that never send a WSYNC, because the kernel is designed to be exactly 76 cycles long. If it does work, I suspect the command would be , “breakif _scycles>#76 Function Description _bank Currently selected bank _cclocks Color clocks on a scanline _cycleshi Higher 32 bits of number of cycles since emulation started _cycleslo Lower 32 bits of number of cycles since emulation started _fcount Number of frames since emulation started _fcycles Number of cycles since frame started _icycles Number of cycles of last instruction _scan Current scanline count _scanend Scanline count at end of last frame _scycles Number of cycles in current scanline _vblank Whether vertical blank is enabled (1 or 0) _vsync Whether vertical sync is enabled (1 or 0)

What I have been finding is that there isn’t as much time as you want between drawscreen as you would like.the current way I have been handling it is to handle collisions on a rotating basis. Since my objects are currently using sub-pixel movement, and most of the objects don’t move faster than 1 pixel, I don’t really need to perform collision detection every frame. Instead, you can stagger your collision handlers over several frames such that each object is checked at least once every 4 frames. (Example below). You can also make it more complicated, and only try to schedule the handlers over multiple frames if you have 2 or more simultaneous collisions (I.e. of collision(player0, playfield) and collision(player1,playfield) are both true then use the temp1 frame value to decide which handler to call this frame, otherwise always handle a single collision instantly.) __mainLoop ; frame counter. useful for animating player ; objects every so often or handling collisions ; on a regular schedule _frame = _frame + 1 ; joystick handlers here if joystick0right then goto __rightMove if joystick0left then goto __leftMove if joystick0up then goto __upMove if joustick0down then goto __downMove ;... ; other game stuff ; draw screen so pixel perfect collisions can be detected drawscreen ; get frame remainser div by 4. range 0-3 temp1 = _frame & %00000011 ; schedule collisions on a regular 4 frame basis if !temp1 then goto __handleP0collision ; P0 on zero frames if !(temp1 - 1) then goto __handleP1collision ; P1 on 1 frames ; missile0 on 2 frames and missile1 on 3 frames if !(temp1 - 2) then goto __handleM0collision else goto __habdleM1collision ; all handlers have goto __returnCollisions ; to skip the rest of the other checks above __returnCollisions goto __mainLoop

I found it while scanning the forums. breakif _scan>#262 responds with “breakpoint added” or added breakpoint. if you hit tilde ‘ to enter the debugger again and enter the exact same breakif statement, it will remove the breakpoint.

Pretty sure the last couple lines are, " Dedicate line (blue) Ship "Fk/ft" (blue, not sure) ....a Stalcup ...for trip to ...yville I'll (red) O...order Shrink WRAP memo to --------- about suitcase heavey Check on service of F. Car"

Sorry, I should have mentioned the playfield is dynamic. I think I will go with flickering the near pfpixels. This will only take 6 bits for on/off status and 2 bytes for the x,y location of the top-leftt playfield pixel (could shrink this to 1 byte, since the playfield is 32x44 pfpixels, but alternating colors. So really 32x22 pixels). Upon detecting a collision with the playfield, I will flicker off the P0 playfield pixels (storing them so I can restore), then on the next frame check collisions again. Any collisions are real, so handle them appropriately, and restore the turned off P0 pixels no matter what. I think I just need to worry about P0 player moving into contact with a new set of playfield pixels (using subpixel movement of .75 or less, so shouldn't be an issue in between 2 frames.)

The bBasic guide on Random Terrains site says this... The issue I am having is that my playfield is broken up into alternating bands of playfield pixels of different colors (p0 or p1 color). Each playfield pixel is 4x4. I only care if a player collides with their opponents color playfield pixels. If I want pixel perfect collision detection between a player and their opposing color playfield blocks, what possible ways can I go about achieving that. i suppose I could flicker the playfield, only drawing the P0 opposing color playfield with the player. (and visa versa for P1). Then after I call drawscreen, only opposite color pfpixels will trigger collisions. I suppose the other way is to take my 8 pixel wide x 12 pixel tall P0 sprite and perform a pfread(x,y) for any of the 6 possible opposite color playfield pixels that could collide (4 possible if aligned to the playfield/ divisible by 4), and calculate if a 4x4 pixel block would fall on any of the active pixels of the current player animation. (Would require getting the current animation pointer, and then bit-wise and with the y-scanline a 4-pixel wide box, then increment and repeat for the remaining 3 lines. Is there some other way in bBasic to do this that I am missing, or can I store/erase the 6 possible P0 playfield pixels, call drawscreen again to get new collisions with only P1 pfpixels, then afterwards restore P0 pfpixels and call drawscreen again. Can I even call drawscreen multiple times before I actually want to draw the screen? [i am guessing no] If I don’t call drawscreen early, I could kind of flicker the near P0 pfpixels by turning them off in the previous loop, then in the current loop all collisions(player0,playfield) will be valid collisions with P1 playfield pixels. Then I could restore the near playfield pixels I turned off. (So that is one more possible solution, near pfpixel flicker)

Are you certain your component inputs are not also composite RCA inputs. Some newer TVs incorporate the two together rather than having separate inputs. What you will normally see is a yellow ring around the Y input and white lines linking to the RW audio inputs. There is no standard, so you need to test the TV to see if it recognizes the console. https://www.hdretrovision.com/240p

https://en.m.wikipedia.org/wiki/Roguelike#:~:text=Roguelike (or rogue-like),death of the player character. Roguelike (or rogue-like) is a subgenre of role-playing video games characterized by a dungeon crawl through procedurally generated levels, turn-based gameplay, tile-based graphics, and permanent death of the player character. Most roguelikes are based on a high fantasy narrative, reflecting their influence from tabletop role playing games such as Dungeons & Dragons.

In case I don’t beat it. 26328 - CapitanClassic

I love that the collision detection on 2600 means that just the taillights can hit you at night. 😎

I remember playing this before, and the trick is to go at a steady pace, making progress (Any hits in the later stages send you back real far). I forget what numbers you need at each stage to have a decent chance of finishing on time (and determining if you need to put the pedal to the metal.) patch achieved 7572 - CapitanClassic

I think I can beat this one, but it sure is hard without proper planning of killing the left/right shields. 26328 - CapitanClassic

I am currently working on a game, and using bBasic for the rough draft. Trying to start in assembly is extremely hard, because getting multiple players, missiles and playfield updates on the screen is extremely difficult. I figure with bBasic / DPC+ I can work on the game logic and get a feel of how the game could look (if I can fit it all in the kernel), before trying to do the game in assembly. Trying to get an every marginally complicated kernel working without tutorials for all the more complicated kernels (switchdraw, skipdraw, dodraw, maskdraw) makes it a chore to get anything going on the screen.

Thanks that was it. I didn’t realize that when bBasic makes its first preprocessing pass it couldn’t correctly parse that value. (Kind of makes sense, since it is a run-time variable).

I am having an issue with reading if a playfield pixel is on using bBasic and the DPC+ kernel. I have a playfield that is 32x44 pixels (each 4x4). There is color banding such that each even row (starting with 0, TOP) is the same color, and each odd row (starting with 1, BOTTOM) is another color. Each playfield pixel I am interested in is 4x8, consisting of a top colored one color, and a bottom of a different color. What I am trying to do is check if either the TOP or BOTTOM of a playfield pixel is already turned on. If it is, then get another random pixel. The code bellow will eventually fill the screen, and will loop endlessly searching for an unfilled bottom playfield pixel. I have a similar subroutine for the pfpixelTOP, but when the TOP pixel is already filled in, the code below doesn’t recognize it is already filled in, and fills in the bottom anyway. What am I doing wrong for the check top and check bottom already filled pfread calls? Is there a way in Stella to debug the DPC+ ram values or bBasic (I.e. could I assign temp5 to a bBasic variable or read/display the pfpixels status var000-var127?) __mainLoop gosub __fillPlayfield ; playfield is 32 x 44 ; each pixel is 4x4 DF6FRACTION = 128 DF4FRACTION = 128 DF0FRACINC=64 DF1FRACINC=64 DF2FRACINC=64 DF3FRACINC=64 drawscreen goto __mainLoop __fillPlayfieldBottom __checkPFBottom ; get random X pixel range 0-31 temp3 = (rand & 31) __nextVert ; get random bits covering Y range ; only need 22, since each pfpixel consists of top+bottom temp5 = (rand & 31) ; outside random range for bottom 1-43 if temp5 > 21 then goto __nextVert temp5 = (temp5 * 2)+1 ; check bottom already filled if pfread(temp3,temp5) then __checkPFBottom ; check top already filled if pfread(temp3,temp5-1) then __checkPFBottom ; not already filled, so fill it pfpixel temp3 temp5 on return

This doesn’t seem possible unless one is PAL and one is NTSC

What I don’t think was common knowledge was the Decathlon Pole Vault trick. I don’t think I saw Twin Galaxy’s posting any high scores +30m until after 2005-2010.

There is no bonus for 4 lives. You start out only displaying 3 extra planes. You need to score at least 30,000 (6 planes in reserve), and then die (5 shown) to get a bonus. I don’t think it is possible to actually get plus 8, since the maximum is 9 planes in reserve, and I don’t think the planes are decremented until the scrolling is complete when displaying your new plane from your reserves. ”8+ Extra Lives = 5 Bonus Points!”

Just in case I can’t find my Flashback 2. 51060 - CapitanClassic

One Lone Coder has a good video (and subsequent video) handling billard physics. He does all the work in C++, but the equations are based off Elastic Collisions https://en.m.wikipedia.org/wiki/Elastic_collision Or you might check GameDev stack exchange. https://gamedev.stackexchange.com/questions/7862/is-there-an-algorithm-for-a-pool-game

I like River Raid, but this is one of those games that I fail miserably at when using the keyboard. I think it has to do with the fact that switching from left/right inputs nearly immediately causes the plane to keep its velocity. Because of this, I have a tendency to crash into the canyon walls. The normal Atari joystick has more of of throw to it, so it isn’t so easy to accidentally switch directions and keep your speed. Looks like I am going to have to find my Flashback 2, and fire it up.

I have found a lot of your tools quite useful. I especially like the PlayPal for creating character animations. https://alienbill.com/2600/playerpalnext.html i am sure I will find Atari Riff Machine useful for testing music/sound effects online with my phone without having to breakout my PC and a downloaded app.

According to the Stella Manual, you can set command line options for controllers https://stella-emu.github.io/docs/index.html#Properties - bc Keyboard I suppose where you set the path in Atari Dev Studio to Stella.exe, you can just include the command line arguments (hopefully, haven’t tested that yet) Keyboard Also known as the Star Raiders controller, functionally identical to the Kid's Controller and Keyboard Controller. Game included an overlay with commands, for use with Star Raiders. -lc <type> Set "Controller.Left" property. See the Game Properties section for valid types. -rc <type> Set "Controller.Right" property. See the Game Properties section for valid types. -bc <type> Sets both "Controller.Left" and "Controller.Right" properties. See the Game Properties section for valid types.

I would expect that piracy of tape games was a huge hindrance to software development companies. In the USA, you at least had to have your game cracked (happened fairly quickly) go to a local group that connected to a BBS to download the latest cracked software, and copy the disk using something a little more expensive than a tape player with 2 decks (that everyone had).