Sprite display problem.

[Kiwi]

 

Screenshot taken by Yurkie, Thank you for taking the picture.

 

The problem is on the real Colecovision, the sprites on the bottom is initially scrambled. During the pause() statement. The sprite slowly phase in the correct places after a few minutes. The emulator does not simulates this. I assuming it has to be the fifth sprite on that line might be the cause the problem. There's 24 sprites displayed on screen. The problem I believe are sprites 8-15. The 2nd screen shows the beetle phasing in before letting the first screen sets in. The 3rd screen, the lightning bolt is phasing in, until button press to change to night scene.

 

 

 

The attachment contains the latest build of the mock-up scenes and the source code. In this build added stuff to the NMI to flicker sprites and flash the heart power up.

 

Please note, this probably won't turn into a real game, but just teaching myself how the graphic and sprites work.

 

I'll hook up my other computer and record a video of in action with the TVtuner card tomorrow.

 

Any idea is appreciated. Thanks.

[newcoleco]

 

Screenshot taken by Yurkie, Thank you for taking the picture.

 

The problem is on the real Colecovision, the sprites on the bottom is initially scrambled. During the pause() statement. The sprite slowly phase in the correct places after a few minutes. The emulator does not simulates this. I assuming it has to be the fifth sprite on that line might be the cause the problem. There's 24 sprites displayed on screen. The problem I believe are sprites 8-15. The 2nd screen shows the beetle phasing in before letting the first screen sets in. The 3rd screen, the lightning bolt is phasing in, until button press to change to night scene.

 

 

 

The attachment contains the latest build of the mock-up scenes and the source code. In this build added stuff to the NMI to flicker sprites and flash the heart power up.

 

Please note, this probably won't turn into a real game, but just teaching myself how the graphic and sprites work.

 

I'll hook up my other computer and record a video of in action with the TVtuner card tomorrow.

 

Any idea is appreciated. Thanks.

It looks like one of those limits some of you experienced from time to time with sprites while using the particular screen mode 2 text I'm using in my projects without any problem. The only experiementation I've done myself, and it occurs only once, with this kind of situation is that the sprites order may have an effect and apparently putting as the first sprites the ones at the bottom of the screen helps to solve this issue.

 

The best solution to completely avoid this kind of weird situation is to copy both the color and pattern to completely fill up the 3 charset and then make sure to use the graphic mode 2 bitmap settings instead of the variation I've named "screen mode 2 text".

[Tursi]

This is actually a documented problem with the 9918A/9928A VDP (and probably the PAL versions too). The problem is that it's not exceptionally well documented, I've only seen it noted in the TMS9918 Programmer's Guide from TI.

 

The problem is that when you use bitmap mode with the pattern table masking flags, it also (usually but apparently not always) affects all sprites from 8-31. Sprites 0-7 are unaffected. TI's documentation simply tells you not to use sprites 8-31 in that case.

 

The only workaround is what Newcoleco says - use the full bitmap mode without masking tables, and just copy the pattern table to all three tables.

 

I've got a YouTube video up that demonstrates the effect using a bitmap test program I wrote for the TI-99/4A - once I understood it I found it very reliable to predict what would happen - but some people say it doesn't /always/ happen, so there may be more to it!

 

-- bitmap test app. The first half is under emulation, so you can skip that. Jump to about 9:20 to see the sprite issue.

 

I can't attach the VDP document, unfortunately. It's 2.5MB and my upload limit is 2MB, it doesn't compress worth a darn and the only other option I thought of, multiple RAR files, is not permitted by the forum. So, for a limited time, you can grab a copy of it here: http://harmlesslion.com/temp/Video%20Display%20Processors%20-%20Programmer's%20Guide.pdf

 

The problem is mentioned in section 8.4.2.

Edited March 20, 2011 by Tursi

[Kiwi]

I wrote this theory on my blog about my guess on what's happening.

 

The sprites are grouped by the power of 8 are grouped 0-7,8-15,16-23,and 24-31. The screen is segmented into 3, due to they hybrid nature of the screenmode2. I think 0-7 should work in the top third of the screen, 8-15 should work in the middle, and 16-23 should work in the last third. 24-31... I'm not sure. I think these order should load properly in those region and the 5th sprite should drop like it should. One of the mock-up that was made for a birthday friend with 14 sprite didn't have any sprite problem.

 

From the information from Tursi's post, I should rewrite the theory as 0-7 can be anywhere. 8-15 on the top only. 16-23 for the middle, then lastly, 24-31 in the last section.

 

I did make a test program having sprite 0-15 on the top portion of the screen. The sprite displays properly on the CV.

 

 

It's a wrote in progress test since I want those box to fall on to the ground and be in a line, just to see the result. Then reposition the sprites for that mockup. I think without that fifth sprite on that line, the sprite would not correct itself after a minute.

 

Thank you both for the replies.

 

Thank you for the VDP programming manual Tursi.

Edited March 20, 2011 by Kiwi

[youki]

While developping Ghost'n Zombie , i had this sprite duplication problem (as you can see in tursi's video) on real console (worked well in emulator).

 

I read tons of MSX forums to find out the "problem". and i have finally found (according to post i read) it was due to a VDP bug.

 

And i finally manged to workaround this problem by setting the screen2 mode text this way :

 

screen_mode_2_text();

vdp_out(3,0x9f);

vdp_out(4,0x3);

 

I have to dig into hard disk and favorite to find where i have found the explanation.

[youki]

I found back the thread i was talking about that here :

 

http://www.atariage.com/forums/topic/143304-did-you-have-problem-on-real-console/page__view__findpost__p__1752992

[+5-11under]

This is good news. I've got an unfinished game, JetBoat!, which originally used 32 sprites. I ran into difficulties. Reducing the number of sprites to about 24 helped a lot, but it still wasn't perfect.

 

... just so you know, the game is a long ways away, requiring some large-scale updating. So many projects, so little time. It's just good to know that there's a solution available that should help out.

[Tursi]

I haven't done all the experimenting I'd like to with the issue, but I do know this much for certain:

 

-Sprites 0-7 are unaffected, they work anywhere on the screen in any combination

-The mirroring of higher numbered sprites matches the mirroring of the first pattern table. That is, if you set up to repeat the pattern table across all three zones of the screen and drop sprite 8 at the top, it will appear in all three zones. If you set it up for only two, then only those zones carrying a copy of the first pattern table will mirror the sprite.

-Sprites 8-31 only mirror in zones below them - you can see this in my video

-Sprites 8-31 are cut off when they cross a zone boundary

 

What I haven't looked at in detail:

-Are sprites 8-31 all affected equally? (I think Kiwi's theory of grouping may be worth further investigation)

-Do the color table mask bits have a predictable effect? (The quick testing I did in that video suggests that some combinations of color mask bits affect the visibility of some sprites, so that definately needs more investigation).

 

It is a glitch though which is apparently not present on compatible chips, so I'm inclined to think it's better avoided than abused. On the other hand, there are so few ways to abuse this chip it's kind of neat to find one.

[Kiwi]

I haven't done all the experimenting I'd like to with the issue, but I do know this much for certain:

 

-Sprites 0-7 are unaffected, they work anywhere on the screen in any combination

-The mirroring of higher numbered sprites matches the mirroring of the first pattern table. That is, if you set up to repeat the pattern table across all three zones of the screen and drop sprite 8 at the top, it will appear in all three zones. If you set it up for only two, then only those zones carrying a copy of the first pattern table will mirror the sprite.

-Sprites 8-31 only mirror in zones below them - you can see this in my video

-Sprites 8-31 are cut off when they cross a zone boundary

 

What I haven't looked at in detail:

-Are sprites 8-31 all affected equally? (I think Kiwi's theory of grouping may be worth further investigation)

-Do the color table mask bits have a predictable effect? (The quick testing I did in that video suggests that some combinations of color mask bits affect the visibility of some sprites, so that definately needs more investigation).

 

It is a glitch though which is apparently not present on compatible chips, so I'm inclined to think it's better avoided than abused. On the other hand, there are so few ways to abuse this chip it's kind of neat to find one.

 

I think if we understand the glitch, we could use all 32 sprites without having to use bitmap mode. I don't think the Colecovision can decompress the entire pattern RLE to RAM and use that data as pattern since it needs 2048KB and I need to look through the book to see if it can decompress a segment of it. It's kinda complicated solution to tile the screen this way and I'm nuts about using tiles to be honest.

 

testscene.zip

 

Falling boxes to test how it reacts as it falls through 3 region of the screen. 0-7 are the bottom left boxes, 8-15 are the right bottom boxes. The boxes above are 16-31. 8-15 boxes, before reaching the third region, it clips at the boundry and pops when it crosses that line. The +5 sprites limitation was to test to see how the sprite phase in place(Would it correct itself faster), correcting itself after a minute or so. Without that fifth sprite, I don't think the phasing won't work.

 

I'll work on the next test scene later since I need to get some sleep.

 

EDIT: I think youki's solution is a good workaround.

Edited March 23, 2011 by Kiwi

[bfg.gamepassion]

This is good news. I've got an unfinished game, JetBoat!, which originally used 32 sprites. I ran into difficulties. Reducing the number of sprites to about 24 helped a lot, but it still wasn't perfect.

 

... just so you know, the game is a long ways away, requiring some large-scale updating. So many projects, so little time. It's just good to know that there's a solution available that should help out.

 

I've got the same problem. UpdateSprites(0,24) is ok.

UpdateSprites(0,25) and more, all the sprites flashes when there is more than 7 sprites on the screen ...

 

I've try what it sayed in this thread, i've got always the problem ... :( Any other idea ?

 

EDIT : UpdateSprites(0,25) --> all the sprites blink even if there only one sprite at the screen ...

Edited April 11, 2011 by bfg.gamepassion

[bfg.gamepassion]

Ok solution find by Youki.

 

Instead of using updateSprites(0,32) i use :

 

put_vram (0x1b00,sprites,128);

 

and the problem diseapear ...

Edited April 11, 2011 by bfg.gamepassion

[youki]

This is good news. I've got an unfinished game, JetBoat!, which originally used 32 sprites. I ran into difficulties. Reducing the number of sprites to about 24 helped a lot, but it still wasn't perfect.

 

... just so you know, the game is a long ways away, requiring some large-scale updating. So many projects, so little time. It's just good to know that there's a solution available that should help out.

 

I've got the same problem. UpdateSprites(0,24) is ok.

UpdateSprites(0,25) and more, all the sprites flashes when there is more than 7 sprites on the screen ...

 

I've try what it sayed in this thread, i've got always the problem ... :( Any other idea ?

 

EDIT : UpdateSprites(0,25) --> all the sprites blink even if there only one sprite at the screen ...

 

 

try to use :

 

put_vram (0x1b00,sprites,128);

 

Instead of UpdateSprites.

Edited April 11, 2011 by youki

[Kiwi]

I use updatesprites(0,64);. No matter how many sprite on screen, this will not blink the sprites.