Dave C

So I started out learning BASIC on a TRS-80, typing in programs from magazines (like many people here), later I wound up going to school and learning formally. So I have a mix of self-taught and formal education and job experience. I will say - I like to code but I have never really been the best amongst my peers - I just like it enough to persevere and I have been lucky enough to keep going. I know that because of how I learned programming by typing things in I always want to start from the smallest possible examples and work from there. So I like to read the examples at the site you mention and also Alien Bill https://alienbill.com/2600/bbkickstart/ - I think they are good. I also have to troubleshoot a lot, and it is good to ask questions (I am not good at this myself). I believe the forums here are really, really good at helping. One other thing I like about Atari, there are so many public codes to read so I have a "study" directory - it is full of KevKelley's demos, MSohl, yours, random terrain, demoscenes, etc. I look at the code, run them in Stella and step through to see how they work and make changes to see what happens.

I think your version wins on game mechanics - things like picking up the pizza box feels more tactile, the use of sprites and missiles matches the way the kernel works (there's going to be flicker in my code, right now more than there strictly needs to be), the street layout allows for more destinations, etc.

Happy National Pizza Day! https://foodchannel.com/tag/national-pizza-pie-day

Yeah... there's kind of two variants but they are both Pizza Boy... I am specifically building a version tuned to visually match @kid_snz 's AR project work I would say @KevKelley's is also Pizza Boy tuned with more gameplay-oriented elements.

Interesting. I was trying to adjust the bounce based on which side of the building the boy was on (trying to make turning corners smoother, there was a tendency to bounce the wrong way away from a corner) but this created some situations where you "slide" through / across a building. Your loop cuts the bounce logic short in a couple of interesting ways... NYC $$$. I was wondering if the boy should get a higher score for faster delivery / get a delivery canceled. I was hoping to get the lives/score on the same line but it's tricky using the sprites that way (have to use both sprites for the score even with just 3 digits...)

This is great. I only recently learned of this tool (seeing the demo of your tracks on ZPH podcast - very cool and motivating) it's pretty cool. I am on OS/X so i had to build myself which got a little weird - had to make some changes like the following... - noteAreaWidth = noteFontMetrics.width("000: C#4 I7 31") + noteAreaWidth = noteFontMetrics.horizontalAdvance("000: C#4 I7 31") I got what I thought was Qt5 but it appears to have marked the width() method obsolete (and a few other, minor things) - is it worth it to update the code or might that break compatibility on "regular" Windows builds (happy to provide a CR with the changes I had to make)?

Thanks all! I start feeling like the taxis aren't dangerous enough, but then I'll get hit by one...

small update - hacked in $ score, life display and a new crash animation from @kid_snz - I still haven't gotten to trying out barricades (next) and collision on the buildings is still messy... pizza-boy-20220206.bin pizza-boy-20220206.zip

@KevKelleyI'm thinking about making a more modified kernel that may help with both trying to give @kid_snz a playfield to match his painting and help get more sprites in like the jackhammer guy, cones, etc - if we expect to have a lot of sprites that don't move vertically makes it easier to reuse sprites - as long as there's enough RAM to hold the data (which - the superchip does have available RAM...). The general purpose kernels can't make those assumptions. Attached is my latest demo - another update with some taxi movement and tuning the sound a little. pizza-boy-20220203.bin pizza-boy-20220203.zip

It could be the cones maybe only slow you down / make you lose some control. Which could be interesting on the street. The flicker could be manageable if everything is offset vertically / maybe play around with blink (like the pretzel blinks rather than flickers - originally to get around the limit on the number of sprites in the multisprite kernel)

Yeah so I was finding it hard to figure out all the playfield options without looking at the actual kernel. This section that can be seen from @Al_Nafuur’s link is the one that I needed to deal with to be able to use PF0 sty temp1 ldy pfpixelheight lax (PF1pointer),y stx PF1 ;+7 26 lda (PF2pointer),y sta PF2 ;+7 33 ;sleep 6 stx PF1temp2 sta PF2temp2 dey This code is loading the current playfield line number into the y register then loading up PF1 and 2 (note: no PF0 at all in the main playfield kernel) then there’s some business where it saves the values in RAM for faster access in case they are needed later What I did is hardwire in the playfield references to get a little time back and also be able to remove the need to do all the side-saving - TLDR I got enough cycles back from that to get the 7 cycles needed for PF0. I was thinking about the possibility of asymmetric plus multisprite - for this game specifically it could be made to work by doing all the sprite repositioning in places where there are blank lines. It would mean making almost a new kernel though.

Screenshot of the latest AR-type version (.. and the blink+flicker effects makes taking a screenshot a little odd. I'm thinking someone must have solved this before... or there's an option in Stella I don't know)

Yes CTRLPF can work for some playfields. The main caveats are there will be a blank space in the middle because (as I discovered) multisprite doesn't use PF0. The other is on some lines multisprite loads PF1 and PF2 in an order that makes sense for mirrored but causes a bit of a glitch with repeated. So to mod the kernel I didn't have to do major major changes I just had to find enough room to add PF0 (7 cycles) and then dial the writes back/forward a notch... and it's *almost* there... (there's a slight glitch in the P0 sprite)... I'm including my latest demo. I did a translation of one of @Sohl's sounds as a POC - I think I might want to just bring in the asm updated sprites from @kid_snz the repeated playfield player moves half speed as the original cabs weave around a little player glows when invincible added an extra invincible sound There's a couple of bugs one is that collision is still janky and collision with the playfield seems extra janky now I was able to iron out repeated playfield glitches - but - there's a slight twinge in P0 sprite when it crosses a P1 I'm including the .bas file in an archive with the custom kernel - VS Code *should* be able to build everything as long as it's all in one directory. pizza-boy-20210130.zip pizza-boy-20210130.bin

So I've been keeping with the idea of trading ideas in BASIC (levels the playing field since @kid_snz started in bB)... but it's possible to sprinkle in assembler so there's no problem incorporating @Sohl's code. So the last couple of days I was also playing around with customizing the multisprite kernel to get more playfield options (trying to repro the graphics in the original art while retaining some ability to tweak the game from BASIC). Short story - I've made a POC for doing a repeated symmetric playfield (normally not allowed). It still has a couple of glitches but I believe I can resolve them.

Thanks, it's partly OCD but also in actuality if I didn't name everything I would lose track of what I was doing - especially keeping track of the numbers. I always like to remember / be reminded - the computer does not care if code is good or bad it flows either way.

that cart game looks hilarious (in a good way) like the cart has a mind of its own

All we really have to know is the y position of the boy (is is near a cab lane) and then the relative x positions/direction of the cab. If we had a motor sound we could make it quieter or louder the closer the boy is to a cab? or just make it honk if it is about to hit the boy.

Yeah i've noticed that as well, I'm a little confused by what happens when I mess around with different playfield options - I assumed I was mis-counting the number of lines in my playfield data or something but now I'm not sure.

I like your title screen, it took me a minute to realize it was using the sprites. The item flashing was partly a way to get around the 6 sprite limit, it winds up having a 'Game & Watch' feel that seems appropriate. It does make it impossible to do a screenshot tho... and I'm not sure about the "dropoff marker", doesn't seem quite right how it looks / works but I needed some way to show where I was putting the hit box for deliveries.

If I read this right - your idea is to make the player be blocked by buildings - but not all the time? We are having a lot of the same ideas for the kid_snz delivery concept... In my latest I tried to play with this by using playfield collision but immediately skipping if it takes place in certain horizontal bands (which I figured out by guesstimate / trial and error). This takes advantage of the playfield design having the streets run horizontally. It feels odd turning around corners though, it's very easy to get stuck on corners - and if the numbers are off you get some side weird effects. if !collision(playfield, player0) then goto __Skip_PF_Collision ; skip collision if it takes place in these horizontal bands if player0y < STREET_FRONT_0_Y_MAX && player0y >= STREET_FRONT_0_Y_MIN then goto __Skip_PF_Collision if player0y < STREET_FRONT_1_Y_MAX && player0y >= STREET_FRONT_1_Y_MIN then goto __Skip_PF_Collision if player0y < STREET_FRONT_2_Y_MAX && player0y >= STREET_FRONT_2_Y_MIN then goto __Skip_PF_Collision I really like the way delivery works in your demo. And your title screen - I borrowed the idea of your title screen but mine is pretty weird looking r/n.

New demo merging elements of other demos - splash screen from KevKelley (except mirrored, need to think about ways around that) - to get around the 6 sprite limit, I had some sprites be "shared". These don't flicker so much as blink on and off. I specifically chose sprites that should be player objectives, like the pretzel and/or delivery addresses. - more gameplay - the pretzel now grants immunity - you can now run out of lives - sounds when you get hit by a taxi - yes it's the Fugue in D Minor that I pulled code from various basic demos and transcribed the notes from Wikipedia pizza-boy-20210124.bin pizza-boy-20210124.bas

There is actually an online tool that can help with this: https://www.igorski.nl/apps/slocum-tracker

For that flag effect did you use P0/P1 color scheme? I was playing around with switching the PIZZBOY demo to use repeat instead of reflect. I saw some glitching, the multisprite kernel must be loading PF registers in the order it thinks it needs to load them for reflection. I played around a bit today as well - made a fusion between my last demo and @KevKelley 's layout with the square-style buildings. - added the ability to deliver to buildings (marked by the --- it moves over time) The virtual collision computations are still a bit off (esp the buildings - you have to hit the marker) pizza-boy.poc.bas.bin

I really like the way the pizza box works as well as the cars zooming across the screen, very cool.

That makes me wonder @kid_snz were you thinking about sounds (should there be sounds)?