Closed Frank-74 closed 6 years ago
Only if somebody will decode that microcode.
Same applies fro the factor 5 games like rogue squadron.
Maybe microcode for, Battle for Naboo, Rogue Squadron, Indiana Jones will be quite similar if not the same. Indiana Jones is quite a good adventure when you get into it. Even with the odd bugs.
I looked at Rogue Squadron implementation in Lemmy plugin. Very specific and unique thingy.
@Frank-74 Can you rename this ticket Indiana Jones/Battle of Naboo microcode Implementation please?
For your information, I started some prelimilary work on those games. They are significant different than SWRG but Indy and Battle of Naboo are quite the same (some differences exists).
For the time being, I am hopeful it can be done with a lot of efforts.
I'd like to help here, but except for the n64 Manuals (http://ultra64.ca/resouorces/documentation/) i have no infos what to do. How can i dump ucode? Nemu doesn't help here...
This ucode is really complex. For those interested, there is an old article about the game here:
http://www.ign.com/articles/2000/11/10/bringing-indy-to-n64
A good part of the ucode was rewritten but it was not totally "rewritten from scratch".
Few features in this ucode are very unique. Interesting but challenging.
I dumped some ucode from battle for naboo/indy and compared it with rogue squadron. One part was the same for all, and one is the same like in BfN and Indy. RSP code indy.txt RSP code indy2.txt RSP codebfn2.txt RSP codebfn11.txt RSP coders1.txt
@olivieryuyu Can you provide any useful information on how i can help with decoding? How to start out?
@StenApp
I already deciphered a big portion of the microcode.
Thanks for proposal though!
@olivieryuyu sounds great, thank you. Can you give a short status? Blog entry maybe?
Update will be shared where possible. Stay tuned.
@olivieryuyu, i would love to read a bit more about your adventures with reverse engineering. I understand as far as dumping the microcode and translating MIPS assembly to x86 or C, but im sure you've learned some tricks to identify certain patterns. Would be cool to see a video or guide that tells someone what they need to get the job done
a really crazy ucode...
Do you believe that the menu are simple sprites (texture rectangles)???
Nope!!! They are triangles!!!!!!
Screenshot from Angrylion plugin
I assume that was in order to achieve the "flipping page" transitions without resorting to framebuffer tricks.
We started new crowdfunding campaign for Indi and Naboo on Idiegogo:
Visit it to see what is already done and what is planned to be done when the campaign will reach the goal. Any kind of support is welcome.
Supported of course! Like to see "unknown ucode" message vanished.
How about to post a reddit entry? I'm to new there so my post got deleted.
I have no reddit.
The campaing does not seem to be successful, that is a bit unfortunate...
It is a hard work to do the reverse engineering and the microcode of Factor 5 are really huge and complex compared to the others.
For instance Indiana Jones/Battle of Naboo is double the size of F3DEX2, which was the biggest Nintendo microcode.
@StenApp
It probably got deleted because there's already one for the campaign: https://www.reddit.com/r/emulation/comments/7ogzuc/gliden64_indiana_jones_and_the_infernal_machine/?utm_source=amp&utm_medium=comment_header
@oddMLan I think it was my first post on reddit, I would have needed to post or comment things before.
@olivieryuyu I'm not sure why so less people support your decoding, maybe many think they get it anyway or they don't care, because of the age of N64. It's sad because Factor5 games are the last games to get native. I'd like to see in the end of decoding how you did that in form of technical blog or documentation. None the less: respect for your work.
I am sure there are others that will donate more before the campaign is over. And the campaign is very modest, it will be filled.
Although, yes, i do think this should drive more attention.
It might be useful to make sure that people realize that the dev is not Gonetz, who has a running patreon for GLideN64.
It is a campaing of both Sergey and me, the work on the HLE project being done together.
After Indy, there is still many things in HLE to do:
Batte of Naboo specific commands HVQ microcode (if really need) Fog issue in Zelda OOT S2DEX issues in various games Dark Rift issues
Of course this campain for Indy would be the last one for supporting HLE reverse engineering in GlideN64. But seeing the little attention it brings, it is a bit demotivating :(
@olivieryuyu what is your input for the 64DD games? Certainly those will need some work, too. Campaign is funded so get it done please! :)
mhhh one spend anonymously the rest to fill the 600 Dollar, it's the second time one did.
@weinerschnitzel. Thanks! 64DD games uses standard ucodes, I already checked out.
@StenApp : at the end of my HLE adventures (many months), I will do a small introduction on how I do the reverse engineering. Yet the first step is to understand MIPS (https://chortle.ccsu.edu/AssemblyTutorial/index.html)
@olivieryuyu
When I look at my dumps of Indy and BFN I see what you mean with double the size as SDEX2 code.
One started with 0x000 J 0x064
and one with 0x000 ORI V1, R0, 0x0000
.
Your dumps are only partial ones, they do not cover the entire ucode. It is due to the usage of overlays as the code does not fit entirely in the IMEM. I will explain this in the introduction when my adventures are over.
Small remark:
One of the command uses a specific COP0 register to simulate a random value for the particule systems.
No RSP plugin emulates this, so LLE implementation does not behave exactly as it should.
In HLE it is possible to circumvent this issue and therefore being more close to result on a real N64.
So for once HLE is better than LLE :)
I’m simply amazed at how much knowledge and abilities you have gained in only a couple of years. Appreciate your hard work @olivieryuyu
last call for supporting of the Indiegogo campaign, time's running up:
Few screenshots of the particle effects system in the HLE version.
Bug reports are now welcome for Indiana Jones from backers.
two bugs so far:
Impressive work
These working with pj64 or mupen only?
it works with PJ64 and Mupenplus indeed.
The other emus may boot the game but they will have various graphic bugs.
One of the command uses a specific COP0 register to simulate a random value for the particule systems.
Which register?
Can anyone upload a ucode dump for this particular command? I don't really know much about the game so a dump would be convenient :smile:
MFC0 V0, DP clock counter
DP clock counter is not emulated any RSP plugin I would think.
Thanks! I figured it was the clock counter :smile: . So far, I've only seen that get used in Pokemon Stadium 2 GB Tower iirc. Of course my microcode collection is nowhere near complete though.
I guess I'll have to try dumping more of indiana jone's code, so I can see what it does with that number.
crash at the waterfall in level 1 fixed.
Need now to focus on the terrain generation for Battle of Naboo. It will be a long long road...
Working on Battle of Naboo. It is clear that the technic used for ground generation is a heighmap. From colors Y is generated with X and Z provided by the CPU.
Still amazed what Factor could do with microcode.
@olivieryuyu Is it similar to Rogue Squadron's terrain generation system? I'm looking forward to read your technical documentation about N64's code world. :-)
Not really.
Finally went through the whole code for ground generation. It was really hard. The code uses a lot the parallelism of the vector unit of the RSP.
few screenshots of the HLE version of Battle of Naboo
Ground generation works nearly flawlessly
Particles system!
Space fights are nice :dancing_women:
Nice, when will source code be updated with the ucode?
@gonetz @olivieryuyu impressive work you two!
Any chance of work being done to HLE this game?
I've made a fixed branch of Project64 that has an RDB option hack for Indiana Jones and Battle for Naboo here: https://github.com/Frank-74/project64/tree/ForceFpuLoc
This build has fixes for savestates as well, so both old and new types work, compressed or uncompressed. Compiled build with VS2008 SP1 here: https://dl.dropboxusercontent.com/u/9498358/n64/Project64FixFpuLoc.zip
GLideN64 just hangs with a black screen, whereas Glide64 responds with: Error: Unsupported uCode! crc: d5c4dc96.
Jabo 1.7 just crashes the emulator, but 1.6.1 gives this: Unable to detect microcode settings Microcode ID: $8A4F88F1.
LLE is fine, but it's slow.