Jump to content

walaber

Members
  • Content Count

    159
  • Joined

  • Last visited

Community Reputation

217 Excellent

1 Follower

About walaber

  • Rank
    Chopper Commander

Recent Profile Visitors

4,559 profile views
  1. 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.
  2. 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
  3. 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.
  4. 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.
  5. 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.
  6. thanks for the detailed examples. I will give some of these ideas a go and see how much I can crunch the data!
  7. 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.
  8. 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.
  9. 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).
  10. 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
  11. 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.
  12. 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
  13. 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
  14. 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!
  15. 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.
×
×
  • Create New...