jrok
-
Content Count
1,156 -
Joined
-
Last visited
-
Days Won
5
Posts posted by jrok
-
-
*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.
- 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.
-
bB always starts execution at the beginning of the .bas file. If you put vblank there with a return, bB will start out with the return which can never work as there is nothing to return from yet.
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).
-
When you say you don't have any code, do you mean there's no "return" statement? You'll need one.
Yeah, it returns. I just meant that I'm not running any code before the return.
I was able to replicate the issue with a small test program, and putting it in bank 1 worked for me.
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.
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.
-
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?
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?
-
OK, I think I know the answer.
If there is an inter-bank goto or gosub, this is done with throwing the address-1 on the 6507 stack and doing an RTS. If the goto or gosub is to a label at the very beginning of a bank, the 6507 will do a dummy fetch of $x07F, which is DF7WRITE, and will write one byte of garbage to the stack every frame and increment this pointer while the program seems to run normally otherwise.
Stella ignores this because reads to DPC+ write registers are ignored (clearly they should not be!)
So the fix is to not do any inter-bank jumps to labels at the very beginning of a bank, or place a line of dummy code before the label (like a=a) until the problem can be fixed.
Thanks so much, Fred!
-
Could you try placing "stack 256" near the beginning of your code (before the main loop) and see if this changes anything in Stella or Harmony, or makes them consistent? This may at least rule out stack issues.
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.
-
It works!
Flickering is better.
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
-
It works!
Flickering is better.
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
-
It works!
Flickering is better.
So the screen doesn't turn green anymore? Does the screen still drift left after 48 seconds?
-
The problem (I think) has a few causes. The first is that I still think the stack is imbalanced (not sure yet if it's bB or the game - jrok hasn't commented on his stack use) and the stack pointer (DF7) was not properly initialized in DPC_startup.asm (DF6 is set instead of DF7 - it's an easy fix.)
On Harmony, all uninitialized data fetchers are set to zero, which is the beginning of DPC+ RAM. In Stella, they don't appear to be set to anything at all. Stella should be fixed to set all fetchers to zero as Harmony does, which will keep things consistent and may help root out bugs like this and stop crashes.
Hey Fred,
Sorry, I forgot to comment on that. No, I'm not using the stack in any of the posted binaries.
-
Latest build doesn't run even in Stella on my end. Gives an ARM exception fault.
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.
-
Latest build doesn't run even in Stella on my end. Gives an ARM exception fault.
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)
-
Perfect! I only get an elegant black screen. Nothing appears (in fact something appears for a millisecond).
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.
-
Tested.
There is a difference: no vertical bars.
After 48 seconds the background scrolls to the left for a while (like when you move the knight to the right) as version #2, then the screens turns to green as version #2. Again, gameplay is unaffected.
In other words, you have removed the nice vertical bars intermission.
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?
Regarding knights flicker, I have to say that you really don't see anything when players overlap.
I love colorful knights too but I think that flicker ruins that important part of the game.
It definitely flickers a lot at that point.
Personally I don't think its a deal breaker, since it doesn't flicker that way all the time, but I'm fairly flicker tolerant.
Jrok, if you're intent on reducing flicker, what about simplifying the dark knight only?
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
-
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.
-
@batari I've tested with the DPCplus.arm in the DPC+ programming thread and it does the same thing.
@Jrok, all the builds seem to be unstable and bounce the screen like crazy.
Looking in stella your scanline count is fluctuating quite a bit, your not getting to a drawscreen in time.
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.
-
@batari I've tested with the DPCplus.arm in the DPC+ programming thread and it does the same thing.
@Jrok, all the builds seem to be unstable and bounce the screen like crazy.
Looking in stella your scanline count is fluctuating quite a bit, your not getting to a drawscreen in time.
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.
-
I've been trying to track down this bug myself. If you find what is really causing it let me know! Like I mentioned in the EggVenture thread, you shouldn't have to rewrite everything every frame, all this does is hide the corruption that's still occurring. I do believe there is a pointer running amuck unseen until it starts writing erroneous data into the Graphics bank. Those that are rewritten every frame stay alive so to speak, but the rest gets a screen wipe.
Those streaks are the playfield, in my game you can fly into them and it causes the collision to register a hit with the PF.
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.
-
Jarod, if you turn up the volume to the maximum (both YT and your PC) you'll hear the normal in game sounds.Now I test second version.
Thanks Philsan, but I don't think it's necessary. I'm sure that version will show the same bug.
I think the only surviving elements, like the castle, are those that have their graphics set in the main loop, like the rider and the enemies. The graphic strips can be cleared away by clearing a level (guessing you set the playfield at the beginning of a level) but the background colors never come back.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.
-
Confirming the same thing happens on an NTSC system with Harmony.
I think you've hit a bug that ScumSoft ran across. EggVenture loses it's colors on occasion too, and it looks like DPC+ ram is being overwritten in places.
Is there an event that happens 20 or 30 seconds into the game?
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.
-
Three (or four I don't remember exactly) big strips grow from the top to the bottom of the screen, one after the other, from left to right, building a "cage".
After a while the screen becomes green.
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
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Charge!
in batari Basic
Posted
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:
ChargeDPC_4.bin