200 replies to this topic

[Philsan]

jrok, on Sun Jul 24, 2011 11:02 AM, said:

ChargeDPC_4.bin

Sometimes screen bounces up and down.
Like in the emulator, frist horizontal line isn't completely filled.

[jrok]

Gah!  I've been testing this thing so much lately, I'm getting careless about removing little diagnostic snippets.  In version 4, I accidentally left the Dragon's breath stuck on it's fastest speed... probably making the game pretty tough to advance in.   The speed of the fire columns is supposed to start slow and get faster when certain waves are passed.

This version fixes that.  Also, in the interest of making testing easier, players start each game with 9 lives (each new knight beginning with 9 Armor) and each surviving castle heals 10 points instead of five between waves.

That should make progress a bit easier, so hopefully someone will be able to reach the Wizard boss level.

Cheers,
J

 ChargeDPC_5.bin   32K   50 downloads

Edited by jrok, Mon Jul 25, 2011 12:53 PM.

[batari]

"Out of range" is a condition added to the release version of Stella to indicate when the code attempts to access data outside of the Harmony's valid memory address range.

I think the issue happens when not all players are defined before the first drawscreen.  The workaround for now is to define all players even when not all are used.  It looks like other problems will arise from residual data so I'm going to zero-fill everything on the first call to drawscreen.

Please try defining all players and let me know if the bug goes away.

[jrok]

New version of Charge! is up.  I've tried to do more extensive documentation for this build, all of which I've added to the first post, along with a copy of the new binary.

The main change is that I've added scoring and an HUD to track remaining lives and health.  This involved eliminating a running tally of remaining dragons to be slain, but I don't think that's such a big sacrifice. There have also been some graphical and gameplay changes, including:

• Revised horse handling.  Acceleration/deceleration is much faster and more responsive.
  
• Revised Dragon sprites, including a "divebomb" sprite state.  I actually what I thought was a pretty cool animated version of this, but I think it's too costly in terms of memory and cycles.
  
• Revised Dragon/Wizard movement and AI.
  [* Revised repair phases, including bonus lives, health regeneration and Castle Rebuild boosts.
  
• Twenty levels included (after wave 10, waves will loop to Wave One, but the numbers for waves 11-20 will include an underline beneath them)
  
• Underpowered the Foot Soldiers slightly, making it more difficult for them to destroy your Castles.
  
• Revised jousting somewhat to make it a little more forgiving.  If a Knight catches you in a sweet spot, however, prepare to be bounced around and torn up by his sword.

Overall, I think I'm happy with the game's progress.  I don't think I'll be able to develop it with Batari's new 1.1d build, unfortunately, sicne the program makes extensive use of my VBLANK routine, and it doesn't seem that there's much room left for that with the new kernel, but that's okay.

I think I've robbed the cupboard bare of RAM (without going to the stack, which probably wouldn't be useful for my game).  I've used all 26 bytes of RIOT RAM available, as well as the x coordinates and NUSIZ registers of unused virtual players.  I have a few bits left over that I can put to use in the main loop, but other than that I think I'm maxed out.  One thing I am curious about is whether I can modify the core files to zero out the y coordinates and heights of my unused multiplexed sprites, and recover those bytes for other uses.  If so, I think I can squeeze in my "Rescue the Captured Damsel" gameplay, as well as a few other surprises.  

In any case, I think this is mostly shaping up the way I imagined it.  Thanks to everyone in the community for your help and ideas so far.

Cheers,
J

 ChargeDPC_072811.bin   32K   59 downloads

Edited by jrok, Thu Jul 28, 2011 3:13 PM.

[Philsan]

Jarod, sometimes screen bounces up and down on Harmony cart.
This happens only when knight moves and screen scrolls, never when it doesn't move.

[jrok]

Philsan, on Thu Jul 28, 2011 4:44 PM, said:

Jarod, sometimes screen bounces up and down on Harmony cart.
This happens only when knight moves and screen scrolls, never when it doesn't move.

I'm getting an even 262 scanlines on my binary.  Could it be related to your PAL setup?  Can Harmony be manually set to run NTSC programs?

[Philsan]

jrok, on Thu Jul 28, 2011 4:52 PM, said:

Philsan, on Thu Jul 28, 2011 4:44 PM, said:

Jarod, sometimes screen bounces up and down on Harmony cart.
This happens only when knight moves and screen scrolls, never when it doesn't move.

I'm getting an even 262 scanlines on my binary.  Could it be related to your PAL setup?  Can Harmony be manually set to run NTSC programs?

In fact Harmony has 3 different firmwares (NTSC, PAL50, PAL60), I use PAL60, but actually I don't know what are the differences between those firmwares. Perhaps Fred could explain.
My NTSC roms run fine with PAL60 firmware.

I think it's a good idea if someone with NTSC firmware tests your latest binary.

[jrok]

Philsan, on Thu Jul 28, 2011 5:01 PM, said:

jrok, on Thu Jul 28, 2011 4:52 PM, said:

Philsan, on Thu Jul 28, 2011 4:44 PM, said:

Jarod, sometimes screen bounces up and down on Harmony cart.
This happens only when knight moves and screen scrolls, never when it doesn't move.

I'm getting an even 262 scanlines on my binary.  Could it be related to your PAL setup?  Can Harmony be manually set to run NTSC programs?

In fact Harmony has 3 different firmwares (NTSC, PAL50, PAL60), I use PAL60, but actually I don't know what are the differences between those firmwares. Perhaps Fred could explain.
My NTSC roms run fine with PAL60 firmware.

I think it's a good idea if someone with NTSC firmware tests your latest binary.

Hmm, on second thought, I think the problem is on my end.  For some reason, my autoexec file for testing scan wasn't working on my x64 computer, where I did most of my testing.  The autoexec would load into Stella, but it wouldn't break the program while running.  This might be my fault too, so I'll have another look at it over there before I would call it a Stella bug.  

It seems like most of the extra cycles are being executed when the Enemy Knight is on the screen. Is it your experience that this is when the screen bounce usually takes place?  Or is it whenever the horse is moving, no matter what is on screen?

Thanks.

[jrok]

jrok, on Thu Jul 28, 2011 5:28 PM, said:

Philsan, on Thu Jul 28, 2011 5:01 PM, said:

jrok, on Thu Jul 28, 2011 4:52 PM, said:

Philsan, on Thu Jul 28, 2011 4:44 PM, said:

Jarod, sometimes screen bounces up and down on Harmony cart.
This happens only when knight moves and screen scrolls, never when it doesn't move.

I'm getting an even 262 scanlines on my binary.  Could it be related to your PAL setup?  Can Harmony be manually set to run NTSC programs?

In fact Harmony has 3 different firmwares (NTSC, PAL50, PAL60), I use PAL60, but actually I don't know what are the differences between those firmwares. Perhaps Fred could explain.
My NTSC roms run fine with PAL60 firmware.

I think it's a good idea if someone with NTSC firmware tests your latest binary.

Hmm, on second thought, I think the problem is on my end.  For some reason, my autoexec file for testing scan wasn't working on my x64 computer, where I did most of my testing.  The autoexec would load into Stella, but it wouldn't break the program while running.  This might be my fault too, so I'll have another look at it over there before I would call it a Stella bug.  

It seems like most of the extra cycles are being executed when the Enemy Knight is on the screen. Is it your experience that this is when the screen bounce usually takes place?  Or is it whenever the horse is moving, no matter what is on screen?

Thanks.

It also seems like the cycles are fine throughout the first level, then they begin to jump starting with level 2.  Is that also what you are seeing?

[EDIT]
Okay, I just ran the program again in Stella 3.4.1, and this time made it to Level 3 with an even 262 scanlines (I might have gone even father, but accidentally hit "Escape").  I'm really clueless about what's going on, except maybe that some set of conditions is getting tripped at a certain point during play that screws up the timing from that point on.  

Edited by jrok, Thu Jul 28, 2011 5:48 PM.

[RevEng]

I was able to get it to trip semi-regularly in stella... If you go to a screen with a castle animation and reverse a bunch of times and shoot in the air it will usually trigger within 4 or 5 shots.

It doesn't seem to make much difference if the dark knight or dragon is on the screen or not.

[Philsan]

Screen bounces immediately from level one.
It bounces sometimes when you move knight, no matter what is on screen.

[Legend]

Awesome! Hope I can make some time next week to try it out.

Although the new player graphic looks really cool and impressive, I kinda liked the original one like in your avatar. I think it has a little more character and kinda amusing when the horse runs.

The damsel idea sounds really cool.

You can never have enough games with dragons and Wizards!

Very glad this is still going.

Edited by Legend, Fri Jul 29, 2011 6:20 AM.

[RevEng]

jrok, on Thu Jul 28, 2011 3:12 PM, said:

I don't think I'll be able to develop it with Batari's new 1.1d build, unfortunately, sicne the program makes extensive use of my VBLANK routine, and it doesn't seem that there's much room left for that with the new kernel, but that's okay.

Why not jump to code in another bank at the start of vblank, and return when the code is done?

[jrok]

RevEng, on Fri Jul 29, 2011 7:19 AM, said:

jrok, on Thu Jul 28, 2011 3:12 PM, said:

I don't think I'll be able to develop it with Batari's new 1.1d build, unfortunately, sicne the program makes extensive use of my VBLANK routine, and it doesn't seem that there's much room left for that with the new kernel, but that's okay.

Why not jump to code in another bank at the start of vblank, and return when the code is done?

Do you mean something like:

 vblank
 goto VertBlankStuff bank2


 bank 2

VertBlankStuff 
 (code to run during vblank)
 return otherbank

Would the only additional cycles used be for the bankswitch, in that case?

[EDIT]
Actually, taking a second look at the above code, I guess that wouldn't work.  Could you give me example of what you're thinking?

Edited by jrok, Fri Jul 29, 2011 9:46 AM.

[RevEng]

Yup, that should work.

The bankswitch overhead happens during vblank itself, so unless you're nearly full during vblank you don't have to worry about it.

[jrok]

RevEng, on Fri Jul 29, 2011 10:12 AM, said:

Yup, that should work.

The bankswitch overhead happens during vblank itself, so unless you're nearly full during vblank you don't have to worry about it.

Thanks RevEng.  I think I might try that in a future build, since I'm wasting some cycles testing the bounding boxes of various enemies (although, I guess I might have to keep doing this if batari's pixel collisions don't work for resized p1's)

[jrok]

New Build:

• I think I've resolved all of the program's timing issues, so this should work harmoniously with Harmony Carts now.
  
• I changed the bonus structure a bit.  Now, players earn an extra life at the 500 point mark, and Castles always repair a max of 5 hit points at the beginning of a wave (this may change again at some point, along with scoring in general).
  
• I think the difficulty curve is a bit smoother now, and it should be easier for players to at least reach wave ten and duel the wizard.

New ROM attached here and in first post.

 ChargeDPC_073111.bin   32K   58 downloads

[sandmountainslim]

Very good!  Quite an improvement over the last build I played a year or so back.
Keep up the good work!
Wp

[jrok]

sandmountainslim, on Sun Jul 31, 2011 8:03 PM, said:

Very good!  Quite an improvement over the last build I played a year or so back.
Keep up the good work!
Wp

Thanks, slim!  Let me know how far you can get, high score, etc.

[Philsan]

Screen still jumps.
Can someone test the game with Harmony cart NTSC firmware?

[jrok]

Philsan, on Mon Aug 1, 2011 1:07 AM, said:

Screen still jumps.
Can someone test the game with Harmony cart NTSC firmware?

I confess that I'm stumped.  I'm definitely running a steady 262 scanlines in Stella now, and I think I've kept an accurate count of my cycles.  Maybe I can try posting a version for you that omits a certain large element, like the enemy knight, and see if that alters your output?  

[Philsan]

jrok, on Mon Aug 1, 2011 1:20 PM, said:

Philsan, on Mon Aug 1, 2011 1:07 AM, said:

Screen still jumps.
Can someone test the game with Harmony cart NTSC firmware?

I confess that I'm stumped.  I'm definitely running a steady 262 scanlines in Stella now, and I think I've kept an accurate count of my cycles.  Maybe I can try posting a version for you that omits a certain large element, like the enemy knight, and see if that alters your output?  

Before wasting your time, it would be better to wait that someone tests the game with NTSC Harmony firmware and NTSC TV!

[SpiceWare]

jrok, on Mon Aug 1, 2011 1:20 PM, said:

I confess that I'm stumped.  I'm definitely running a steady 262 scanlines in Stella now, and I think I've kept an accurate count of my cycles.

Stella does not emulate the cycle time of the ARM code.  Any ARM code "runs in 0 cycles" as far as the emulated 6507 and TIA are concerned.

On real hardware the ARM code takes more than 0 cycles, and is possibly the cause of your screen jitters.

Edited by SpiceWare, Mon Aug 1, 2011 2:28 PM.

[ScumSoft]

I tested it on my Harmony(NTSC) and the screen drops down a scanline whenever there is to be a new graphic load for the building in the back, and goes back up one scanline when there isn't one being shown. I saw no screen roll that would indicate deviating from 262 scanlines. Are you perhaps taking too much time in Vblank that would offset it by a scanline?

[jrok]

SpiceWare, on Mon Aug 1, 2011 2:26 PM, said:

Stella does not emulate the cycle time of the ARM code.  Any ARM code "runs in 0 cycles" as far as the emulated 6507 and TIA are concerned.

On real hardware the ARM code takes more than 0 cycles, and is possibly the cause of your screen jitters.

Thanks, Spiceware.

Do the cycles the ARM code uses correspond solely to changes in sprite registers?  Does anyone know if fast-fetch mode possible in the bB DPC kernel?

ScumSoft, on Mon Aug 1, 2011 3:44 PM, said:

I tested it on my Harmony(NTSC) and the screen drops down a scanline whenever there is to be a new graphic load for the building in the back, and goes back up one scanline when there isn't one being shown. I saw no screen roll that would indicate deviating from 262 scanlines. Are you perhaps taking too much time in Vblank that would offset it by a scanline?

Thanks, Scumsoft.  Yeah, it's possible.  I was updating all the virtual p1 x positions during Vblank, so I tried moving that into the main loop.  Not sure if it fixed anything, but it's the only thing I could think to do.

 ChargeDPC_080111.bin   32K   59 downloads

Edited by jrok, Mon Aug 1, 2011 6:31 PM.