Sprite Issues - Screwy Playfield [Fixed]

[Cybearg]

I've been working on a game for a game jam challenge and it has been going very well, except now I'm suddenly having issues with one kind of sprite (the little insect) causing the playfield to go all wonky, as you can see in this video:

 

http://youtu.be/C9O1T7BzMCc

 

I had the same issue in the past with the owl enemies, but they stopped causing problems all of a sudden. It was going well, until it suddenly started acting up with the insects.

 

Note the little bit of extra playfield in the bottom-left of each screen (when the playfield is illuminated). That's been there the entire time I've been working on this game, but I'm pretty sure that it isn't normal for the standard kernel. Just a note: I'm using no_blank_lines. So this leads me to think that either I'm forgetting some important addition to the no_blank_lines optimization to deal with the scanlines being slightly off-sync, or the kernel has a bug.

 

The game runs at a solid 262 scanlines per frame, with not even a brief fluctuation so that isn't the problem. Also notice that as soon as I collide with the insect sprite (which sets it to inactive, gives the player a bonus, and teleports it off-screen), the playfield weirdness is immediately gone.

 

Just a note, the game jam event is due within 19 hours of me making this post (it ends 9:00 CST, 10:00 Eastern), so expedient advice would be much appreciated!

 

EDIT: It isn't no_blank_lines causing the problem. Removing it still leaves me with a messy playfield when there are insects about.

Edited April 28, 2013 by Cybearg

[+Random Terrain]

Can you make a video or post a .bin file without the off and on flashing? It would be easier to tell what is going on and keep us from going blind or having an epileptic seizure.

 

And are you using the standard kernel in the older version of bB or the newer version of bB that can also use the DPC+ stuff? That might make a difference. I went back to the older version since the standard kernel doesn't seem to act quite right sometimes using the new version.

[Osgeld]

post code plz

Edited April 28, 2013 by Osgeld

[Cybearg]

post code plz

Sorry. I didn't just because I wasn't sure if posting the code would violate any rules for the game jam. I assume that getting help on a toolset bug doesn't count as disqualifying "collaboration," does it?

 

Can you make a video or post a .bin file without the off and on flashing? It would be easier to tell what is going on and keep us from going blind or having an epileptic seizure.

 

And are you using the standard kernel in the older version of bB or the newer version of bB that can also use the DPC+ stuff? That might make a difference. I went back to the older version since the standard kernel doesn't seem to act quite right sometimes using the new version.

 

Yeah, sorry. The theme for the jam was "minimalism", so I had the idea of a game where you play as a bat flying through caverns using echolocation, or the closest I could come on the 2600.

 

I'm using the DPC+, newer standard kernel, so far as I'm aware.

 

http://youtu.be/1aPPy5JN5eI

batty.inc

batty.bas

batty.bas.asm

[Cybearg]

Well, I don't know why, but the problem seems to have fixed itself for the time being.

 

I just added sound to the game, and at first I was getting the messy playfield issue for every screen, even for caves with owls or no spawns. Then, kind of out of nowhere, it stopped doing it. This attached version works just fine.

 

But since it just randomly went away, I suspect it will be back. Any ideas on how it can be fixed? Is it a standard kernel issue? If so, where can I find an older version to use?

 

Also, I tried setting the game to 8k so I can use the title screen kernel, but setting romsize from 4k to 8k screws up my sprites:

 

 

I'm using the same Assembly that is normally used--I got it by just putting the playfield/sprite data into bataribasic normally and then copying the Assembly code out so that I could make a modular sprite/playfield system that is hopefully a bit more efficient and I put the sprites and playfield data at the end of the file, like normal. It works fine for 4k, but for some reason not for 8k. It doesn't matter which bank I put the sprite data in, it just doesn't like it. Any idea why?

 

The playfields still work, though.

batty.bas

batty.bas.asm

batty.inc

batty_8k.bas

batty_8k.bas.asm

batty.bas.bin

batty_8k.bas.bin

batty_noflash.bas.bin

[+Random Terrain]

Hopefully SeaGtGruff or RevEng will see this thread in time. Since you are mixing in assembly language, you might be doing something naughty without realizing it. I see you made a new post as I was typing this. I also see that RevEng is reading the thread, so he might have some answers for you.

[RevEng]

Since you are mixing in assembly language, you might be doing something naughty without realizing it.

 

Give the man a prize!

 

Cybearg... any data that the kernel uses must not cross a page boundary, or else it winds up using an extra cycle and screwing up the display. As you add more code your sprite graphics are sometimes crossing a page boundary, and sometimes not, which is why it is happening seemingly randomly.

 

Look at how bB wraps sprite data to ensure alignment by looking at the assembly generated by the player0: command.

 

Regarding the blocky sprites, when you use 8k the kernel gets placed in the last bank. Your sprite data is in the first bank, where the kernel can't reach it.

[Cybearg]

Look at how bB wraps sprite data to ensure alignment by looking at the assembly generated by the player0: command.

It always seemed to me like it just arbitrarily put the sprite data towards the end of the Assembly file. What do I need to do to ensure that it doesn't break page boundaries? Is that what this does?

 

if (<*) > (<(*+7))
repeat ($100-<*)
.byte 0
repend
endif

 

... And if so, do I need it before every sprite, or just a few?

 

Regarding the blocky sprites, when you use 8k the kernel gets placed in the last bank. Your sprite data is in the first bank, where the kernel can't reach it.

Ah, makes sense, though I've tried putting the sprite data in the second bank and they still come up as solid squares. Do I need to set the sprite data (the assembly that calls the sprite stuff) all in the second bank as well? Because it doesn't seem like bB does that. When I check the assembly file, it seems to make a call for teh sprite data in a separate bank than where it's located.

Edited April 28, 2013 by Cybearg

[RevEng]

What do I need to do to ensure that it doesn't break page boundaries? Is that what this does? [...] And if so, do I need it before every sprite, or just a few?

 

Yes. The "7" is owing to your sprite height being 8. Adjust as needed for different sized sprites. You need to do this for every sprite.

 

Ah, makes sense, though I've tried putting the sprite data in the second bank and they still come up as solid squares. Do I need to set the sprite data (the assembly that calls the sprite stuff) all in the second bank as well?

It only needs to be the sprite data. I've attached working code so you can see an example.

 

batty_8k.bas.bin

batty_8k.bas

 

Also, please amend the title of this thread since your issues weren't the result of a kernel bug.

[Cybearg]

Thanks for the information! I ended up not going with 8k for the game itself, but it'll be important to know for other games. Thanks again!

[RevEng]

Not a problem!