Jump to content
IGNORED

WIP- Space Taxi


Just Jeff

Recommended Posts

 

Thanks for the info!

 

I realize I have worded that poorly (or probably more precise: Never thought that through completely :) ). I don't want to emulate the conditions of a certain time period, let's say 1982. I never owned a VCS back then (my first computer was a C64 in 1985), so that holds no meaning for me anyway. Instead, I'd like to preserve what makes the VCS special in comparison to other home computers.

 

What I mean by that is that the lack of RAM, the lack of a framebuffer and the weird sound chip in combination with only having 76 cycles per scanline is the main challenge that attracts me to the VCS, that makes programming for it so special. If I add more RAM, ARM support or a special music chip, I feel like I could simply move to the C64 instead and have a similar, but more "original" experience.

 

To me, adding a moderate amount of ROM is different however. All this allows is more data for levels, graphics, and music, but the fundamental way of how to make use of that data stays the same. (The exception is that more ROM also allows unrolling loops which gives you more computing power, but I'll stay away from that in this game.)

 

I hope that makes sense. :)

 

Agree with your sentiment, good analogies! Though I think all of these also correlate with the specific pre-crash timeframe:

 

If I add more RAM, ARM support or a special music chip, I feel like I could simply move to the C64 instead and have a similar, but more "original" experience.

 

For the same reason relatively speaking, a little bit of extra RAM or ROM still feels very original to me, but the larger ROM and RAM sizes not as original because we never saw those configurations bitd.

Link to comment
Share on other sites

Yup, in a asymmetric PF, empty scan lines cannot be avoided when you reposition sprites. Unless you find an area with symmetry.

 

Ah, thanks a lot for that comment! The last sentence made me realize I can simply do two different kernels, one for asymmetric playfield more where no sprite multiplexing happens, and one for mirrored mode that allows for multiplexing. Having some symmetric level designs that in turn will be able to have more moving hi-res objects should enhance the experience a lot. :)

 

I'm still working on some helper scripts (for example one that converts a 32x40 .png image to .asm level data), after that I'll create a WIP thread and showcase the proof of concept kernel.

Link to comment
Share on other sites

Ah, thanks a lot for that comment! The last sentence made me realize I can simply do two different kernels, one for asymmetric playfield more where no sprite multiplexing happens, and one for mirrored mode that allows for multiplexing. Having some symmetric level designs that in turn will be able to have more moving hi-res objects should enhance the experience a lot. icon_smile.gif

You could also switch between such kernels in the same level. And besides symmetric you could also use the asymmetric playfield defined by CTRLPF.

 

That way you can define areas, where you can reposition sprites and/or display them with higher resolution.

Link to comment
Share on other sites

Hi!

 

I'm done writing for the day so I'll post what I have so far. The idea here is to remove the DoDraw to save cycles. It still appears in the code, but I think I can simply remove it at this point. Not sure if I can or if I need some additional routine that just sets the pointer to a specific line in my "padded graphics" as I call them. The goal was for the kernel to check for the players only once every 20 lines, and on that line, it may not be able to update the playfield or something else, so the screen would have to work around that restriction. But now that I look at it, I may have exceeded that goal.. Dunno.

 

The nice thing is that its a one line kernal with a multicolored player 0, asymmetrical playfield, and 12 cycles to spare for more color changes or whatever.. Player 0 flickers between the taxi and the passenger and Player 1 is used for pad numbers, gas cans, and other stationary objects.

 

The second half of the kernel has 3 RESP0s would not always be necessary or useful, freeing up 3 or 6 more cycles.

 

How does it look?


ArenaLoop3:
        sta WSYNC           	; 3 
;---------------------------- start of setup line of the 20 line band
        lda #PLAYER0_HEIGHT-1 	; 2  2 - Player 0 is the taxi and the passenger, flickered
        dcp Player0Draw     	; 5  7 - This check is done once every 20 lines only
        bcs CDoDrawGrp0     	; 2  9 - so the player Y pos must be adjusted to
        lda #0              	; 2 11 - hit on increments of 20. Then the pointer
        .byte $2C           	; 4 17 - must also be adjusted to begin at the proper line.
                            	;        The player graphics will be padded with 
CDoDrawGrp0:                	;   10 - 20 zeros above and below them, making
        lda (Player0Ptr),y  	; 5 15 - 5 byte high players, 45 bytes, for example.
        sta GRP0            	; 3 18 - Though the paddings can overlap to save
        lda (PlayerColorPtr),y	; 5 23 - 20 bytes per.
        sta COLUP0				; 3 26
        
        lda #PLAYER1_HEIGHT-1   ; 2 28 - Player 1 is for stationary objects such
        dcp Player1Draw     	; 5 33 - as pad numbers and gas cans
        bcs CDoDrawGrp1     	; 2 35 - since they are stationary, they can be
        lda #0              	; 2 37 - written late so long as they are kept
        .byte $2C           	; 4 41 - off of the first line of the band.
                            	;        
CDoDrawGrp1:                	;   36 - It is unlikely that playfield updates
        lda (Player1Ptr),y  	; 5 41 - can occur on the first of the 20 lines
        sta GRP1            	; 3 44       
        lda (Player1ColorPtr),y	; 5 55


        sta WSYNC           	; 3 58 - 18 cycles left over
        
;---------------------------- start of playfield lines of the 20 line band

Playfield:
		lda (Player0Ptr),y  	; 5 5 - If the player is not here,
        sta GRP0            	; 3 8 - zeros (padding) will be written
        lda (PlayerColorPtr),y	; 5 13
        sta COLUP0				; 3 16
		ldx TopBand0			; 2 18
		stx PF0					; 3 21
		lda (Player1Ptr),y  	; 5 26
        sta GRP0            	; 3 29
        ldx TopBand1			; 2 31
        stx PF1					; 3 34
        sta RESP1				; 3 37 - Display the object
        ldx TopBand2			; 2 39
        stx PF2					; 3 41
        ldx TopBand3			; 2 43
        stx PF0					; 3 47
        ldx TopBand4			; 2 49
        sta RESP1				; 3 52 - Display the object again
        stx PF1					; 3 55
        dey                 	; 2 57
        sta RESP1				; 3 60 - Display the object a third time.
        cpy #19					; 2 62
        bne Playfield       	; 2 64 - 12 cycles to turn player 1 on/off

Link to comment
Share on other sites

 

Thanks for the info!

 

I realize I have worded that poorly (or probably more precise: Never thought that through completely :) ). I don't want to emulate the conditions of a certain time period, let's say 1982. I never owned a VCS back then (my first computer was a C64 in 1985), so that holds no meaning for me anyway. Instead, I'd like to preserve what makes the VCS special in comparison to other home computers.

 

What I mean by that is that the lack of RAM, the lack of a framebuffer and the weird sound chip in combination with only having 76 cycles per scanline is the main challenge that attracts me to the VCS, that makes programming for it so special. If I add more RAM, ARM support or a special music chip, I feel like I could simply move to the C64 instead and have a similar, but more "original" experience.

 

To me, adding a moderate amount of ROM is different however. All this allows is more data for levels, graphics, and music, but the fundamental way of how to make use of that data stays the same. (The exception is that more ROM also allows unrolling loops which gives you more computing power, but I'll stay away from that in this game.)

 

I hope that makes sense. :)

 

I agree 100% here for my personal taste/approach.

Link to comment
Share on other sites

Why do you need the cpy #19 instead of reducing the initial value by 19? And how does the kernel branch to ArenaLoop3?

 

BTW: I think there is a GRP0 where it should be GRP1.

 

#19 has no real meaning right now. The kernel will have multiple bands, so they would all end with CPYs as Y decremented from 200 or so.

 

Similar answer for ArenaLoop3- it would fall in from the previous kernel band called ArenaLoop2, running through that section once, never returning to it in any one frame. The idea is to not do any playfield updates on that line, but do other things. I originally, made it that way for the DoDraw, but like I said, I don't think I need DoDraws anymore.

 

You're right about the GRP0.. Thanks!

Link to comment
Share on other sites

Seven years ago I made tests with batariBasic.

I think that with today's bB DPC+ kernel it is possible to do a good conversion.

More so with assembly.

For voice (and high score saving) there's AtariVox+ device.

post-12528-0-48059900-1485808032_thumb.png

 

BTW, a friend of mine made a few working levels for Atari 8-bit computers:

http://atariage.com/forums/topic/214580-space-taxi-is-there-a-clone-for-atari-8-bits/?p=2795459

  • Like 5
Link to comment
Share on other sites

  • 1 year later...

If Space Taxi ever becomes a reality on the VCS, I would be all over it. I always thought the sheer number of levels would restrict things a lot...that variety was what kept us coming back. Played this game so much on he C64!

 

I spent a lot of time playing Space Taxi on C64... it was one of my favorite games. I don't know how hard it would be to replicate on the 2600... but I agree that the hardest part just might be trying to get all the levels in with the differing animations.

 

BTW, someone programmed a version for the PC that really is an exact replica of the C64 version... all the sounds and game play are spot on.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

 

I spent a lot of time playing Space Taxi on C64... it was one of my favorite games. I don't know how hard it would be to replicate on the 2600... but I agree that the hardest part just might be trying to get all the levels in with the differing animations.

 

BTW, someone programmed a version for the PC that really is an exact replica of the C64 version... all the sounds and game play are spot on.

Cool.. Yeah the number of screens is starting to appear pretty daunting. 32K doesn't look like enough- plus 3 of the banks are set aside for voice, leaving me with even less.

Link to comment
Share on other sites

  • 3 weeks later...
  • 4 months later...

That looks great! I can't wait for a playable version as it was one of my favourite games on the C64.

 

Please incorporate AtariVox for the speech!! 'PAD 5 PLEASE!'

 

I got a little start on it but need to put it back down due to tax season and a home emergency- so here's a little bit of progress:

attachicon.gif2019-02-24.jpg

  • Like 2
Link to comment
Share on other sites

I have some banks set aside for speech and I've done some testing. (attached) I cut the sample off a little early and it runs a little fast so it sounds like I'm saying "Hey Tax" after inhaling helium but I assembled the tools I needed and tested it to prove it works and moved on to other stuff. Note- it will blank out the kernel.

 

I've heard of AtariVox but am not really familiar. In what ways would it be different? Would it allow a decent kernel? Would it do a decent replication of the C64 version when relying on its vocabulary?

 

HeyTaxi.bin

  • Like 1
Link to comment
Share on other sites

  • 3 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...