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!

If I'm understanding this correctly, it works best/only if you are using sprites as tiles. If you are actually using character mode (and have it anchored at the beginning of the DL as to be under everything else), it becomes problematic and doesn't seem to work as expected... I'm running into this now with something I'm working on. It looks like I *have* to use the 'adjust the bottom zone' method as I am using 32 DLs that I am 'scrolling' through, and I need to use character mode to scroll over a landscape. The DLL itself is 26 zones high for the visible screen, and I'm using 32 to wrap around so I can 'AND #$1F' the top zone when I add 1 and work my way down.

Thank you Trebor, I was just coming here to link to your video and explain.

That is a thing of beauty

If it were that price here in the States I'd pick up another one just for backup... My current one is in storage at the moment...

You really do great work!

Looks great!

Oh not at all! (Thank you) I just wanted to explain why it was done that way. 😊

Hey Guys: The reason for this is because I was well into the development of the game (actually basically finished) when I was asked to take into account multiple button layouts. Thinking people would be used to the 'Super Mario Bros' layout, that was the default I went with. What I found was people not understanding how the controls worked, and getting quite a few requests to change it. First it was the button arrangement (A to jump, B to run/shoot -> B to Jump, A to run/shoot)... and then a few requests to make the CX-40 work with the game (Up for Jump, button to fire/run). So I was basically trying to please everyone by adding all of these options via the difficulty switches, as I really didn't want to change more than I had to. The difficulty switch positions are described in the manual. Thanks! Bob

Those look incredible... Great job!

Nice! I used Dynamic DL creation in ReZolve (I promise to finish that at some point)... But I will look this over. Always open to new suggestions... to learning a more efficient way of doing things. Thank you!