search

AtomicAcidbath / Glide64

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

Extreme-G XG2 - texture corruption & incorrect view size #56

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
using the rear view, there is corruption (see image02) while it is correct
using jabo plugin (see snap01).

Also, the texture size for this game and many others are quite large such
that certain parts are not visible using glide64 while it correct using
jabo plugin.

Original issue reported on code.google.com by pokefan0...@gmail.com on 7 Mar 2010 at 4:42

Attachments:

GoogleCodeExporter commented 9 years ago 
The game is tested using glide64 and jabo in 1964emu and PJ64 v1.6.  In some
situation, PJ64 v1.6 is able to re-size it correctly to fit the screen while
incorrect at other times.

I assume it is a glide64 plugin problem because it is correct with jabo plugin.

Original comment by pokefan0...@gmail.com on 7 Mar 2010 at 4:55

GoogleCodeExporter commented 9 years ago 
mergeable with issue 35

Original comment by WC-Preda...@web.de on 7 Mar 2010 at 11:18

GoogleCodeExporter commented 9 years ago 
I think the developer will decide if both issues can be merged - I don't have 
any
issue with it.  Anyway, I don't quite understand your bug report and could not
visualize the problem or whether it is the same as this bug report.

Original comment by pokefan0...@gmail.com on 7 Mar 2010 at 1:41

GoogleCodeExporter commented 9 years ago 
i spoke from the same thing but you show it better :)

Original comment by WC-Preda...@web.de on 7 Mar 2010 at 1:48

GoogleCodeExporter commented 9 years ago 
i wanna test the newest glide64 r but can´t found it anywhere
found only r96, i want r101
where or who?

Original comment by WC-Preda...@web.de on 7 Mar 2010 at 2:08

GoogleCodeExporter commented 9 years ago 
I am not sure if I should say this but search the web for "Glitch64 SVN r101" 
and you
may just find a place where you get regular update or just compile it yourself 
or
wait for developer to release as hotfix.

Original comment by pokefan0...@gmail.com on 7 Mar 2010 at 2:29

GoogleCodeExporter commented 9 years ago 
but why does it work with u & j rom? what´s the difference?

Original comment by WC-Preda...@web.de on 10 Mar 2010 at 8:36

GoogleCodeExporter commented 9 years ago 
I don't have U & J version of this game.

Original comment by pokefan0...@gmail.com on 10 Mar 2010 at 10:35

GoogleCodeExporter commented 9 years ago 
this error happens only on the e rom, the others work fine
maybe a hz prob, e = 50, u = 60
hmm...

Original comment by WC-Preda...@web.de on 10 Mar 2010 at 10:46

GoogleCodeExporter commented 9 years ago 
Please check it again with r104. Probably the problem has the same origin.

Original comment by gon...@ngs.ru on 15 Mar 2010 at 4:52

GoogleCodeExporter commented 9 years ago 
i want to test it but i can´t compile it

Original comment by WC-Preda...@web.de on 15 Mar 2010 at 5:02

GoogleCodeExporter commented 9 years ago 
rear view corruption has been fixed but the screen position is still push down
causing truncated text and image.

Original comment by pokefan0...@gmail.com on 15 Mar 2010 at 5:17

GoogleCodeExporter commented 9 years ago 
Hmm, try to set pal230=1 in the ini for this game.

Original comment by gon...@ngs.ru on 16 Mar 2010 at 3:51

GoogleCodeExporter commented 9 years ago 
using pal230=1 will push screen position up a little but it still too far down 
and it
seems to make the intro screen image bigger and grow sideway.

Not sure if you understood what I am trying to say.

Original comment by pokefan0...@gmail.com on 16 Mar 2010 at 4:32

GoogleCodeExporter commented 9 years ago 
Ok, thanks for testing. I'll try to fix it.

Original comment by gon...@ngs.ru on 16 Mar 2010 at 11:47

GoogleCodeExporter commented 9 years ago 
Thanks.

I attach 2 screenshot from 1964Video - "This Game is Rumble Pak" is not visible 
in
glide64 and the bottom portion after the icons in image2-1 is truncated in 
glide64.

Original comment by pokefan0...@gmail.com on 16 Mar 2010 at 1:01

Attachments:

GoogleCodeExporter commented 9 years ago 
did it jump up & down everytime?

Original comment by WC-Preda...@web.de on 16 Mar 2010 at 1:19

GoogleCodeExporter commented 9 years ago 
I think you are using PJ64 which will flicker in some scenes because it is 
trying to
adjust the screen position.  It will succeed in some scenes but not always.  If 
you
test longer, you will know what I mean.

Original comment by pokefan0...@gmail.com on 16 Mar 2010 at 1:24

GoogleCodeExporter commented 9 years ago 
but the big question is: why does it work with U & J and not in E?
in rhe ini the entry of extreme g 2 are taken for U & E
maybe E needs his own entry?
all weird

Original comment by WC-Preda...@web.de on 16 Mar 2010 at 1:33

GoogleCodeExporter commented 9 years ago 
>why does it work with U & J and not in E?
It can be caused by variety of reasons, e.g. core issues, different frame 
buffer size.

Original comment by gon...@ngs.ru on 17 Mar 2010 at 10:44

GoogleCodeExporter commented 9 years ago 
can you test the possibe reasons anyway & fix it?
or did i thought to easy?

Original comment by WC-Preda...@web.de on 17 Mar 2010 at 10:54

GoogleCodeExporter commented 9 years ago 
Sure. Status: Accepted.

Original comment by gon...@ngs.ru on 18 Mar 2010 at 4:02

GoogleCodeExporter commented 9 years ago 
tested latest build on PJ64 v1.6 and the incorrect texture size is still 
happening
(seems unstable) on some frames while it is ok in others.

Original comment by pokefan0...@gmail.com on 7 May 2010 at 1:37

GoogleCodeExporter commented 9 years ago 
For my own testing, I did the following changes in "void _ChangeSize ()" and it 
seems
to fix the incorrect display (see attached images).

float aspect = (settings.adjust_aspect && (fscale_y > fscale_x) && 
(rdp.vi_width >
rdp.vi_height)) ? fscale_x/fscale_y : 0.85f;

if (aspect = 0.85f)
   rdp.scale_y = (float)settings.res_y / rdp.vi_height;
else
   rdp.scale_y = (float)settings.res_y / rdp.vi_height * aspect;

rdp.offset_y = ((float)settings.res_y - rdp.vi_height * rdp.scale_y) * 0.05f;

if (((wxUint32)rdp.vi_width <= (*gfx.VI_WIDTH_REG)/2) && (rdp.vi_width > 
rdp.vi_height))
    rdp.scale_y *= 0.6f;

So far, other games are still displaying correctly despite this change.

Original comment by pokefan0...@gmail.com on 29 May 2010 at 9:36

Attachments:

GoogleCodeExporter commented 9 years ago 
Also, I made the following changes in "void _ChangeSize ()" and it seems to fix 
New
Tetris(U) display issue too.

if (region >= 0 && settings.pal230)

See attached images.

Original comment by pokefan0...@gmail.com on 29 May 2010 at 9:45

Attachments:

GoogleCodeExporter commented 9 years ago 
put it in gonetz :D

Original comment by WC-Preda...@web.de on 29 May 2010 at 10:29

GoogleCodeExporter commented 9 years ago 
This is not necessary the correct fix as PJ64 v1.6 try to do its display 
adjustment
for extreme G 2 but fails at certain points.

The changes I made is very crude and probably incorrect but works for me on my 
modded
1964 using 16:9 at 19200x1080.

I am still waiting for an official fix to the display issue.

Original comment by pokefan0...@gmail.com on 29 May 2010 at 1:30

GoogleCodeExporter commented 9 years ago 
pls give me your version

Original comment by WC-Preda...@web.de on 29 May 2010 at 6:07

GoogleCodeExporter commented 9 years ago 
It is advisable to wait for the official fix and not appropriate for me to 
distribute
my compiled version.

I still have problem with PJ64 v1.6 altho' it works well on my modded 1964.  
So, my
fix is not really the proper fix.

Original comment by pokefan0...@gmail.com on 29 May 2010 at 7:12

GoogleCodeExporter commented 9 years ago 
ok but i want to play xg2 with glide soon :)

Original comment by WC-Preda...@web.de on 29 May 2010 at 7:45

GoogleCodeExporter commented 9 years ago 
Gonetz,
I have changed the following to the above :
1. from 0.85f to (fscale_y/fscale_x) * 1.05f ;
2. from 0.05f to 0.025f
3. from 0.6f back to original 0.5f (otherwise RE2 may have corruption)

So far, games tested works well.  Not sure if these info is useful to you.

Original comment by pokefan0...@gmail.com on 30 May 2010 at 5:05

GoogleCodeExporter commented 9 years ago 
I think I will stick to the following changes until the official fix.  
It seems to be working fine using 1920x1080 & 1600x1024 for 16:9.  
Also, tested some games on 4:3 and looks fine too.

Glide64 - Main.cpp - void _ChangeSize ()
----------------------------------------
float aspect = (settings.adjust_aspect && (fscale_y > fscale_x) && 
(rdp.vi_width >
rdp.vi_height)) ? fscale_x/fscale_y : (fscale_y/fscale_x) * 1.04f;

if (region >= 0 && settings.pal230)

if (aspect != fscale_x/fscale_y)
    rdp.scale_y = (float)settings.res_y / rdp.vi_height;
else
    rdp.scale_y = (float)settings.res_y / rdp.vi_height * aspect;

rdp.offset_y = ((float)settings.res_y - rdp.vi_height * rdp.scale_y) * 0.01f;

Original comment by pokefan0...@gmail.com on 30 May 2010 at 8:15

GoogleCodeExporter commented 9 years ago 
Thanks for the hints. I need some time to find, what is actually wrong and why 
your
fixes work. So far, I don't understand this line:
rdp.offset_y = ((float)settings.res_y - rdp.vi_height * rdp.scale_y) * 0.01f;
I think, it should be
rdp.offset_y = ((float)settings.res_y - rdp.vi_height * rdp.scale_y) * 0.5f;

Original comment by gon...@ngs.ru on 31 May 2010 at 8:48

GoogleCodeExporter commented 9 years ago 
Using 0.5f for the offset will cause a small strip of black border at the top
(especially visible if you are using a resolution that matches the ration 16:9 
or 4:3).

Pushing the value to 0.01f will remove the top black border (I think the gap 
also
depend on the aspect value applied on that particular game).  So far, this is 
the
best value for me as I use resolution that matches the ratio in window mode.

Original comment by pokefan0...@gmail.com on 31 May 2010 at 9:47

GoogleCodeExporter commented 9 years ago 
>Using 0.5f for the offset will cause a small strip of black border at the top
It expected behavior. Look:
rdp.vi_height - height of the original N64 image.
rdp.vi_height * rdp.scale_y - height of the image being drawn.
settings.res_y - screen height
settings.res_y - rdp.vi_height * rdp.scale_y - difference between screen height 
and
image height.
Plugins adds a offset to center the image on the screen. The Y offset is
rdp.offset_y = ((float)settings.res_y - rdp.vi_height * rdp.scale_y) / 2
that is half of the difference between screen height and image height.
If you will calculate it as 
rdp.offset_y = ((float)settings.res_y - rdp.vi_height * rdp.scale_y) * 0.01f;
you will just divide the difference by 100, that is make it nearly zero and the 
image
will not be centered.

Original comment by gon...@ngs.ru on 31 May 2010 at 2:16

GoogleCodeExporter commented 9 years ago 
>if (region >= 0 && settings.pal230)
region = 0 is NTSC. pal230 setting is for PAL games.
Tetris works incorrect because of emulator's core issues.
Use Mupen64 to play this game without this hack.

Original comment by gon...@ngs.ru on 31 May 2010 at 2:34

GoogleCodeExporter commented 9 years ago 
I checked the problem. It is Project64 core issue. In short: height of the N64 
image
is calculated by emulator and stored in special registers of GFX_INFO 
structure. For
this game the height is changed each frame in some places. One frame it is 198, 
on
next frame it is 238, while it must always be 240. This causes the screen shake,
because height of the rendered image depends of N64 image height. I don't know, 
how
Jabo avoided the issue, and honestly I don't care. I tested the game with 
Mupen64 -
it works perfectly. I'll not add special hacks to avoid emulator's bugs. But 
you of
course may do it for yourself.

Original comment by gon...@ngs.ru on 31 May 2010 at 3:18

GoogleCodeExporter commented 9 years ago 
then pls pokefan send me your version or you release 2 versions of glide gonetz 
(or 1
extra only for xg2 pls)
maybe you ask jabo
i don´t want to use mupen

Original comment by WC-Preda...@web.de on 31 May 2010 at 3:29

GoogleCodeExporter commented 9 years ago 
forget something
why does it work with j & u?

Original comment by WC-Preda...@web.de on 31 May 2010 at 3:31

GoogleCodeExporter commented 9 years ago 
Gonetz,
I am sure you are right and I respect your reply.  Thanks for checking.

WC-Preda,
I am not a glide64 developer and it is inappropriate for me to send you my 
version.
Take Gonetz advice and use Mupen to play XG2.
I did it out of curiosity and wanted to play all my N64 games using 1964.

Original comment by pokefan0...@gmail.com on 31 May 2010 at 4:22

GoogleCodeExporter commented 9 years ago 
>why does it work with j & u?
Because j & u are NTSC. PAL versions have different frame rate and screen size. 
This
means that e version is coded somehow different, and it's not well emulated by 
some
emulators.

Original comment by gon...@ngs.ru on 1 Jun 2010 at 6:10

GoogleCodeExporter commented 9 years ago 
gonetz can you make this things from pokefan include in glide only for me & 
send it
to me pls?

Original comment by WC-Preda...@web.de on 1 Jun 2010 at 7:25