Jump to content

rensoup

Members
  • Content Count

    331
  • Joined

  • Last visited

  • Days Won

    1

rensoup last won the day on December 1 2019

rensoup had the most liked content!

Community Reputation

462 Excellent

About rensoup

  • Rank
    Moonsweeper

Profile Information

  • Gender
    Male

Recent Profile Visitors

594 profile views
  1. So while Vinscool's taking care of the music ( seems were getting somewhere 😀 ) we need sound effects too... Sound being my favourite subject I haven't got a clue where to start 😎 Just curious if anyone would be able to design them ? A few things: As far as I know sound effects play constantly during the game (footsteps, gates moving up and down) but Kerian (BBC version coder) confirmed that only one can play at a time. The music only plays for key events (losing a fight, winning a fight, drinking potion,...) so it's ok to use all 4 pokey voices for fx if required. They should take as little space as possible and play as fast as possible. I was hoping for digisound at first but mem/cpu aren't available. 100 bytes per sound max ? I'm not sure if a custom solution is required or dmsc's LZS player would be fine ? The LZS player takes about 10-15 scanlines though... which is good for tunes that play from time to time but perhaps a little much for sound effects that play constantly (but again less channels could be used). The compressor may not be able to do much on such short files either so perhaps SAPR would be ok ? Here are the samples from the PC version. There are about 30(but the BBC version only has 20) popfx.zip
  2. yes the wall regularity is a problem, it's a single 16x63 tile, and it should be pretty easy to update the code to make it 32x63 but the main problem is memory right now, that extra tile would cost 256 bytes... which is a lot at this point. Same with wall transitions. I don't have all the assets and still have a lot of code to churn out so I don't know precisely where I'm sitting in terms of mem usage I'm still considering it if there is space near the end of the project.
  3. I knew that bold font wasn't big enough 😁
  4. it even says so in the original apple2 source code: * Read joystick * * Out: joyX-Y * * joyX: -1 = left, 0 = center, +1 = right I had a big brain fart and wrote $80 as -1 😅 Well this is actually code that I use in my virtual version (6502 emu + DirectX) which I should never have left in the Atari version Good catch!
  5. Why not just use a label ? Then you can check the result in the debugger if you still want to use that syntax.
  6. Like Rybag said, that's an insane suggestion... Replacing software masking with hardware masking and a kernel as high as a player to change GPRIOR as an easier solution ? This is so impractical in so many ways I don't know where to start...😵
  7. Thanks, and if you don't do it I will do it myself and make everybody's eyes bleed 😱 Well what are those places ? The flickering mostly occurs when there's a guard because there's more PMG data to update... I've completed L2 in PAL & NTSC and as far as I can tell they play the same (latest Altirra)
  8. ? the prince is split you mean ? There's a large area between the torso and ankles that doesn't have PMGs usually, so the DLIs can be set anywhere in that zone... that's the theory of course because I haven't tried yet
  9. Well as long as there's only 2 characters on screen it should be ok... The function which adds a new DLI, checks if there already one on a given scanline then tries again a few lines above if that's the case. Otherwise I'll just disable the overlay for the shadow and it'll look spooky without any skin and I'll just pretend it's a feature!
  10. Well I happen to be needing a bunch of background tiles 😀 For the NTSC version, the glitches are simply because I have to do so much in the VBi... as for the slowdowns, they're one of PoP's trademark features 😏 (plays the same in PAL, and also on C64, BBC, Apple2 )
  11. On a tech note: PMG overlays turned out to be a gigantic pain in the butt, requiring changes to the graphics converter (to reduce the current memory footprint and improve speed somewhat as well a splitting the extra color from the main sprite and figuring out how to make the best use of 2PM per sprite) So with large sprites, PM01 are used for the head/arms/torso then repositioned with a DLI for the feet. And that's mixed in with static DLIs for the potion. One of the nastier bugs I had was that I sometimes ended up triggering the VBi with a DLi, which was ok as the NMI handler would detect it and return early. Except that I wanted to figure it out and fix it properly so instead of returning early, I added a KIL instruction. This forced the game to crash but only very sporadically. It should be fixed but I left the KIL just in case. If you encounter a crash: please post a screenshot with the debugger enabled. Another potential issue is the NTSC version which has barely enough time to complete the VBi before the first DLI fires... it seems to work (I've had to move the screen down a little though) but I haven't tested it much. Let me know how that goes. Enjoy 😎
  12. Well here it is (if I didn't mess it up)! In this release (20/01/13) (available from the first post of this thread): -one playable level (L2) -PMG overlays with repositioning for the player (not for the enemy yet) -preliminary music by Vinscool -a lot more animation frames redone by TIX -fix: random button presses during fights -bug: running to the right then left, still keeps running to the right Feedback welcome, particularly on the music side. For the next release (may be some time away): -hopefully PMG masking (another potentially huge pain) -perhaps speed up the game somewhat (falling tiles are a big issue it seems, on every 8bit platform with even the BBC dropping to single digit framerate with just 2 falling tiles!) -hunting for memory (a constant battle but getting thougher with every new added feature)
  13. Not sure what you mean (remember that all 4 colors can be above -and- below the PMGs ) ?
  14. Regarding masking... I might have already said that but PoP is a worst case scenario. Hardware masking with PMG on top of each other would just mean halving the player count, one player to cover another one... I need all 4 players to cover the hero + enemy. Software masking is the only way to make the best use of those PMGs. -PMGs over the playfield, means that any background bloc covering the PMG would require realtime shifting to mask the PMG data -PMGs under the playfield means masking the PMG data into the already drawn playfield which is probably less costly. Unfortunately the playfield covering the PMG contain color 0 which means the PMG will show through the cracks in the pillars for instance... that may look ok though.
  15. Thanks everybody! Yes it seems I introduced this bug a long time ago, I'll look into it eventually.
×
×
  • Create New...