Cannonfire-cart release survey

[+SpiceWare]

Wow Nukey - that was quick! I've been hacking distella(working on the a new TRACE feature I added for the jump table) to help me do what you just did. I see you used some additional distella flags as well, I'll have to read up on what those do.

[Nukey Shay]

To be honest, I never bother with traces (unless I'm completely stumped). It's usually very easy to pick out areas of coded instructions vs. data...and jump tables are pretty easy to find (a string of data that uses alotta $Fx values is a good giveaway). Distella uses address locations as labels, so the LSB/MSB of any program routine that is not preceded by a label can just be searched for. Switches p, a, and f insure that the resulting disassembly is directly compatable with Dasm (to check the binary the disassembly creates is a perfect 1:1 copy of the original). P just includes the "processor 6502" line, A supresses that letter for implied instructions that act on the accumulator (as "ASL A" would generate an error), and F makes sure that all zeropage stores that use absolute addressing remain at 3 bytes when it's reassembled to a binary (or else Dasm might interpret STA$0080 as STA$80...losing a cycle). Aside from those, I always include S...so that cycle counts are shown. Helps keep track when hacking/optimizing cycle-dependant areas like the display kernal. And the C switch is just to indicate the CFG file that dictates how the areas should be treated (tho I use GFX instead of DATA, because the latter doesn't include the option to place all data values on seperate lines...GFX does this already).

The D (interpret everything as code) switch is initially useful to create the CFG file...but I never use the I (trace interrupt vector) and R (relocate out-of-range rom addresses) switches unless I'm already sure that the program does either.

Checking all stores to ram whose addresses are used for indirect-addressing picks out any vectors that have been missed...if a program is LDA($ram),y...just search for all stores to $ram to collect LSB's, and stores to $ram+1 to get the MSB's.

Depending on how well these vectors are hidden within the code, it usually only takes a half-hour or so to do the entire process on a 4k rom. This program was pretty easy, because almost all GFX vectors were given in straightforward data tables. The kernal routines are pretty forgiving regarding cycle time, the original program didn't care much when pages were crossed (I did shuffle the tables to keep everything from doing so, tho...in addition to sharing identical data between tables to pick up some spare ROM). There was also an overabundance of JMP instructions...either easily converted to unconditional branches for those in range, or eliminated completely by moving routines around.

There's undoutedly more than the 100 bytes already saved that can be done

Edited April 21, 2007 by Nukey Shay

[espire8]

Over 100 free bytes?... Perhaps there's room for adding stuff now and all I can think of is additional music! Of course I can live with what's in there now but being that a couple of people already suggest it perhaps there's a fitting tune sitting around the community not spoken for and waiting for a home.

I need to wait though because I did ask Darrell if he would assist me to do a scrolling color routine for this hack in the first place and the extra space may come in handy for him.

Obviously as Omegamatrix said, it can be alot better though I always try to finish on my own when hacking anything and I wish I could do more in this department, but i think i reached the end of what i'm capable so I'm very gratful to those who are making it happen.

I think this is something alot of people will enjoy.

[+SpiceWare]

Preliminary tweek - fireball color cycles, but only per frame, not per line.

 

Besides the color cycling (per line like the knight in Medieval Mayhem), I'd like to get rid of the screen glitch when the dragon get's shot and flies offscreen.

cf20070421.bin

Edited April 21, 2007 by SpiceWare

[+SpiceWare]

To be honest, I never bother with traces (unless I'm completely stumped). ...

Ah - I've only used distella once before, for Warlords, and it got everything on the first try.

[espire8]

Looks great! Per frame works very well here.

However I think the fireballs I shoot at the dragon are too dark too see clearly and needs brightening up, but I think you're already aware of that this being a preliminary tweek and all.

Good fireballs though!

[Omegamatrix]

Preliminary tweek - fireball color cycles, but only per frame, not per line.

 

Besides the color cycling (per line like the knight in Medieval Mayhem), I'd like to get rid of the screen glitch when the dragon get's shot and flies offscreen.

I shot the dragon and see the glitch you mean. The screen drags up with the dragon now, and it didn't before. I second that the fireballs look to dark when you shoot them back now. The Fireballs that fall do look a lot better.

Edited April 22, 2007 by Omegamatrix

[Math You]

I love that Dragon I think he needs to be a bit brighter though. Maybe the rising lava could be red aswell (see pic).

 

Is there any chance that the music could use a more subtle sound

[keilbaca]

Looks like a very pretty hack. I know the game, i knew it since I read the description, its now one of my favorite games thanks to the high score club.

[+SpiceWare]

I shot the dragon and see the glitch you mean. The screen drags up with the dragon now, and it didn't before. I second that the fireballs look to dark when you shoot them back now. The Fireballs that fall do look a lot better.

Hmm - looks like that glitch showed up in Nukey's source in #25 as his source in #21 doesn't shift the screen upward. Now that I know that, it should be easier to track down.

 

The same routines that draw the dropping fireball also draws the rising fireball. I'm not sure why the color cycling isn't happening on the way up. I tried adding an extra command to fix it and the screen started to jitter, so I'm evaluating what options I have to fix it.

 

 

I love that Dragon I think he needs to be a bit brighter though. Maybe the rising lava could be red aswell (see pic).

 

Is there any chance that the music could use a more subtle sound

Graphic changes are up to Espire8, though one step brighter on the red may not be a bad idea.

 

I've added a shimmer lava effect last night before I went to bed, but it's not quite right. Next post should have it.

 

We'll see about the music - it's not my forte.

Edited April 22, 2007 by SpiceWare

[+SpiceWare]

I reverted to Nukey's source in post 21, which used up all of the ROM. I've been reimplementing his ROM savings and making sure the dragon flying off screen doesn't screw things up. It does go to 263 lines for a bit, but that's not as bad as before. It might be related to the fix to make the screen 262 lines.

 

I've redone enough that I was able to add back the flickering fireballs, plus added glowing lava.

cf20070422.bin

[Omegamatrix]

The screen still moves a little bit when you hit the dragon. It goes up and down one or two scanlines. I didn't notice it jumping to 263 lines anywhere in Z26. The lava looked pinkish to me, but I am a little bit color blind.

[espire8]

I love that Dragon I think he needs to be a bit brighter though. Maybe the rising lava could be red aswell (see pic).

 

Is there any chance that the music could use a more subtle sound

Graphic changes are up to Espire8, though one step brighter on the red may not be a bad idea.

I took a look at MRB's pic and tried to get something as close. The compare below is not very accurate but I implemented the color change in this bin Cf_dragon_color02.bin Going too bright would give a neon effect so I just went one step brighter. Let me know what you think of this shade.

Btw-- if you look closely after torching the dragon, you'll notice he is actually a she.

 

Click on pic to watch it animate.

 

I reverted to Nukey's source in post 21, which used up all of the ROM. I've been reimplementing his ROM savings and making sure the dragon flying off screen doesn't screw things up. It does go to 263 lines for a bit, but that's not as bad as before. It might be related to the fix to make the screen 262 lines.

I have a hunch that's what it is. i can't think of another reason why the original programmer set it to 263 in the first place as I do still notice the screen rising just a step while the dragon flies off.

 

About the lava, I don't know if it's just me but the upward movement seems to bother my eyes after playing a while. I think it would be better to give it the kind of flasing effect without the upward scroll -sort of like the end screen wall flash in adventure but just in yellowish orange hues instead of the red and pinkish that's there now.

[Nukey Shay]

I reverted to Nukey's source in post 21, which used up all of the ROM. I've been reimplementing his ROM savings and making sure the dragon flying off screen doesn't screw things up. It does go to 263 lines for a bit, but that's not as bad as before. It might be related to the fix to make the screen 262 lines.

I have a hunch that's what it is. i can't think of another reason why the original programmer set it to 263 in the first place as I do still notice the screen rising just a step while the dragon flies off.

 

About the lava, I don't know if it's just me but the upward movement seems to bother my eyes after playing a while. I think it would be better to give it the kind of flasing effect without the upward scroll -sort of like the end screen wall flash in adventure but just in yellowish orange hues instead of the red and pinkish that's there now.

 

I left the original WSYNC instructions in the assembly. There's one that was commented out below label LF0E8 (this is where the line of color appears in the original game). The other WSYNC was just moved above the VBLANK below label LF561 to correct the jaggy line. Both of those changes could be undone just by removing the semicolons (which should go back to 263 scanlines). Since that is an odd number, it might be better to leave the moved WSYNC below label LF561 in place in addition to restoring the original line. That would correct the glitched lower scanline and leave the game @ 264 scanlines (a count many other games use). Since using a WSYNC eats up the remaining cycles on a scanline, it's probable that the removed WSYNC below label LF0E8 is the cause.

[Math You]

Btw-- if you look closely after torching the dragon, you'll notice he is actually a she.

 

Click on pic to watch it animate.

That explains the purple eye shadow. Very sexy The new shade of red looks really good too.

Edited April 23, 2007 by MRB

[+SpiceWare]

Thanks Nukey - I'll probably go with the 264.

 

I'm going to have to take a break from the hack for a few days, possibly longer. My hard drive started to fail last night so I'm picking up a new one at Fry's tonight(wow - 500 GB for $120!) and will be reinstalling everything over the week. Hopefully I'll be able to resume next weekend.

 

Thankfully I had enough of a heads up that I was able to back up all my data last night.

[Nukey Shay]

Damn...I just bought a 250gb for $80

[+SpiceWare]

I've got my computer back up and running. Still set stuff up, but think I'll be able to do a couple hacks tonight.

 

1) For the dragon color change - is it just the red that was brightened 1 level?

 

2) For the lava - I'll change it to flash like the fireballs. Should I use the orange color that the fireballs are using, or maybe the red would work if it's just the 4 darker reds instead of all 8?

Edited April 26, 2007 by SpiceWare

[espire8]

I've got my computer back up and running. Still set stuff up, but think I'll be able to do a couple hacks tonight.

 

1) For the dragon color change - is it just the red that was brightened 1 level?

 

2) For the lava - I'll change it to flash like the fireballs. Should I use the orange color that the fireballs are using, or maybe the red would work if it's just the 4 darker reds instead of all 8?

 

Hey Darrell, glad to hear your computer is tunning up fine.

-The dragon's color originaly was 1 step next to the darkest orange which almost look red, the value being $32 though i'm not sure how that translates to hex code language. The new dragon color is value $44 which is the same red as the current lava color and being the 3rd step from the darkest, I think.

 

-As for the lava color, hmm... I was thinking about orange so it would match with the color surrounding the score, but I like your suggestion for the red with the 4 darkest hues. Sounds like it could work.

Let's try red first since it's already there and compare.

Edited April 26, 2007 by espire8

[+SpiceWare]

$32 is hex

 

I did note the game was coded with $33 - no biggie, the lowest bit gets dropped when setting the color so $33 is the same color as $32. I modified the source and put:

 

DragonRed = $44

 

at the top and changed all the color tables to use DragonRed instead of $33. This lets me change the color of the dragon with 1 edit. We can also make a PAL60 version very easily by doing the colors this way.

 

Lava's been changed as well.

 

Haven't fixed the cannon shot color yet.

cf20070426.bin

Edited April 27, 2007 by SpiceWare

[+SpiceWare]

Forgot to mention - I think I fixed the line count problem too. It should be a stable 262.

[espire8]

I got home late before trying out your last posted bin yesterday. It's shaping up very nicely! Glad you fixed the scanline as well. The lava flash is so much better now though I too did forget to mention about the flash pattern -if the effect could be in and out instead of continual. I'm not sure of how to explain this so I threw together a couple of gif samples below to demonstrate what I mean. Click on them both to compare the animation.

 

If you can change the patten from this... ...to this

 

The colors in the gif's are way off of course (darker than it should be), but at least you can see the patten I'm refering to on the gif in the right hand side.Use an orange color for the lava this time with all 8 shades (values $20 thru $2E) just to compare the result.

 

Also, while you're at it, see if you can change the ground under the cannon where the scores are to a color value of $F0 to make more easy to see a distinction where the lava starts to rise. Once you fix the cannon shot color that should be it.

 

...although I'm not sure what can be done for the music? Oh well. one step at a time I guess .

[espire8]

...it would be neat if flames or sparks could jump out of it periodically.

Here are a couple of boiling lava bubbles I whipped up that may work according to what Nukey suggested earlier. I did two versions both using the in-out flash effect with different colored bubbles.

 

I can only use one or the other though , and I know I'm racing ahead of myself a little here but I'd like do a full screen sample version of the whole lake of fire and need to ask everyone which color bubble would you perfer, the dark or light?

An easy solution to the burning ground idea would be to grab frequently-changing values from ram memory and store them to the playfield gfx as it's drawing the cannon. Playfield is currently being used for the yellow color (but this could just as easily be done by changing the background color instead). With PF0-2 free, some random pixels could be used on every scanline that the yellow color appears on. Setting player priority would keep the cannon visible, so you'd have 2 colors to fill in the ground fire.

Man! too bad I can't code for squat .

[+SpiceWare]

Currently there's 0 bytes of free ROM since I reverted to the source from post 21 to make the screen glitch go away. I'll need to redo some of the ROM savings Nukey did and test after each one to make sure the screen doesn't scroll up when the dragon's hit. The boiling lava looks cool - I'll see what I can do once I free up some space for it.

[espire8]

Thanks Darrell, here's the same fire lake in two different colors with the boiling lava for a better compare than the first. If you need the individual frames let me know. I'm wondering which color to keep, I kind'a like the yellow lava better. Any thoughts from anyone?

 

 

 

Hopfully, if I understood Nukey correctly, this would be possible to implement once there's some space available.

Edited June 12, 2007 by espire8