Jump to content
IGNORED

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


Revontuli

Recommended Posts

5 hours ago, Revontuli said:

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.  

Running the new Developer Mode machines under A7800 (Version 5.0 and newer), can make definitive whether or not it is related to DMA utilization.

 

If DMA is not the issue, it may be worthwhile to try -waitvsync or -triplebuffer options from CL to see if it is video (driver)/refresh rate related.   Alternatively, each one can be permanently set under 7800.ini.

 

 

From:
waitvsync 0

 

To:
waitvsync 1

 
...OR...

From:
triplebuffer 0

 

To:
triplebuffer 1

However, do not enable both.  Just one or the other. 

 

A7800 defaults to window mode, and in window mode waitvsync should be utilized.

 

If waitvsync is turned on, A7800 will utilize more of your system's CPU waiting for the proper time to draw.  The option waitvsync does not work with "-video gdi" mode.

 

In full screen mode, triplebuffer should be utilized; leverage waitvsync instead, only if triplebuffer does not remove the tearing/stutter, or if you swap between full screen and window modes.

 

As an additional check, press F11 to bring up the performance percentage/frame rate counter.  If that dips below 100% there is a setting and/or performance issue for A7800 running on that particular system. 

 

If a performance issue is noticed, try changing the video setting to 'auto' under the a7800.ini file's "OSD VIDEO OPTIONS" section to see if performance improves.

 

 

# OSD VIDEO OPTIONS

#

video auto

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

10 hours ago, Trebor said:

If DMA is not the issue, it may be worthwhile to try -waitvsync or -triplebuffer options from CL to see if it is video (driver)/refresh rate related.   Alternatively, each one can be permanently set under 7800.ini.

That did it, thank you!  I figured it was a sync issue - A7800 is the one I go to when I want test accuracy, so this was a good thing to figure out (and note if others play it on A7800).

 

Developer mode is awesome as well :)

  • Like 3
Link to comment
Share on other sites

I'm working on adding the save/load system at the moment.  I suppose this comes from focusing on the menus early on, and wanting a lot of features, but they're eating up the ROM bank space very quickly!  I was hoping to "reserve" the DMA hole for the ending sequence, but I'll almost certainly have to use some of it to round out the menu system.

 

A few questions regarding using the high score system to save game progress:

 

-Are the High Score Cart and the AtariVox/SaveKey functionally identical when it comes to saving "game data"?  Anything I'd need to keep in mind when hsdevice is 1 vs. 2?  I'm not using the score boards, and my current plan is to have 3 save game slots, with each slot being 3 bytes or so.

 

-What does HSC/SaveKey/AtariVox default to if the spaces haven't been used?  My guess is $FF, or possibly random, but is there a recommended way of knowing if data has already been saved, or if the save system hasn't been used yet and is "blank"?  My tentative plan is to have a checksum or tag for the last nibble of the save data, especially if I know the cart/vox/key defaults to $FF.  

 

[EDIT] - It looks like default values can be set to zero, then loaded (defaulting to 0) - I've been overthinking that ? A7800 supports the High Score Cart, but how does that jive with testing a save system as implemented through 7800Basic?  On my system, the emulated HSC and XM run and don't crash, at least, but I'm at a place where I don't know if my code is wrong, my emulation setup/config is wrong, or it isn't actually supported yet, as it doesn't seem to "save" the data.  I've just started to dig through the A7800 documentation and forum threads, but if anyone has a quick answer, it would be appreciated :)  I'm a little hesitant to try on my physical AtariVox or SaveKey until I have it working as well as I can in software...

 

[EDIT EDIT] I'm able to save high scores on Dragon's Havoc, at least, so I can rule out emulator configuration - I'll see if I can narrow things down.  My first question still stands - any difference between the HSC and the AtariVox/SaveKey?  And anything else I should keep in mind if I'm only using these peripherals to save data, and not scores, within emulation or otherwise?

 

[EDIT EDIT EDIT] OK - I think I have the basics working, or at least what doesn't work is my fault ?  Now I just need to work out the logic traps that come from having nested menus that change on context.  UI is harder than you think it's going to be, even taking that it's going to be hard into account...even on 8-bit platforms, if you want to do a half-decent job with it :)

 

[EDIT X4] And here's a screenshot, temp art, debug values in the corner, incorrect palettes and all!

 

HarpysCurseSaveScreen.thumb.png.2cf1496c06d6bf97876e05b414738fb1.png

 

Oof, I'm going to need to add an "are you sure?" sub-menu to this, aren't I?

Edited by Revontuli
  • Like 4
Link to comment
Share on other sites

A verification (yes/no) before Saving/Loading is in - while I might tweak a few little things, and of course swap out the graphics and get canonical color palettes in, I *think* I have all the menus in for the game.  

 

HarpysCurseSaveVerificationScreen.thumb.png.c1ddf1d3c1c1c1d9b990dbe18a06c755.png

 

You can input the password or load a game from the title, you can save a game or view the current password at certain checkpoints, and you can view the password or save your game at the "game over" screen, as well as just continuing from the last checkpoint.  This turns out to have a lot of edge cases and overlapping states - harder than it sounds and looks to implement, and if you do it right no one should notice.  If you do it wrong, *everyone* notices.  The menus take up around 9k of ROM all told - I could probably optimize them a bit, but honestly that would likely make things harder to read or follow, and I'm happy it works as well as it does.  I still have space on the bank (and elsewhere) for coding the ending sequence (however that turns out) and sprucing things up with some margin graphics.  

 

[EDIT] and after fixing a dumb bug I introduced trying to streamline things, I verified it works on a bona fide AtariVox/Concerto setup!

 

Edited by Revontuli
  • Like 3
Link to comment
Share on other sites

  • 5 months later...

DEVELOPER SPOTLIGHT ON REVONTULI

PLUS WORLD PREMIERE OF HARPY'S CURSE!


Tomorrow we have the honour of having 2600 & 7800 homebrew developer Todd Furmanski / @Revontuli LIVE on ZeroPage Homebrew! He will take us on a journey through his development history and we'll also be checking out the EXCLUSIVE WORLD PREMIERE of his new Atari 7800 game Harpy's Curse! Have your questions ready!

 

 
Games:

(WATCH AT 1080P60 FOR BEST QUALITY)

 

 

  • Like 6
  • Thanks 1
Link to comment
Share on other sites

Todd has put out nothing but high quality excellent games.  Harpy's Curse though looks to be the crème de la crème for me.

 

Super psyche of the continued development and the exclusive stage for the World Premiere.  Making the whole show a developer spotlight is icing on the cake.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

@ZeroPage Homebrew Thanks again for hosting the spotlight - it was great seeing folks play through all the games, and a really nice interview!!

 

Now that the game is premiered, the hope is to have a demo version available for PRGE - plus I should start posting more about the features (a lot of which came together in the last week or two!)

 

Untitled-7.thumb.png.9476aeafa225ad28370e7f56431a8556.png;'

Coils.png.b6576af79d0a8f31d35e159fbf831dcc.png

Spikes.png.c43ea35cc709bb03dc63064563fde7c8.png

  • Like 4
  • Thanks 2
Link to comment
Share on other sites

22 hours ago, Revontuli said:

@ZeroPage Homebrew Thanks again for hosting the spotlight - it was great seeing folks play through all the games, and a really nice interview!!

 

 

Thank you so much Todd, it was an honour to interview you on the show and to premiere your new game! Looking forward to seeing people's reaction to playing it at PRGE!

 

- James

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Achievement Unlocked: Defeat Final Boss with 100% Item Collection

 

HarpysCurse_Statues.thumb.png.47c6a2da435bb7033ed21d0fd6a1d599.png

 

Yes - I got the major milestone of playing through the whole game without cheats or debug codes!  And only found like 5 or 6 bugs doing it :)  Nevertheless, the game didn't crash or run into any game-stopped glitches, and I collected all the keys, powerups, and defeated all the bosses.  

 

I need to play more on hardware at this point, and I plan on refining everything, but this still is a huge checkbox to fill in.  

 

Here is the current ROM usage:  

 

 

7800basic compilation complete.
User-defined 7800.asm found in current directory
   stack allowance: 6 nested subroutines.
   the canary is situated at: $1ea
   5907 bytes of ROM space left in the main area of bank 1.
   3310 bytes of ROM space left in the main area of bank 2.
   6217 bytes of ROM space left in the main area of bank 3.
             4096 bytes of ROM space left in DMA hole 0.
   3556 bytes of ROM space left in the main area of bank 4.
             4096 bytes of ROM space left in DMA hole 0.
   4078 bytes of ROM space left in the main area of bank 5.
   16383 bytes of ROM space left in the main area of bank 6.
   27 bytes of ROM space left in the main area of bank 7.
             1773 bytes of ROM space left in DMA hole 0.

 WARNING: High score support is enabled, but the hiscorefont.png was
  NOT imported with incgraphic. The high score display code
  has been omitted from this build.

   hiscore assembly:  636  bytes
   3544 bytes of ROM space left in the main area of bank 8.
   custom pokeysound assembly:  743  bytes
     $18e0 to $1fff used as zone memory, allowing 14 display objects per zone.
     61 bytes left in the 7800basic reserved area.

 

I still have a comfortable amount of space left (the only bank that's really starting to feel crowded is Bank 7, where I store all the text and menus).  Bank 6 (and the extra 16K of RAM, for that matter) are currently untouched, I have them reserved for experimenting with POKEY sound/music.  While I came into the project with multibank ROM in mind, I did have a smaller scoped version in case I had to fall back on 48K structure - a smaller game, certainly, but with many of the features intact.  

 

The ZPH stream and PRGE got me to headbutt my way through my designer's block - everything could probably use some polish, but the last few weeks turned this project from an engine into a proper game.  Different boss behaviors, password system dovetailing into checkpoints found in the game, 500+ screens of platforms, enemies, and items to place - it was a sprint, and I'm keeping an eye out for possible critical fixes, but for now, I'm going to get some sleep.  Here are some more screenshots:

 

HarpysCurse_Boss.thumb.png.18a0042ec8eaf4738c2b8509d3c01584.png

HarpysCurse_Brick.thumb.png.cbdebf43ab65a9f8de9c27964e4ce9eb.png

 

HarpysCurse_TotallyNotJoust.thumb.png.d220c6e227138cf4c392a50bafd3cb31.png

Coils.png.d23c16078a29ddfbb30f40cccde9234f.png

Spikes.png.9a71988476e321b3a1ba114069ee99f4.png

 

HarpysCurse_Checkpoint.png

  • Like 4
Link to comment
Share on other sites

*Need something to drop jaw to floor*

1 hour ago, Revontuli said:

Different boss behaviors, password system dovetailing into checkpoints found in the game, 500+ screens of platforms, enemies, and items to place...

*Thanks!*

 

To help with perspective, the LoZ Overworld is 128 screens.

Traversing this game would be the equivalent of moving across every screen of the aforementioned overworld ~four times.

  • Like 2
Link to comment
Share on other sites

On 4/24/2022 at 6:42 AM, Trebor said:

Running the new Developer Mode machines under A7800 (Version 5.0 and newer), can make definitive whether or not it is related to DMA utilization.

 

If DMA is not the issue, it may be worthwhile to try -waitvsync or -triplebuffer options from CL to see if it is video (driver)/refresh rate related.   Alternatively, each one can be permanently set under 7800.ini.

 

  Hide contents

From:
waitvsync 0

 

To:
waitvsync 1

 
...OR...

From:
triplebuffer 0

 

To:
triplebuffer 1

However, do not enable both.  Just one or the other. 

 

A7800 defaults to window mode, and in window mode waitvsync should be utilized.

 

If waitvsync is turned on, A7800 will utilize more of your system's CPU waiting for the proper time to draw.  The option waitvsync does not work with "-video gdi" mode.

 

In full screen mode, triplebuffer should be utilized; leverage waitvsync instead, only if triplebuffer does not remove the tearing/stutter, or if you swap between full screen and window modes.

 

As an additional check, press F11 to bring up the performance percentage/frame rate counter.  If that dips below 100% there is a setting and/or performance issue for A7800 running on that particular system. 

 

If a performance issue is noticed, try changing the video setting to 'auto' under the a7800.ini file's "OSD VIDEO OPTIONS" section to see if performance improves.

 

  Hide contents

# OSD VIDEO OPTIONS

#

video auto

Excellent tips, Trebor.  I wasn't aware of any of these details.  The more you know! :)

  • Like 3
Link to comment
Share on other sites

On 3/3/2022 at 5:35 AM, Revontuli said:

 

(This is simply tech demo footage, a proof of concept to see if this will work on a technical level)

 

Something I've been working on as Dragon's Havoc is in the user testing phase.  It's planned to be a sort of combination between Metroid and Joust - Imagine if Samus controlled like the Ostrich Knight while navigating a large maze.  Horizontal scrolling between several sections, I'm working in bringing in enemies and different block types next.  I'm also keeping an eye on performance - I'm expanding off of the scrolling engine I made for Dragon's Havoc, but the collision detection is much more sophisticated now, the level data allows more tiles, and you are now able to move backwards.  

 

While I still have a scenario where I can fit this game in 48K, like I have with my past projects, I did some tests and I finally went mulitbank!  I started structuring the game early enough that I think I can pull it off.  Even in 48K I budgeted for at least 128 screens' worth of game (currently each 256-byte scrolling level section defines an area 8 screens long), but I'm still experimenting with how I'm organizing the level data.

 

No, I won't be moving any of the Dragon's Trilogy to multibank - they work well in 48K, they're either done or in their finishing phases, and I want them to be released in a timely manner!  Part of my reason to go into retro homebrew is to finish stuff! :)

 

It'll likely still be awhile before I even get even a demo version publicly playable, let alone released, but I want to show what I have so far since I'll certainly have questions moving forward.  For instance, I'm seeing what's needed for POKEY compatible sound as well, along with what I need to consider when making this for a cartridge - I'm tentatively going with 128kRAM, $450 for POKEY address - any pitfalls or things I need to think about with that setup?  

Nice! Good progress so far!

Use some SMB style compression or my RLE system for ICT and you can get way more.

Link to comment
Share on other sites

I certainly can get more screens - even without RLE or other types of compression (I've really only used about half my ROM space).  The game actually feels like a pretty nice size, although I want to see how folks play it.  While compression might be needed in the future, I like having the versatility to place blocks how I want and not worry too much if I'm "trolling" whatever compression system might be used (RLE can make things *bigger* if you're not careful!).  

 

If I did nothing *but* level with the ROM space I had left, I could probably fit over 1,000 (and probably at least doubling that with compression and careful level design).  But Dragon's Descent has over 500,000 levels, each with 20-50 screens, so level size isn't everything :)  That said, I'd probably compare the size of this game to Legacy of the Wizard, which had ~256 screens (not counting bosses) but more tiles per screen.

 

Oddly, the bottleneck I'm most concerned about is the bank switching when rendering frames - I do logic on one bank and rendering on another, and if I take too much time things could glitch, so every new line of logic is something I need to weigh, even if the ROM banks themselves have space for it.  It's something I'll be looking at more closely as I start testing this first full-featured build.  I have a few other things I might add (I certainly have space for more enemy types, for instance), but the game should be played a bit by other folks first.

 

HarpysCurse_Heart.thumb.png.09678d21c4716c2f200068c582f07434.png

 

 

  • Like 4
Link to comment
Share on other sites

1 minute ago, Revontuli said:

I certainly can get more screens - even without RLE or other types of compression (I've really only used about half my ROM space).  The game actually feels like a pretty nice size, although I want to see how folks play it.  While compression might be needed in the future, I like having the versatility to place blocks how I want and not worry too much if I'm "trolling" whatever compression system might be used (RLE can make things *bigger* if you're not careful!).  

 

If I did nothing *but* level with the ROM space I had left, I could probably fit over 1,000 (and probably at least doubling that with compression and careful level design).  But Dragon's Descent has over 500,000 levels, each with 20-50 screens, so level size isn't everything :)  That said, I'd probably compare the size of this game to Legacy of the Wizard, which had ~256 screens (not counting bosses) but more tiles per screen.

 

Oddly, the bottleneck I'm most concerned about is the bank switching when rendering frames - I do logic on one bank and rendering on another, and if I take too much time things could glitch, so every new line of logic is something I need to weigh, even if the ROM banks themselves have space for it.  It's something I'll be looking at more closely as I start testing this first full-featured build.  I have a few other things I might add (I certainly have space for more enemy types, for instance), but the game should be played a bit by other folks first.

 

HarpysCurse_Heart.thumb.png.09678d21c4716c2f200068c582f07434.png

 

 

Dude, I've waited for a game like this for such a while PLEASE KEEP GOING!!!!

Edit: oh, you are using bank switching? And it looks like you are using bank switching....... so that means: 4 mb super = 4 MILLION TILES. (Or 4 mil/120 for 16*16 tile screens)

Edited by Ecernosoft
Link to comment
Share on other sites

Oddly enough, I've managed to get this far (three full games and one largely feature complete) using 99% 7800Basic, with a only a tiny bit of ASM here and there.  It's certainly on the "shoulders of giants," looking at and using a lot of what folks have posted as a foundation, combined with a lot of tricks I've learned over the years.  The thing is, if I decided to go full ASM, I'd probably still be trying to draw a square without having the screen roll :) 

 

I've posted a thread on the basics of how I did the scrolling in Dragon's Havoc and Harpy's Curse - it involves having a screen (plus an extra column for the borders) worth of tile data in RAM, dividing it into two parts, and drawing them reversed.  You only need to update one column of tiles at a time, and even that only when you scroll to a new column.  The process fits in stock RAM, and is fast enough to do in 7800Basic with the double buffer, and still gives you time for more additional sprites, comparable to a stock NES.  Dragon's Havoc could have more on-screen "sprites" than Gradius for the NES, without flickering.

 

I'm probably going to have to dive a little deeper into assembly as I mess with the POKEY chip, but oddly I haven't found 7800Basic in any way limiting - quite the opposite.  I was able to get 512 screens populated with tiles, palettes, and enemies in about 2 weeks since I had a solid pipeline that went from a bitmap I painted in photoshop go through a processing script directly to byte data.  If I was deep in assembly coding, I'd have spent those two weeks trying to find which register was causing some display list list to glitch.  I've nothing but respect for those who code in assembly, but I personally lack the discipline - I'm more of a designer who realized he'd have to learn to code in order to implement his ideas. 

 

I've also been involved with many projects over the years that got delayed (or even scuttled) by folks who insisted on more complicated tech than the project required.  You can make a fun game without cutting edge tech - heck, you can make a fun game with 52 pieces of paper (it's called a deck of cards!)  Batari Basic and 7800Basic got me started and running on the 2600 and 7800 very quickly, and debug almost as quickly, and that's honestly made a ton of difference in getting stuff working, improved, polished and finished.  

 

If I were going to do a video series, I'd probably talk more about the design than the specific code - I'd probably communicate in pseudocode if it came to that, like I did in the scrolling thread.  Even the bank switching is less about coding prowess and more about strategizing what you load when, and where you place things.  

 

While I have an idea or two for my Next Big Game (I've teased the idea of an RPG a few times on streams), I'm also tempted to release a few smaller-scope games.  Maybe something with the driving controller, or at least the paddles.  I picked up a Quadtari...I've a few ideas on what I could do with that.  Also, making a screen-by-screen platformer along the lines of a Donkey Kong-alike or Jet Set Willy could be interesting.  I've yet to make a "proper" 4K 2600 game, and while I like making larger scope games, I also think the 7800 is near-perfect for quirky "golden-age arcade"/2nd console generation (i.e. early 80's single screen) style games.  Dragon's Descent was meant to be one of those, something that would not look out of place in a 1983 arcade (and in turn ported to the 7800).

 

But I still need to finish this game - my favorite game I've ever made is the next one I want to make, and yet I've somehow been able to complete a loose trilogy of games without losing interest or patience.  Even with the software done, games take time - in practice it takes several months from a "final build" ROM to getting the boxes, manuals, etc. finished, printed (to say nothing of user testing) to a state where you can order a physical cartridge from Al.  

 

Harpy's Curse itself is planned to have its public debut, at least in demo/alpha form, at PRGE this year in (looks at watch) about a week and a half.  I should probably post a specific thread devoted to the game in the main forum, since I've move pretty far beyond "proof of concept" by now :)

 

 

TL;DR - long tangent-filled developer semi-rant - Hey, it's my development thread! 😜  And a demo of Harpy's Curse should be playable (but not for sale yet) at PRGE!

Edited by Revontuli
  • Like 7
Link to comment
Share on other sites

10 hours ago, Revontuli said:

Oddly enough, I've managed to get this far (three full games and one largely feature complete) using 99% 7800Basic, with a only a tiny bit of ASM here and there.  It's certainly on the "shoulders of giants," looking at and using a lot of what folks have posted as a foundation, combined with a lot of tricks I've learned over the years.  The thing is, if I decided to go full ASM, I'd probably still be trying to draw a square without having the screen roll :) 

 

I've posted a thread on the basics of how I did the scrolling in Dragon's Havoc and Harpy's Curse - it involves having a screen (plus an extra column for the borders) worth of tile data in RAM, dividing it into two parts, and drawing them reversed.  You only need to update one column of tiles at a time, and even that only when you scroll to a new column.  The process fits in stock RAM, and is fast enough to do in 7800Basic with the double buffer, and still gives you time for more additional sprites, comparable to a stock NES.  Dragon's Havoc could have more on-screen "sprites" than Gradius for the NES, without flickering.

 

I'm probably going to have to dive a little deeper into assembly as I mess with the POKEY chip, but oddly I haven't found 7800Basic in any way limiting - quite the opposite.  I was able to get 512 screens populated with tiles, palettes, and enemies in about 2 weeks since I had a solid pipeline that went from a bitmap I painted in photoshop go through a processing script directly to byte data.  If I was deep in assembly coding, I'd have spent those two weeks trying to find which register was causing some display list list to glitch.  I've nothing but respect for those who code in assembly, but I personally lack the discipline - I'm more of a designer who realized he'd have to learn to code in order to implement his ideas. 

 

I've also been involved with many projects over the years that got delayed (or even scuttled) by folks who insisted on more complicated tech than the project required.  You can make a fun game without cutting edge tech - heck, you can make a fun game with 52 pieces of paper (it's called a deck of cards!)  Batari Basic and 7800Basic got me started and running on the 2600 and 7800 very quickly, and debug almost as quickly, and that's honestly made a ton of difference in getting stuff working, improved, polished and finished.  

 

If I were going to do a video series, I'd probably talk more about the design than the specific code - I'd probably communicate in pseudocode if it came to that, like I did in the scrolling thread.  Even the bank switching is less about coding prowess and more about strategizing what you load when, and where you place things.  

 

While I have an idea or two for my Next Big Game (I've teased the idea of an RPG a few times on streams), I'm also tempted to release a few smaller-scope games.  Maybe something with the driving controller, or at least the paddles.  I picked up a Quadtari...I've a few ideas on what I could do with that.  Also, making a screen-by-screen platformer along the lines of a Donkey Kong-alike or Jet Set Willy could be interesting.  I've yet to make a "proper" 4K 2600 game, and while I like making larger scope games, I also think the 7800 is near-perfect for quirky "golden-age arcade"/2nd console generation (i.e. early 80's single screen) style games.  Dragon's Descent was meant to be one of those, something that would not look out of place in a 1983 arcade (and in turn ported to the 7800).

 

But I still need to finish this game - my favorite game I've ever made is the next one I want to make, and yet I've somehow been able to complete a loose trilogy of games without losing interest or patience.  Even with the software done, games take time - in practice it takes several months from a "final build" ROM to getting the boxes, manuals, etc. finished, printed (to say nothing of user testing) to a state where you can order a physical cartridge from Al.  

 

Harpy's Curse itself is planned to have its public debut, at least in demo/alpha form, at PRGE this year in (looks at watch) about a week and a half.  I should probably post a specific thread devoted to the game in the main forum, since I've move pretty far beyond "proof of concept" by now :)

 

 

TL;DR - long tangent-filled developer semi-rant - Hey, it's my development thread! 😜  And a demo of Harpy's Curse should be playable (but not for sale yet) at PRGE!

I might get into c or 7800basic soon. Probably C for @Traxx’s sanity of me. This is a perfect reason!

Edited by Ecernosoft
Link to comment
Share on other sites

I'm messing around with a script that outputs all of Harpy's Curse levels as one big image file: 

mapsegment.thumb.png.c9c3520e9affa1c03201f0c0d9cbdf0f.png

 

I still need to get the colors and section tile sets in place, but the basics are in - it's actually good to see how it all fits together like this.  Once I get proper colors and enemies in, it'll help me visualize things more concretely than my pixel->tile system.


Access to a full map would totally spoil the game, of course - although it might be interesting to include one as a physical "feely" for those who buy the cartridge.  I'd have to talk to Al about it, but I imagine it would be along the same lines as a game coming with a poster.

  • Like 2
Link to comment
Share on other sites

I've also been experimenting/learning POKEY audio within 7800Basic.  I did a quick little conversion of my arrangement of Tamlin for the TIA into a straight square-wave rendition in POKEY:

 

Tamlin with the TIA:

 

 

Tamlin with the POKEY:

 

 

I'll assert the TIA rendition still has a bit more character, but that's till not totally fair to the Pokey chip - I'm still messing with the timing and not really using new any frills or features beyond increased resolution/better tuning.


I'm treating channels more as spaces where I'd stick any treble notes that I can, instead of as "tracks" per se, similar to how the 7800Basic TIA Tracker works.  That approach made the TIA music somewhat tolerable to listen to, as while I usually had one channel for sfx and another for music, the priority system effectively gave me an extra channel.  The music is almost always playing, while sfx only happen in individual events, and can "drown out" or cut off a wayward note without too much issue.

 

I will admit I might need help - I'm about as good a musician as the TIA is an audio chip :)  I'm having fun seeing how far I can get arranging various works of music for the POKEY, but I also know there are folks here who are far, far better acquainted with the chip.

 

The samples above I made using the built in psound function and my own cobbled together system - I used an echo (or "shower quality") type effect when making notes with the TIA, and wanted to see how it carried over to the POKEY.  For the record, though, I also got the 7800 POKEY engine properly intergrated into my 7800Basic build of Harpy's Curse, which would probably be the route to go if I get a composer to help: 

 

 

I also have an entire 16K of RAM (and 16K bank of ROM) that I've kept ununsed with the anticipation of storing/managing music, so we'll see how this develops.  Any advice would be welcome for a poor scrub like me who's still pretty new at chiptunes :)

 

 

 

  • Like 3
Link to comment
Share on other sites

1 hour ago, Revontuli said:

I've also been experimenting/learning POKEY audio within 7800Basic.  I did a quick little conversion of my arrangement of Tamlin for the TIA into a straight square-wave rendition in POKEY:

 

Tamlin with the TIA:

 

 

Tamlin with the POKEY:

 

 

I'll assert the TIA rendition still has a bit more character, but that's till not totally fair to the Pokey chip - I'm still messing with the timing and not really using new any frills or features beyond increased resolution/better tuning.


I'm treating channels more as spaces where I'd stick any treble notes that I can, instead of as "tracks" per se, similar to how the 7800Basic TIA Tracker works.  That approach made the TIA music somewhat tolerable to listen to, as while I usually had one channel for sfx and another for music, the priority system effectively gave me an extra channel.  The music is almost always playing, while sfx only happen in individual events, and can "drown out" or cut off a wayward note without too much issue.

 

I will admit I might need help - I'm about as good a musician as the TIA is an audio chip :)  I'm having fun seeing how far I can get arranging various works of music for the POKEY, but I also know there are folks here who are far, far better acquainted with the chip.

 

The samples above I made using the built in psound function and my own cobbled together system - I used an echo (or "shower quality") type effect when making notes with the TIA, and wanted to see how it carried over to the POKEY.  For the record, though, I also got the 7800 POKEY engine properly intergrated into my 7800Basic build of Harpy's Curse, which would probably be the route to go if I get a composer to help: 

 

 

I also have an entire 16K of RAM (and 16K bank of ROM) that I've kept ununsed with the anticipation of storing/managing music, so we'll see how this develops.  Any advice would be welcome for a poor scrub like me who's still pretty new at chiptunes :)

 

 

 

Oh. Nice!

 

Also,I'm sorry for asking again, but ROM image please??? I'm so excited to play this, and it looks freaking awesome.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...