"Harpy's Curse" - A MetroidVania for the 7800 (Beta version now available!)

[RevEng]

55 minutes ago, playsoft said:

I checked ARTI in the A7800 debugger and it looks like it is doing POKEY discovery which involves POKEY reads. I'd try getting rid of that, just do a simple POKEY initialisation assuming it is present at $450 without any POKEY reads. No guarantees though.

@Muddyfunster if you're using a recent 7800basic to do the compile for ARTI, just change "set pokeysupport on" to "set pokeysupport $450". This will switch to the simple pokey init getting assembled, instead of the autodetect one.

[+Trebor]

1 hour ago, playsoft said:

Yes, unfortunately there is an unrealistic expectation that all programmers need to do is apply a simple "fix" to get POKEY audio on Concerto. None of us completely understand the Concerto firmware issues, so working around them is often a long process of trial and error.

 

However I did want to share what has worked for me, in case it is useful for others. When I have ram@4000, I am able to get POKEY audio from Concerto by not setting pokey@450 in the header and initialising POKEY by simply setting all registers to 0 and then SKCTL to 3 - without doing any POKEY reads.

It is truly appreciated.  Thank you.  Please continue to share.  Much like yourself, my intention was also to inform others in knowing my experience, not exacerbate the situation.

 

1 hour ago, playsoft said:

I checked ARTI in the A7800 debugger and it looks like it is doing POKEY discovery which involves POKEY reads. I'd try getting rid of that, just do a simple POKEY initialisation assuming it is present at $450 without any POKEY reads. No guarantees though.

Excellent, and thank you again!

  

22 minutes ago, RevEng said:

@Muddyfunster if you're using a recent 7800basic to do the compile for ARTI, just change "set pokeysupport on" to "set pokeysupport $450". This will switch to the simple pokey init getting assembled, instead of the autodetect one.

Perfect and awesome!   Fingers crossed, but this indeed accompanied with the aforementioned absence of pokey@450 in the header should cover the necessary ground for Concerto.  Thank you as well!  

 

Here's to hoping none of this will be necessary sooner than later for Concerto.

[+Muddyfunster]

Thanks @RevEng, I'll compile a new build and drop it in the ARTI thread. I do have the Pokey stuff in the reserved area and ARTI uses 7800basic build 0.20. Hoping that doesn't make a difference.

[Revontuli]

Took a "break" from POKEY testing and level design to update and test how saving data might work - Although I'll probably hold off on making this public until I get other stuff working.  Allowing saves through peripherals basically guarantees the game won't work on most emulators, and makes debugging much, much more complicated, and will only work for the small percentage of folks who have a compatible peripheral.  JS7800 might work with it, but I think the save game slots will be shared by everyone with the link.  There's a reason I put a password system in place as a backup    

 

 

That said, I had to do some updating but it seems to work on my SaveKey and Dragonfly (now to test on the AtariVox and Dragonfly, the Concerto and SaveKey, AtariVox and Dragonfly, etc. etc. - you might see why I've held off on this, it makes POKEY testing on peripherals easy by comparison  ) I hope I can at least get it properly working on the published cartridge version.

 

The method to access the 2nd quest is current being tested, this is all feeding back to testing the password system and save games.  I'll probably try to upload a final "beta" build for the new year - It's a full game as it stands, with bosses, intro, musical score, ending - the whole deal.  The proper "2nd Quest" I'm working on is really for those who have already beaten the game and think it's too easy, so I want to spend some time to make sure I do the quest justice.  It's also for those who think I should do more with the little secret I put in!

[Revontuli]

I tried messing with the 7800header - if it's "fixed" on the Concerto w/ POKEY, does it typically "break" for, say, the DragonFly? Removing the @450 tag removes ability for the DF to play the POKEY soundtrack, which makes sense but, again, I've no way of knowing if it fixes it for the Concerto at this time, at least on my end, and I want to keep the number of iffy ROMs floating around to a minimum

 

I can try posting the fix - or anyone who got it working on their Concerto has my blessing to posting a ROM of the game with the fixed header in this thread.  

[playsoft]

5 hours ago, Revontuli said:

I tried messing with the 7800header - if it's "fixed" on the Concerto w/ POKEY, does it typically "break" for, say, the DragonFly? Removing the @450 tag removes ability for the DF to play the POKEY soundtrack, which makes sense but, again, I've no way of knowing if it fixes it for the Concerto at this time, at least on my end, and I want to keep the number of iffy ROMs floating around to a minimum

 

I can try posting the fix - or anyone who got it working on their Concerto has my blessing to posting a ROM of the game with the fixed header in this thread.  

Yes, it will have to be a special Concerto build unfortunately, as DF needs the pokey@450 bit set.

 

For your Concerto build you will need to build with "set pokeysupport $450" as @RevEng suggested, then use 7800header to unset pokey@450 from the header data.

[Revontuli]

8 hours ago, playsoft said:

For your Concerto build you will need to build with "set pokeysupport $450" as @RevEng suggested, then use 7800header to unset pokey@450 from the header data.

Thank you (and thank you for the build) - I figured this was the process, but currently have no way of testing it!  I uploaded the Concerto/Pokey build to the original post.

 

[+Trebor]

11 minutes ago, Revontuli said:

Thank you (and thank you for the build) - I figured this was the process, but currently have no way of testing it!  I uploaded the Concerto/Pokey build to the original post.

Tested and works perfectly under Concerto as does the version I modified the header for earlier, but neglected to post. 

Sorry about that, I was side-tracked and forgot to return to the thread to post accordingly.

 

Having this and the newly updated demo build of Dragon's Havoc is a real treat.  I'm particularly not very disciplined with the firing technique of the latter, so the opportunity to see some of the later levels is awesome.  Thank you!

[Ecernosoft]

On 3/3/2022 at 12:15 PM, Muddyfunster said:

Looking good @Revontuli. Excited to see where you take this one!

I agree. So excited for the final release!

[Ecernosoft]

On 4/24/2022 at 2:22 AM, Revontuli said:

Y'all called it - I took a page from Castlevania's various password systems, although those got surprisingly complicated.  The icons grids from Bloodlines and 3 are a nice way to encode a bunch of booleans.  I didn't want to program an alphabetical input system, and I doubt anyone wanted to use one

 

Finalizing the level format - although in terms of appearance it's still all largely temp, test, and older sprite art - I'm getting to the actual "art" phase soon.  The *types* of blocks are in, though, so I can actually think about what they'll look like.  I'm looking forward to toying with how spikes, water, columns, and statues will look in various parts of the maze...

 

 

 

 

Current compiler output:

7800basic compilation complete.
User-defined 7800.asm found in current directory
   stack allowance: 6 nested subroutines.
   the canary is situated at: $1ea
   6402 bytes of ROM space left in the main area of bank 1. <- (Main game logic)
   12977 bytes of ROM space left in the main area of bank 2. <- (Level data)
   6450 bytes of ROM space left in the main area of bank 3. <- (Normal game drawing)
             4096 bytes of ROM space left in DMA hole 0.
   6287 bytes of ROM space left in the main area of bank 4. <- (Boss drawing)
             4096 bytes of ROM space left in DMA hole 0.
   13861 bytes of ROM space left in the main area of bank 5. <- (More level data)
   16383 bytes of ROM space left in the main area of bank 6. <-(Tentatively reserved for sound)
   2393 bytes of ROM space left in the main area of bank 7. <-(Menus and other Text screens)
             4096 bytes of ROM space left in DMA hole 0.
   7623 bytes of ROM space left in the main area of bank 8. <-(Shared bank, .asm modules, current sfx, player and level background graphics)
   custom pokeysound assembly:  743  bytes
     $18e0 to $1fff used as zone memory, allowing 14 display objects per zone.
     513 bytes left in the 7800basic reserved area.

 

A busy week trying to finalize the rest of the game systems.  Adding a feature is an O(n^2) problem, as you have to reconcile any new feature with every one you've added previously, trying to fix any bugs you've discovered or introduced...

 

Today was coding more enemy behaviors - I think that those will be the last major CPU processes in the main game loop - if it runs OK with all this in, I'll feel much better playing with the data.  I've been having fun with it, though - I'm able to combine different movement patterns with other qualities (does the enemy shoot?  is it affected by gravity?) so that they can be a variety of types of enemy behavior for the player to encounter.  

 

The maze will have a few things to look for - while I do have explicit keys and locks, I also have a few powerups. I'm not making the powerups required, for the most part, but they'll be *very* nice to have.  Collecting one of them will give a screen telling you what it does and how to use it - Of course, part of me was tempted to make this game as cryptic as Legacy of the Wizard or Goonies 2, but I think folks expect a little more fairness (and explanation) nowadays. 

 

I've roughly budgeted how big the game will be in terms of levels - My next step will be adding in a "blank" data to make sure it all fits and loads in ROM.  I mentioned my estimate above - I think between 2 banks I can get 64 "sections" - each section being a horizontal scrolling area 8 screens long - so 512 screens total, each screen being 10x10 tiles.  I could probably make even more, but I want to see how much space the other banks use once I get a better handle on how much more space other systems (particularly sound) will need.  And I should see how big this much level data feels as I start planning out where to place powerups, keys, and bosses.

 

The password system is working, although I'm not encrypting it yet, as it's currently a nice debug system to cheat progress at this point.  I've a plan to use SaveKey/AtariVox as well, which will hopefully be straightforward since I'm not using any of the data to save a high score on this game.  It still requires testing on physical hardware, which I have, but iterating and testing on such hardware takes that much longer, so I've been putting it off...

 

...oddly, the first ROM bank I'm starting to feel the "crunch" on is the one I allocated for menus.  Text and proper menu/UI behavior takes up a ton of space!  I have the basics in, except for the Save/Load screen.  I'm pretty sure I'll be able to fit the menus in on a functional level, my main worry is how much will be left over for fun stuff like the ending, pretty title graphics, etc. 

 

Sounds and saves notwithstanding, I'm actually shifting gears into content.  As mentioned above, I'm starting level design proper (not just formations to test stuff), as well as starting to doodle some sprites and pixel art again.  It's tricky, though - you an *finish* a feature, but you never complete art and design, you can only to get to a point where you can say "eh, good enough."

 

I may ask about this is a more focused post, but while performance *seems* okay on both BupSystem and the Concerto, A7800 sometimes gives a graphical "stutter" - It doesn't *seem* to be related to how busy the game is (i.e. performance as such, it happens at intervals unrelated to, say, how many enemies are on the screen), and it might be something similar to what I ran into with Dragon's Havoc, where a slight mismatch in game and display framerates "catches up" at regular intervals.  As I said, it still seems to run OK on the Concerto, but I'll be testing more on A7800 (and the Dragonfly, once I get the power supply figured out) as I try my hand on including POKEY sound.  
 

ICT3's system uses 8 5 bit characters. Origonally it was supposed to be words but since I didn't know how to use the extra 6 characters I used stage graphics for the characters.

[Revontuli]

Got the news yesterday!  Thanks to everyone for playing, and for those who have helped with my various coding questions during the development process!

 

 

Take a look at the nominated games here and cast your votes for the games of your choice here!

Edited February 4 by Revontuli