homebrew Taxi Panic!

[+Random Terrain]

30fps.

 

Thanks. I'll put some links to that site on my web site and mention that people might want to use a Max FPS setting of 30.

[+Random Terrain]

I was playing with the numbers and it seems like 33 gives a smoother result without increasing the file size by a huge amount.

 

30 FPS 33 FPS

 

 

 

 

 

 

[walaber]

Yeah Atari games seem to compress really well into animated GIF format so file size isn't much of a concern. 33 does look nice I'll try that.

[Mr SQL]

30fps.

True that

[Jinroh]

Looking great I really love how the city and driving is shaping up!

[+Random Terrain]

33 does look nice I'll try that.

That's good. I added a link to that site in two places so far:

 

randomterrain.com/atari-2600-memories.html#links_for_programmers

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#useful_tools

[Lendorien]

I saw this an immediately thought of the arcade game Rally-X.

 

I love how it's looking. The physics of the car are great. This could turn out to be quite the gem!

[walaber]

had a bit of an interlude with very little progress, but in the last few nights I've been able to lay the foundation for the next system: passengers! so far I've been working on my city editor, so I can author where the passengers are, and where they want to go. next I need to turn this into data appropriate for the game, and write the code to display, pick up, and deliver passengers. that sounds like a good milestone to release another build for feedback.

 

here's a shot of the editor in a special mode where it "visualizes" the connections between passengers and their desired destinations (by drawing lines between them). this will look like spaghetti by the time the game is done

 

[Kylearan]

The shot looks like there's a one-to-one relation between passengers and destinations, so that every pick-up point will have the same delivery point every time. Why not define a number of pick-up points plus a number of delivery points and randomize the missions?

 

Randomization is good for replayability.

 

Looking forward to the game in any case!

[RevEng]

How about having some seedy pickup points, like a bar? The drunk passengers usually pay better, but there's a chance they'll cause trouble mid-ride, and you need to race them to the police station while they damage your cab and cost $$$.

 

I'm also seeing a Choplifter type drop-off sequence.

[+Propane13]

You know, I kind of want to be able to drive on the runway...

[Thomas Jentzsch]

Me too!

 

Maybe a place for an Easter Egg?

[walaber]

I will definitely consider adding some randomization into the game once I get the core system working, although Crazy Taxi, which this game is inspired by, is much lass random than you think. Some of the fun for skilled players comes in learning the patterns and ways to move around the city without having to slow down and turn around much, essentially "linking" multiple fares together. I want to try that out first, but we'll see how it goes.

 

as for the runway, yeah that and inside the "stadium" seem like cool places to add a secret way to get in there

[walaber]

Finally got some of the code "plumbing" together for picking up and dropping off passengers. Very debug visual feedback, but now you can see the passengers as little green lines on the screen. When I stop near one I pick them up, and the background turns white (for debugging purposes). I drive them to their destination, drop them off, and the background goes back to black.

 

Now I need some kind of guidance arrow that let's you know where the destination is, and some kind of HUD to show time remaining, score, an icon of the destination, etc.

 

I'll probably have to shrink my screens a bit to make room for the HUD, which is good since that will save some memory

 

As you can see I'm flickering the potential customers, it shows up a LOT in the GIF but should look OK on a proper monitor/Stella.

[walaber]

OK, I've got some semblance of picking up and delivering passengers working! Basically, look for the little colored lines (people) int the city. stop near them to pick them up. The color of the person indicates the rough distance to their destination (red = nearby, yellow = kinda far, green = quite far).

 

After you pick them up, a white indicator will appear at the edges of the screen, indicating the general direction you need to go (North, South, East, West, North-East, etc). Follow that. when you're on the block with the desired destination, the indicator will turn to an arrow shape, and be placed next to the destination. stop there to drop off the passenger.

 

if you drop someone off successfully, you can then pick up another customer and drop them off. There are a lot of bugs right now, including some super ugly transitions between screens, and some destinations are impossible to drop off people (the distance check is failing). If you encounter that, just restart

 

any feedback is welcome, I've made a lot of progress and it's starting to feel like a game! Next I think I need to fix the existing bugs, and then move on to a basic timer and scoring system.

 

requisite GIF:

 

(I wonder how I can capture a GIF that doesn't flicker so insanely, this isn't what it looks like in Stella at all)

 

 

...And new build download link:

taxi-panic_2016_03_29_pickup_and_delivery.bin

[+Random Terrain]

Any feedback is welcome . . .

I don't like the playfield doing what it's doing when you bang into it.

 

 

 

(I wonder how I can capture a GIF that doesn't flicker so insanely, this isn't what it looks like in Stella at all)

Looks like you're not pressing Alt + P.

 

 

 

 

 

[Thomas Jentzsch]

I don't like the playfield doing what it's doing when you bang into it.

I suppose that is just debug code. If anything should blink, then it is the car itself. Combined with some sound.

[Thomas Jentzsch]

I don't like the flickering sprites now. Maybe you could use a missile instead to indicate the direction? A simple bar at the screen border should do. That or intelligent flicker with sprite reuse.

 

Also the indicator should be a bit more precise and not just in steps of 90°, but at least 45°. That allows better planning of the route.

 

I noticed a bug when I am transporting a passenger. Sometimes an intermediate screen shows up for a few frames.

 

Another bug is related to picking up the passenger. At the start, the left passenger is picked up not when you run over it, but when you are below him.

[Mr SQL]

Great progress Walaber, Taxi Panic is looking awesome!

 

The flicker is fine with Stella phosphor as RT illustrated or real phosphor (better still) so the question becomes do you want to support LCD displays, and do you want to support Stella without phosphor enabled.

 

I have to do the latter with StarBlitz because phosphor simply doesn't work in Stella at high frame rates; with the features in the deluxe edition I can't support Stella at all, LCD or even PAL displays, but I also have a standard edition to accommodate those configurations.

 

You could create a maximum fun edition and one that uses the Lowest Common Denominator (in this case the LCD might literally be an LCD or the emu) so no one has to turn on phosphor in Stella.

 

 

[walaber]

Thanks for the feedback. The weirdness when you collide with the terrain is just a bug at the moment, so is the weird intermediate screen when driving around with a passenger.

 

The indicator does support 45 degree increments, although I agree more fidelity would be nice.

 

I'm not sure how to reduce flicker further, because here's what I'm working with:

- Reflected playfield that takes nearly an entire scanline to update

- That leaves one scanline (of the 2 scanline kernel) to draw the car, 1 destination sprite, the guidance arrow (sometimes), and up to 2 passengers on the road (using missiles at the moment).

 

so my solution at the moment is that I flicker a missile for the passengers (because they need unique colors), and I flicker between the destination and the guidance arrow (when carrying a passenger). any thoughts on how I could reduce flicker? the kernel feels pretty tight unless I go to some crazy sprite routines that take less cycles.

[Thomas Jentzsch]

The indicator does support 45 degree increments, although I agree more fidelity would be nice.

Probably the flicker distracted me too much.

 

I'm not sure how to reduce flicker further, because here's what I'm working with:

- Reflected playfield that takes nearly an entire scanline to update

Hm, I count 8*6 = 48 cycles. That's about 2/3 of a scan line.

 

so my solution at the moment is that I flicker a missile for the passengers (because they need unique colors), and I flicker between the destination and the guidance arrow (when carrying a passenger). any thoughts on how I could reduce flicker?

Do you need both, the destination and the guidance arrow at the same time?

 

the kernel feels pretty tight unless I go to some crazy sprite routines that take less cycles.

Have you looked up SkipDraw and SwitchDraw?

[alex_79]

so my solution at the moment is that I flicker a missile for the passengers (because they need unique colors), and I flicker between the destination and the guidance arrow (when carrying a passenger). any thoughts on how I could reduce flicker? the kernel feels pretty tight unless I go to some crazy sprite routines that take less cycles.

Maybe you could ensure that the destinations are never placed on vertical positions where the direction indicators may appear, or you could display an arrow above or below the playing area to indicate the direction (maybe together with a score).

 

To indicate the destination, you could just flash slowly (like, every 20-30 frames) the destination sprite, or alternate between two colors, or between the destination and an indicator.

 

Anyway it's looking very good so far. Keep up with the good work!

 

Edited March 30, 2016 by alex_79

[walaber]

I originally thought about hiding the passengers on the street (and all destinations) when you're carrying a passenger, so I could re-use the other sprite and possibly missiles or other objects for better navigation feedback. But I'd really rather not do that, because a big part of the game is learning the city, which is reinforced when you pass by other destinations while delivering a passenger to another destination. If they're hidden during that time, you lose key landmarks most of the time.

 

Same thing with potential passengers. while you're delivering passenger A, it's important to see potential next passengers and remember where they are, so you can go pick them up after you drop off your current passenger.

 

BTW this is the sprite draw routine I'm using, it takes 22 cycles:

; sprite graphics...
	TXA						; 2	
	SEC 						; 2
	SBC PlayerPosY+1				; 3
	ADC #C_PLAYER_SPRITE_HEIGHT 	                ; 2
	BCS .DrawPlayerTaxi				; 2(3) - total of 11

	NOP 						; 2
	NOP 						; 2
	NOP 						; 2
	SEC 						; 2
	BCS .DoneDrawPlayerTaxi 	        	; 3  - total of 11
	
.DrawPlayerTaxi
	TAY 						; 2 + 1 for branch
	LDA (PlayerPtr),Y 				; 5
	STA GRP0		 			; 3  - total of 11

.DoneDrawPlayerTaxi

The other issue is that I'm not sure how I'd add horizontal re-positioning during my kernel, in order to avoid flickering when things don't overlap horizontally... because the positioning logic takes 1+ scanlines just for it, and I don't really have a spot in my kernel to spend an entire scanline doing nothing but re-positioning. I could go even more interlaced with the graphics I suppose?

 

my current kernel looks something like this (pseudo-code)

TOP:
WSYNC

convert scanline index into playfield index - 10 cycles

set initial values for PF0,PF1,PF2 - 24 cycles

wait 2 cycles

set mirrored values for PF0, PF1 - 16 cycles

Clear PF2

decrement scanline index, do some loop logic

Clear PF1
Clear PF0

Draw taxi sprite - 22 cycles

Draw secondary sprite (either destination, or navigation arrow, flickers every other frame) - 28 cycles b/c I also set COLUP1 here.

Draw 1 passenger/pedestrian on the road (missile) - currently using missile 1 - 21 cycles including setting COLUP1

So it's a 2 scanline kernel with only 1 WYSNC, to make sure the playfield code is perfectly synched. I have to set PF0,PF1,PF2 to zeros as well to make every other scanline empty (since I'm spending that scanline doing sprite and missile graphics). It would be cheaper to just set COLUPF to black, but that would break my collision routines, which depend on checking for collision between P0 and the Playfield.

 

I currently have a separate kernel for collision resolution frames, where I stop drawing other sprites and instead draw 2 single pixel missiles in front of the car to detect how to best resolve the collision.

 

Ideally I'll add a 3rd kernel as well, for "highway" screens, which will sacrifice drawing pedestrians or destinations in favor of drawing some traffic that you have to dodge.

[+SpiceWare]

The other issue is that I'm not sure how I'd add horizontal re-positioning during my kernel, in order to avoid flickering when things don't overlap horizontally... because the positioning logic takes 1+ scanlines just for it, and I don't really have a spot in my kernel to spend an entire scanline doing nothing but re-positioning. I could go even more interlaced with the graphics I suppose?

You end up having 11 different kernels that each take just a single scanline to reposition the player at 1 of 15 X values. Simple demo here which also shows how to do it while eliminating the HMOVE lines on the left:

EarlyHM26:		;   15 positions for   0 -  14
	lda EarlyHM	; 3 18
	sta HMP1	; 3 21
	SLEEP 2		; 2 23 other TIA updates can be done here
	sta RESP1	; 3 26
	SLEEP 41	;41 67 other TIA updates can be done here
	jmp EarlyHMOVE
	
EarlyHM31:    		;   15 positions for  15 -  29
	lda EarlyHM	; 3 18
	sta HMP1	; 3 21
	SLEEP 7		; 7 28 other TIA updates can be done here
	sta RESP1	; 3 31
	SLEEP 36	;36 67 other TIA updates can be done here
	jmp EarlyHMOVE
...
EarlyHM66:    		;   15 positions for 120 - 134
	lda EarlyHM	; 3 18
	sta HMP1	; 3 21
	SLEEP 42	;42 63	other TIA updates can be done here
	sta RESP1	; 3 66
	SLEEP 4		; 4 70
EarlyHMOVE	
	sta HMOVE	; 3 73

EarlyHM71:  		;   15 positions for 135 - 149
	lda EarlyHM	; 3 18
	sta HMP1	; 3 21
	SLEEP 47	;47 68 other TIA updates can be done here
	sta RESP1	; 3 71
	sta HMOVE	; 3 74	early HMOVE works at both 73 and 74
	jmp bsl71	; 3 77/1

EarlyHM22:		;   15 positions for 150 - 159
	SLEEP 4		; 4 19 other TIA updates can be done here
	sta RESP1	; 3 22
	lda EarlyHM	; 3 25
	sta HMP1	; 3 28
	SLEEP 39	;39 67 other TIA updates can be done here
	jmp EarlyHMOVE

Each kernel has a lot of extra time that can be used for updating the playfield, etc. To make things easier with your kernel do the repositioning during one or more of your blank playfield scanlines as on those scanlines you only need to update PF0, PF1 and PF2 a single time with the same value of 0.

[Thomas Jentzsch]

; sprite graphics...
	TXA						; 2	
	SEC 						; 2
	SBC PlayerPosY+1				; 3
	ADC #C_PLAYER_SPRITE_HEIGHT 	                ; 2
	BCS .DrawPlayerTaxi				; 2(3) - total of 11

	NOP 						; 2
	NOP 						; 2
	NOP 						; 2
	SEC 						; 2
	BCS .DoneDrawPlayerTaxi 	        	; 3  - total of 11
	
.DrawPlayerTaxi
	TAY 						; 2 + 1 for branch
	LDA (PlayerPtr),Y 				; 5
	STA GRP0		 			; 3  - total of 11

.DoneDrawPlayerTaxi

There are a few tricks to accelerate this code:

1. Instead of branching to .DrawPlayerTaxi draw to something like .SkipDrawPlayerTaxi and from there back to .DoneDrawPlayerTaxi. That saves one cycle.
2. Maybe you can make sure that the carry is always set. That would save another 2 cycles
3. This is more complicated: Use Y as your scan line counter and for loading the sprite data. For doing that, you have to manipulate the pointer so that it points to the graphics when the scan line is reached.

There are quite some advanced tricks which save time and have been discussed a lot, e.g. check this thread.