Here it is: Mupen64Plus v1.3!

[nmn]

Oops, that was my fault. I just committed a fix to svn.

Ahh, I didn't think about that. Well, nice that its fixed now, because I have a feeling that explains why my resampling changes aren't working XD (Just have to revert a little I'm guessing and everything should go fine.)

Speaking of which I'll be working on a JttL Audio GUI, but also, Mupen64Plus for Windows. I haven't mentioned this often enough I guess, But yes, I am working on it, My main issue is creating a reliable MinGW with GCC 4. Right now It's having an issue with compiling binutils because it complains about makeinfo (but WTF?! Its installed, along with bison and friends...)

 

[vision]

I'm running Mupen64plus on AMD64 X2 in Arch Linux. It works great! You guys are the best, I remember a while back trying to run the original Mupen64, and it wasn't pretty. Really great job guys.

Now, I'm getting a little spoiled and I'm trying to load the hires texture pack for OOT in Mupen.. it actually loads and the title screen starts but then locks up as the moon starts to lower, right before Link and Epona come into view.. any ideas? Should I pull from SVN instead?

PS: Here's the halt output.

Non-integral hi-res texture scale. Orig = (32,32) Hi-res = (64,128)
*** glibc detected *** mupen64plus: malloc(): memory corruption: 0x00002aaabbb71820 ***
======= Backtrace: =========
/lib/libc.so.6[0x2b42a68f8808]
/lib/libc.so.6[0x2b42a68fb03c]
/lib/libc.so.6(__libc_calloc+0x108)[0x2b42a68fc648]
/usr/lib/libGLcore.so.1[0x2b42a706b548]
======= Memory map: ========
00400000-00493000 r-xp 00000000 08:13 5447765 /usr/bin/mupen64plus
00692000-00696000 rwxp 00092000 08:13 5447765 /usr/bin/mupen64plus
00696000-02da9000 rwxp 00696000 00:00 0 [heap]
40002000-40004000 rwxp 00000000 00:0d 1593 /dev/zero
40004000-40005000 ---p 40004000 00:00 0
40005000-40805000 rwxp 40005000 00:00 0
40805000-4088a000 rwxp 00000000 00:0d 1593 /dev/zero
4088a000-4088b000 ---p 4088a000 00:00 0
4088b000-4108b000 rwxp 4088b000 00:00 0
4108b000-4108c000 ---p 4108b000 00:00 0
4108c000-4188c000 rwxp 4108c000 00:00 0

 

[Tillin9]

If your pack is using 32-bit PNGs, using svn as opposed to 1.3 will help.

However, this begs the question what video driver and texture pack? I have Kman/Federelli's for OOT, and using the open source radeo r300 driver it seems to work fine for me with 1.3 or the latest svn. I have to manually set Rice to use OpenGL 1.3 (as my driver doesn't support anything better) in the svn build likely because of the OpenGL 1.4 combiner changes.

Might also be this issue: http://www.emutalk.net/showthread.php?t=43906

 

[Richard42]

]Non-integral hi-res texture scale. Orig = (32,32) Hi-res = (64,128)

That's the problem. Rice does not currently allow using textures which are not integral multiples of the original resolution. I can remove this check quickly if you can pull from SVN and test it and let us know how it works.

 

[vision]

I can remove this check quickly if you can pull from SVN and test it and let us know how it works.

If you could do this, I will gladly test it. Just let me know and I'll pull an SVN copy.

However, this begs the question what video driver and texture pack?

I use the one from DGEmu.. I can't remember what it's called. The link is here.

http://www.dgemu.com/forums/index.php?showtopic=327734

Though it seems to be down for the moment. Hmm. I'm also using Rice's plugin.

EDIT: My bad, it appears that pack is also located on EmuTalk. Sorry guys, I'm new here. http://www.emutalk.net/showthread.php?t=34361

 

[Richard42]

If you could do this, I will gladly test it. Just let me know and I'll pull an SVN copy.

I just committed a tentative fix in rev 185. It still prints a warning but I added the necessary calculations to correctly load an unevenly scaled texture. Let me know how it works.

 

[vision]

I've checked out 185 and am testing now. Earlier I was playing around in Project64 on XP and loaded both the cel-shaded pack and the high-res pack to make sure they work okay; confirmed. I'll post back here with test results.

 

[vision]

Alright, so that worked. As you mentioned, instead of simply crashing, Mupen printed a warning to console every time a non-integral scale was performed. Overall though, it really didn't look too bad. I would say that the hi-res pack looks almost identical to PJ64 on Windows, save for a couple of very minor glitches that you'll see below.

The cel-shaded pack suffered slightly. I think that this might be related to the bizarre folder names it uses, some have french accents on the letters and I don't believe they conform to Linux/UTF-8 standards.. i.e. when you unpack the cel-shaded .RAR in Linux, Nautilus shows the directories like this:

So maybe that explains something. Or, I could just be an idiot.

Keep in mind that the HiRes pack by Federelli is only listed as being 21% complete. I don't have the Kman pack. I wish I did. The cel-shaded pack, by Djipi, is listed as being 100% complete. Also keep in mind that both of these packs look near-perfect on XP with PJ64 - at least in the 20 minutes I spent, nothing jumped out at me.

Anyway. Here are the shots from the cel-shaded pack and the hi-res pack, respectively.

Cel-shaded

Hi-res

So as you can see there are a few issues.. but.. at least it loads.

Btw Richard, I'm keeping this SVN commit, you can't have it back

Also.. sorry for the weird size differences.. gotta love photobucket I guess :S

 

[vision]

UPDATE: Having played through the game a bit more, I really haven't spotted any other problems in the cel-shaded pack. Mostly just the black half of Link's Kokiri outfit and some menu issues. It looks and runs great.

 

[Richard42]

Btw Richard, I'm keeping this SVN commit, you can't have it back

You're welcome; keep it. Of course it will also be in the next release as well. We're going to have some nice new features.

Do you mind if we post some of these screenshots in our gallery on the google code site?

 

[vision]

Sure. Check your PM for some more.

 

[Richard42]

Namco Museum, which was unusable for like, forever until Glide64 v12 got it going, does not start with Glide64 or RiceVideo on Mupen64plus, but works fine with mupen64-0.5 and the Glide64 v12 plugin. On Plus, it only offers a black screen.
....
The DrMario64 pills that can be seen with mupen64-0.5 and the Glide64-v12 plugin cannot be seen dropping with mupen64plus and the Glide64 plugin. Since it's never worked with glN64 I haven't tried that or Rice yet with it.

I tried DrMario with a 32-bit build of Mupen64Plus from SVN and the 32-bit Glide64-v12 plugin. I couldn't see the pills drop with this combination, so I don't know what could be wrong.

I found the problem with Namco Museum - it hangs when the NoAudioDelay is set to true in mupen64plus.conf. If you set it to false, it will work. I'm going to fix this shortly.

 

[Eck]

Nice! It's always good to hear of the fixes coming. That Dr. Mario pill dropping without seeing the pills was a long standing issue until Glide64-wonder++-v12. I think I remember it's the same with Project64 and their official plugins. Still works on the mupen64-0.5 with that plugin, but not on Plus with its Glide64, which I haven't tinkered with besides setting the resolution and trying that read frame buffer thing that doesn't appear to do anything.

Namco Museum also is tricky. It used to instantly crash like now (mupen64 or Project64), but then with new versions of Glide64 it started to work but would not show all the visual in the game so couldn't be played, and then worked fully with Glide64-wonder++-v12 on the mupen64-0.5. It'll be interesting to see if it's playable once that audio setting is made and the game starts.

 

[okaygo]

6 Pages... wow

 

[vision]

6 Pages... wow

You have no idea how happy some of us are to have playable N64 emulation on our 64-bit Linux boxes..

 

[olivieryuyu]

Very good version:

Well as i don't see any new version of Mupen coming soon, i have 2 requests:

1) support of PJ64 savestate
2) possibility to disable the memory expansion

 

[ebenblues]

1) support of PJ64 savestate

You can use our issue tracker to make these kinds of requests. I added an issue for PJ64 statesave support:

http://code.google.com/p/mupen64plus/issues/detail?id=52

 

[okaygo]

Guys the latest SVN has a lot of bug fixes, so people who are still interested in this project (and DEVELOPERS) can come check out our home page, try out the latest SVN and continue to report bugs. Also join the google groups.

 

[T3mporal]

Hi, everyone who is developing this new Mupen! I think that if I say my feelings about, you can, maybe, have any insight... don't know... well, here i go:

1->With Mupen64, every time I ask for pausing (from the pause button on its interface), the program freezes. With Mupen64plus this is fixed!

but...

(WITHOUT COMPIZ AND NVIDIA DRIVERS WORKING):
2->With Mupen64, the first 10 minutes sounds really "heavy" for Xorg, that keeps loading up to 100% every X seconds, BUT, after these 10 minutes, Xorg comes back to load at normal rate (something about 30%~40% ALL the time) and Mupen64 with 45%~55%.
BUT, with Mupen64plus Xorg keeps loading 100% of the processor every 5~6 seconds all the time, no matter how many time I let the program running.

I use ubuntu 7.10, running on:
Asus A7V400-MX;
AMD Sempron 2300;
1GB ram;
NVIDIA GeForce 4000 MX (With proprietary drivers - I mean thats the latest stable one for my Video Card);

I hope this helps!

And sorry my english, I'm not a native speaker.

 

[ebenblues]

Guys the latest SVN has a lot of bug fixes, so people who are still interested in this project (and DEVELOPERS) can come check out our home page, try out the latest SVN and continue to report bugs. Also join the google groups.

Yeah, I wouldn't be surprised to see a 1.4 release candidate in the next week or two...