PacManPlus

I have reserved $19,$79 in the first post, but $19,$80 is used by Space Invaders...

Things to know: - There is a 'level warp' somewhere on each major level that takes you to the next major level (i.e. 1-X, 2-X, 3-X, and 4-X ... It wouldn't make sense to put one on 5-X ) - There are 1Ups scattered about on random levels - There is a 'Secret Level' that can be... found...

I think it was a Pokey *address* issue.

I just got this 'baby' in today. I have to say, this is a thing of beauty, even more so in person! The build quality is incredible; not too light, not too heavy. The pushbuttons feel great as well. I HIGHLY recommend this to anyone thinking of getting one. This amazing controller will be used when playing any 4-way games... Especially Baby Pac-Man Thank you doubledown!!!

Thank you so much for that waaay-too-nice compliment! Nice to meet you as well! With regards to the 16 high display, thank you - I'll have to check if I can get the tile graphics down to match... Otherwise I'll be taking up more graphics area with the different combinations of two 8-high tile possibilities. I'm already pushing it with 12.

Apologies for not saying it earlier, but thank you for that idea. I was too busy trying to figure out how that would work... 😝

Good question... Actually it's because I wanted to match the source material, but I see your point. Maybe I can get away with that...

BTW, for all the years I've been doing this (almost 20), I happen to pick a game that contains quite a few things I've never done before... But that's good; it takes me out of my 'comfort zone'.

...I meant to put this in the 'Programming' sub-forum (oops)

Hey all: Most of my games use a static DL, where all of the sprites are already defined in each DL and moved on or off screen depending on the vertical zone. The remaining few use a dynamic DL routine where it adds a sprite to the end of whatever DL zone it occupies. I attempted to use this in Bentley Bear, but it was actually *slower* than the static DL build. It is used in ReZolve however (which uses 16-scanline zones with 16-high sprites so at most they take up 2 zones). Along with the scroll routine that I've settled on (i.e. the same idea they used in Xevious), I need a faster DL build routine, one that can handle 24 high sprites on 8-scanline zones. Nothing I have is fast enough to let the 'sprite loader' routine *and* the *screen scroll* routine to happen in vblank. I don't have the memory for double-buffering, so I just need to find some tricks to build the DL as quickly as possible... Any ideas? Thanks, guys! Bob

Good point, and thank you for the reminder. It looks like the PAL version of Xevious moves the screen further down, and introduces more space between the score and the playfield. I will do the same.

Ok, so someone just gave me this idea in a passing thought: Do what Atari/GCC did with Xevious: Just run the display off the bottom of the screen. THIS is the one that actually works for me. I've already applied it, and it seems to work wonderfully! I've added extra 'null' scanlines at the top (as I see they did the same thing), so I have 216 display lines that run *just* beyond the bottom visual area of the screen. No worrying about adjusting the bottom zone, no overrunning Maria (which I couldn't get to work )... I *love* this idea. If it ends up working well (and someone doesn't think of any "gotchas"), this is what I'm going with. Just wanted to put that here as another alternative. Thanks guys!

Yeah - I have to preserve the palettes each line is using as well as they change depending on the terrain, so I would have had to move the object addresses and the Palette/Length byte. It seemed to be just easier to move the pointers (If I'm doing something wrong, let me know). That's actually an interesting idea... I like that Thank you; I'm going to give that a shot.

I have to figure that out, because I have kind of a 'hybrid' DL build; the Character Mode is static, and the sprites are dynamically built. Originally, I was *going* to put those 20 bytes in front of each line (I'm trying to get my 'loader' routine as fast as possible)... and make them all 1 byte in width and then just modify the width of the 4 objects in the last zone, but I think that would still take up too much Maria time. If the 20 bytes are inserted in front of the last zone, I now have to remove them when they aren't in the last zone (because the character mode bytes are static)... I don't know... I'll have to figure something out... Thanks, RevEng!