Just Jeff

OK, I see the difference. Thanks! Though yours does still run every frame- correct? This looks a little like what I did for friction I think, though my "#gravity" is effectively #1 there. As for friction being a fraction of the speed itself- how do you suggest doing that? LSRs of the speed byte? A divide loop? I'm pretty happy with the way the taxi behaves now, except it is pretty noticeable at very slow speeds that the friction is a bit much. So I think this would help that. Attaching the latest .bin.. This is now a somewhat playable screen. Notice an itinerary is now on the bottom right corner, in the dashboard. It took me quite a while to figure this out and used more tables than I thought it would. Most of this is based on RAM bytes named "Itinerary" and "PassengerState". In the attached bin, the Itinerary essentially says- Pad2, Pad3, Pad 4, Up. PassengerState tracks if he is visible, boarding, hailing, etc, The goal of all of this is that the kernel only has to decide if the passenger is on that level of pads or not- nothing more. So in the above screenshot, the kernel only knows the passenger is on pad 1 or 2 because in RAM, Sprite1 is already loaded with zeros, and Sprite2 is already loaded with the passenger graphics. When it gets to pads 3 and 4, it simply skips over them both. In VBLANK: FlightPlanLevels: ;This is how the kernel determines if it should diplay the passenger on a particular level of pads ;.byte 1 ;Need an odd number of pads .byte 2 .byte 2 .byte 1 ;Moved FlightPlanSides to bank2 because it loads graphics from bank 2 ;This table contains ObjectX and ObjectY limits to check if contact was made at the right pad from the Itinerary. FlightPlanPickUps: ;From bottom, up WestLimitPU ;.byte #0 ;Making Itinerary offset $ff = Up. .byte #117 ;Pickup Pad 4 .byte #0 ;Dropoff Pad 3 .byte #117 ;Pickup Pad 2 EastLimitPU ;.byte #35 ;Dropoff .byte #152 ;Pickup .byte #35 ;Dropoff .byte #152 ;Pickup NorthLimitPU ;.byte #186 ;Dropoff .byte #114 ;Pickup .byte #114 ;Dropoff .byte #186 ;Pickup SouthLimitPU ;.byte #123 ;Dropoff .byte #75 ;Pickup .byte #75 ;Dropoff .byte #123 ;Pickup ShoutOuts4: ;Currently keeping the graphics 8 high- so this number times 8 .byte #UPGfx_HEIGHT-8 ;Up! .byte #HeGfx_HEIGHT-8 ;Hey! .byte #PaGfx_HEIGHT-8 ;Pad 3 .byte #HeGfx_HEIGHT-8 ;Hey! ShoutOuts5: .byte #PexGfx_HEIGHT-8 ;Up! .byte #YGfx_HEIGHT-8 ;Hey! .byte #D3Gfx_HEIGHT-8 ;Pad 3 .byte #YGfx_HEIGHT-8 ;Hey! And in another bank: FlightPlanSides: ;.byte 0 Removed so the last item is a pickup, and therefore the gate will open .byte 1 .byte 0 .byte 1 The in-kernel decision: .loop2 ;-----0 3 Five cycles quicker for the remainder of the loop sta GRP0 ;3 11 lda PassengerLevel ;3 14 Check to see if the passenger is on this line bne .notHere ;2/3 16/17 Zero means he is on this level of pads lda Sprite1,x ;4 18 sta GRP1 ;3 21 -Jeff SpaceTaxi.asm.bin

I'm on it! I told myself I wasn't going to worry about comb lines and I'd probably have to shrink the screen down by 16 clocks for time reasons anyway, but things are coming together nicely so far and I'll see if I can stick with the full screen. Early HMOVEs fit in fairly easily so far and I think its worth it. Player 1 is the gate, passenger, pad numbers and platform "caps?". I'm in the middle of writing the taxi and passenger states so basically at this point the game is: When the passenger, who is clearly inebriated, appears at pad 2, you pick him up and bring him to pad 3. An argument ensues and he refuses to get out of the cab. In a fit of suicidal rage, you take off and slam the taxi into a wall, taking the both of you out and starting the process all over again. Is that how the original game is played? I don't remember exactly. SpaceTaxi.asm.bin

align 256 TaxiGearUpGfx: .byte %00000000,%00000000,%00100100,%11011010,%11111111,%01000110,%01001000,%00110000 ;Taxi, gear up Player0Gfx: .byte %10000001,%01000010,%00100100,%11011010,%11111111,%01000110,%01001000,%00110000 ;Taxi, gear down Player0_HEIGHT = * - Player0Gfx ;Additional frames for landing collision checking .byte %00000000,%01000010,%00100100,%11011010,%11111111,%01000110,%01001000,%00110000 ;Both legs short .byte %00000001,%01000010,%00100100,%11011010,%11111111,%01000110,%01001000,%00110000 ;Left leg short .byte %10000000,%01000010,%00100100,%11011010,%11111111,%01000110,%01001000,%00110000 ;right leg short Hmm well I figured this would have prevented that, but it did not.

Ah so it is the reason then since it a little quicker. I always thought it was used because it took exactly the same amount of time as the code it skips. Guess I never looked into it. Thanks!

Good Morning.. I don't recall ever running into this before. Looks like a typical page boundary issue, but no amount of align 256s seem to be able to fix it. The shearing here is my fault, but note how it changes when the taxi is on the line. So it seems obvious I'm gaining a cycle. I did see this in the debugger. What's up with the "4-5" cycles Whatever it is, it appears I'm getting it when the taxi flies through it, but that doesn't make sense either since the branch is taken when the taxi is present. Any ideas? Thanks- -Jeff

I give you "Hey Taxi!".. No AtariVox though. See attached .bin. Additionally, the taxi is now fully functional, including landing gear with the very reasonable feature of disabling horizontal thrusters while deployed. I also rewrote the collision routine so that it can detect half-misses with one leg on and one leg off. It uses 3 frames to test the collision using 3 different images. If all three images collide/don't collide as expected, the landing is good. Two nice side effects of this was that I didn't have to write any code for attempting to land with the gear still up. Due to the fact that the gear up image is 8 bytes higher than the gear-down image, the frame that is supposed to have no collision, does have a collision- so its ruled a crash. The other side effect was that the taxi shows a little bounce due to the delay while checking all the frames. I was worried about it but I think it actually looks good. Also added the code for crashing due to coming in too fast vertically. In this bin, I changed the playfield priority so you can view the collision detection if you want to click through frame by frame. You will see: Initial collision detection which triggers the check routine. Should be a collision. If the taxi was off the left side a bit, its a crash. Should be a collision. If the taxi was off the right side a bit, its a crash. Should not be a collision. (Detects side impacts and roof impacts, etc) And here is the table. Its checked against the playfield/P0 collision register which sets D7 when there is a collision: CollisionTable: ;These match the frame on which collisions should or should not occure when checking. .byte $80 ;This one is never used because zero offset graphic frame is already known to collide. .byte #0 ;Both legs short- shouldn't be a collision .byte #$80 ;One leg short- should be collision .byte #$80 ;The other leg short- should be collision That's all for now- Jeff SpaceTaxi.asm.bin

Thanks! I got something done on all this. I increased the gravity and also the upward thrust and yeah I think its better. Also added some collision and landing routines as well and even some graphics and sounds. Most of it, I would call placeholder graphics and sound- more to come. Did this too.. Saving a few bytes and cycles. Thanks! New .bin attached. No fancy crash sequence yet- just a red flash on the screen and your taxi is reset on the top left of the screen. I debugged most of it, but there are a few left. You can escape the top left of the screen- basically because P0 isn't written yet where the collision should happen. Also, if you drive into the side of one of the landing pads, its correctly ruled a crash, but when you're reset on the top left, the taxi just hovers there until you push up. I have to add more to the landing checks- right now, you can have one leg on the pad and one off and its ruled a good landing. I think when I fix that, the weird hover will go away. I think what I'll be doing is cycling through different graphics when landing which will test each leg, one at a time. If one doesn't collide then its a crash. -Jeff SpaceTaxi.asm.bin

Good Morning, I re-familiarized myself with what I had going on and then did the taxi thrust, momentum, gravity, and drag routine. Take a test drive and let me know how it feels. Let me know what it would take for me to put you in this car today. A .bin that jumps right to it is attached below, but I also posted it on the first post of this thread and intend to update that one regularly so it's easy to find. I feel like I re-invented wheel here so maybe there is some more efficient way to implement it. I used 4 bytes of RAM which are currently at $81 - $84: VMoveIncrement ds 1 ;Accumulates the the vertical speed on every frame. When the sign changes, the taxi moves up or down a line VerticalSpeed ds 1 ;Changed by the joystick and then decays with gravity HMoveIncrement ds 1 ;Accumulates the the horizontal speed on every frame. When the sign changes, the taxi moves left or right a clock HorizontalSpeed ds 1 ;Changed by the joystick and then decays with drag And here's the movement routine I came up with. Basically, the joystick controls the rate (Speed) at which the byte (Increment) is incremented. When the increment byte changes sign, the taxi moves up or down a line, or over a clock. Then the sign is flipped back. This allows for 128 speeds in each direction. -Jeff: CabMovement: SUBROUTINE .processHSpeed ;Check to see if its time for a horizontal 1 clock move lda HorizontalSpeed beq .doneHMove ;? Can I somehow reduce this to one branch check? bmi .goingLeft ;Positive numbers move the cab right, negative is left adc HMoveIncrement sta HMoveIncrement bpl .doneHMove ;If we have accumulated more then 128 bits inc ObjectX ;then there is a 1 clock move clc adc #128 ;Flip the byte back over to positive while preserving the accumulated bits ;ora #$ff :? This seems to halve the speed for some reason sta HMoveIncrement ;Roll it over 180 degrees to positive jmp .doneHMove .goingLeft adc HMoveIncrement sta HMoveIncrement bmi .doneHMove ;If we have accumulated more then 128 bits dec ObjectX ;then there is a 1 clock move sec adc #128 ;Flip the byte back over to negative while preserving the accumulated bits ;ora #$ff :?This seems to halve the speed for some reason sta HMoveIncrement jmp .doneHMove .doneHMove .processVSpeed ;Check to see if its time for a horizontal 1 line move lda VerticalSpeed bmi .goingDown ;Positive numbers move the cab up, negative is left adc VMoveIncrement sta VMoveIncrement bpl .doneVMove ;If we have accumulated more then 128 bits inc ObjectY ;then there is a 1 line move clc adc #128 ;Flip the byte back over to positive while preserving the accumulated bits sta VMoveIncrement ;Roll it over 180 degrees to positive jmp .doneVMove .goingDown adc VMoveIncrement sta VMoveIncrement bmi .doneVMove ;If we have accumulated more then 128 bits dec ObjectY ;Then there is a 1 line move sec adc #128 ;Flip the byte back over to negative while preserving the accumulated bits sta VMoveIncrement jmp .doneVMove .doneVMove .checkBounds ;? Temporary code to roll the cab over to the other side of the screen ldx ObjectX cpx #152 bne .notRight ldy #1 sty ObjectX .notRight cpx #0 bne .notLeft ldy #151 sty ObjectX .notLeft ldx ObjectY cpx #190 bne .notTop ldy #9 sty ObjectY .notTop cpx #0 bne .notBottom ldy #189 sty ObjectY .notBottom .gravity ;? Probably move this code to Overscan ldx VerticalSpeed cpx #128 ;Downward speed maxes out at 128. 127 would be up beq .noGravityInc lda FrameCounter ;Governs the rate of gravity and #%00000011 ;Change VerticalSpeed speed every 4 frames bne .noGravityInc ;If not 0, then skip the gravity increase dec VerticalSpeed ;Increase downward speed (or decrease upward speed) .noGravityInc .drag ;Reduce horizontal speed if moving to create drag lda FrameCounter and #%00000111 ;Apply drag every 8th frame bne .nodragInc lda HorizontalSpeed beq .nodragInc ;If stopped, then no drag bmi .goingLeft2 ;If cab if moving left, then reduce Horizontal speed by 1 dec HorizontalSpeed ;Therfore cab is moving right, so decrease HorizontalSpeed by 1 dec HorizontalSpeed ;Counteract the inc HorizontalSpeed below that always happens when moving. .goingLeft2 inc HorizontalSpeed .nodragInc rts SpaceTaxi.asm.bin

Alright I think I'll dig this one back out of the heap again.. Maybe this is the year!

Ah yes.. I missed that. Did you forget to mention VS Code or is there something I don't know?

Another option is to get Microsoft VS Code and then install Atari Development Studio. All free. Compiling and running is just clicking one button after that.

The Stella Programmer's Guide is actually an interesting read. I read it without knowing any assembly at the time. It's not 100 pages- more like 35 pages of actual reading. I recommend reading it for understanding- No need to commit all of it to memory. https://atarihq.com/danb/files/stella.pdf

How poor are your assembly skills? I've never done a PAL conversion, but this doesn't seem like it would be too difficult in many cases, having such a limited scope with a known goal. Perhaps you could do this yourself.

This is a really great game! I like the light show.. Needs easier levels for me though.

I use this Excel spreadsheet that I made for 48 bit displays (attached). Just put ones where you want them and the conditional formatting turns it blue. Also, it writes the code (upside down) for you on line 22 that you copy/paste into your editor. I also made an attempt at ring girl for you. _graphics.xlsx

Good Morning.. Looking for a designer again. See details here: BBlocks (Completed!) - Page 5 - Atari 2600 Programming - AtariAge Forums

Here's is the last draft that our designer sent us before he had to give up due to other obligations. Its supposed to evoke the classic 2K style of the launch titles, which was our goal when writing the game as well. We thought it would be fun to be on the box but that seemed to be the toughest element- It still needs more if its going to work. Any comments, suggestions on the design? Still looking for a new designer btw..

Does anyone have any interesting design ideas for the packaging? Amateur mockups accepted! Here's another art theme that never occurred to me before for some reason.. I misspelled BBlocks though- that's a little embarrassing. Does anyone know a designer that might want to work with us?

Here's a little doodle that I thought might be interesting for box art...

Just a little more on this.. TIA is always running, so even though you are in VBLANK, all of the colors and horizontal positions are still "there". How does it remember? It remembers everything you told it and holds it until you change it. This is why you see stripes when you pull a cartridge out. Its showing the last things you told it, on every scan line, forever. So if you think of Pong, for example. It's only necessary to set the paddles once when the game is turned on, then TIA remembers. Only the ball needs to be updated every frame.

Nice job! Are you interested in refining this program? You have some more learning opportunities here if so. I see 8 or 9 things ranging from inefficient to incorrect here. Here are two that are actually affecting this program negatively: As spendidnut mentioned earlier, hit alt-L to see if you are displaying the proper number of lines (262). This program is running only 259 which brings us to issue #2- you're using the carry flag incorrectly. The carry flag should be set for subtraction, not cleared. If you step through the code in Stella (hit the ~ key), you will see that you are actually subtracting 2 on your first time through your loops, even though you have sbc #1. If you clear that up, you'll be running at 262 lines. There are other things too.. Let me know if you are interested in reworking them..

The easiest way to help is to see your code.. So you may want to post it. Short of that.. Did you set CTRLPF to reflect? After that, you will be writing your data to registers PF0, PF1, and PF2 to draw the top and bottom of your design, and need only PF0 for the middle of it (though you could just repeatedly write 0s to the PF1 and PF2 registers there). Are you aware of the fact that you have to put your PF0 and PF2 data in backwards? (For the left half of the screen) This is all on page 39 of the programming guide if you need to read up on it.

Little tip: Stella shows extra flicker with odd frame rates. Get your scanline count to 262 and the prominent flicker you see will go away. I think it might be fine after that.

I feel a 1 clock object with similar luminosity is undetectable. On the other end on of the scale- an 8 clock object flickering black and white is. What colors and clocks are you using?

I still can't figure out how to jump or pick up the gun. Also, do we post high scores here? I got 0!