Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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
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:
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
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
>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
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
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
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
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
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
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
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
[deleted comment]
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
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
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
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
[deleted comment]
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
>>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
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
[deleted comment]
[deleted comment]
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
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
The blending issue is fixed.
You may close this issue.
Thanks
Original comment by pokefan0...@gmail.com
on 19 Jul 2010 at 8:00
Original comment by gon...@ngs.ru
on 19 Jul 2010 at 3:35
Original issue reported on code.google.com by
pokefan0...@gmail.com
on 18 Jun 2010 at 12:28Attachments: