homebrew Taxi Panic!

[Mr SQL]

Both of those techniques are excellent if you wish to display very many sprites but have the drawback of variable flicker when the sprites overlap.

 

How many sprites do you need? imo you can double the players and the missiles without flicker if you alternate precisely every other frame.

 

This works because phosphor persistence is designed for 30 FPS and the Atari is double the spec at 60; the flicker free characters in this unreleased prototype are a good example:

[walaber]

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!

[Mr SQL]

 

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.

 

 

Very cool, that's going to look even better on CRT.

 

imo that's where it counts

[walaber]

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

[Thomas Jentzsch]

only problem now is apparently my labels are to verbose they're all so long Stella has to shorten them

Maybe another feature helps you here: SUBROUTINE

 

By adding SUBROUTINE after a label (e.g. a subroutine start), you can use local labels (which start with a .) like e.g. .loop and don't have to make up unique label names. The local labels are only visible between two SUBROUTINEs.

[walaber]

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

[maiki]

Please, do you test the output on real CRT TV? The reason I'm asking is because many times it is very difficult to read the numbers and letter in 2600 games when "wrong" colors are selected and RF signal puts various artifacts to the pixels. And what makes everything worse is that for some reason nearly all 2600 fonts tend to overgrow horizontally but stay squashed vertically. Such wide text is really not comfortable to read at all.

[walaber]

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.

[walaber]

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

[AtariBrian]

Excellent job so far , can't wait to see a finished game .

[the.golden.ax]

sally will like this

[+grafixbmp]

I wondered about your cases where you had 3 player sprites on the screen and the thought about if you cycled both sprites across all 3 positions. So instead of one on 60 frames and the other on 30 they could share the load and be on 40 frames by being off every 3rd frame. Just a passing thought...

[LS_Dracon]

As for optimization, have you thought about variable vertical resolution for PF?

Some screens with buildings only, no diagonals or other details, can be made with 12 bytes only...

 

Edit : Found 2 problems :

 

1 : Running and hitting the corner of the vertical exits, makes the screen jumps (randomly?)

happens at bottom of the screen, also.

 

2 : The "hit spark" is bleeding in this area.

 

 

Edited April 11, 2016 by LS_Dracon

[+Propane13]

Perhaps since you've hit the "Sacrifice gameplay or graphics" decision, maybe it might make sense to increase to 8K?

I know it may not be desirable for certain reasons, but if it makes a better game, maybe it makes sense.

[walaber]

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).

[walaber]

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.

[LS_Dracon]

Removing PF0 is a good idea.

Perhaps you save bytes enough for code new kernel with variable resolution, which will save more bytes yet.

 

Or move to 8k, and then you can build other city and makes the game looks better.

Edited April 12, 2016 by LS_Dracon

[gauauu]

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).

 

This is what I did in my game, changing each screen from 1 pointer to 3. It ended up saving hundreds of bytes. Hopefully it will pay off for you as well!

[Thomas Jentzsch]

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).

Have a look at my AA blog for data overlapping optimizing. DOOD should save you some time.

[walaber]

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.

[Thomas Jentzsch]

Right, your table would be 250 bytes (2*5*25). So it all depends on the amount of data you can save by overlapping. And the number of PF columns you can reuse completely.

 

And additionally you can indirect the table and save bytes there too:

 

E.g. if your whole map consist out of 50 different data blocks (= PF columns), then you need a two byte pointer table (2*50=100 bytes) and another table of ids pointing at the pointers (5*25=125) bytes. So in total you are down to 225 bytes.

 

Also you do not need all bits of the two byte pointers. In our case of 50 different data blocks, you need 11*50 = 550 bytes. That means 3 pages. So you can reduce the two byte pointers to single byte low pointers and derive the high byte from the id (e.g. id 0..19 = page 0, id 20..39 = page 1; id 40..49 = page 3. That reduces your table by 50 bytes, but costs you a bit of extra code (~15 bytes). Overall we are at 190 bytes then.

 

And instead of 1375 bytes for the map (as it is now), you would need 550 + 190 = 740 bytes. And the latter already includes all pointers and assumes there is not partial overlapping (which definitely is not the case).

[walaber]

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

[walaber]

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.

[walaber]

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.

[Sapicco]

Hi, sorry there are a lot of pages to read through here. Will this be made into a cart? If so, please add me to the preorder list. Thanks!