Closed Frank-74 closed 6 years ago
Well done @olivieryuyu and @gonetz. I hope you had as much fun with the adventure as I did following!
wooooooot @gooner!!! lol
When does any of this get a public release?
It is close now. I need to polish the code: remove debug stuff (circa 4K lines atm), add optimizations etc. Then it will be pushed to feature branch and after public beta testing will go to master.
Exciting times a head!!
@gonetz Congratulations on the work of Indiana Jones and Star Wars Batlle For Noob although I became aware of the campaign late, I wanted to help with the donation but had already closed the deadline. I am anxious. Congratulations. and hugs.
I’m excited and I was certain it would happen even if I didn’t donate this time.
I'd like to test the alpha I have, but my system isn't working right. Flickers always between two resolutions:
In the menu of BFN it stays small:
Since I compiled mupen64plus-gui on macOS/MacBook Pro I'm unsure how to nail this down.
I don't think mupen64plus-gui works properly on Mac
@loganmc10 okay but how can I check which component isn't working right?
It's the GUI itself, you filed a bug for this a while ago: https://github.com/m64p/mupen64plus-gui/issues/33
The task completed: https://gliden64.blogspot.ru/2018/05/hle-implementation-of-microcodes-for.html
Source code pushed to feature branch: https://github.com/gonetz/GLideN64/tree/indi_naboo
Windows beta builds: https://drive.google.com/file/d/1rQCMNWo684HFHLLGWBBVvuiW6dlUOJYt/view?usp=sharing
Notice for developers: The microcodes use advanced particles system. Particles rendered with texrect command. GlideN64 implementation of texrect is not fast. Thus, I implemented optimized version of textured rectangles, specially for particles. It can be up to hundred times faster than original. Unfortunately, that optimization involves bunch of hacks. The way particles system works makes hack-less optimization impossible. The commit with this optimization is "Indi Particle Optimization hack.". Desktop test builds do not include that optimization: the code works fast enough without it. I'd like you to test the code with and without that optimization on mobile devices. If there will be no difference, the hack will not go to master. You may test the 3rd level of Indiana and 3rd level of Naboo - they use lots of particles.
Do you happen to have a save state for Mupen64plus?
I won't be able to test for a day or so, but I'm curious whether PJ64 will crash at the end of each level with GLideN64 the same way it does with LLE plugins like Angrylion's. Fortunately, the game should work perfectly on mupen64plus, though.
Regardless, bravo @gonetz and @olivieryuyu This is absolutely fantastic work.
@loganmc10 m64p is probably hardcoded to use LLE for Indy/Naboo, IIRC, so you should probably rectify that.
Alright I've updated m64p, it should attempt to run these games in HLE by default now
And here we go, the code is finally released to the world :)
As written by Sergei on his blog, it was a long and hard road. It was long days and nights of deciphering a difficult code ... But the result is here!!! :D
The ucode is based actually on F3DEX for some parts but changed so drastically that not so much remains from the original ucode.
A side note: the RSP of the N64 is a powerhorse actually: 62mhz MIPS coprocessor with a vector unit. You could clearly do a lot of math with it and this is what the Factor 5 devs did, enhancing the possibility of effects of the N64 (lighting, particles, etc).
The ucode attempts also to mitigate the RDP fillrate limitations by segmeting the memory in a specific way and running "sub-displaylist" only when some graphics will be drawn on the screen.
I am not surprised about the comment in one of the interviews of the Factor devs that it was hard to fight against fill rate limitation. It is cleary the bottleneck of the N64 and this is why the Zstorp ucode is actually the efficient solution for having a high level of polygons and high resolution on the N64.
Also there is something to add: ALL games are now playable in HLE.
Ultra64 introduced the concept of HLE and it was critized that HLE could never be as compatible as LLE.
Well if HLE won't be totally accurate of course, it proves to be still a valid concept of emulation. Plenty of people prefer playing in HLE by the way :)
Battle of naboo cheat: LEC&FIVE Indiana Jones cheat: FORGEOFF
It give access to all levels :)
If someone courageous could go through both games and try to find bugs, that would be cool!
Hey guys,
been hanging on to these since the announcement of HLE GLideN64 - I opted out of the donations, so I was unable to fully test these two codes. Please let me know if there are any issues.
Indiana Jones and the Infernal Machine (U) 60 FPS Hack
81058F76 0001 80058F71 0001 80058F6F 0001
Note: OC = 2. Needs more testing now that HLE is possible
Star Wars Episode I - Battle for Naboo (U) 60 FPS Hack
81080296 0001
Note: OC = 2. Needs more testing now that HLE is possible.
Found a bug. In the opening sequence of the third mission, the back of Indy's jacket is bugged.
Angrylion's:
GLideN64 HLE:
@gonetz I tested in Android. The particle hack adds about 10-20% performance improvement on level 3 of battle for naboo. In my Snapdragon 835 device, the game goes from 27-35fps to 35-43fps on level 3. I think the hack is worth while since it makes the game run full speed on my device.
@AmbientMalice bug confirmed, thanks!
@fzurita Ok, thanks! I'll build next beta with this optimization enabled. May be somebody will find an issue with it.
Bug fixed. New beta build: https://drive.google.com/file/d/1kG1_lD4dXIYO0F5zlBHRY6x7aRuWC3y4/view?usp=sharing
Happy to report that the life raft has also been fixed. I assumed the jacket and raft were probably the same issue, so I didn't report before:
Beta1:
Beta2:
Cool! The bug was in very basic functionality. It could cause much more troubles.
BTW, this build includes particles optimization hack. If you will find a regression with particles, please report.
I found and fixed an issue with optimized particles. New beta build: https://drive.google.com/file/d/1gSheFz7uQE_TjtPxcWzi4DJ5l14DnwGP/view?usp=sharing
@gonetz You mention on one of the articles linked here that theres a useful spreadsheet from @olivieryuyu Where can I get that spreadsheet? Also, I am in the midst of experimenting with real hardware and I'd love to play around with this. Where can I get the source for just the ucode that I can run through the nintendo ucode compiler?
Better to ask @olivieryuyu about it. I may publish only my part of the work.
@gonetz Tell you what, if you and @olivieryuyu release your work, i'll Paypal 200 dollars for you to split. It must be in a form I can compile ("out of the box") for the n64 (hardware) using the sdk and id need a LOT of comments explaining things. Plus Id want a skeleton spec file prepared with the correct parameters for the microcode. If anyone wants to contribute more, I can set up a gofundme, but my 200 stands.
Id even be willing to upfront some (up to half) of it as a goodwill gesture (we can negotiate). That is how badly I want this ucode.
To qualify, it must also be under an OSS license other than the GPL (or LGPL). Apache and MIT are both fine and preferred.
If you wish to move forward, send me an email at nicholas@nicholasterry.com and we can talk further.
It must be in a form I can compile ("out of the box") for the n64 (hardware) using the sdk and id need a LOT of comments explaining things.
RSP microcode was written in pure assembly. It's not compiled. You could just dump the microcode, if you really want it. Comments could be useful though.
Hi Nicholas,
I don't think what you are asking is even possible (not without a lot of work at least).
If you are really interested to do that, I guess your best chance would be indeed to dump the ucode and check the microcode implementation of Sergei.
Olivieryuyu
Some idealistically things are non-buyable...
Hi, why build beta (Indiana Jones and Star Wars) not working with Project 64 2.3.2? Start with Black Screen. Here Star Wars Rogue Squadron playable normal with Project 64 2.3.2 and RSP Mupen64Plus.
Perhaps pj64 forces lle for that game. Check in advanced settings
I have weird graphics issues with Project64 2.3.X, both in HLE and LLE, regardless of graphics plugin. Project64 2.4.X works fine.
The reason it works in Project64 2.4 I think it has something to do with the DK64 Bone Fix, which affects other games. An accuracy improvement. Something to do with float point magic. The fix was also ported to mupen64plus, so it should work well there too, as long as it is a recent version.
Hello everyone, I'm testing the version (GLideN64_indi_naboo_beta3) and I found the first Bug on the screen (Battle for Naboo). Amazing how the emulation of this game is going well, all the other screens are flowing well, great personal work.
do u have a savestate pls?
@olivieryuyu , Extract the Save state from the folder, I had to zip because the site did not accept the file format without zip. Rom version that I used was Star Wars Episode I - Battle for Naboo (U) [!] StarWars BFN.zip
Hello, I'm fairly new to the Nintendo 64 emulation scene. I backed the project on Indiegogo because I'm a big Indy fan and I wanted to preserve this interesting alternative version of Infernal Machine, The game runs and plays great on the latest version of Mupen64Plus and the last GlideN64 beta, but I am encountering an annoying graphical "issue". I guess the problem is related to my mipmapping setting. I don't know how to explain this and I had some difficulties in catching the issue in a screenshot. Textures on far walls change following a weird lateral/diagonal movement: in other words, the engine doesn't simply swap the different quality textures, there's strange progressive "curtain effect" when the texture quality changes, I noticed that disabling the LOD emulation stops the "issue", but in that case I have the feeling the graphic quality drops a little. I'm sorry I couldn't be more precise: probably that strange mipmapping behaviour is ok with the game and I'm just not used to that. :-P I also noticed some popping sound which becomes less annoying if I lower the internal resolution. BTW, great work on this seemingly impossible emulation! Thanks again. :-)
@Diduz I think I know what you are talking about. First time I thought that it is a bug in our ucode implementation. However, LLE mode works the same. Moreover, I have real N64 and I see the same problem when I run Indy with it. It is less noticeable due to low resolution but it still there. BTW, thanks for your support on Indiegogo!
@GamingTVYT The problem exists, thanks for the report and savestate! It happens only with HLE.
Fixed the bug reported by GamingTVYT : https://github.com/gonetz/GLideN64/issues/1259#issuecomment-394146828
New beta build: https://drive.google.com/file/d/10eURmfdD9NeJtXa_H0a824eC_78irooP/view?usp=sharing
The bug in the scenario is fixed. Thanks. But now white particles appear when I shoot or I'm destroying something.
@gonetz Sergey, I've created a video which shows what I was trying to explain. Look at the strange behaviour of mipmapping on walls! https://drive.google.com/file/d/1s9_9sLY4dFxEaZY8YJiulvZ8iqGlrTSt/view?usp=sharing
@Diduz Please give me savesvate from this place.
@GamingTVYT Yes, I made a mistake in previous fix. Corrected. New beta build: https://drive.google.com/file/d/1wS2R2GG-Rwa02sUnHcK3v0SHyqfSE1iq/view?usp=sharing
@gonetz Okay, here's the savestate. ;-) Indiana Jones and the Infernal Machine (U) [!].zip
Thanks! Yes, mip-mapping works incorrect there. It is an issue, but it is not HLE issue.
@gonetz Do you think there will be a way to fix that? :-)
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.