Pictodrive - Magical Flying Hat Turbo Adventure


AllYourBase

Still Fresh
Joined
Mar 21, 2008
Messages
10
This is a bit of a strange one, I wondered if it was just me!

The latest version of Pictodrive normally works like a dream on my F-200 overclocked to 235mhz. However on the excellent Magical Flying Hat Turbo Adventure often 1/3 of the sprites dissapear so u can see the backgrounds through them sometimes.

Any ideas why? Is there a setting I might want to change somewhere??! :P
 
Hit Y (assuming you haven't changed the default controls) to cycle through the 3 rendering engines. Changing to 16-bit accurate mode has fixed all such problems I've encountered.
 
I tried it out to see what was wrong, and indeed, a block of lines is missing on the sprites.

The odd thing about this is that neither the 16-bit nor the 8-bit accurate renderers plus accurate timing & accurate sprites setting would cure this rendering problem, and ironically, the 8-bit fast renderer is the only one that fixes this. :blink:
 
Are you guys sure this didn't happen on real hardware? Sounds like the sprites are hitting per-line limit.
 
Nice the 8-bit fast renderer does indeed fix this sprite problem.

@Exophase - this didnt happen on the original hardware. It is a nasty glitch so I would have noticed it as a wee lad playing this on my first imported megadrive!
 
QUOTE

"Pictodrive" XD



Yeah my sprite limit code might be too aggressive, I'll check that. 8-bit fast renderer doesn't do sprite limits, so it works better in this case.
 
As far as i remember, this happens in this particular game, if you have sprite masking implemented like the documents describe it (sprites with a horizontal position of 0 mask other sprites occupying the same line). This masking mode should in fact just set in, if there is another sprite with a higher priority anywhere between the sprite at hpos 0 and the sprite that should be masked.
 
Lordus said:
As far as i remember, this happens in this particular game, if you have sprite masking implemented like the documents describe it (sprites with a horizontal position of 0 mask other sprites occupying the same line). This masking mode should in fact just set in, if there is another sprite with a higher priority anywhere between the sprite at hpos 0 and the sprite that should be masked.
Thanks Lordus, that fixed it.
 
Last edited by a moderator:
Back
Top