Jump to content
IGNORED

Charge!


jrok

Recommended Posts

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.

 

Charge_HarmonyTest2.bin

Link to comment
Share on other sites

@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.

Edited by ScumSoft
Link to comment
Share on other sites

@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.

Edited by jrok
Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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

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. :D

 

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.

 

Mike, you have tested the game on real hardware, what do you think?

Perhaps in my CRT TV the result is worse than in other TVs.

Link to comment
Share on other sites

Mike, you have tested the game on real hardware, what do you think?

Perhaps in my CRT TV the result is worse than in other TVs.

 

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?

Link to comment
Share on other sites

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. :D

 

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

 

Charge_HarmonyTest3.bin

Edited by jrok
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

 

Charge_HarmonyTest4.bas.bin

Edited by jrok
Link to comment
Share on other sites

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.

 

Charge_HarmonyTest4.bas.bin

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

The stack is still suspicious as it's the only fetcher that's not reset every frame.

 

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.

 

And, please do it with code that was giving you trouble. The fact that things seem to be working with latest changes is no consolation when the cause of this bug is not yet known.

Edited by batari
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

Charge_testStack.bas.bin

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...