Dave C

Yes since now I'm thinking about would it be just as easy to use the same kernel as @KevKelley but find a way to add more sprites. My demos above used the following kernels but both had flaws: - DPC+ - high resolution playfield, many sprites (up to 10) but doesn't work with javatari - multisprite - works with javatari but less resolution and less sprites (up to 6)

Okay this is what happens when I can't let go of an idea - multisprite version - these batari kernels really are very different... (reversed y axis - different resolution - much lower res playfield... but Javatari compatible)... pizza-boy.poc.bas pizza-boy.poc.bas.bin

Aaah. Makes sense. I believe Javatari is a requirement here so DPC+ is no bueno. And I just thought "DPC basically has all the sprites - I just throw some sprites in some DPC sample code, crib some notes from the LawnBoy conversion and there's an easy POC..." That being said - here's a POC using DPC+ pizza-boy.dpc.bas.bin pizza-boy.dpc.bas

Is there any downside to using the DPC+ kernel? That appears to check a lot of boxes (it's still kid_snz's game but I'm definitely up for helping out, I can see where understanding all the different kernels is a bit of a stretch for a beginner).

I think the interesting thing when I saw the art concept I thought - that looks like something that would be just about possible. The big thing with the Atari playfield is it is 40 pixels across so that limits the complexity of the graphics. So KevKelley's example shows some complex buildings within that 40 pixel space - all playfield. I had some thoughts about making the buildings more detailed using sprites but... it gets weird... It's legal to have three copies of a sprite on a line without bending any rules - but four is hard without using another sprite. And in batari basic (maybe someone can correct me if I'm wrong) except for some very special effects you will have flicker if there is more than one sprite on a line that isn't the player. So... I was wondering if you could successfully combine sprite and playfield and at worst only the windows would flicker (make the sprite act as windows): (negative sprite over playfield - debug mode, yellow is sprite, purple is playfield) But - the flicker is still not the best and you have to make sure the playfield and sprite line up, which gets tricky: (fail) That makes me think the buildings should probably just be playfield. Guessing that will also make collision simpler. (big playfield buildings)

That's a good point on multisprite - I was wondering if one of the souped up bB kernels could handle most everything. I don't know how to phrase it but it's like - the buildings in the artwork are very intriguing to me... - you could make them exactly as shown with playfield graphics only and they'd be a bit chunky - you could make a compact one by combining playfield with sprites (use sprites to make the windows) - and you could have 3 but.. you need them spaced just right and it's just a little bit tricky...

New bugfix release: LegendarySpear_NTSC.bin LegendarySpear_PAL60.bin

That is exactly what I needed. ...and this looks like the culprit. - and $0f ;2 53 + and #$0f ;2 53 This was where the code extracts bottom half of an enemy sprite's horizontal positioning byte (the top half contains the HMOVE for fine positioning, the bottom half controls RESP1 strobing) - but only for the case of being in the middle of drawing the player. TLDR with developer mode on - total havoc. So far not finding anything else super obvious. The game feels like it plays different in developer mode... but I also haven't played in a while so my memory is a bit fuzzy.

thanks!

Thanks Darrell - I thought I had erased all those glitches (I hate those) but I didn't have that mode set, I'll go back over it. The forgetting to do # sounds familiar... I have also had a number of problems that long story short - were due to missing certain transitions (I strobe RESP1 for every enemy - and have separate routines depending on whether I need to do an early or late strobe and whether I am drawing the rider or not - lots of opportunity for mistakes and on a few occasions found the code had drifted to branch near a page boundary - adding an new uncounted cycle ). I question whether or not it was a good idea to do things this way but once I got it mostly working it was hard to get loose of making it work for real.

Those are seriously awesome. I've been in the Salesforce building in Bellevue, WA but never past the lobby. Very very cool.

I might be able to help a little bit here - I have one ask which is I have couple ideas I'm working on and would like some input on graphics - could be nothing more than just concept art but I'm also looking for some font and sprite ideas.

It's a lot of work to make a full game... but - this concept + the AR project looks interesting especially if just one level. I like the style and use of colors - Atari has lots of colors for the era, nice to use them. There are some challenges you'll need to understand to make the game - the taxis and the player are 9 pixels wide, sprite is only 8 - there are only two sprites having the player carry the pizza past a taxi means three different sprites on one line, close together - similarly buildings - multiple is okay, you can make the same sprite appear up to three times, not four, but add the player and the pizza and the tree... The player + pizza + (any other graphics) is the one I'm not sure there's a nice solution without compromises. I'm thinking about the recent homebrew Doggone It, has the player delivering boxes but does some clever color changes to make the player look like they have a box in their hands.

+1 . Writing to RESP0 has ... all kinds of tricky side effects. To keep things simple strobe RESP0 before you go into your display loop. This could be as simple as inserting WSYNC / SLEEP ... / sta RESP0 - before you go into LVScan. By changing the sleep value you'll be able to observe how strobing at different points sets the sprite to different horizontal positions. It is also super helpful to use stella in debug mode and step through frame by frame / line by line to observe what's happening on each scan line.

Updated for end of year... I've made a few minor tweaks for stability, I'm calling this version the final release. I did do a little work towards having a splash screen / thinking about different gameplay elements but ultimately that will have to be a new game (or maybe a Director's Cut?). In the meantime I've been mocking up some ideas for a new project or two, can't decide on whether it should be 2600, 8-bit or ... I like the idea of something multiplayer with the paddles. The 2600 paddle situation is... interesting... I like the idea of doing more animation... and always liked the style of shooter/fighter/platformers like Rolling Thunder, Ninja Gaiden, Metal Slug... my gut says that seems more like something not to try and fight the stock 2600 hardware with...

Here's the original inspiration

Not really a game of any type, just a (very glitchy) demo I came up with after some marble game demos started popping up in my feed. marbles.asm marbles_NTSC.bin marbles_PAL60.bin

For sure I've been benefitting from the tips and tricks.

Forgive me if I didn't RTFM enough on DASM or Stella. I am wondering if there are existing tools for analyzing 6502 assembly and suggesting optimizations. I didn't find anything obvious but I'm kind of guessing *something* exists...? For example - I found a spot in some of my code where I loaded a register but never used its value in any way before reloading. Now maybe I might be using that for timing purposes but in this case it was just me blundering around changing things and losing track of what I was doing. It seems like something DASM - or Stella - would be able to call out though... Similarly - unreachable code /data - locations in ROM that are initialized but never read during the run of a program. There are other situations - like - I have code that takes advantage of knowing for instance that y will happen to have value $ff and instead of doing a ldy #$0 it will do an iny to save a byte of code space. I'd like to set an inline assertion for Stella to break if that ever becomes untrue... that seems more like something that could be done with a little bit of build scripting...

K. Well I was intent on having a "no screens day" but that is blown. Going to call the latest release candidate 2.5 in honor of AtariDOS 2.5. Fixed a few little errors arounds hits/damage that I was noticing - basically due to some code size optimizations I was using to squeeze the last few bytes like not loading a value into a register that would already have that value as a side effect of some other operation... that weren't valid anymore (TBH I have mixed feelings about those particular kinds of opportunistic tweaks, not only because the fact that I found a lot of them suggests I did a bad job of register management, but also I keep finding the occasional bit of dead code that is totally safe to eliminate).

Thanks, I was looking at Stampede when I first put it together, but it's kind of more like a side scroller now. But I appreciate now how much variety is in Stampede in terms of the cattle movements and graphics/ I'm now super annoyed at the timing around game end - it's easy to die while pressing the fire button and restart the game quickly when maybe that wasn't your intent. The hit box detection is also a little wonky but not totally sure if that's good or bad. Also it's somewhat maddening that I keep finding a byte here and there I can use to make fixes and stay under 2k (why didn't I see some of these before)... and I just realized there's a way to get a whole 23 bytes (at least)

New weekend new release, will update the head messages. I'm likely to take a break after this and do some other projects (other than bug fixes). new hit mechanic - to score you must attack the enemy head on (you can't hit them in the legs and score) new charging mechanic - charge attacks hit anywhere, and can break rocks. cleaned up a bug with enemy variety (was missing a color) I played around with the charge covering more ground, having the hit location affect score etc but couldn't get a balance.

Thanks for the feedback! There is a little difference in speed and point value between the colors, but it does seem like there isn't as much variety as I would expect - something I'm going to look at, I'm wondering if I have a bug or two somewhere. I have been having trouble tuning the speed and progression in general. I also haven't come up with anything to do with the charge mechanic (other than the visual effect). In the current build the player doesn't so much leap back as bounce back to the original location after an attack - is that what you are seeing? Earlier versions there was no bounce back at all, you would just charge forward and stay there (you also couldn't range very far around the screen)

I'm now at what feels ~ close to a "real" game... so the latest version is now "release candidate 1". I just managed to use the last bytes available* to add a reward if you can finish with a max score... ... although I haven't been able to get that score myself (well, not without cheating) * I'm sure there's more room to be found - but... I'm taking it as a sign that this last bit of space in the upper reaches of the ROM just got filled

Latest changes are up. - couch compliant (when the game ends you can press fire to restart) - more aggressive speed increase - refactoring some of the graphics code to free up code space - cleaning up some graphics and sound glitches This version feels like more of a challenge - prior versions were a bit too easy. Play on Javatari