Menu
▾
▴
#1134 American Girl Julie Finds a Way (U) - 3D background missing
Tested on SVN4081 with Softrasterizer and Advanced Bus Timing ON and OFF. When you go ingame the 3d environment like the buildings are invisible but if you slightly turn left by 90° all the missing graphic appear. See the picture for more details.
Little note about this game: there is another game called American Girl Kit Mystery Challenge (U) that is developed by the same company and i think it uses the same engine for the 3d environment but here there is no such bug.
Discussion
Anonymous
Missing 3d environment
fixed in r5043 - needed emulation of system jamming when writing 3d commands during pending flush state.
Yeah, but you guys reverted the changes in r5056. Are there any plans for a better workaround, or do I really have to settle for an old revision just to play these two games?
Confirmed!
there are no plans for a better workaround. im sure it will get fixed one day accidentally.
Well, that's quite a drag. Though you seem to have exaggerated as you said in your commit in that "it broke over 8000 games" etc.
That being said the implementation you did for Kit and Julie was a partial hack if I'm not mistaken, and for the time being players might as well have to make do with revisions prior to 5056.
well, i'm pretty sure it broke over 80 games at least.
The current code is a hack, the attempted revisions for american girls were a hack. The true behaviour isnt understood. The attempted revisions were worse hacks, it turns out.
So it seems. Even if we enable this on a per-game basis it would still go against the notion of making the emulator accurate.
Still present on SVN5370 on both renderer. If you move your character the background is rendered correctly.
Can workaround by making box test always pass. So at a gross level, the missing geometry is caused by the game discardnig it due to failing box tests. Still need to find out why box test is inaccurate.
Based on earlier confusion, it would maybe be due to timing. The game dues use the FIFO to send these box test commands.. it should then be waiting for the fifo to be complete before drawing anything else. Don't see how that would malfunction. Maybe it wasnt supposed to be getting stuck in the fifo for any time at all (and the game isnt waiting for fifo to finish)? That would explain why 'jamming' fixed it (game software couldnt proceed for a long time, after which point the fifo would have definitely finished)
Last edit: zeromus 2016-08-13
Alright, I fixed this in r5530. There's a great deal of sense to this fix (box test is busy as soon as a box test command enters the fifo), but still nobody is sure overall how the fifo works. It's kind of incredible that the fifo sets these busy flags according to what enters it; but they would not really be useful if everything was happening immediately.
As I've suspected for a while, it isn't meant to be a dumb frontend to the geometry engine that keeps it fed with data, but an actual smart component that monitors what comes into it and updates its state accordingly, before it even buffers anything.
I really feel like what american girl is doing is genuinely what the geometry engine is meant for: send it a slab of commands (matrices and box tests) and then wait for it to finish processing the whole lot.
The transform busy flag can be viewed similarly--really, it's for reading back the transformed matrix. You want to spew a bunch of matrix commands into the fifo and then wait for them to finish.
But if you're viewing the fifo this way, why not use the empty flag as a "!busy" flag? Well.. it would need to incorporate the status of the box test into a composite "busy" flag in order to be faithful. So really I wonder why there isn't a fifo busy flag, which is basically the same thing, to me, as a 'geometry engine busy' and would incorporate the box test busy flag.
WELL. There is such a flag. We need to test if it behaves this way.
"I really feel like what american girl is doing is genuinely what the geometry engine is meant for..."
American Girl? You mean Webfoot? Well, since they're the ones who did the dirty work for THQ on behalf of AG.
No, I mean the game, american girl. Maybe webfoot programmed it or maybe julie's got tattoos and started hacking.
Alright lol. Too bad the buildbot ain't doing any new builds lately, but I could just get away with the sources anyway. :D
rogerman posts new builds on desmume.org downloads page occasionally, check there. hopefully youll get your sick julie fix on pretty soon.
Alright, and nah, I already beat Kit's anyway, and I'm not that of a 70s fan so meh on Julie.
But on the game's internals, was it just a proof of the games being poorly coded? And what exactly is a box test anyway? Is it some sort of bounds or something like that?
Last edit: Huck Jones 2016-08-14
No, like I said, it's a perfectly sensible thing it did and I'm surprised more games don't do it and we didn't have to fix it sooner
The box test determines whether an object is visible to the camera. You skip drawing invisible objects after finding out they're invisible. its kind of a low budget technique, because a more sophisticated game engine will have its own systems for visibility checking, and it impairs gpu and CPU parallelizing, but its a neat HW feature.
My sister was always on team felicity.
Kinda' quirky if you ask me, as I haven't heard of that occlusion culling technique before besides BSP, the raycasting technique in Wolf3D, and the like. But that's the way Nintendo pulled it off anyway with that oddball GPU of theirs. I assume there's an invisible box around the player, and anything not covered by the visible regions of the box are discarded, am I right?
And they retired Felicity some five years ago. :(
Last edit: Huck Jones 2016-08-14
"frustum culling"
She's like 300 years old now, I guess that's a pretty good run.
251 years old, if you're referring to Felicity, as she was born in 1765, or at least that's what AG said. So yeah, she had a pretty good run. :p
And it made sense considering the rather constrained limits, but there's conflicting information about it as while Wikipedia claims the DS can do 2048 tris per frame, most others state the DS can do a maximum of 120k.
2048 triangles per frame * 60 ~= 120k triangles per second
Fixed on SVN5531