search

MathewWi / glidehqplusglitch64

Automatically exported from code.google.com/p/glidehqplusglitch64
0 stars 0 forks source link

Monster Truck Madness 64 - overlapping text tile? #138

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
The text on the game menu seems to be wrapped or overlapped by another 
one(image1-3).
On LLE, it is worst because you can't even see the text.

Original issue reported on code.google.com by pokefan0...@gmail.com on 27 Aug 2010 at 1:29

Attachments:

GoogleCodeExporter commented 9 years ago 
You can't see the text with Ziggy's plugin.
With my plugin, the bug looks the same as in Glide64.
My current theory is that the computation of TMEM addresses for 4-bit tiles 
fails. I know that the RDP:
1. uses nybbles to calculate all TMEM addresses;
2. uses a sophisticated method to round TMEM addresses off.

Original comment by spovali...@gmail.com on 27 Aug 2010 at 3:53

GoogleCodeExporter commented 9 years ago 
I have been trying to download your plugin and its source that you posted on 
emutalk but not successful.  I think I have problem downloading from easy share.
If it is not too much trouble, can you post a link on mediafire for me. Thks.

Original comment by pokefan0...@gmail.com on 27 Aug 2010 at 3:56

GoogleCodeExporter commented 9 years ago 
I posted the RSP plugin in 2008, but I haven't released my RDP (graphics) 
plugin, which is responsible for this effect.
Anyway, here's a screenshot from my plugin.

Original comment by spovali...@gmail.com on 27 Aug 2010 at 4:05

Attachments:

GoogleCodeExporter commented 9 years ago 
No problem.  I will test it when you release it.

Original comment by pokefan0...@gmail.com on 27 Aug 2010 at 4:07

GoogleCodeExporter commented 9 years ago

Original comment by gon...@ngs.ru on 8 Sep 2010 at 3:49

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
I solved the problem, in a very logical way. The thing is, if texel1 is used in 
the 2nd cycle of the combiner, it is in fact texel0 (what Ziggy called 'texel 
swapping'), BUT for the next pixel (s + ds, t + dt), not for the current pixel.
This is more logical from the RDP pipelining point of view, than Ziggy's idea 
of texel swapping.

Original comment by spovali...@gmail.com on 19 Oct 2010 at 11:02

Attachments:

GoogleCodeExporter commented 9 years ago 
Cool! Thanks for the info.

Original comment by gon...@ngs.ru on 20 Oct 2010 at 3:13

GoogleCodeExporter commented 9 years ago 
This problem is not corrigible under Glide3x API, is it?

Original comment by spovali...@gmail.com on 4 May 2011 at 8:59

GoogleCodeExporter commented 9 years ago 
I'm not sure. Did not try to fix it yet.

Original comment by gon...@ngs.ru on 7 May 2011 at 10:54