- ddtest.jpg (118.29 KiB) Viewed 6976 times
The digging code was the hurdle and ended up being very difficult because of some of the nuances of the original which I wanted to replicate perfectly, and was about 75% of the time doing frame by frame+memory watching in an emulator and 75% more time trying and scrapping much code. Ended up with a whole bunch of tables to determine what tiles get dug at what distance, what tiles they turn into, per direction....pretty happy it works with just a couple bugs I know how to fix via table editing..quite epic how much time I dumped into this part of it but hell, it works now! I tried to dig out "uzebox" in the screenshot, with an arguable level of success there
- dddigintro.jpg (42.86 KiB) Viewed 6972 times
I am reworking this to use SD instead of EEPROM to allow more and larger entries. It really is necessary for this game to have that much entries, and I don't care to use 2-3 EEPROM slots for this even though it is easier. I have rather elaborate, for an Uzebox game, graphics for both title/high score screens. Currently I went back to mode 3 for now to finish game logic, so I do not have the ability to display the title graphics as they make the game >64k. A very large decision needs to be made and I am procrastinating. Mode 13 or Mode 74. Either of these makes flash a non-issue, even with the large decorative graphics. Mode 13 would require a redesign of the title graphics(I have too much time into making them, to ditch them lightly), or possibly omitting them for the 128 tile limits. Ram tile tricks are required at a minimum. Mode 74 is more narrow than Mode 13, so I cannot do the side score panel in that case. Then I must do the score like the arcade version above the playfield....but this then comes tight up against the already short screen.....the screen needs to be short to blit 64 ram tiles...so many things pushing up against each other. The game itself simply cannot be done well with mode 3, because there is up to 8 enemies and there is bad flicker with even 6 due to ram tile limits. That's graphics stuff but I will figure it out, nothing that can't be done just decisions to make.
I have a possible work around for the short screen. It seems it might work well to fall back to 56 ram tiles(which buys me ram to do 2 player) without much flicker, and that also saves cycles in the worst case scenarios. I fear when all is said and done, I will have to drop to a screen height of 24 tiles to blit that much at slower 4bpp;that sucks. I think(and this makes mode 74's narrowness less of an issue) that I will do scoreboard on top, and make the field wider than the NES version that this port currently looks like. This will then be more like the arcade and have much more room to play in;so it is actually a gameplay issue as well..NES version is not ideal. With 24 or 25 tiles high it is even shorter than the NES version, so setting up the high point value-multi enemy squishing-rock falls that are the pinnacle of high skill play becomes almost impossible. I am probably going to scroll the whole field vertically to follow the player, so that the logical size of the playfield matches the arcade version even though you cannot see it all at the same time. This is the method GameBoy and PS1 ports I have seen dealt with it(arcade was vertically oriented). This saves the game from being a crappy port basically.
Sound, it is all there already. It is a clone of the NES sound and was done in my normal NSF->Midi->Uzebox method. This was made rather easy with Nebososo's Patch tool. It is essentially indiscernible from the original on all accounts. None of it uses noise or PCM. The inline mixer is used, and UART is turned on. There is an untested network state machine that retrieves the latest high scores in the background while waiting for vsync flag. This works with a tiny Tx/Rx buffer, and it only does the heavy stuff during the high score screen. I may have finally found a generic way to do this, and the uzebox.net server was built with this tiny buffer, zmodem-esque method in mind.
That's it for now. The player walks, digs, and responds to demo input almost perfectly. The harpoon shooting/pumping half way works, but the enemies do not function correctly with this yet. Once I get the enemies actually moving correctly I will release a playable demo. There is a lot of enemy logic already done, and as with all of this stuff, it was painstakingly derived by frame by frame analysis of the NES version with some hints from the Atari 7800 version's assembly code. In the end I will be happy if it feels authentic to the original, but enemy AI will likely not be exactly the same behavior.
Rant over for now, thanks for the interest if you read even half of that, the first playable demo might be the finished version if development keeps going this well.
- ddtitle.jpg (16.8 KiB) Viewed 6975 times
That was a great game and I remember playing it in the arcades. Mode74 sound good to be, would give it it's own feel than the NES I think. You were thinking of mode13 using the 7 colors mode or 15 colors mode? For sure the 15 colors mode kills he performance. For the 7 colors mode, I've identified lots of optimizations in the blitter, so it could work out. But eh, mode74 is there and done! 
