walaber

just a quick note to say that I've been heavily distracted messing around with VR development in my little free time that I have, so development on this has stalled for the moment. I do hope to return to it though, especially since I'd made so much progress on the game. I think I'll have to probably go over 4K in order to finish the game, so once I revisit the project step 1 will be to set up bank switching, something I've never done before.

Well it took a while but here is an updated ROM in all 3 formats, this fixes SaveKey issues. Beware that if you have the 1.0 version, and you play the game on "Hard (no lava", it's possible that the game will overwrite a byte on the saveKey that's reserved for "Assembloids". The new build resolves the issue and keeps save data in the proper spot for Wall Jump Ninja on the SaveKey wall_jump_ninja_20160508_v1_1_NTSC.bin wall_jump_ninja_20160508_v1_1_PAL.bin wall_jump_ninja_20160508_v1_1_PAL60.bin

thanks for the feedback. hitting a wall does slow you down, but doesn't change the overall deceleration rate. I'll take a look at the physics tuning and tweak it before the next release.

updated my exporter to try more combinations of data overlapping, and now I'm up to 398 bytes free (saved another 38 bytes). Next I need to come up with a scheme to get some traffic in the city.

Success! I changed up my formatting, and with the change I've gone from 126 free bytes to 360 free bytes! not bad! Basically I did the following: 1. Broke my PF data into PF0, 1, and 2 sections, and ran a (naive) algorithm in my editor export to overlap the data. 2. Changed my main data table to be in "bytes from the beginning of the PF data section", 1 byte each, so I need 6 bytes per screen now. 3. Simplified my code to prepare playfield data based on the above. It's not quite as optimized as it could be, and I might try adding to my overlap algorithm to search more aggressively for overlap, but I'm quite happy with the results so far. My current city layout never pack to more than 255 bytes per playfield section, so my single-byte offsets in me table are working fine. Right now all the playfield data is using 546 bytes in total, including the actual PF data, and the screen table.

thanks for the detailed examples. I will give some of these ideas a go and see how much I can crunch the data!

Thanks Thomas, I am familiar with your tool, it's pretty awesome. The biggest issue for me is that my table to data for the city would need up to 5 pointers for PF data for each screen (there are 25 screens), which would add up to a very big table. So I need a cheaper way to derive the location of each piece of PF data if I want to overlap it more aggressively. I think I have an idea that won't be quite as efficient as DOOD, but will be a good trade off for my game. I'll post if it works.

I guess the other big thing would be to make the screens more 'square' by ignoring PF0 altogether. that would save a lot of data for sure... and those poor PF0 bytes are only using 4 bits per byte as well... so wasteful some of the city block layouts would suffer a bit, but the tradeoff might be worth it in the end... I'll look for more optimizations that don't sacrifice content first.

thanks for the feedback and bug reports, I think I have a handle on why they are happening. good suggestion on optimizing the PF data for some of the simpler block layouts... the tradeoff there would likely be a separate kernel for those (I don't think I can afford branching or other logic in 1 kernel), which might outweigh the data savings with additional code size. That's one of the trickiest things, is trying to estimate if a given change will actually be net positive since most tradeoffs trade ROM for CODE or vice-versa. I think it's time to focus on optimizing my playfield data though, it's the biggest piece by far and definitely has lots of repeat data. My guess is that if I can overlap and share more data, that savings will outweigh the additional pointers I'll need in my city data table (each screen would go from 1 ptr to 5 ptrs).

progress! I've got all the basics of the scoring system implemented now. Basically here's how it works: Each customer has a "base fare" they will pay, scaled by how far away the destination is. The amount of time you have to deliver them is also distance-dependent. For each second you're driving them and you don't collide with anything, you get a "tip". Eventually there will be another tip for a perfect delivery (no collisions), but that's not hooked up yet. The score display is pretty ugly but functional at the moment. 6 digits for score, and two meters (sandwiched between the black lines), top meter is time left to deliver the current passenger, bottom meter is overall time until game over. The taxi flashes red when you are less than 3 seconds from running out of time to deliver a passenger. Here's an updated build. The tuning of the amount of time you have to play, how long you get depending on passenger distance isn't tuned very well at the moment, so the game is not very exciting yet. I'm also missing 1 big gameplay feature: tracking who you've delivered so you can't pick them up again. Unfortunately I'm down to... ~160 bytes free at the moment, so I'll likely need to do a size optimization pass soon in order to add the remaining features mentioned above, not to mention sound, title screen (ideally), and preferably music. oh yeah, and TRAFFIC!!! taxi-panic_2016_04_09_scoring_system.bin

Yeah I have a harmony connected to a (pretty crappy) CRT and I test the game on it fairly frequently. good point to check on the text and make sure it's readable.

I was indeed aware of SUBROUTINE, and I've been using it properly on this project (I didn't use it on Wall Jump Ninja). still, apparently my label names are too verbose Lately I've been working on the scoring system, so far I just have a variable big enough to hold a 6-digit score, and I've created a 48-pixel kernel for the score (and eventually timer) display at the bottom of the screen, as you can see here: Next I need to implement the basic timers, and the code to display them next to the score, and then the game will actually have a win/lose condition. I'm dangerously low on ROM, though: Free RAM: 14 bytes Code SIZE: 2114 bytes Data SIZE: 1497 bytes ROM Free: 481 bytes only 481 bytes isn't much. after I get scoring working, I'll have to embark on an optimization pass to try and get some space back, since I still need sounds (ideally also music), and preferably some kind of title screen... not to mention I really want traffic on the big "highway" roads to dodge... it's going to be SUPER TIGHT to fit this game into 4K. I'll likely be asking for help in ideas and ways to optimize both the code and the data from everyone here

OK, I've fixed a lot of bugs, here's a new build that's feature-wise identical to the last one, but should be much cleaner to pickup and drop off passengers, transition between screens, etc. The screen shouldn't flicker and flash so much when you hit walls now, and I've also made way for the HUD at the top of the screen now (that's the yellow band of color you see now). up next is a scoring system! taxi-panic_2016_04_03_pickup_and_delivery_bug_fixes.bin Also, I can't believe I just recently learned that you can add an option to the command line for DASM and generate a "symbol" file, which Stella can interpret, and give you MUCH more readable source code in the debugger. Up until now I was just parsing through the raw source in the debugger looking for my code... WOW this is a life-saver. in case anyone wasn't aware, it's the "-s" option in DASM that does the trick, use it to output a .sym file of the same name as the .bin, and (if they're in the same folder) Stella will auto-detect it. only problem now is apparently my labels are to verbose they're all so long Stella has to shorten them

All of the flicker currently is alternating every frame, so anything that flickers flickers at exactly 30hz. it looks great in Stella with Phosphor enabled. I'll try it out on hardware tomorrow and see how it's looking on an actual CRT. for the time being I need to fix bugs, and then get some more gameplay in. after that I can perhaps look at optimizing the kernel further. some of the other sprite techniques are pretty cool, thanks for the links!

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.

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.

looks nice, but the brown background on a black cartridge makes it a bit bland... maybe do a much larger zoom-in on the car and focus on it instead?

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

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.

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

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

Saw this on facebook today, hopefully I'm not reposting, but didn't see an obvious thread. Basically it's a Flashback, screen, speaker, battery, and controller all shoved into an original 2600 cartridge! pretty awesome. A version of this with Harmony permanently inserted and an SD card slot would be super cool http://toyland.gizmodo.com/an-atari-cartridge-game-boy-lets-you-play-retro-games-w-1766043576?utm_campaign=socialflow_gizmodo_facebook&utm_source=gizmodo_facebook&utm_medium=socialflow

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.

30fps.

I use a simple program called LICEcap which is available for Windows and OS-X. I just record myself playing the game in Stella with that. It's a pretty great program.