Paper Mario - missing intro sprite

[GoogleCodeExporter]

Using latest official Glide64 WIP on Mupen64
--------------------------------------------
1.  start Bomberman64U and stop game at image1.
2.  start Paper Mario and you will notice the 3 logo sprites in image2-4 are 
missing (only the white bg) until the next frame appear(image5).
3.  if you don't Bomber64U but starts Paper Mario first, image2-4 will display 
correctly.
4.  there are other scenarios that will cause it too e.g. closing OB64 at 
certain displayed frame before starting Paper Mario.

Original issue reported on code.google.com by pokefan0...@gmail.com on 18 Jun 2010 at 12:28

Attachments:

• Bomberman64U_01.jpg
• PAPER_MARIO_02.jpg
• PAPER_MARIO_03.jpg
• PAPER_MARIO_04.jpg
• PAPER_MARIO_05.jpg

[GoogleCodeExporter]

I have tried my latest compile version on PJ64 v1.6 and there is no more 
missing logo when Paper Mario is started after Bomberman64U.  Can't verify 
latest official WIP because it crash PJ64.

You may proceed to close this issue if you can verify that the official 
WIP(HWFBE) version is working too.

Original comment by pokefan0...@gmail.com on 30 Jun 2010 at 5:36

[GoogleCodeExporter]

Just tested latest official WIP (without "Rice") on Mupen64 and still have the 
same issue.  Does the official WIP works for you?

Not sure why my latest compile version works on PJ64 v1.6 (still trying to get 
it to work on 1964).

Original comment by pokefan0...@gmail.com on 30 Jun 2010 at 3:01

[GoogleCodeExporter]

It is working correctly if "Rice" format is checked but these issues will 
surface if "Rice" format is unchecked. - tested on PJ64 v1.6

Original comment by pokefan0...@gmail.com on 1 Jul 2010 at 8:44

[GoogleCodeExporter]

Same as issue #84.
Latest compile version works on PJ64 v1.6 correctly with / without "Rice" 
format checked.

Same texture blending issue(missing sprites in logo screen) for 1964 and 
Mupen64.

Mupen64 crash when loading games with "Rice" format checked.

Does your windows build crash Mupen64?

Original comment by pokefan0...@gmail.com on 3 Jul 2010 at 7:33

[GoogleCodeExporter]

Unable to verify official WIP on PJ64 v1.6 because it crash emu on closing rom.
If you can verify official WIP works in PJ64 v1.6(above scenario) then you may 
proceed to close this issue as invalid.
Thanks

Original comment by pokefan0...@gmail.com on 11 Jul 2010 at 7:46

[GoogleCodeExporter]

tested r151 on HWFBE version - fixed.
But it causes graphics glitches in menu when save file is selected - I will 
open separate issue.

Please close this issue.
Thanks

Original comment by pokefan0...@gmail.com on 11 Jul 2010 at 5:13

[GoogleCodeExporter]

Since r151 is released under trunk, I will mention the issue here since I 
tested it in HWFBE version.

When you select your game save under Paper Mario game menu, you will graphics 
glitches during the transition effects (same when you press B after selecting - 
see image1).

I suspect it is caused by "memset(&rdp.vi_width, 0, 
sizeof(rdp)-sizeof(rdp.RomName));"

For my own testing, I change it to "sizeof(rdp.vi_width)" and it seems to fix 
the glitch.

Original comment by pokefan0...@gmail.com on 11 Jul 2010 at 6:17

Attachments:

• PAPER_MARIO_1.jpg

[GoogleCodeExporter]

There seems to be some weird issue especially RE2 but I think I will wait for 
official HWFBE version to verify them.  Anyway, RE2 is not very stable 
previously.

Original comment by pokefan0...@gmail.com on 11 Jul 2010 at 9:08

[GoogleCodeExporter]

I did some tests on my compiled version + r151 (HWFBE) on 1964 & PJ64 v1.6.  
If I comment out just the following from r150, it will still fix those blending 
issues in PD, OB64, Paper Mario, JFG, Quake II etc.  
Also, there is no intermittent sound lost or additional graphics glitch in RE2 
or Paper Mario.  There is no crash in PJ64 v1.6 (as before) and speed is still 
good.  
FYI.
//  rdp.n_cached[0] = 0;
//  rdp.n_cached[1] = 0;
//  rdp.cur_cache[0] = 0;
//  rdp.cur_cache[1] = 0;
//  rdp.c_a0  = 0;
//  rdp.c_b0  = 0;
//  rdp.c_c0  = 0;
//  rdp.c_d0  = 0;
//  rdp.c_Aa0 = 0;
//  rdp.c_Ab0 = 0;
//  rdp.c_Ac0 = 0;
//  rdp.c_Ad0 = 0;

//  rdp.c_a1  = 0;
//  rdp.c_b1  = 0;
//  rdp.c_c1  = 0;
//  rdp.c_d1  = 0;
//  rdp.c_Aa1 = 0;
//  rdp.c_Ab1 = 0;
//  rdp.c_Ac1 = 0;
//  rdp.c_Ad1 = 0;

//  rdp.texrecting = 0;
//  rdp.rm = 0;
//  rdp.render_mode_changed = 0;
//  rdp.othermode_h = 0;
//  rdp.othermode_l = 0;

//  rdp.cimg = 0;
//  rdp.ocimg = 0;
//  rdp.zimg = 0;
//  rdp.ci_width = 0;
//  rdp.ci_size = 0;

//  rdp.cur_tex_buf = 0;
//  rdp.acc_tex_buf = 0;
//  rdp.cur_image = 0;
//  rdp.tbuff_tex = 0;
//  rdp.aTBuffTex[0] = rdp.aTBuffTex[1] = 0;

Original comment by pokefan0...@gmail.com on 12 Jul 2010 at 12:00

[GoogleCodeExporter]

>If I comment out just the following from r150, it will still fix those 
blending issues in PD, OB64, Paper Mario, JFG, Quake II etc.

Do you mean that if you take r150, switch to branch HWFBE_Fixes and just 
comment out that part of rdp_reset() function then all mentioned problems will 
gone? It would be very strange. 

Original comment by gon...@ngs.ru on 12 Jul 2010 at 4:27

[GoogleCodeExporter]

Initially, I implement your r151 change into my compiled r150 build (HWFBE 
version).
-  encounter graphics glitches e.g. Paper Mario and RE2
-  intermittent sound lost after testing several games (not specific) e.g. XG2
-  may crash 1964(never in my r150 build)
-  random crash when closing emu or rom in PJ64 v1.6 during testing
   - r150 working perfectly for me in PJ64 v1.6 (no crash & no blending issue)

I look at what is changed & commented out the above from rdp_reset() function 
in my latest compiled r150 build (include all my previous changes - not the 
trunk/hwfbe r150).
-  tested with known blending scenarios e.g. PD lighting, OB64 smoke & missing 
logo screen, Paper Mario missing logo screen, JFG keyboard & fb effect glitch, 
Quake II missing text intro screen.
   - no blending issue 1964 & PJ64 v1.6( same as before)
   - did not crash in PJ64 v1.6(same as before)
   - did not crash 1964(same as before)
   - did not encounter any additional graphics glitch
   - no intermittent sound lost (RE2 works very well in 1964 with 1964Audio)

I will wait & test your official r151 hwfbe version to see if there is any 
difference in result.

Original comment by pokefan0...@gmail.com on 12 Jul 2010 at 4:56

[GoogleCodeExporter]

Compile official trunk r151 & using official ini and test on Mupen64
- fix blending issue but still have that graphics glitch in Paper Mario
- unable to verify RE2 in-game because of invisible characters & flickering
  - most likely setting in official ini or Mupen64

I still want to verify against your official hwfbe r151 against my compile to 
see if there is difference in result on 1964 & PJ64 v1.6.

Original comment by pokefan0...@gmail.com on 12 Jul 2010 at 1:34

[GoogleCodeExporter]

Tested same official trunk r151 & ini on PJ64 v1.6
- fix blending issue
- new graphics glitch in Paper Mario game menu & corrupt bg during fb effect
- new graphics glitch in RE2 intro cutscene bg
- crash emu when closing Bomberman64U at the intro cutscene, no crash if close 
at game menu
- crash emu when closing emu after closing RE2

Original comment by pokefan0...@gmail.com on 12 Jul 2010 at 1:58

[GoogleCodeExporter]

You're right. My fix causes bad side effects. I missed something important. The 
change reverted.
Your solution is not right too - the code you commented is correct by itself. 
Weird, that without it the program works more correct.
Suggestion: revert to r150 (or update to r152, which is the same) and add this 
line to rdp_reset() function:
rdp.flags = 0;
This should fix blending issues and must not have bad side effects. Please 
check it.

Original comment by gon...@ngs.ru on 12 Jul 2010 at 4:27

[GoogleCodeExporter]

Tested "r150 + rdp.flags = 0" on 1964 & PJ64 v1.6 (HWFBE version)
-----------------------------------------------------------------
1.  Blending issues fixed
2.  No bad side-effects found in my testing

You may proceed to close this issue.
Thanks

Original comment by pokefan0...@gmail.com on 12 Jul 2010 at 6:32

[GoogleCodeExporter]

Tested Official trunk "r150 + rdp.flags = 0" on Mupen64 & PJ64 v1.6
-------------------------------------------------------------
1.  Blending issues fixed
2.  PJ64 v1.6
    - close RE2 then close emu may crash emu
    - close Bomberman64U at the corrupted fb effect intro transition crash emu
3.  Mupen64
    - RE2 in-game characters are visible now BUT
      - it may become very transparent at some point then normalize
      - bg may flicker some point (1-3 sec)
      - bg may become black at frame changed (character is visible) for 1 sec
    - it may be a core (never tested this game on Mupen64)

Original comment by pokefan0...@gmail.com on 12 Jul 2010 at 7:18

[GoogleCodeExporter]

The HWFBE version tested is my "compiled version + rdp.flags = 0" and not the 
official hwfbe version. I still need to verify your official hwfbe version to 
see if there is a difference in result.

I still believe the crash that I am getting in PJ64 from official version is 
not related to this fix (other bug).

Original comment by pokefan0...@gmail.com on 12 Jul 2010 at 7:26

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

compile & test Official "r152 + rdp.flags = 0" on Mupen64 & PJ64 v1.6
---------------------------------------------------------------------
1.  Blending issues fixed
2.  No bad side-effects found in my testing
3.  Mupen64
    - RE2 in-game characters are visible now BUT
      - it may become very transparent at some point then normalize
      - bg may flicker some point (1-3 sec)
      - bg may become black at frame changed (character is visible) for 1 sec
    - it may be a core issue because it works well in 1964

You may proceed to close this issue.
Thanks

Original comment by pokefan0...@gmail.com on 13 Jul 2010 at 4:25

[GoogleCodeExporter]

My findings:

For PJ64 v1.6, I think it is best not to include rdp.flags = 0.

1.  at r150, there is no blending issue & it is very stable with no crash for 
tested cases.

with rdp.flags = 0, it seems ok but still not very stable, e.g.

1. start PD v1.1 after starting emu.  at intro cutscene, press A to stop 
cutscene and image will freeze or stop but sound continues (it doesn't go 
in-game).  stop the rom and it crashes emu (official & my version - same)

2. start PD v1.0 after starting emu (works fine).  close rom and start PD v1.1 
and do item 1 action, sound may or may not stop. if it stops, it will go 
in-game.  close rom then close emu - crash emu (official & my version - same)

3. if I exclude rdp.flags = 0 i.e. r150 - sound will not stop for item 1 but 
there is no crash when you close rom & emu.  For item 2, everything works 
normally and there is no crash.  I don't believe it is the only case of 
instability.

This fix doesn't seem to benefit PJ64 v1.6 because it doesn't have blending 
issue in r150 whereas 1964 & Mupen64 have blending issue and need the fix.  But 
1964 is very stable with the fix (no issue with PD v1.1).

Just my own observations from my testing.

Original comment by pokefan0...@gmail.com on 13 Jul 2010 at 9:42

[GoogleCodeExporter]

I had stable blending issue scenario on Pj 1.6:
- Load PM, load savesate from Dry Dry Ruins, close rom
- Load PD, load save with coronas visible - coronas corrupted.
rdp.flags = 0 fixes that.

Actually, all fields of rdp object must be re-initialized (mostly by zero) 
every time new rom is loaded to avoid collisions. memset(ptr, 0, size) does 
exactly that thing. I can't find, why it causes problems. I'm too lazy to write 
for each field manually rdp.this_field = 0; but most important fields must be 
initialized. flags is one of them, because it controls parameters of the 
rendering and if some its bits remained from previous game the rendering will 
go wrong. Anyway, initialized or not it no way should affect stability of 
emulation. Rather plugin's code in whole is not very stable, or compiler's code 
optimization causes stability issues.

Original comment by gon...@ngs.ru on 13 Jul 2010 at 11:29

[GoogleCodeExporter]

I am sure you are right.  Just ignore my comment on stability issue.
I am happy that the blending issue is fixed in 1964.
Thanks and you may close this issue.

Original comment by pokefan0...@gmail.com on 13 Jul 2010 at 12:21

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It seems simple to use 1 line to clear everything in RDP and then set those 
non-zero objects.

It seems to work well on the tested cases in 1964 & PJ64 v1.6
- fix blending issues
- no crash & very stable

Maybe I will try your memset method after I do some reading.

Original comment by pokefan0...@gmail.com on 13 Jul 2010 at 6:16

[GoogleCodeExporter]

>>It seems simple to use 1 line to clear everything in RDP
1 line? how?

Original comment by gon...@ngs.ru on 14 Jul 2010 at 3:40

[GoogleCodeExporter]

I got it from the web.

RDP data = {0};

But I don't know how to solve "wxString RomName" error during the clearing, so 
I move it to a new struct.  It works ok for PJ64 v1.6 but Bomberman64U may 
flicker during intro cutscene.  Now moving both enum to new struct to test 
(when it works well in PJ64, something weird happens in 1964).

Original comment by pokefan0...@gmail.com on 14 Jul 2010 at 5:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It would seem sufficient to just comment out the following 4 lines because 
rdp.flags is not cleared to fix blending issue.
  rdp.rm = 0;
  rdp.render_mode_changed = 0;
  rdp.othermode_h = 0;
  rdp.othermode_l = 0;

With just rdp.flags added, I get some weird issue (same as clearing RDP) e.g. 
random black screen during game load (not specific).  The above seem best for 
me.

Now I am testing by adding more objects to be cleared as below.  So far, all my 
test cases work correctly and I can run many games in a single emu session 
without any weird problem.  But I have to clear so many more objects (probably 
run a while longer to see if anything weird happens).
  for (i=0; i<4096; i++)
      rdp.tmem[i] = 0;
  for (i=0; i<10; i++)
      rdp.pc[i] = 0;
  for (i=0; i<4; i++)
      rdp.col[i] = 0.0f;
  for (i=0; i<4; i++)
      rdp.coladd[i] = 0.0f;
  rdp.halt = 0;
  rdp.flags = 0;
  rdp.update = 0;
  rdp.updatescreen = 0;
  rdp.window_changed = FALSE;
  rdp.scissor_set = FALSE;
  rdp.v0 = 0;
  rdp.vn = 0;
  rdp.filter_mode = 0;
  rdp.model_stack_size = 0;
  rdp.t0 = 0;
  rdp.t1 = 0;
  rdp.cmd0 = 0;
  rdp.cmd1 = 0;
  rdp.cmd2 = 0;
  rdp.cmd3 = 0;
  rdp.acmp = 0;
  rdp.zsrc = 0;
  rdp.tri_n = 0;
  rdp.debug_n = 0;
  rdp.dl_count = 0;
  rdp.pc_i = 0;
  rdp.prim_depth = 0;
  rdp.blend_color = 0;
  rdp.prim_color = 0;
  rdp.fill_color = 0;
  rdp.fog_color = 0;
  rdp.env_color = 0;
  rdp.shade_factor = 0.0f;
  rdp.prim_lodmin = 0;
  rdp.prim_lodfrac = 0;
  rdp.vi_width = 0.0f;
  rdp.vi_height = 0.0f;
  rdp.clip_min_x = 0.0f;
  rdp.clip_max_x = 0.0f;
  rdp.clip_min_y = 0.0f;
  rdp.clip_max_y = 0.0f;
  rdp.offset_x = 0.0f;
  rdp.offset_y = 0.0f;
  rdp.scale_x = 0.0f;
  rdp.scale_y = 0.0f;
  rdp.scale_1024 = 0.0f;
  rdp.scale_768 = 0.0f;
  rdp.scale_x_bak = 0.0f;
  rdp.scale_y_bak = 0.0f;
  rdp.cmb_flags = 0;
  rdp.cmb_flags_2 = 0;
  rdp.n_global = 0;
  rdp.vtx_buffer = 0;
  rdp.uncombined = 0;
  rdp.geom_mode = 0;
  rdp.Persp_en = 0;
  rdp.LOD_en = 0;
  rdp.use_lookat = FALSE;
  rdp.s2dex_tex_loaded = 0;
  rdp.bg_image_height = 0;
  rdp.ci_height = 0;
  rdp.ci_end = 0;
  rdp.zi_width = 0;
  rdp.zi_lrx = 0;
  rdp.zi_lry = 0;
  rdp.ci_upper_bound = 0;
  rdp.ci_lower_bound = 0;
  rdp.ci_count = 0;
  rdp.main_ci = 0;
  rdp.main_ci_end = 0;
  rdp.main_ci_bg = 0;
  rdp.main_ci_last_tex_addr = 0;
  rdp.zimg_end = 0;
  rdp.last_bg = 0;
  rdp.num_of_ci = 0;
  rdp.copy_ci_index = 0;
  rdp.copy_zi_index = 0;
  rdp.swap_ci_index = 0;
  rdp.black_ci_index = 0;

Original comment by pokefan0...@gmail.com on 17 Jul 2010 at 9:24

[GoogleCodeExporter]

No more testing for this issue from me unless you have further change to your 
official fix.

Original comment by pokefan0...@gmail.com on 17 Jul 2010 at 7:09

[GoogleCodeExporter]

The blending issue is fixed.
You may close this issue.
Thanks

Original comment by pokefan0...@gmail.com on 19 Jul 2010 at 8:00

[GoogleCodeExporter]

Original comment by gon...@ngs.ru on 19 Jul 2010 at 3:35

• Changed state: Fixed