WIP- Space Taxi

[Just Jeff]

 

Making this game is going to be a lot of hard work.

 

Have no fear. The tiger team from group Savage has secured the adventure capitol necessary for implementing the code, should actual game code be necessary. Though I will have to submit revised sales estimates, reducing from 10 to 20 million, down to 100 to 200 as many have suggested.

[+Karl G]

Not every game concept or early WIP becomes a completed game in the end. That's just the nature of development projects done in a person's spare time. I don't think comparing those unfinished projects to the Knight Rider "project" is really fair, though.

[CrazyChris]

Not every game concept or early WIP becomes a completed game in the end. That's just the nature of development projects done in a person's spare time. I don't think comparing those unfinished projects to the Knight Rider "project" is really fair, though.

My point was that Knight Rider is not really a serious project.

[Just Jeff]

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

[Prizrak]

Absolutely love space taxi, not sure how it would turn out on the 2600 but given all the tools we now have its definitely doable.

Sent from my SM-G996U using Tapatalk

[Just Jeff]

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

Edited August 6, 2022 by Just Jeff

[Bomberman94]

The space taxi itself looks really nice. The physics are great and „feels“ correct to me - it could drop a bit faster so it becomes more difficult. Now we need some nice graphics and a collision/landing routine ??

[Prizrak]

Taxi cab seems to float and stuff like it's supposed to. Would be amazing to use the AtariVox and give us "Hey Taxi!"

Sent from my SM-G996U using Tapatalk

[4ever2600]

Pad 3 please.. 

[glurk]

Code simplifications:

 

;clc

;adc #128 ;Flip the byte back over to positive while preserving the accumulated bits

 

and #$7f ; make positive

 

;sec

;adc #128 ;Flip the byte back over to negative while preserving the accumulated bits

 

ora #$80 ; make negative

 

Edited August 8, 2022 by glurk

[Just Jeff]

On 8/6/2022 at 1:00 PM, Bomberman94 said:

The space taxi itself looks really nice. The physics are great and „feels“ correct to me - it could drop a bit faster so it becomes more difficult. Now we need some nice graphics and a collision/landing routine ??

 

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.

 

On 8/7/2022 at 11:48 PM, glurk said:

Code simplifications:

 

;clc

;adc #128 ;Flip the byte back over to positive while preserving the accumulated bits

 

and #$7f ; make positive

 

;sec

;adc #128 ;Flip the byte back over to negative while preserving the accumulated bits

 

ora #$80 ; make negative

 

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

Edited August 13, 2022 by Just Jeff

[Prizrak]

Very nice, looks like things are coming together. Space Taxi is one of those games I never thought would be on the 2600 but you may make this a reality

[+ZeroPage Homebrew]

3 hours ago, Just Jeff said:

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.

 

Thank you for continuing with this! Space Taxi is one of my favourite games on the C64 and seeing it come to life on the Atari 2600 is going to be amazing. You've got an awesome start to it so far!

 

Looking forward to playing it on ZPH in the future!

 

- James

[Bomberman94]

23 hours ago, Just Jeff said:

 

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 64 kB · 10 downloads

Wow - I played your last bin file (although I have a PAL Atari 2600). Great : physics are fantastic and „feels right“. First walls, platforms and I must say: From the looks of it, it could be even better than on the C64 😳

[Thomas Jentzsch]

.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

I think you should not use the frame counter here, because it doesn't allow fine adjustments of gravity.

I would use fractional math instead:

.gravity
    lda  VerticalSpeedLo
    sec
    sbc #gravity
    sta  VerticalSpeedLo
    bcs .noGravityInc       ;If no underflow, then skip the gravity increase

    dec VerticalSpeed       ;Increase downward speed (or decrease upward speed)
.noGravityInc

Also, instead of a fixed maximum speed, you could add friction. E.g. decreasing the speed by a fraction of the speed itself. That way the speed will max out automatically.

 

Of course the same would work on horizontal speed too.

[Just Jeff]

On 8/6/2022 at 1:46 PM, Prizrak said:

Would be amazing to use the AtariVox and give us "Hey Taxi!" 

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

Edited August 19, 2022 by Just Jeff

[Prizrak]

Stunning progress, love to see you making this a reality. 

[Just Jeff]

On 8/6/2022 at 4:47 PM, 4ever2600 said:

Pad 3 please.. 

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

Edited August 28, 2022 by Just Jeff

[4ever2600]

6 hours ago, Just Jeff said:

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 64 kB · 7 downloads

LOL NO WAY!  I used to play that game almost all the way through and never remember it actually happening in the game!  Maybe it's just lore, like a side story they are telling you in the instructions?  Companies used to do that to hype up the game.

 

Then again, I could just be wrong...  been a long time.  

[Keatah]

I think the difficulty switches should be used to enable/disable the horizontal thruster for easier landings for kids. Just like the oldschool games did in 1977-1978. Maybe even have the landing struts always down too..

[4ever2600]

No way, no baby mode. Lol

[Just Jeff]

On 8/13/2022 at 5:07 PM, Thomas Jentzsch said:

.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

I think you should not use the frame counter here, because it doesn't allow fine adjustments of gravity.

I would use fractional math instead:

.gravity
    lda  VerticalSpeedLo
    sec
    sbc #gravity
    sta  VerticalSpeedLo
    bcs .noGravityInc       ;If no underflow, then skip the gravity increase

    dec VerticalSpeed       ;Increase downward speed (or decrease upward speed)
.noGravityInc

Also, instead of a fixed maximum speed, you could add friction. E.g. decreasing the speed by a fraction of the speed itself. That way the speed will max out automatically.

 

Of course the same would work on horizontal speed too.

 

 

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

Edited September 5, 2022 by Just Jeff

[Thomas Jentzsch]

1 hour ago, Just Jeff said:

As for friction being a fraction of the speed itself- how do you suggest doing that?  ASRs of the speed byte?  A divide loop? 

I am always doing shifts. Not only powers of 2 but also combinations of shifts (e.g. 3/32 or 5/64) are easily possible here for the friction. And that is usually good enough. Also make sure that the frictions friction does not become zero at low speeds (e.g. by rounding up).

[Bomberman94]

Wow the last build is slowly getting a real game - I like it a lot. Great physics and the graphics could be even better than the C64 ones 😳

[+ZeroPage Homebrew]

ZeroPage Homebrew is playing Space Taxi on tomorrow's stream LIVE on Twitch, hope you can join us!

 

Tue Sep 13, 2022 @ 6PM PT | 9PM ET | 1AM GMT+1Day

WATCH LIVE: https://www.twitch.tv/zeropagehomebrew/
WATCH LATER: https://youtube.com/zeropagehomebrew/

 

Games:

• HERO 2 (2022 Retail Build | 2600) by Game Select / Ricardo Pim @Ricardo Pim
• Space Taxi (2022 WIP | 2600) by Just Jeff @Just Jeff
• Duck Race (2022 WIP | 2600) by Fort Apocalypse @Fort Apocalypse
• 8 Tanks (2022 WIP | 2600) by by Fort Apocalypse @Fort Apocalypse
• Lineman! (2022 WIP | 2600) by Kevin Kelley @KevKelley

 WATCH AT 1080P60 FOR FULL QUALITY