WIP- Space Taxi

[Mr SQL]

 

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.

[Kylearan]

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.

[Thomas Jentzsch]

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.

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.

[Just Jeff]

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

[Thomas Jentzsch]

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.

[enthusi]

 

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.

[Just Jeff]

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!

[+Philsan]

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.

 

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

[Just Jeff]

I worked on the load screen. I overestimated Atari's graphics again. I thought the 45 degree angles would be a little nicer. This one screen is like 2 1/2 K. Does that sound like a lot?

 

Edited August 25, 2018 by BNE Jeff

[Thomas Jentzsch]

Titlescreens always tend to become large.

[atarilovesyou]

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!

[MissCommand]

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.

[Jinroh]

Oh rad, I had never heard of this game.

 

I was never about the C64, so that makes sense. x3

 

Though a version for the VCS would be killer. I would snag that one. :3 This game looks so fun!

[Just Jeff]

 

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.

[atarilovesyou]

But many of the levels are really kinda filler on the 64...I wouldn't be too ticked if there were fewer, that kept the most interesting levels. Or even create levels the VCS could handle, provided they are still challenging and fun. UP, please!

[RevEng]

On the other hand, CPUWIZ has 2600 boards that go all the way up to 256k.

[Just Jeff]

Yup.. I estimate about 1/3 of the Commodore screens would come out well, then all bets are off.. and more ROM would be needed.

[Keatah]

I (we) know lots of interesting and amazing things can be done in small rom sizes. So, why not feel free and use whatever memory is necessary? It's understood that maps and levels can take up a lot of space. Besides, you may want to have that space for user-submitted levels.

[Just Jeff]

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:

[+ZeroPage Homebrew]

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:

2019-02-24.jpg

[+sramirez2008]

Oh yeah! I can’t wait for this. Would be great if the speech could be included.

[Just Jeff]

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

[Just Jeff]

Worked on it a little more. I think it's time to leave the graphics alone and work on some game logic.

[CrazyChris]

Whoa!!! I thought this was going to be another Knight Rider thread!

[azure]

Whoa!!! I thought this was going to be another Knight Rider thread!

 

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