splendidnut

Probably should give one last update for this year (2018)....with a buggy yet feature complete (maybe?) version. Notes from week of December 17th (12-21-2018): - converted to using new level layout structure.. code paths are still similar to previous implementation Level Data was 52 bytes... now is 60 (nibbles specifing allowed directions at intersections) - worked on level drawer which utilizes new level layout data - will help reduce storage required for levels - played around with burger colors - partly as an attempt to fix remaining burger dropping issues - partly because of tomatoes appearing like purple onions on some systems Notes from last week of December 2018: - finished new level loader code Now uses the same data structure that is used to control movement (player/enemy) - tweaked Pepper spray - added scoring for enemies riding to the bottom - added lives and pepper counters - added items using current flicker method (when item is shown, all sprites flicker at 20hz, so it's pretty harsh) - added makeshift title screen (displayed using the main game kernel) - scoreboard flashes between score and lives/pepper - fixed music engine to allow selection of music playing (for start of level, player death, and level victory music) Things missing: - Flicker management (lots of code written... but not finished yet, so cannot be turned on... it's an all or nothing kind of thing) - Floating scores for enemies dropped onto burger pile (little more involved since multiple enemies need to be hidden) Still need to: - load level layout data into DPC memory and access it that way which would allow level data to be stored in only one bank (as opposed to 3 copies, burger/movement/level banks) - work on enemy logic (handle dead ends, avoid turn arounds, etc...) There are probably a few other things I added or broke in this build. Enjoy! chaoticGrill-2018-12-31.bin edit: Had to fix the year in the notes... apparently I was a little too ready for the new year to start.

Have you tried experimenting with flipping the second condition around? Try: if player2y < player1y && player2y + 24 > player1y then _wait and look at the code that produces. The code puts a copy of A, which is the result of player2y+24), onto the stack. Then performs the comparison with player1y. PHA TSX PLA -- puts A on the stack and puts the stack pointer into X and then "pops" A from the stack... A still exists on the stack since pop only reads the value and moves the stack pointer without clearing that spot. CMP 1,x access that copy of A on the stack using the saved pointer which needs 1 added since the stack pointer always points at the next available spot and not the last value added. If TSX was moved outside of the PHA PLA then it would be CMP 0,x instead. To answer the other portion of your last question, < and >= are the simplest cases to handle in assembly (equal and not equal are also simple cases). For good information about doing comparisons in assembly: http://6502.org/tutorials/compare_instructions.html Hopefully I explained that clearly enough

Wow, this looks amazing! Great work John. Can't wait to see this in action.

Finally, some sanity has returned to this thread. You're seeing exactly what I'm seeing issue-wise with the movement code. The code still makes decisions at grid points and not real intersections. Basically I patched the decision code to favor turning at grid points (instead of intersections), which keeps the enemies moving, but still has issues with dead ends and reversing directions. It makes for an interesting playing experience since you're never quite sure what the enemies will do. Part of the problem with the enemy movement code is due to the underlying level data structures. Right now I have separate ladder and platform bitmaps which are geared more toward making the player easy to implement (since the player only moves one direction at a time) rather than the enemies (who need to pick a direction based on available options). What it really comes down to is that I need to switch from separate platform and ladder bitmaps (~52 bytes per level) to an intersection array. This would allow both the player and the enemies to know available directions at each intersection and would potentially be more efficient. This is something I've been putting off, since it will involve quite a lot of rework due to the fact that this affects the player, the enemies, and the burgers (since they need to know where the platforms are when falling). Another thing I would like to do along with this would be to rework the level graphics loader to utilize this new data structure to dynamically build the playfield graphics instead of using a big, pre-made playfield graphics array (~170 bytes) for each level. That would open up some interesting opportunities. The other issue I'm aware of is the burgers on level 4 will still occasionally get stuck, and yet you can magically finish the level. Which happens, more or less because the code counts burgers as they pile up regardless of whether they're on a plate or not. How's that for nifty code?

So here's a minor/major update depending on how you look at it. But I finally got around to messing with the enemy movement code (added more duct tape), and things seem to be working a lot better. It's still not perfect, sometimes they do really funky things, but for the most part, the enemies don't stop moving. It is definitely starting to feel more like a game now. As always, there are probably still some bugs in other areas too. Enjoy. chaoticGrill-2018-11-29.bin Still need to work on (no particular order): Flicker management (partially working, have all the pieces, just need to finish plugging them together) Pepper/Lives counters Items (dependent on flicker management) Scoring of enemies dropping Once these things are done, the game will basically be feature complete, but not necessarily finished. ALSO, if any one would like to help out on Sounds, Music, Title Screen, Extra Levels, please let me know.

Wow, that's a lot of suggestions. I'll have to think about it.

It seems there was a little bit of wackiness with the scoring of the squashed enemies... I've fixed it so that it lines up with the floating score being displayed (and extended how long the floating score is shown). It'll be in the next build.

1) Scoring squashed enemies is definitely working correctly... and is added to the score at the top immediately before the floating score disappears. It gets tricky to notice if burgers are also falling and bumping into one another. 2) It may not be the spawn points, but the fact that the enemies all spawn at the same time and start moving right as the level starts. I still need to add in spawn/start delays for them. 3) There are only 6 levels.... and hence only six sets of character initialization data. The code only allows up to 4 enemies on a level; whereas, the arcade allows up to 6 (I believe). I'm pretty sure I don't have the available time to do all 6. I've set up a simple time sliced approach to handling enemy movement. Currently, only one enemy is allowed to move per frame, and so it takes 4 frames for all four enemies to move. Overall, I'm thinking I'm going to differ quite a bit from the arcade here, since I'm thinking of adding in more level layouts. And I'll probably be letting you guys be the ones that design them

Worked on improving Player movement code this morning, and I got a bit of a sliding window working. Might be a bit buggy, but here it is: chaoticGrill-2018-11-20.bin Enjoy.

The name is not set in stone. But I think Hamburger Havoc is a little overzealous: Last I checked, the chef made burgers... didn't destroy them At some point (in the Zeropage Homebrew stream featuring Chaotic Grill ) Thomas Jentzsch suggested Burger Chaos, which I like.

I took a break from working on the flicker management and worked on some tweaks and improvements. Changes: Level layout fixes Tweaked all of the chef animations and added chef throwing pepper animation Fixed pepper spray collision boxes. Fixed score resetting issue Added floating score to squashed enemies Added ability for enemies to climb back to level. Enjoy. chaoticGrill-2018-11-11.bin

"Sliding" to the ladders/platforms using a 3/4 pixel wide zone is one of the ideas I'm thinking about doing. It looks like the arcade version does "snapping" to each ladder rung, and "sliding" to a ladder when on a platform and that's probably what people are use to. I believe I had wider zones on the ladders before the August 2018 builds... which people didn't seem to mind that the player could hop on the ladder earlier and climb offset to center.... But then there were issues with getting on the platforms... since they did not have the wider window. Which is due to the fact that I was/am using a trick to calculate whether the player Y coordinate is at a platform. I basically rewrote that code this past March/August to the current implementation which is pixel perfect. To compensate, I implemented the "diagonals" of the Atari controller which some/most Atari games ignore. The code prioritizes the opposite axis to which the player is currently moving allowing easy turning when moving (i.e. if the player is moving right and pushes right/up, the player will turn onto the next available ladder going up). I think the big issue comes when people use the joystick as if it were a 4-way arcade joystick... passing thru the center point when trying to turn. This is what I've noticed when I test the game out on an actually Atari. I believe this is the situation I need to handle better. This is probably where "sliding" should come into play, when the player starts to move from a standstill near an intersection.

Fixed all these except for Level 1... might keep that one how it is now since that makes for a nice and colorful intro to the game (and doesn't affect gameplay/scoring since all burger pieces are scored the same) The code is already setup to blank the screen for 15 frames. BUT yes, I did need to fix level initialization so that it was spread over two frames (not one frame which is how the Oct 10 build does it). I didn't see this issue at first since my working build was set to show the debugging info bar under the scoreboard. But this is fixed now. The burger pieces are a tricky, complicated beast. Speeding up the burger pieces would make them jerky... currently they can only run at 30fps. The burger movement code is spread over two frames due to time constraints. Making them bounce up more also causes issues, mainly when the platforms are close together (i.e. level 4). The vertical compression of the levels probably comes into play here as well. (portrait vs landscape) I did spend quite a lot of time playing around with these things in the past and ultimately arrived at this point. So, I really have no plans to change how the burger pieces work, since they seem to be working relatively well now... I'd much rather fix the remaining issue(s) with them and call it good. I might do a write up on their inner workings at some point.

And there's still room for potentially more levels.

Thanks! The things you mention are definitely issues I'm aware of. The enemy logic is an issue with them not properly identifying intersections, And your suggestion for player movement is something I've had in mind and not quite implemented yet (well, partially implemented, but didn't have the time to debug properly between releases) As for the score bar shifting... I'm guessing that all depends on which version of Stella you are using (I'm using 5.1.3). I do know there is an issue with scanline counts when a player dies/switches level As for a GENERAL UPDATE for everyone else: I'm currently knee deep in rewriting drawing kernels (18 of them) for the flicker management stuff. Things seem to be going well so far... but there are a few issues that are cropping up. Timing is becoming a major issue... but I think i might be able to massage the code a bit to fix this; I believe I still have time available somewhere. The other minor issue is I'm going to need to stop using the hardware for sprite reflection and add the extra sprite patterns.. For the next update, I'm guessing it's going to be another week or two before either (A) I manage to implement flicker management or (B) I give up and work on game play issues.

Sure, that would definitely be helpful to see. Although I have a lot of the pieces I need right now, it would still be nice to see what others have done. This is definitely going to take a lot of finagling to get working.

Nice! So a couple of days ago I did attempt to fix the player movement problem by trying to add a wider tolerance when moving from a stand still. But I screwed something up and the chef became glued in certain spots. So I commented out that code before releasing the last build... but I'll definitely revisit it at some point.

Yeah, I think that's going to be next thing I'm going to work on... Ignoring the flicker management issue and instead focusing on the game play elements has been the big thing that's allowed me to make so much progress over the last couple of months. Now that I'm far enough so that the game is somewhat playable, it's probably a good time to work on it.

Yeah, I noticed that score bug, and I'm not sure why it's resetting. I'm thinking there's some rogue code somewhere doing it.

I have another build ready to share. Earlier this week, an idea hit me for how to implement pepper without waiting for better flicker management. It's not perfect (it doesn't get drawn right at the top of the screen), but it seems to work nicely. Also, the enemy peppered animation sequences are not quite right yet, but they're in there. And there are a few other things too. To summarize: * Initial pepper implementation - mostly working * Enemy peppered animations - sequence needs tweaking * Partial score tracking - Scoring of falling burgers * Ability to turn music on/off - Right Difficulty Switch * Tweaked player victory animation I think that's everything. Enjoy. chaoticGrill-2018-10-10.bin

Hmmm... Have you guys tried using the diagonals? The code is written to favor turning at intersections while moving.

No worries. It's good to have a critique. And a rebuttal: Background music is there, the volume is currently set at 0... If you grab 2017-03-06 version (mainly just a music/graphics demo) in the first post, you can hear it. I turned the volume off because it's really annoying to hear it all the time while testing. I was planning on tying it into one of the console switches for switching it on and off... but I never got around to doing it. Some time in the future, pepper will be implemented. Not really sure when yet. Screens 5 and 6 are missing... need to rearrange some data to make room for the graphics data for them. All the animations from NostAlgae37 stole their space. Starting positions were mainly set to the top for ease of testing while implementing the burger dropping logic. Burgers are still getting stuck on Level 4? I would need quite a bit of detail on the screen state like what burgers were set in motion, which enemies were riding down, etc. Yup, enemy AI is still wonky because I haven't touched it. The enemies generally get stuck when you pass them on a parallel ladder going the opposite direction and they are in the middle of a ladder in line with a parallel platform. Which makes test runs thru a level easier in a way. Cimmerian pretty much nailed the details of the current flicker algorithm. Better flicker management is planned, I already have quite a bit of code written for it. I just haven't gotten around to finishing it yet. And that partially ties into why you don't see Items or Pepper yet I've tweaked the winning animation to include another frame with his arms down... You'll see it in the next build. This is one area where I didn't consult with NostAlgae37 first before releasing. I probably should give a bit of a TODO list (items are in no particular order): Flicker management Fix enemy logic Pepper implementation Lives and Pepper counter Scoring -- will probably be quite a hefty task, but relatively easy to implement. Will be a pain to test. Title Screen More/better sounds and music Let me know if I missed anything.

Food for the savages... another update: Attempted to fix the issue when too many burger pieces are in motion... Level 4 seems to be working better, wasn't able to fully test yet. Chef can be killed Chef can beat the level and move on to the next one (may be a bit buggy... Level 1 seems to work) Scoreboard temporarily replaced with WIP tag Please let me know of any bugs that you might find. Enjoy. chaoticGrill-2018-10-04.bin

Yes, I've been meaning to write you a nice thank you note... But I might as well do it publicly. Thank you so much for contributing your time and skill to develop the sprites and animations. It's been a nice motivating factor having someone else help out on this project in such a big way.