Hacking DaedalusX64 has been updated

  • Thread starter Thread starter TheMrIron2
  • Start date Start date
  • Views Views 58,709
  • Replies Replies 74
  • Likes Likes 16
-03 breaks stuff randomly. I recall once SnemulDS breaking in-game logic such as missing walls/collition detection in some platformers.

Just saying
 
they may both be emulators but that doesn't mean anything. snemulds is for ds, this is for psp. snemulds emulates the snes, this emulates the n64. they both work completely differently.
 
they may both be emulators but that doesn't mean anything. snemulds is for ds, this is for psp. snemulds emulates the snes, this emulates the n64. they both work completely differently.
that´s totally incorrect.

Emulating the CPU and other parts will break depending in how these parts are assembled, and if optimizations take place. Add that the N64 processor has more vector like opcodes, besides the usual processor opcodes. If those are written in C or higher, using -03 will cause some issue or bug that is harder to detect than -O2

I am basing this from research, so I know what it means. It means if an opcode the emulator relies on unrolls a loop, then the emulated parts might behave incorrectly and lead to weird bugs such as not working with other emulated hardware parts or not emulating input timeouts or the likes.

At that level, I would safely say, building an emulator at -O3 without doing side by side testcases will break functionality and that will end up in bugs.

It does not matter if a SNES and a N64 work different, the emulators behave all the same (for high level and low level ones) and I know -O3 will give you a nasty bug that will take some time to find out.
 
Last edited by Coto,
you still haven't answered my question though. I can't for the life of me find what the heck an O3 is. Google says it's ozone.
 
I am answering your months or years ago next-to-have questions, for such simple things a google search will do.
 
well yeah of course I already tried google. O3 can stand for more things than you'd think. I think I found it though so nevermind.
 
1.1.4 has been released.

Will get it installed (on Vita) later and have a play :-)

--------------------- MERGED ---------------------------

Changelog from Github page for those that are interested:



This is a stable release and compilation over all of our work up until now.
Changes:
*improved stability and performance
*minor changes to the dynarec
*updated some UI aspects to remove graphical bugs

-Notes
*If using a ps vita please delete the MediaEngine.prx form the DaedalusX64 folder. This will prevent issues when running audio in async mode. The vita does not have and does not emulation the psps co processor.
*Preview images have been removed from the binary file since it is to large to for github. If you would like them please down load them from this repo and place them in \DaedalusX64\Resources\Preview.

-Plans:
*Improve dynarec further
*Correct exiting to XMB
*Update the VFPU code to match that of the current PSPSDK
*Complete vita detection so the mediaengine prx is not loaded when in use on a vita​
 
that´s totally incorrect.

Emulating the CPU and other parts will break depending in how these parts are assembled, and if optimizations take place. Add that the N64 processor has more vector like opcodes, besides the usual processor opcodes. If those are written in C or higher, using -03 will cause some issue or bug that is harder to detect than -O2

I am basing this from research, so I know what it means. It means if an opcode the emulator relies on unrolls a loop, then the emulated parts might behave incorrectly and lead to weird bugs such as not working with other emulated hardware parts or not emulating input timeouts or the likes.

At that level, I would safely say, building an emulator at -O3 without doing side by side testcases will break functionality and that will end up in bugs.

It does not matter if a SNES and a N64 work different, the emulators behave all the same (for high level and low level ones) and I know -O3 will give you a nasty bug that will take some time to find out.

Yes, O3 is unstable (the compiler flag, @poudlink) - but it doesn't cause any major issues apart from bad exiting so we've kept it in. If we ever get to comfortable full speed in most titles (maybe if we looked at static recompilation) then we could change O3 back to O2 - but right now, the little speedup it gives us is important and the trade-off isn't significant so we're sticking with it.
 
  • Like
Reactions: cvskid
Great news! Ocarina of Time is now largely full speed with sound! Here's a picture of Ocarina of Time (ripped from the GameCube collection) running on a PSP 1000 with sound on. As the framerate counter shows, it's full speed! Average framerate is just short of full speed (19FPS?) but it's very playable and very close already. DaedalusX64 1.1.8 is looking good! You can get it here and try it for yourself.

blPGNCC.jpg
 
Great news! Ocarina of Time is now largely full speed with sound! Here's a picture of Ocarina of Time (ripped from the GameCube collection) running on a PSP 1000 with sound on. As the framerate counter shows, it's full speed! Average framerate is just short of full speed (19FPS?) but it's very playable and very close already. DaedalusX64 1.1.8 is looking good! You can get it here and try it for yourself.

blPGNCC.jpg

Hello.:)

Thank you.
The Game runs good on the PSP 1004.:yay:
(unfortunately the Cutscenes not so).
The Sound is a little bit "crackling".

Good work.
Thank you for Sharing ! :)
 

Site & Scene News

Popular threads in this forum