Print

[XPort]

XBoyAdvance - GBA/GBC/GB/SGB/SGB2 Emulator for XBox v20

What's new :
 - Reverted back to 1.7.2 core
 - Implemented relevant portions of VBAsmooth code
 - Delayed auto-load save states to avoid strange slowdown
   Sometimes when the auto-loading of save states happened,
   the GBA emulation would be very very sluggish, like the timing
   is off.  Seems the GBA emulation needs to "warm-up" for a second
   before loading the save state.

Notes
-----

Usually newer cores mean better cores, but this does not seem to be the case
with the last 2 releases.  I haven't seen any information that indicates
any games play better with the 1.8 core, (quite the contrary actually) so
I've backported to 1.7.2.

In the last version, I stated that I wouldn't do this, but I was talking
about 1.7 since that seems to be the fastest one.  This version, however,
now appears to be faster than even version 9 thanks to the vbasmooth additions.

[samsbak]

Wow ...all these fixes !....so good to have you back!

got your mameox running on my cabinet

(IMG:http://myspace-109.vo.llnwd.net/00326/90/11/326761109_l.jpg)

[-x-]

So it runs better now?

[yodanut]

Hmmmm. I'm going to give this a try, but it's worth noting that the whole reason VBASmooth was discontinued is because the core improvements in version 1.8b rendered its existence pretty much pointless.

http://vbasmooth.emulation64.com/

Whenever I mentioned speed I was actually comparing version 18 to version 9 and only on a very limited number of games. Though I never used any release between 10-17 for a very long time (nor with a wide variety of games),  the 1.8 core used in version 18 did seem faster to me than the 1.7.2 releases, and the 1.8 build is undeniably faster on my PC than the builds that preceded it. I actually expected version 18 of XBA to be the fastest one yet. Why it was a bit slower than v9, I don't know. Maybe the unofficial updates to the code made by pockemonhacker but which aren't on the build available at vba.ngemu.com are the source of the slowdown? All I know is that the 1.8 build available available at vba.ngemu.com is, at least on my 900Mhz P3, undeniably the fastest one yet.

This post has been edited by yodanut: Feb 26 2006, 12:18 AM

[yodanut]

Yep, it's just like I thought. The horrible 1.7.2 timing bug that caused unbearable slowdown in Metroid Zero Mission is back. When the bug is not present this build runs well, perhaps even as well as v9, but it's a shame that this particular bug (which is discussed here , affects quite a few games including both Metroids, and was squashed in 1. has to rear its ugly head. I know this is turning out to be a lot of work for something you wanted to be rid of Xport, but perhaps using that final 1.8b3 build of VBASmooth, which I believe lacks the later modifications by pokemonhacker that may also have adversely affected performance, might be a better choice instead.

This post has been edited by yodanut: Feb 26 2006, 01:05 AM

[XPort]

QUOTE(yodanut @ Feb 25 2006, 05:42 PM)

Hmmmm. I'm going to give this a try, but it's worth noting that the whole reason VBASmooth was discontinued is because the core improvements in version 1.8b rendered its existence pretty much pointless.

http://vbasmooth.emulation64.com/

Whenever I mentioned speed I was actually comparing version 18 to version 9 and only on a very limited number of games. Though I never used any release between 10-17 for a very long time (nor with a wide variety of games),  the 1.8 core used in version 18 did seem faster to me than the 1.7.2 releases, and the 1.8 build is undeniably faster on my PC than the builds that preceded it. I actually expected version 18 of XBA to be the fastest one yet. Why it was a bit slower than v9, I don't know. Maybe the unofficial updates to the code made by pockemonhacker but which aren't on the build available at vba.ngemu.com are the source of the slowdown? All I know is that the 1.8 build available available at vba.ngemu.com is, at least on my 900Mhz P3, undeniably the fastest one yet.

I ran some rough tests on my PC using the official Visualboy Advance 1.7.2, 1.8.0b3, the most recent vbasmooth based off of 1.7.2 core, the most recent vbasmooth based off of 1.8.0b3, and on the most recent spacey build based off of 1.7.2.  Metroid was the game I used to test.  When the game loaded up, I simply held down the space bar to throttle it as fast as it could go.  I enabled no filters and was using plain DirectDraw.  The breakdown from fastest to slowest was as follows:

1.7.2vbasmooth, 1.7.2spacey, 1.7.2original, 1.8.0b3vbasmooth, 1.8.0b3original

1.7.2spacey was almost exactly equal to 1.7.2vbasmooth, but was a tad bit slower on the portions I viewed.  

Yodanut - are you using filters during your tests?  That would probably explain the discrepancy.  It seems clear to me that based on the tests I ran on my PC (and also based upon the XBox port), that 1.8.0b3 is significantly slower than 1.7.2.

[Potman]

nice, thanks a ton, now i  can move from version 9 to this version.

[digital71]

Kick ass (IMG:style_emoticons/default/biggrin.gif) !

[Diontae18]

Thanks heaps for the update with the optimizations

[yodanut]

QUOTE(XPort @ Feb 25 2006, 08:38 PM)

I ran some rough tests on my PC using the official Visualboy Advance 1.7.2, 1.8.0b3, the most recent vbasmooth based off of 1.7.2 core, the most recent vbasmooth based off of 1.8.0b3, and on the most recent spacey build based off of 1.7.2.  Metroid was the game I used to test.  When the game loaded up, I simply held down the space bar to throttle it as fast as it could go.  I enabled no filters and was using plain DirectDraw.  The breakdown from fastest to slowest was as follows:

1.7.2vbasmooth, 1.7.2spacey, 1.7.2original, 1.8.0b3vbasmooth, 1.8.0b3original

1.7.2spacey was almost exactly equal to 1.7.2vbasmooth, but was a tad bit slower on the portions I viewed.  

Yodanut - are you using filters during your tests?  That would probably explain the discrepancy.  It seems clear to me that based on the tests I ran on my PC (and also based upon the XBox port), that 1.8.0b3 is significantly slower than 1.7.2.

Actually Xport, the slowdown doesn't occur all the time, only in certain (frequent) portions of the game.  Encountering it for the first time in Metroid Zero Mission requires about 5-10 minutes of playtime: it's plainly noticeable when you reach the first brown vertical area in the game, in case you or anyone else wants to see what I'm referring to. Before then the game would run normally. According to the thread I linked to in my original post, other games, such as Duke Nukem Advance and Doom GBA, suffer from this issue as well, though I haven't tested any of them myself. I have no idea why it occurs, but it's definitely a bug in 1.7.2 and not related to the system's performance, since the emulator (including music) continues to run at 100%. It's only the gameplay that slows down.  

I haven't performed the same tests you have, Xport, and perhaps the general relative performance of the emus does progress as you say under those conditions. All I've tested are the Metroid games during gameplay with no filters (i.e. Normal mode on PC, plain DirectDraw) and a frameskip of 2, and under those conditions 1.8.0b3 original stays full speed almost throughout the entirety of gameplay, even more consistently than 1.7.1 and certainly more so than 1.7.2. But perhaps this is only true only within certain games and scenarios and not overall. That kinda sucks for Metroid fans, but hey, what can you do? The interest and effort are appreciated anyway.

This post has been edited by yodanut: Feb 26 2006, 06:30 AM

[BanjoK]

Thanks for the new release XPort.

[GLiTcH]

QUOTE(samsbak @ Feb 25 2006, 03:18 PM)

Wow ...all these fixes !....so good to have you back!

got your mameox running on my cabinet

OMG.. werent you banned..


thanks for the emu

[Hitmanx5]

Hey thanks again! Love your work!

[XPort]

QUOTE(yodanut @ Feb 25 2006, 11:51 PM)

Actually Xport, the slowdown doesn't occur all the time, only in certain (frequent) portions of the game.  Encountering it for the first time in Metroid Zero Mission requires about 5-10 minutes of playtime: it's plainly noticeable when you reach the first brown vertical area in the game, in case you or anyone else wants to see what I'm referring to. Before then the game would run normally. According to the thread I linked to in my original post, other games, such as Duke Nukem Advance and Doom GBA, suffer from this issue as well, though I haven't tested any of them myself. I have no idea why it occurs, but it's definitely a bug in 1.7.2 and not related to the system's performance, since the emulator (including music) continues to run at 100%. It's only the gameplay that slows down.  

I haven't performed the same tests you have, Xport, and perhaps the general relative performance of the emus does progress as you say under those conditions. All I've tested are the Metroid games during gameplay with no filters (i.e. Normal mode on PC, plain DirectDraw) and a frameskip of 2, and under those conditions 1.8.0b3 original stays full speed almost throughout the entirety of gameplay, even more consistently than 1.7.1 and certainly more so than 1.7.2. But perhaps this is only true only within certain games and scenarios and not overall. That kinda sucks for Metroid fans, but hey, what can you do? The interest and effort are appreciated anyway.

I don't believe I've experienced this slowdown of which you speak, but given the chatter on forums about it, I'll take it as a given that the problem exists.  It really doesn't matter.  If you were to load up Metroid in 1.7.2, get to the part with the slowdown, press the spacebar to throttle it, then do the same thing with 1.8, I'm sure you'll see that 1.8's max speed does not come close to 1.7.2.  I understand that it's a timing issue and not related directly to how fast instructions are being carried out on the GBA emulation - but my point is that 1.8 makes *everything* slower.  It may fix the problem with the timing, but that problem is hardly what I'd call pervasive.  I can't claim to have played a lot of GBA games on XBoyAdvance, but my kids have and they can't recall ever coming across this problem.  Furthermore, for the games that it does affect, it doesn't even affect most of the game - just portions.  

Regardless, for the people who are really bothered by this, there is v19 for you.  Someone will have to perform a lot more tweaking on the 1.8 core for it to be as fast as 1.7.2.  As of right now, you can't have it both ways.

[tetsuo55]

Thanks for this best of both worlds solution!


This post has been edited by tetsuo55: Feb 26 2006, 10:30 AM