"Goombario" isn't in "Paper Mario 2: The Thousand-Year Door"

I mean "Professor Frankly"

Well it doesn't crash. The game still runs; the only problem I have is that when he
goes to pull the fence off, it doesn't change and the game is stuck in that sequence.

I can reproduce this error (and yeah, it's Prof. Frankly lol).

The game doesn't crash though. After talking with Prof. Frankly and leaving his
house, the game initiates an in-game sequence where Prof. Frankly is supposed to lift
a piece of the fence off, which would allow the player to progress further in the
game. After Prof. Frankly talks about lifting it off, the game gets stuck at the
point right where he is trying to get it off (so nothing happens and you can't move).

The obvious workaround is to use a save game that's just past that point, though that
is a temporary fix.

I tried save game at this point and load, but nothing:(

I think the issue is directly related with the "flipping boat" bug, and the X-Nauts
in the first map not being displayed(after boat sequence).

I also encounter this problem (Dolphin SVN R 1945)

Maybe this is problem in ISO or in emulator (second more probably)

This is (IMO) certainly a problem with the emulator, judging from the number of
people who are having the problem. However, I do not think that this has anything to
do with the invisible x-nauts or the boat-flipping (almost certainly just graphical
glitches, as the game proceeds normally afterwards), but has something to do with
the dsp. Could someone who has access to visual studio 2008 please compile r1174 and
host it somewhere, as it looks like (according to a video here:
http://www.youtube.com/watch?v=cUSAMl7B3bY) it works on that version.

wait, never mind...it says that in the video he used a cheat code (super jump) to
get over the fence, but it freezes at hooktails castle. So we're back to waiting
until it's fixed.

R2124 and bug is still same, famous fence problem!

Several other games have similar strange hangings. Fire Emblem for the GameCube
hangs, Pikmin 2 hangs, Paper Mario for Wii hangs to. StarFox Adventures hangs or
refuses to work to, but before almost anything happens at all (more than that the
logo shows), so it may be a different problem.

I have a really old dolphin-emu installer that I burned to a disk, from back when
dolphin-emu was closed-source (version 1.3 beta, from early 2007). Perhaps (for
those of us who don't have the hardware to get save data from our gcn cards) it
would be possible to go past the fence in that version, and then load the save in
the current version. Unfortunately, the old version uses 2mb memory card files while
the new version uses 16mb ones, and the old version crashes before the fence
(crashes, not hangs). So, if there is some way to tell the new dolphin-emu to use
2mb files, or a way to convert 16mb files into 2mb files, please tell me and I'll
see if I can make it work. Thanks!

just point the new dolphin to your memcard file. It should use whatever size it is
(as long as it's a correct memcard size)

I tried...paper mario says the memory card is corrupt, and wants me to format it
(and delete all the data). It doesn't have a card manager. (like I said, this thing
is ancient)

ok, I was thinking some, and I thought up an explanation for the fence problem.
Be aware of these facts:
The ship curls as it flips over.
Normally, the fence should fall down off the screen, not swing open and fall over,
as one would think.
Someone reported (on the dolphin-emu forums) that at a later point in the story
(they got save data from their gcn right after the fence part), part of a wall
should curl down, but doesn't.

The way the ship flips is like this:
The 3d ship (the original one) dissappears.
A flat plane appears in its place.
The plane flips over (either by way of animated texture or true 3d deform).
then, either:
a. the plane chugs away like it's a 3d ship
or b. the plane dissappears, a 3d ship facing the other way appears, and the new
ship chugs away.

(I am relatively sure that) The problem is the adding of new object. It just never
happens, and in the ship example, the cutscene doesn't wait for it to and keeps on
going regardless, but in the other examples, it waits for it to appear, but it never
does. If anyone on the dev team can debug and fix this, I'm sure many people would
be very grateful, as it may fix pikmin 2 and the other games mentioned by jp.

I don't still think this problem has anything to do with the dissappearing x-nauts,
though I stand corrected as to the vanishing ship's part in this problem.

I think it does have to do with the X-Nauts in that scene. They're probably drawn the
same way that the 2D boat(for flipping) is drawn. Those X-Nauts in the scene are
definitely 2D.

marc...@cox.net : this is a little late to get a save from a memcard before the
memcard manager, use the memcard manager from the current revision to export as .gci,
use a hexeditor to change the first six bytes to be the save id (G8ME01) for NTSC
paper mario, Once you have edited the gci use the memcard manager to import the .gci
file into a new memcard or a memcard from a current revision.

OK, so the problem is almost undoubtedly that the call for adding a new 2D object is
refused at a very low level. Probably not implemented yet?

I did what you said, lp, and here is what the first 25 bytes of the .gci are:

47 38 4d 45 30 31 ff 02 6d 61 72 69 6f 73 74 5f 73 61 76 65 5f 66 65 5f 66 69 6c 65

In ASCII:

G8ME01 ff 02 mariost_save_file

Looks like the game code, then a verification line for the game...but the game code
is correct?!?

What did you want me to change it to?

Looks like it already has the game code, so you only need to import the gci into a
new memcard for a current revision. For the really old revisions it used to be 00 00
00 00 00 00 for the first 6, which is why I included that part

The memcard manager can't open the old 2 mb card files (invalid size error), and the
old dolphin can't open the new files (paper mario says the memory card is corrupt),
so it's hopeless.

Well, if the fence thing doesn't work now, it probably never did.

But in case any of you want to mess with it, I've hosted the 1.03b installer and an
unmodified .gci of a paper mario save file (so you don't have to play through the
opening and subsequent cutscenes at 10 fps):
http://members.cox.net/marcusw/dolphin_1.03b_stuff.zip
I'll delete it in a few weeks when everyone who wants it has it.

memcard manager will open the .raw file from 1.03, although I had to change a few
things to get it to import the gci correctly so that 1.03 recognizes it as a valid
save, I uploaded it here. http://rapidshare.com/files/199439679/MemoryCardA.7z.html
Don't know if it will help though, because you cant do anything when luigi walks into
the house

yeah, that is an annoying glitch, but I tried putting my .gci in the card (yes, I
remembered to fix the checksum afterwards), and then loading it. 1.03 didn't see the
save data, and made a new one, so I had two 17-block files when I looked at it in
the current memcards manager. No go.

that card already has your gci on it, I had to modify the memcard manager to not
fix checksums, as 1.03 did not correctly use checksums. and currently when you import
a save it automatically imports saves

I guess that was the wrong gci then.....I had file 1 saved at the save block nearest
frankly's house...I reuploaded the .zip with a new gci in it. See if that works.
http://members.cox.net/marcusw/dolphin_1.03b_stuff.zip

I typed the wrong thing previously "currently when you import a save it automatically
imports saves" should have been "currently when you import a save it automatically
fixes checksums". I'll create a new memcard with that gci, i will likely upload it
after 6pm pst

ok. funny thing though, I understood what you meant and didn't even notice it was
wrong until you pointed it out.....

Optimisticly awaiting new memcard.

Could a project member (lp, perhaps) please change the issue report to something
more understandable and that describes the issue more accurately? Like "2D objects
are not initialized correctly in games such as Paper Mario". The description should
be like a bit more concise too ("Talk to goombario with clothes and quit from room"
just doesn't cut it). As the reporter said:
"Sorry for my bad English, because I know this very bad."

http://rapidshare.com/files/199818890/MemoryCardA.7z.html
here's a new link. Someone who better understands why this happens should change the
title, as I have not debugged this issue

no good.....I went through the whole proffessor frankly thing at 3 fps, and it
crashed where it always does. Oh well, we tried :).

But I think that my description of the issue is somewhere close to correct. I will
willingly debug it if you tell my how to.

I'm using r2373 and have the same problem. Any progress ?

I think no:(

yeah, this isn't a but (IMO), just a feature not implemented yet. It sounds like it
would be easy to fix, but it probably isn't. Patience :)

Nobody accepted this issue jet! We must be patient!

Now I'm a dev, so I can change the title. I don't know how to fix the issue, though.

Now that I know how to use the log manager, here's a log snip:
http://paste2.org/p/167530. Not very helpful, but still some info. It means that
yes, there is a pointer/opcode that is not implemented yet.

In r2745 I get constant nagging in the log of

W: PE (r16): unknown @ cc001010
W: PE (r16): unknown @ cc001014
W: PE (r16): unknown @ cc001012
W: PE (r16): unknown @ cc001016

All 4 are always in the same time frame, always the same 4 addresses. Looks to me
like a RECT structure.

Appears once when the "Chapter 1" introduction appears, then it's constant spam after
the boat flips and leaves.

Crash on stop.
Saving/loading at the first save block will fix the spam.

Yes, the problem with the "Chapter 1" scene is that there are words that appear
going around the spinning emblem, and they are the same type of thing as the boat
and fence objects.

"Saving/loading at the first save block will fix the spam."

Yeah, the reason that happens is becuase of the way the game is programmed,
something like:

while 1:
addObject(flatship)
if flatship.exists():
break

and it keeps going with the cutscene, even though the ship isn't there yet (idk why,
I guess it's because of the way they timed the water splashes behind the boat). The
only difference is that in the fence scene, it waits until the fence is initialized
before it does anything. It never is, so it waits forever. If we can figure out all
the real functions for the new object, we might be able to do a fake object that
will return the expected output, so the game will think everything is ok wnd will
keep going as normal.

Since there doesn't seem to be any progress, I tried some experiments, and I believe
the solution(for the x-nauts anyway) is here:

File: PixelEngine.cpp
Function: Read16
Step: Create cases for 0x010, 0x012, 0x014, 0x016

Different return values can generate interesting effects. I really don't have any
idea where the return value should be grabbed from, so I've been testing out
different values on the X-Naut scene. I sometimes see a blue circle(?) at the
position near the original X-Naut models at the time it's supposed to "copy it" to a
2D surface. The most I've been able to do is produce static for each 2D X-Naut
surface. This also produces static for the boat scene(and causes the boat to actually
FLIP!). Actually does something when he "pulls off the fence" too(although not pretty).

Return Values used: 0xA0, 0xE0, 0xA0, 0xE0

Well it allows for the continuation of the game without using cheats. ;o

Well here is our "fix"!!!

Can you give a patch, because I'm not really getting what is changed to what...

\Source\Core\Core\Src\Hw\PixelEngine.cpp

Line 149 (?)

Add

{{{

case 0x010:
    _uReturnValue = 0x80;
    return;

case 0x012:
    _uReturnValue = 0xA0;
    return;

case 0x014:
    _uReturnValue = 0x80;
    return;

case 0x016:
    _uReturnValue = 0xA0;
    return;

}}}

It's not too much of a fix though, just need to figure out(retrieve) the correct values.

Yes, something happens with the fence (it turns blue), but.....here's the log
(loglevel 3): http://paste2.org/p/173334

So with this the fence turns blue, but does the game still hang?

Yes, but at least it does SOMETHING...

Using those line changes I was able to get up to defeating Hooktail, unfortunately
after the summary text in the end of chapter, it hangs again indefinitely at the
closed curtains...

So what's wrong with mine? Can somebody do an SVN patch for me?

Oh, and hanging at hooktail castle is a known bug...any log snips?

Here's a bit of my log (with the changes):
54:18:656 E: Video glError 00000506 before PS!
54:18:656 E: Video .\Src\PixelShaderCache.cpp:180:
(PixelShaderCache::CompilePixelShader) OpenGL error 0x506 - (null)

54:18:656 E: Video glError 00000506 before PS!
54:18:671 E: Video .\Src\PixelShaderCache.cpp:180:
(PixelShaderCache::CompilePixelShader) OpenGL error 0x506 - (null)

54:18:687 E: Video glError 00000506 before PS!
54:22:812 E: Video .\Src\PixelShaderCache.cpp:180:
(PixelShaderCache::CompilePixelShader) OpenGL error 0x506 - (null)

54:22:812 E: Video glError 00000506 before PS!
54:23:796 E: Video .\Src\PixelShaderCache.cpp:180:
(PixelShaderCache::CompilePixelShader) OpenGL error 0x506 - (null)

54:23:796 E: Video glError 00000506 before PS!

Actually, from what I understand the people who were using cheats to get up to
Hooktails Castle had the game freeze as they were trying to enter the castle. I was
able to get all the way up to the end of it and defeat the last boss.

These code changes actually fixed several things (although they aren't visually
correct). In the sewers there are a set of stairs the appear after you hit a switch.
When I used the Super Jump AR code to get past the gate these stairs didn't appear,
but with the line changes they worked as intended (except the animation was
terrible). There is also a bridge in chapter 1 that has the same crappy animation,
but it works now. I would speculate that these line changes fixed more than just the
fence (from my experience anyway).

wtf is this? why do we have "workaround" status????

Because it's just a workaround?
The return values are incorrect, but they have better results than the default return
value of 0x01.

"I would speculate that these line changes fixed more than just the
fence (from my experience anyway)."

Yes, this should fix the boat, and many other things, too...but it doesn't work on
my computer (perhaps because I'm loading from a savestate)...

Can anybody check if it fixes pikmin 2?

With the workaround I can enter the Hooktail castle and continue up to the end of
the chapter, but at the end, after the final boss of the chapter and after the final
text ends, I see only a red curtain and game freezes, and I cannot continue.

yeah, any log snips?

I tried to grab some logs the other day, but it appears I don't know how to use it
correctly, cause it isn't logging anything.

You need to start it with the option "-l" on the command line.

marcus, that's not true. -l just forces the logwindow to open, which can be opened
anyways from the dolphin menubar. (Tools>show whatever)

thanks for telling me how to open it without starting a cmd window :). I knew there
had to be a better way...

seems to be
0x10 = left
0x12 = right
0x14 = top
0x16 = bottom

Discovered this using values between 0x100 and 0x120 in rogueport sewers (going in
and out of pipes).

Also values of (1, 639, 1, 479) seem to fix the boat scene completely, but crashes on
the mass of X-Nauts scene. We only need to find where the values are supposed to be
pulled from and it will be perfect.

It also makes Mario's "Paper Mode" (2D / Flip / Whatever) perfect. (But not the ally's?)

good. but what's this left/right/top/bottom stuff?

I think it's to do with flipping like flip left flip right

Ok here is a neatened up version of the current work around

good. I'll commit it in a few hours when I have more time.

OK, it's commited. Now let's see how it works for other people...

GAAAH i just realized i added to many spaces on one of them :(

The SVN revision page is notorious for displaying tabs incorrectly, and the
indentation looks fine in VC++ and TortiseUDiff. It's google's error, not yours :)

Thanks for that!

But it seems WAY too complicated for me to do...I hope someone gets it working
correctly, though.

Here is patch with flip renamed to bbox

Is it possible to do this on the GPU in the vertex shader? After computing the screen
coordinates of each vertex, it could update a bounding box variable which could be
read back by the CPU. I'm fairly certain that it would be possible, but it might
require OpenGL 3.0 or DirectX 10.

Well, you can do transform feedback, but it would output values for each vertex, and then one would have to
collect the min/maxes using the CPU (or yet another set of GPU passes) anyway. Plus, it would add latency.

I think it's better to do it on the CPU, but it could be skipped until a game has actually read the registers (nearly
all games write them once as part of initialization).

That's not exactly what I meant. I meant that the vertex shader could update the
bounding box variable at the exact same time that it computes the transformed vertex.
No need to do transform feedback or multiple passes.

I think I'll investigate this. You might be correct that it isn't possible.

Yeah but excluding transform feedback, vshaders can't write anywhere else than intermediate data that gets
passed to the pixel shader.

"Labels: Ye"
Was that intentional?

Great work guys! This also fixes the annoying Pixl glitch in Super paper Mario, which
made the game unbeatable.

2 birds with 1 stone :)

And maybe more than that...

It also fixes the intro hang, the one when you start the game and when you start a
new save. For graphical errors I have a few pictures, don't know if these are caused
by this since couldn't get to where they are before.
In the intro video for a new save file, you can't see Bowser's troops:
http://s512.photobucket.com/albums/t326/KHRZ/?action=view&current=Missingtroops.jpg
Sometimes, sprites appear black (This also happened in the first Paper Mario on
project 64.. hm, related issue?)
http://s512.photobucket.com/albums/t326/KHRZ/?action=view&current=Textglitch.jpg
Also the same black texture did this after the chapter finished:
http://s512.photobucket.com/albums/t326/KHRZ/?action=view&current=Spriteglitch.jpg

Issue 599 has been merged into this issue.

The game still hangs for me at the end of chapter 1 in the screen with the red
curtain. Is it related to this issue or it is another bug ?

that is a different bug.

There's a new problem, I think it's related.
Log:

17:57:635 W: Video Unknown Bypass opcode: address = 0x00000060 value = 0x000b0836
17:57:635 W: Video Unknown Bypass opcode: address = 0x00000061 value = 0x00001bc0
17:57:635 W: Video Unknown Bypass opcode: address = 0x00000062 value = 0x00000000
17:57:635 W: Video Unknown Bypass opcode: address = 0x00000063 value = 0x00010040

Yeah, I couldn't figure that out. The thing is that it says "W", which, if I
remember correctly, stands for Warning. This may be unrelated.

Sigh, who named those Bypass .. it's BP, we don't know for sure what it stands for :)

Either way, those are probably the bbox setup. Then games read those PE registers to
get the results.

Feel free to delete the warning - shouldn't be hard to find.

i vote for bunny propagation

lol. I'll get rid of that warning.

Issue 975 has been merged into this issue.

why not just add the case for that address? The warning is there to catch any unknown
BPs. YAGD calls them Bypass. If it is not Bypass, then what makes it right that they
are called BPs? Nintendo could call them doggies.

omegadox: labels in the symbol maps game makers so helpfully left on their discs.

Which just about sums up the proprietary docs which are available to the public :p

Issue 1248 has been merged into this issue.

Library function at 0x802B6A08 in Paper Mario 2 (NTSC).

int GXSetBoundingBox(int left, int top, int right, int bottom)¶

left = %r3
top = %r4
bottom = %r6
right = %r5

lwz     %r7, 0x2478(%r13)
lhz     %r0, 0x10(%r7)      # PE_BBOX_LEFT
sth     %r0, 0(left)
lwz     %r3, 0x2478(%r13)
lhz     %r0, 0x14(%r3)     # PE_BBOX_TOP
sth     %r0, 0(top)
lwz     %r3, 0x2478(%r13)
lhz     %r0, 0x12(%r3)     # PE_BBOX_RIGHT
sth     %r0, 0(right)
lwz     %r3, 0x2478(%r13)
lhz     %r0, 0x16(%r3)     # PE_BBOX_BOTTOM
sth     %r0, 0(bottom)
blr

And what about Super Paper Mario?

What about it? It's the same as Paper Mario 2.

No it isn't. ttyd is 3d and has turn-based battles, pmw is 2d and has realtime
battles.

And uses the same engine, library functions, etc.

Note:
BPMEM_UNKNOWN_60, BPMEM_UNKNOWN_61, and BPMEM_UNKNOWN_62 don't seem to trigger when
Mario uses his paper powers or pipes.

And uses the same engine, library functions, etc.

Even across different systems? Wow, I would not have guessed that.

I was wrong about the library functions, but the problem in the Wii version is the
same as the GC version. They do use the same scripting engine though. I could change
Paper Mario 1 to be more like Super Paper Mario (2D-enemy stomping, no "battles"), or
Super Paper Mario to be more like Paper Mario 1 (Enemy Battles, etc) without
modifying a single function in either game. BTW the Wii version uses 3D models.
They're the same format as the models in Paper Mario 2.

I could change Paper Mario 1 to be more like Super Paper Mario (2D-enemy stomping,
no "battles"), or Super Paper Mario to be more like Paper Mario 1 (Enemy Battles,
etc) without modifying a single function in either game.

With a hex editor? Or do you have the source?

This is getting way off topic.
A non-existent script editor, I've only been documenting the script format and
opcodes, created an IDC script to convert the data to C-style code. Even the main
menu is scripted.

I think, we have 2 problems:

1. With Bounding box registers when objects are destoyed
2. Copies of same object and correctly show they in game

Ok, back on topic :)

Have some ideas about this problem somebody?

Nope. There is some code in Dolphin that isn't active, but that code will never work.
BTW that comment I posted a while back should be GXGetBoundingBox. Not Set.

Is this issue related to this or should i post a new issue?

deathknight, that code actually does kind of work, for many situations, although it
seems a bit "off" in some way I haven't figured out yet. It slows things down a tiny
bit, too, and since it's not quite working correctly it didn't seem worth to enable it.
It makes some paper mario effects look a bit better, but not looking right.

@hrydgard: Values of (0, 0, 640, 480) will appear to work because it accomodates all
of Mario and Partner's actions, as well as corrects some scenes, even though these
values are incorrect(The reason why it doesn't work for others). It's been a while
since I tried anything so correct me if I'm wrong.

@Hazad: yes that's the issue

How progress?

Just an idea: you might want to be careful with those 640x480 values when not running
at native resolution...

I was referring to the code that is currently disabled in Dolphin.

perhaps someone could implement the bounding box regs properly in the software renderer
first*? :>

*if they aren't already, haven't checked

I' not sure how relevant this is to the bounding box issue but from the descriptions
and pictures in this thread it seems like this issue was half fixed recently.

I've been playing Paper Mario: The Thousand Year Door (USA) G8ME01 on Win 7 Pro 32bit
and noticed since rev 5034 certain graphics such as a castle appearing on the map now
seem to show correctly rather than be invisible and/or black as seen here:
http://img192.imageshack.us/img192/2420/papermariomap.png

However some graphic errors still persist such as the colored dots on characters as
seen here: http://img192.imageshack.us/img192/7610/papermariocoloreddots.png

Issue 2170 has been merged into this issue.

I don't know if this contributes, but... well, I'll tell you.
When I've used the "Software Render" Plugin, the Punis were visible.
I hope that this contributes to the developers of the emulator.
Keep it up! ;)

LexLight5, what version of Dolphin you use?

2.0 RC1. ;)

Tested now at Dolphin 2.0 RC1 - game unstable and I can't load any save.

What about now?

well, my code is still not working 100% so it's disabled, and noone has made an option to enable it. besides my code only addresses one of the possible uses for the bbox stuff, but it might be enough for paper mario.

@LexLight5: I can confirm that the punies and the toads in the Pirate level, are there using software plugin, but I can't get the toads to jump up into the hole and escape, I think it's the same problem as the Elder Punie in the red cage :(

@hrydgard: Perhaps you could add it as a hack? I know I, and many others would be very appreciative if it helps us get pass these hangs :)

I was just messing around with it and I was holding in R (w) to do the glitch and while doing so, jumped up on a pipe. I let go of R and immediately pressed down to go into the pipe and instead of showing black (or the background) it actually showed him going into the pipe the right way! I suggest you try it yourself!
Does this help?

I would love for this to be added as a hack.

Issue 2899 has been merged into this issue.

Issue 2620 has been merged into this issue.

Issue 3385 has been merged into this issue.

Issue 3011 has been merged into this issue.

Issue 1848 has been merged into this issue.

Issue 3148 has been merged into this issue.

Issue 3737 has been merged into this issue.

Issue 4054 has been merged into this issue.

Is there anything new that is happening with this issue?

Not at all. Really.

Why not add it as a hack so it can be disabled and enabled ?
Even if it's not working properly (Users can then choose to turn it off if they don't like it)

BTW Why does it work with the Software Plugin ?

What are you referring to with "it"? The original issue report or the numerous other issues which are thought to be caused by missing bbox support?

Fwiw, it can already be enabled or disabled if you compile from source. No one bothers enough to make it an option (including myself), but you are free to submit a patch.. ;)

Let's say i would make a patch...
In which file(s) should i look ?

Everything which has BBOX_SUPPORT ifdefs in it, and any code which references the bbox members of PixelEngine (prolly is ifdef'ed out as well though).

FWIW, enabling BBOX_SUPPORT doesn't seem to help on any of the HW enabled renderers in r7190, and I can't find an option to go to SW rendering even if I would want such a thing. Using x64 with VC2010 (and invisible punies)

For folks who want to build with it, there's already a #define statement for BBOX_SUPPORT in VideoCommon.h I am not an expert, but I think just uncommenting that define will trigger the (3-4) #ifdef statements to enable it.

Issue 4278 has been merged into this issue.

I was wondering, does enabling this also solve the colored dots randomly appearing on some textures? Since this makes doing a texture pack nearly impossible. (Can't get to build it for myself, some error about 'AR')

You need to enable Safe Texture Cache to fix that.

Issue 4026 has been merged into this issue.

This is my super noob understanding of C++, but... changing values to 0x80 for bbox left, 0xa0 for bbox right, 0x80 for bbox top, and 0xa0 for bbox bottom in PixelEngine.h and the bbox_enable to true at the case line for each direction in PixelEngine.cpp trigger a "case label has already been used" error and the build failing. Is this the correct way to enable support for Paper Mario?

Constant values are incorrect, and enabling the experimental dynamic values just ends up setting them to 0,0,640,480 so it doesn't really work.

dont know if this is "known" fact for this issue but after disabling EFB copies i get these small boxes to appear for where the punies are supposed to be but above and far left/right of original vertical position. see pic for what i mean. (note: tried the prologue with the X-Nauts and the boxes appear there also but just weaker visually)
pic: http://i56.tinypic.com/wtgndy.png

Wow, this sure is a persistent problem.

I guess no other GC emulator deals with those registers either ?

Are you kidding? There's no other gc emulator even worth mentioning when compared to Dolphin. If I'm not mistaken a lot of the developers of other emulators jumped ship to Dolphin to contribute their knowledge once it became clear that Dolphin was THE emulator.

Hello,

I've been fiddling with bounding box registers for a bit, and I managed to somewhat improve the dynamic value's hack. It's not flawless, but there is some progress.

To see for yourself, uncomment the #define BBOX_SUPPORT and do the following to VertexLoader.cpp, in method UpdateBoundingBox():

• remove the "return;" following the comment "No pixels are likely to be drawn - don't update bounding box."

• In the second line after the comment "should possibly adjust for viewport?", change "240.0f" to "264.0f"

• A few lines below, change "(u16)std::min(480.0f, o[1]);" to "(u16)std::min(528.0f, o[1]);"

Sorry not to add a patch file, but I don't really know how to use Git very well.

Also, from what I can gather, the invisible punies/x-nawts/etc are NOT a bounding box issue, because the bounding box registers don't get called at all.

Here is a screen with bounding box working.

The punies/X-Nauts may still be part of the same issue (as observed a couple years ago?), where changing the values could have positive or negative effects on their display. I don't remember clearly, but they may only be copied "once" at the beginning of the scene. Have you logged each time the call occured?

I have logged every time the bounding box registers get called, so it displays on the console.

Upon starting a new game, the game checks for bounding boxes a few times, but not when X-Nauts appear. Still, I will check further to see if I find something.

Also, the "UpdateBoundingBox" hack is not working for boat flipping animations (such as when going to keehaul key (?) or when you first arrive at rogueport).

The boatflips trigger the bounding box registers to clear, but UpdateBoundingBox is never called. As a result, the values read from the register are bogus (top and left are 1023, bottom and right are 0), and the animation doesn't work.

Manually setting bbox registers to top: 0, left: 0, right: 640, bottom: 528, makes the boat animations work flawlessly.

I don't understand much about dolphin, but perhaps UpdateBoundingBox should be called elsewhere?

I was indeed wrong, punies and x-nauts call the bounding box registers before appearing.

It is odd that they don't work however, because UpdateBoundingBox is called and sets the registers correctly.

Unfortunately I don't understand anything about 3D, much less about 3D emulation, otherwise I would try to find a fix. At least now the game can be playable without those huge-backgroud-filled 2D-graphic-of-mario constantly appearing.

Do any other games use this ?

AFAIK just Paper Mario 2 and Super Paper Mario.

Well, finally I did it, bounding box issues are almost fixed.

Here they are, the missing X-Nauts! (check screen)

After reading a lot, it was a rather simple fix.

Fix:

In UpdateBoundingBox (VertexManager.cpp), change

o[1] = (o[1] + 1.0f) * 240.0f;

to

o[1] = (1.0f - o[1]) * 240.0f;

Enable copy efb to texture and disable display list cache.

Mario's paper moves work, boat flips work correctly, and xnauts appear!

Sorry, it's not copy efb to texture, but copy efb to ram.

Enabling dlist cache causes UpdateBoundingBox to not be called sometimes.

There are still some issues regarding left/right bbox positions, it isn't pixel perfect yet.

Wow, awesome!!! I wonder if the dev team could fix it so that we could have it set to efb to texture and have display list cache enabled with it working right...?

Great work (even if I did not understand everything!) ;)

I think I got it pixel perfect now, and I fixed some hangs.

To use, replace UpdateBoundingBox in VertexLoader.cpp with this one:

void LOADERDECL UpdateBoundingBox()
{
if (!PixelEngine::bbox_active)
return;

// Truly evil hack, reading backwards from the write pointer. If we were writing to write-only
// memory like we might have been with a D3D vertex buffer, this would have been a bad idea.
float *data = (float *)(VertexManager::s_pCurBufferPointer - 12);
// We must transform the just loaded point by the current world and projection matrix - in software.
// Then convert to screen space and update the bounding box.
float p[3] = {data[0], data[1], data[2]};

const float *world_matrix  = (float*)xfmem + MatrixIndexA.PosNormalMtxIdx * 4;
const float *proj_matrix = &g_fProjectionMatrix[0];

float t[3];
t[0] = p[0] * world_matrix[0] + p[1] * world_matrix[1] + p[2] * world_matrix[2] + world_matrix[3];
t[1] = p[0] * world_matrix[4] + p[1] * world_matrix[5] + p[2] * world_matrix[6] + world_matrix[7];
t[2] = p[0] * world_matrix[8] + p[1] * world_matrix[9] + p[2] * world_matrix[10] + world_matrix[11];

float o[3];

o[0] = t[0] * proj_matrix[0]  + t[1] * proj_matrix[1]  + t[2] * proj_matrix[2] + proj_matrix[3];
o[1] = t[0] * proj_matrix[4]  + t[1] * proj_matrix[5]  + t[2] * proj_matrix[6] + proj_matrix[7];
o[2] = t[0] * proj_matrix[12] + t[1] * proj_matrix[13] + t[2] * proj_matrix[14] + proj_matrix[15];


o[0] /= o[2];
o[1] /= o[2];

// should possibly adjust for viewport?
o[0] = (o[0] + 1.0f) * 304.0f;
o[1] = (1.0f - o[1]) * 240.0f;

if (o[0] < PixelEngine::bbox[0]) PixelEngine::bbox[0] = (u16) std::max(0.0f, o[0]);
if (o[0] > PixelEngine::bbox[1]) PixelEngine::bbox[1] = (u16) std::min(608.0f, o[0]);
if (o[1] < PixelEngine::bbox[2]) PixelEngine::bbox[2] = (u16) std::max(0.0f, o[1]);
if (o[1] > PixelEngine::bbox[3]) PixelEngine::bbox[3] = (u16) std::min(480.0f, o[1]);

// Hardware tests bounding boxes in 2x2 blocks => left and top are even, right and bottom are odd
PixelEngine::bbox[0] &= ~1;
if(!(PixelEngine::bbox[1] & 1) && PixelEngine::bbox[1] != 0) PixelEngine::bbox[1]--;
PixelEngine::bbox[2] &= ~1;
if(!(PixelEngine::bbox[3] & 1) && PixelEngine::bbox[3] != 0) PixelEngine::bbox[3]--;

}

Please test for bugs and hangs.

Oh, btw, it seems to work in Super Paper Mario as well. Bowser's troops are now visible.

wow, kudos to you crudelios! we all appreciate your hard work for the good of the community! :)

You sir, are a god.

I have just a quick question. I copy pasted the code to VectorLoader.cpp in VideoCommon and set EFB to RAM and disabled Cache Display List like what you said, and I see no effect, I'm using DX9 and x64, did I do something wrong?

You must uncomment the line

//#define BBOX_SUPPORT

In VideoCommon.h, otherwise bounding boxes are not calculated.

Top/bottom values are still off by a few pixels, it's noticeable when you switch to paper mode using vivian as your partner.

Finally someone fixed my old BBOX code! NICE! I knew it was close to working but never managed to get it just right. A burden has been lifted off my shoulders ;)

You should probably make an INI-enabled option to enable bbox calculations, and set it to True in the paper mario games, as they still seem to be the only games to use the feature.

Oh, and crudelios, I just made you a project committer. have fun :)

Thanks hrydgard! :)

I'll add the ini option and commit the changes then.

Great!

A side note for the future: With OpenGL 4.2 and the new atomics functionality accessible from shaders, it might even be possible to implement this feature fully correctly, taking Z-buffer tests into account (that is, computing a bbox from the actual pixels rendered instead of this geometric method). However I doubt any game will ever depend on that, as it doesn't really seem useful for anything.

Feel free to mark this issue Fixed when you have committed.

I can confirm that with the latest git (wow, times have changed...), it is possible to move past the gate, the x-nauts work, and the ship flips correctly with default settings and a clean compile. High-fives to all the devs for making this work, especially crudelios.

This is fantastic! One of Dolphin's oldest issues, fixed. That pixel-for-pixel option might be necessary though.

Thank you SO much for fixing this!! Everything looks perfect, just like on the console!

I'm still getting the issues listed in this thread. I know this is dredging up an old issue, but is there somewhere I can download a patch or something? Because I can't figure out what is being discussed here to fix it myself.

Ask on the forums instead, this is not a support tracker.