splendidnut

Yes. Slowly, but surely.

Strangely enough, the 2600 CPU clock is actually a little bit faster than the C64 (1.19 vs ~1.02Mhz for NTSC regions). On the flip side, the C64 blows the 2600 out of the water graphics-wise.

Just to clarify... I was half-joking about the freeloading part. I understand that there are people out there that have their reasons for not subscribing. Whether those are good reasons or not, is something else entirely and that need not be discussed here. Give what you can, when you can, to things you find valuable to you. I personally subscribed here long ago to support this site because it has been a very valuable resource for me. It one of the very few sites on the internet that serves the original purpose of the internet: to help connect people and spread information. And Al seems like a very stand-up kind of guy... so I keep subscribing... when I remember.

Wait a minute... there are ads on the internet? I'm a subscriber and I run an ad-blocker (a couple). I see no issue other than more people should subscribe. Too many people are freeloaders Thanks for giving us the heads-up on this Al!

I'm guessing that last SEC instruction helps realigns the SetHorizPos subroutine to make sure it's branch instruction doesn't cross a page boundary. That would cost an extra cycle causing the player misalignment that you are seeing. Either add an align instruction (align 256) or move that subroutine to the beginning of the code (before your Start: label). To cut down on cycles for setting up the playfield: - get rid of the use of temp variables (Temp0, Temp2) they aren't really needed as long as you update each individual PFx register befores its use. - try to avoid recalculating X every scanline (6 cycles) -- tricky and probably not worth the cycles saved. Also, it helps if you put your cycle counts in the code comments... examples can be found here: https://www.randomterrain.com/atari-2600-memories-guide-to-cycle-counting.html

That is not quite correct. The parenthesis make no difference due to the use of the # symbol which triggers immediate mode. LDA #<YoYoGfx will load the low address byte of YoYoGfx into the accumulator LDA #>YoYoGfx will load the high address byte of YoYoGfx into the accumulator

Have you looked at the 3F and 3E bankswitching schemes? I believe they use zeropage locations (not ROM space) to do bankswitching.

For the record... It's DPC+ not DCP+. (as in David Patrick Crane plus more functionality). That has been bugging me all day

I downloaded it a week or so ago and keep finding myself loading it up every once in a while to play a couple of quick hands. This is really good! Overall, the game plays well and is very polished. The card animations are great. The intro animation (ship crashing) is a nice touch... though it could use a bit of sound. Looking forward to seeing the completed product.

Thanks! I can probably tweak the animation sequences of the sprites on ladders... might need to tweak some of the other animations also. The Bonus item is currently on a timer... and really should be based on the number of pieces piled on the plates on the bottom (ex. a new bonus item should appears only after dropping 3 or 4 pieces on a plate... potentially with an expiration timer) Thank you for mentioning dip-switch settings. It never crossed my mind that I should look that up to see what was available.. I do have plans for adding difficulty selection (easy, medium, hard) which is dependent on getting a menu system going ... as of right now, it seems that the "easy" mode baseline has been established after seeing the discussion in the ZPH thread starting: With that said, I've also been tossing around other ideas like tweaking the AI of the enemies so that the hot dog, pickle, and the egg have their own little quirks. The ChaoticGrill game engine only supports 4 enemies on the screen at a time... and I don't think I have the resources (RAM/time) to do more than that. But I can plan around with making the enemies come back more aggressive (move faster) each time you squash/drop them. Sorry for the delayed response.... I've been semi-busy working on and playing around with writing a display/animation kernel for the titlescreen.

I'm sorry... that was not my intention to make you feel like that. Granted, my post was brief (due to getting ready for work), but I thought that by mentioning the VDEL registers, it would help you or someone else realize what the issue was. I really was trying to be helpful, but the way you responded to that really put me off. It made me feel like you were telling me that I had no idea what I was talking about (like you were already a "pro")... Similarly to how you responded when I first posted about ChaoticGrill in the Homebrew Discussion forum. Maybe it's just me... Anyways... glad to hear you figured it out. Take care and keep doing cool projects.

Welp... that's the last time I try to help you.

What does your setup/sprite positioning code look like? Are you setting the player delay registers (VDELP0, VDELP1)?

I'll can add a "wait for button" check after the chef's death sequence. Which... I probably could have thrown in with the fix from earlier. Oh well. It'll be in the next build.

That would be a flaw in the sprite flicker management... Can you get me a screenshot showing the positions of all the enemies when this occurs?