yea unless you like hitting square every 2 seconds due to the popup -_- not to be mean and I appreciate what Wally is doing, but I would rather play R13 official than this...I mean I'd even rather play R10.
(I bet wally plays the CPM4 version lol.)
I don't play the CPM4 version, infact it is my version (earlier build) with pretty colours over the top.... Not everyone knows that. Evidently he can't justify where he got the source so there's your proof.
I do agree though, i'd much prefer R12 though as everything works and yeah.
Wally
Sorry i don't have time to read all 12 pages, quick question , are there new games playable with this version ? Even without sound ..
without sound i would say mario 64 and mario kart 64. with sound there is no game to play yet. hopefully R14 will have like 50 % speedup to get at least some games playable.
Wally, please continue to try to keep daedalus alive. I mean ok fine your version is buggy.. So what? It's your first shot at it. Please stop fighting over stupid things ( EX: I gave you the source! REPLY: NO YOU DIDN'T. REPLY: YES I DID.... and it goes on. Please just can you try to focus on improving daedalus since strmn hasn't updated us in over 6 months?
Any chance of getting a little, even if slow, bit of No Mercy support in R15? All that I get is sound with no picture on the several R12 - R14 releases.
It might be a very easy thing to do since we already have the sound code of that game implanted.
Sorry for the bump, but is is related to the topic.
Myself and shiny are working with the R14 code Wally released here. The new build will be called DaedalusX64 (Not my name don't blame me.) It started strong, then got delayed, because shiny got busy and I never coded for PSP(My C++ experience is strictly Windoze). I have since I started gotten R13 to compile in original from (although with minor IDE related problems.). Right now my progress = 0% I'm currently trying to get R14 compiled and the work on the ME support and supporting more microcodes (Read: Same speed as R13 with sound and more playable games.) I will likely run into the same problems StrmnNrm posted about on his blog. When and if I make any improvements, I will release the source along with the binary.
Two things the emu scene has been lacking ever since UltraHLE, transparency (AKA... open source) and interest in the technical side of emulation.(I also plan to comment my changes to the source and keep a development blog.)
Any questions? I can be reached at DaedalusX64.com as can Captain Morgan 4 and Wally.
I am dedicated to this project because of my love for the N64 and it's technical accomplishments. It and the PSX helped pave the way for the modern generation of 3D gaming and what we as gamers expect out of a console gaming system.
I can assure you that StrmnNrmn is doing better things, and its a good cause.. I can't exactly say what he's doing because it'd reveal who he really is.
Kreationz you can download the R14 source here. (compatible with the latest toolchain)
Few things to note:
R14 has assert error popups everywhere (they can be disabled, I have done it but I can't remember how)
To compile daedalus successfully you must compile the MediaEnginePrx first or have an MediaEngine.prx file allocated somewhere.
Chilly Willy is probably one of the best sources to speak to about this sort of stuff (He'll be onto this topic in a flash I reckon.) I'm trying to help him get it all up to scratch so he can have a crack at it too.. (see ps2dev forums, General Discussion, Nintendo 64 emu PSP)
PM me if you need someone to test :D
Wally
Wally and I are looking into the issue with case errors for folks using linux/bsd to compile Daedalus.
If you look in deadlib/include/DaedLibBuildOptions.h, you'll findQuote:
Few things to note:
R14 has assert error popups everywhere (they can be disabled, I have done it but I can't remember how)
That triggers all the damn asserts you see in the latest builds of Daedalus. Apparently, _DEBUG is being set, and the way that is set is in the main makefileCode:#ifdef _DEBUG
#define DAEDLIB_ENABLE_ASSERTS
#endif
Apparently, the DEBUG_CFLAGS are being used, or _DEBUG is getting defined some other way. You can kill the asserts by killing the check in the DaedLibBuildOptions.h file.Code:DEBUG_CFLAGS = -g -O3 -G0 -Wall -DDAEDALUS_PSP -D_DEBUG
RELEASE_CFLAGS = -O3 -G0 -Wall -DDAEDALUS_PSP
PUBLIC_RELEASE_CFLAGS = $(RELEASE_CFLAGS) -DDAEDALUS_PUBLIC_RELEASE
There IS one bug in this version that needs to be fixed. It's on ps2dev in the thread where I introduced this lib. The fix is to change thisQuote:
To compile daedalus successfully you must compile the MediaEnginePrx first or have an MediaEngine.prx file allocated somewhere.
to thisCode:void dcache_wbinv_all()
{
int i;
for(i = 0; i < 8192; i += 64)
__builtin_allegrex_cache(0x14, i);
}
in the main.c file for the prx. The cache is two-way set associative, so you either need to do the loop 16384 times, or do the cache command twice.Code:void dcache_wbinv_all()
{
int i;
for(i = 0; i < 8192; i += 64)
__builtin_allegrex_cache(0x14, i);
__builtin_allegrex_cache(0x14, i);
}
Yeah, yeah. Hopefully we can get something into a suitable form here in the next week.Quote:
Chilly Willy is probably one of the best sources to speak to about this sort of stuff (He'll be onto this topic in a flash I reckon.) I'm trying to help him get it all up to scratch so he can have a crack at it too.. (see ps2dev forums, General Discussion, Nintendo 64 emu PSP)
PM me if you need someone to test :D
Wally
By the way, if a moderator see this post, pass along a message to whoever maintains the forum to fix the damn code tag support!!!!! :mad:
JLF65; Good to see you actually are working on this.
Kreationz; Being open about development is good, but StrmnNrmn has just about always been. He's just not working on it now or possibly anymore. I don't want to discourage you from working on this, but you guys might want to wait until you have something done before you start promoting what you're doing so much. I say this both for your sakes and for everyone else's.