jrok

The "curtain drop" was only happening with Harmony (Stella wasn't catching the stack error; I think stephana is working on emulating this now). I'm thinking now that something might have been wrong in my code in the previous version, actually. Either that or the file got corrupted again while I was copying it across my drives. If it's the former, I must have absentmindedly fixed it in my latest version this morning. I just tested this one on 3.4.1 and it's working (see attached.) New in this version: The color of the sky changes from wave to wave, progress into night, then to dawn again. Added "Wizard" boss enemy to 10th level. ChargeDPC_4.bin

*Update* I've attached the latest build (and added it to the first post as well). Hopefully this version corrects the stack overflow bug for Harmony, as well as the bounce due to timing problems. For the stack overflow issue, I revised DPCstartup.asm to intialize the pointer, and added "temp1=temp1" after each bank declaration. I don't own a Harmony cart, so it would be great if someone could test this version to confirm. I've restructured my code to resolve my extra cycle problem. The program is drawing a stable 262 scanlines now, but if someone could confirm this on Harmony as well, that would be much appreciated. I incorporated a few minor gameplay changes. In addition to speed and aggression, enemies also cause more damage to your armor and castles with each hit as the game progresses. Next Steps: I'm going to try to alter the Soldier enemy-type to spawn in mobs of up to three copies. I guess the main obstacle is decrementing the number when the soldiers' x-position meets the screen's left edge. Decrementing using the sprite's virtual NUSIZ register at the right edge is fairly straightforward, but the left edge presents some challenges unless I use an additional byte of RAM. I'm thinking of incorporating a bit of Defender-style gameplay, where the dragons can occasionally kidnap someone from one of the castles, allowing you to rescue them by zapping the dragon and then catching the falling damsel for bonus point. I always loved the Galaga trick of allowing your ship to be captured, and then rescuing it for double-the-firepower, so I hope to incorporate something like that as well. ChargeDPC_3.bin

Oh, okay. I thought that the order that vblank appeared within the code was abstracted, and that the compiler would automatically determine when it executes (so long as it was declared within the proper bank).

Yeah, it returns. I just meant that I'm not running any code before the return. Perhaps you can upload it? I've attached a small demo program of my own demonstrating what's happening for me. When I compile the attached source file and run it in latest stable releases of Stella, I only get a bunch of white lines. See my attached binary for the way it looks when I compile with the vblank routine commented out. vblanktest.bas vblanktest.bas.bin EDIT: I was just about to hit post, when I decided to try something first. If you download and compile my source as is, I'm guessing you'll see the same fatal bug that I saw. The reason seems to be that I declared vblank before any other instructions, which appears to break the program. If you move it below that first bankswitch instruction, for instance, and re-compile, the program works normally. I'm not sure if this relates at all to the stack bug we were looking at yesterday, but it seems like adding junk code (temp1=temp1, etc) above the vblank declaration doesn't squash the bug, but it changes the way the bug looks in Stella.

It looks like bB isn't automatically sticking the vblank code in the same bank as the kernel anymore. (bank 1 for DPC+). Try moving your vblank statment and code to bank 1, and it should work there. I did try that. Sorry I forgot to mention it. Also tried bank6 just in case, but it caused a crash either way. I haven't even tried running any code within the statement yet, since the declaration itself with no executed code causes a crash.

I'm not sure if this is a bug, but it seems that the vblank command does not work with the DPC+ kernel. Programs compile with the "vblank" keyword, but they crash on boot. Perhaps this is just a limitation due to routines that are running during the kernel's vertical blank?

Very nice work! The sprite-work in general is very good. I especially like the look of your dragon. Nothing much duck-like about that guy I did notice a bit of lag in the update between the dragon's two halves when he is moving horizontal. I assume that's because you are flickering one player on alternate frames. Perhaps to resolve this, you could try alternating the frame in which his x position updates as well?

Thanks so much, Fred!

Okay, here is a older version where those playfield and color statements were defined outside of the loop. I inserted a stack 256 command (it's the first command after the program's jump to bank 2, and is executed before the loop begins in that bank). I ran the program a few times in Stella, and do not notice any differences there (it seems to run consistent with all other posted versions I've run in Stella). I don't have a Harmony cart, but I've attached the binary for further testing. Charge_testStack.bas.bin

So the screen doesn't turn green anymore? Does the screen still drift left after 48 seconds? No. All OK. Thanks for your help, Philsan. Okay, so just to review my work-around for this bug, it seems that the problem was pretty much as Scumsoft suspected. In the builds where the bug was present, I was defining the playfield data, DF#FRACINC, bkcolors and pfcolors outside of the main program loop. When the playfield was defined once outside the loop, a pointer began writing to it at around 25 seconds after boot. When the colors of the background rows were defined outside of the loop, the pointer overwrote those as well. So to work around, I set all of those values within the program loop before every drawscreen. Hope that info helps a little with the bug hunt. J By putting those in the main loop, all you are doing is rewriting DPC+ RAM every frame so it doesn't get overwritten by the bug. You should be able to put all those outside the main loop (and doing so is highly recommended once the bug is fixed as each takes lots of precious time out of your main loop.) Yeah, absolutely. That's why I wasn't calling it a "fix", I guess. I just wanted to try to confirm that it wasn't a problem with the bB code. I'm trying your stack suggestion on one of the older builds (with all of those defined outside the loop) and will post a binary soon. J

So the screen doesn't turn green anymore? Does the screen still drift left after 48 seconds? No. All OK. Thanks for your help, Philsan. Okay, so just to review my work-around for this bug, it seems that the problem was pretty much as Scumsoft suspected. In the builds where the bug was present, I was defining the playfield data, DF#FRACINC, bkcolors and pfcolors outside of the main program loop. When the playfield was defined once outside the loop, a pointer began writing to it at around 25 seconds after boot. When the colors of the background rows were defined outside of the loop, the pointer overwrote those as well. So to work around, I set all of those values within the program loop before every drawscreen. Hope that info helps a little with the bug hunt. J

So the screen doesn't turn green anymore? Does the screen still drift left after 48 seconds?

Hey Fred, Sorry, I forgot to comment on that. No, I'm not using the stack in any of the posted binaries.

You're running on Stella 3.3.01? Doesn't work on my Stella too (v. 3.4.1). Hmmm, not sure what happened with that last binary. Maybe it was corrupted when I wrote to my drive? I just tested this one in 3.4.1 (32-bit) and it worked. Charge_HarmonyTest4.bas.bin

You're running on Stella 3.3.01? EDIT: I just tested the binary on Stella 3.3.01, both with 32-bit (on Windows XP) and 64-bit (on Windows 7), and it worked okay. Maybe the binary I uploaded was corrupted somehow? Trying a second upload (Charge_HarmonyTest4.bas.bin) Charge_HarmonyTest4.bas.bin

Wow... I'm totally confused now. So, just to confirm, the latest version is completely broken on Harmony, but works on Stella? The only change I made was to define the background colors and pfcolors on every frame.

Okay, I'm not sure what's going on with the automatic scroll, but I think I might have figured out the green color bug. Could you try the attached bin and let me know? I've thought about this a bit, and I might just scrap the pretty horses and revert to single players for the knights if the flicker is truly that bad. Even if I reverted to a single sprite for the dark knight, I'd still have three players on a line, and would have to flicker something. I did try altering the color of the road to dark gray in this version to see if it helps make the flicker less noticeable at all. There are other problems. As Scumsoft noted above, the timing is coming in late on drawscreens, which is probably a result of porting over from the old multisprite kernel where I could execute code during VBLANK. Does anyone know if this is (or will be) possible in the DPC+ kernel? I might be able to work around it by splitting the dragon's code across several frames, but it might be a lot easier if I could execute some of the persistent program functions within a vblank routine. Thanks guys, J Charge_HarmonyTest3.bin

I'd say the easiest way via bB would be to store the players' color tables in the Superchip RAM. From there you'd have multiple options of transforming the color scroll dynamically.

Hmmm, that's odd. It didn't seem to bounce in Philsan's video. Ideally, I'd like to run some code in the vertical blank, but I'm not sure whether that's possible in the DPC+ setup. But, yes, I see that the count is jumping all over the place.

Hmmm, that's odd. It didn't seem to bounce in Philsan's video. Ideally, I'd like to run some code during VBLANK, but I'm not sure whether that's possible in batari's DPC+ setup.

Yeah, that was my next thought (to write the playfield data and DF#FRACINC every time I drew the screen). I attached a new version for someone with Harmony to test, if they have a free moment. If it works, I guess it isn't really a fix so much as a workaround, but it might get us closer to nailing down the actual bug. Charge_HarmonyTest2.bin

Thanks Philsan, but I don't think it's necessary. I'm sure that version will show the same bug. Yeah, RevEng. That's immediately what I thought too. I set the "WAVE" playfield bitmap and then reset the playfield at the end of a wave. I just now tried taking all that gunk out and just defining the playfield and DF#FRACINC once in bank 2. Hoping if you or Philsan have some time you can try the bin attached to this post (Charge_test.bin) in Harmony and let me know the result. Thanks again, guys. Charge_test.bin

Yeah, that's what I'm thinking too. I'm going to take a look in debugger, but whatever it is Stella appears to be correcting for it. Did it happen with the second version of the binary I posted as well? Thanks, J

Wow, that's... uh, interesting . I'm guessing there's a write to the playfield data that Stella is somehow correcting for. I'm not getting any sound in the video, but do those bleeding stripes correspond to a certain sound effect? Thanks for your help, Philsan.

Hmmm, that doesn't sound very good. I initially thought it might be a PAL thing, but now it sounds like a memory leak of some sort. Do the strips appear over the sprites? Are they green or red? And when the screen turns green, is that because the strips have filled it? Thanks, J