Rice-Video
Rice-Video copied to clipboard
death-droid
Some bugs I've encountered
Issue #1 is that the DX9 version is really odd, but in terms of speed it's magical! For some reason, I've tried 2 laptops at home, and had a friend try the DX9 version. On my laptop, it performs better than any plugin I've ever seen! My only issue with it is that the timing is off. What I mean is, the audio is more out of sync. I wish I knew what part of the code effected the timing.
On my friend's computer, the fps was lower than 60, even if he used cheat engine's speedhack. The thing was, I checked his cpu usage in task manager and it was below 25%. For me the fps would dip to like 57 sometimes, but with cheat engine speed hack, it would go to the 200's and sometimes even 300 VI/s. I forgot to mention that the speed/frame limiter option doesn't work for 1964 or PJ64 when using the DX9 version.
Issue #2 is that i keep crashing whenever I use any version of Rice or 1964 Video, using Direct X. I know it's just my computer, because on other computers I've tried, the crashing didn't happen. Another weird thing is that when I run emulator through a debugger, it won't crash, but when I eventually exit the emulator, I'll get some weird message. I should have wrote it down.. At least I know it has something to do with the Direct X code in the plugin. In the meantime, I'll try updating all my drivers.
Issue #3 is that on PJ64 (1.6 or 2.1), when playing SSB64's intro, using Direct X, the video desyncs and DK misses his forward aerial vs Samus, even though it was supposed to hit her. Why this problem doesn't happen on other emulators or even OpenGL, is strange to me. Can someone at least try watching Super Smash Bros 64's intro on PJ64 to see if it happens to them too? This issue applies to every version of Rice & 1964 that I've tested.
[FIXED] Issue #4 is that any version after Rice 5.5.1 has messed up background for the Dream Land stage in SSB64. I'm trying to compare his old code with newer code to see what broke it.
Thanks for submitting this mate! Will try and work on some of these bugs ASAP!
Lol my bad, I realized like 2 days ago that the source I compiled was from 2012, although I already did try your release builds. Is my computer bugged, or is Super Smash Bros 64 really buggy when using the experimental build? The graphics were messed up and the plugin somehow effected my input (I couldn't run, I could only walk).
At the very least, I'd like to see the VI/s being fixed in the DX9 version. It's like playing on sync audio, except the audio doesn't improve. I see a lot of potential though, in the DX9 version. I noticed Mudlord's 6.1.3 DX9 also had that same VI/s problem. I can't expect you to track Rice's old code to fix the Dream Land tree background, because the code is very different.
I still haven't updated my drivers yet. I should do that then see if I still get those crashes.
Super Smash Bros 64 seems to be completely broken at the moment :\ Its something I really need to get to fixing, and also need to find at which point that it became as broken as it is. (Though theres a chance it could also be settings related but eh not sure) So yeah its not only you, something seriously odd is happening in the code.
The crashing is definitely an odd issue :S, I don't think i've played any games long enough to hit any crashing. Though its going to make it a pain in the ass to find out whats causing it if it wont occur when attached to a debugger :\
Ya that is a pain lol. We're probably better off just working on writing cleaner code.
I tried reading through Rice Video's code. It's too complex for me atm. I need to learn Direct X. Do you have any advice for working with open source gfx plugins? For instance, I tried comparing code between different versions of Rice Video, but there were way too many differences, and I can't copy paste code from one version to another.
I'll still attempt to analyze the many different versions of Rice & 1964 Video.
I really do not get why the timing is drastically different in the DX9 version compared to the DX8 version. What part of the code deals with timing? Since cheat engine's speedhack removes the VI/s limit, I think it means that there's some sleep function that's messing things up.
Do you know any thing about StackHash errors? I've been getting a lot of them lately, from testing random things. For instance, I've been working on 1964 and with certain compiler settings, I get errors when doing things. For example, with ultrafast v3, it crashes when I open up Kaillera. Your version doesn't have this issue though. So good job on that :+1: . Another weird thing is that when i compiled 1964 1.1's source, I had to disable data execution prevention just to run it. I'm curious if it's just me, or if there's some bugs.
Tbh, I don't think I tested your latest version of 1964 Video long enough to see if I crash, I'll go ahead and compile it again and test it.
haha yeah which is currently what im attempting to do is clean up the code as much possible so it will hopefully make it easier to fix and replace parts where needed.
Hmmm to be honest :P thres not much really I can suggest, just keep trying at it, think of something you might want to improve and just focus on that. Im not that great of a programmer as it is but I try my hardest to fix and improve stuff where possible.
Win merge is a good program to help try and compare differences between code effectively http://winmerge.org/
:P Goodluck with that, I've probably made and re-arranged files enough it would make it quite difficult to do that.
Hmmmmm yeah it sounds extremely odd, it shouldn't be that different at all since the code in reality wasnt that different from the DirectX 8 code :S
Ummmmmmmm to be honest no, not really. Never really ever looked into it XD You seem to actually run into quite a few crashes. O_O Ahhhh been a long time since Ive looked at the 1964 code, a very long one. Gave up when Project 64 code turned up
Thanks for your help! I think for the most part, those stack hash errors are due to bugs in the code. I had a friend test ultrafast v3 to see if they crash when opening kailera and sure enough he did crash.
I'm really wondering how this plugin broke Super Smash Bros 64. I can't tell if the stack hash problem is fixed because anytime I load a menu, the game freezes. I even tried loading a save state while loading a match in 1p mode. Rofl, it loaded the wrong stage somehow! I had no idea gfx plugins could do stuff like that.
I decided to see how well your plugin runs some of my other games I like to play. FZero played pretty well for the brief time I spent playing it. The speed was around the same as your old dx9 version, so that's good. Unfortunately Diddy Kong Racing, although it still beats most other plugins, got slower since the last version you had in your code google project from 2012.
It seems that I only get this stack hash problem in Smash Bros. I wish I knew what code differectly affects which game. I only know a little about microcodes.
I just tried out Direct64 again, since it's also DX9. it has the same problem with the VI/s being locked and sometimes dipping below 60 VI/s despite the fact that it's not even maxing out my cpu. In fact it's even worse, because I saw slowdowns in games like Banjo Tooie, yet when I used speed hack, the speed went up. It seems like some DX9 issue. Still, DX9 must be amazing compared to DX8 and below since I'm getting such high numbers for VI/s that I've never seen before, when using speedhack to uncap frame limit! I wish that one was open source, it had good potential.
Also, does the 1964 Video LLE from your 1964 project work? I can't get it to compile.
:P Glad to be able to help hmmmm yeah, most likely XD 1964 is definitely one of the more buggy emulators, even before people start modifying it with experimental features.
Well :P Pushed an update that actually allows the game to finally play again, (was a bug in the depth buffer clearing we have been using, and i never updated to Salvys latest version of it (Has a lot of advantages for game like DK64 and Zelda)) Timings however are still off though :\ will look into it more.
Hmmm really?? odd that Diddy Kong Racing is running slower :S Another thing I should look into then >.<
Hmmm must be some weird issue with DX9 conflicting with emulators or some odd thing :S
Ummmm,can not remember at all to be honest :S
Pushed a few commits this morning :P, can you let me know if you find any more regressions when compared against the last commits since they change a fair few things.
Well I'm happy that the stack hash problem was fixed as I suspected. You probably fixed it early on, but there was no way for me to know for sure until SSB64 was working properly. The only regression I can see is a 1-2% decrease in max VI/s when uncapping the frame limit & using speedhack. Keep in mind I max out the compiler optimization settings. This isn't a big deal especially since it's still way faster than most other plugins. I'll take significant fixes over minor slowdown anyway. I tested F Zero and Diddy King Racing and I don't notice a real difference between today's version and the version from like 2 days ago.
With your current version, I was finally able to beat Super Smash Bros 1p mode without crashing or using a debugger. The only other annoying thing for SSB64 is the dreamland tree being slanted when it shouldn't. Idk if the optimization settings messed things up, but the graphics don't look right in SSB64 when I enable sse. Good job on fixing the stack hash error! I was getting so frustrated with that! I'd probably use Rice DX8 for regular gameplay if I could get rid of the stack hash problem. DX9 has great potential, but it will be difficult figuring out how to fix the timing issue. It's also weird PJ64 has extra timing issues with Rice Video. It's one of the reasons I'm less interested in PJ64 now.
I tested Pj64 1.6 as well and the intro still desynches. I'd say priority 1 should be fixing the timing issue caused by DX9. Hopefully in the near future, I'll be able to make significant contributions, since I see great potential in this plugin. On the fly plugin swapping really helps with testing!
Do you think there are other games where Rice Video does worse on PJ64 besides Super Smash Bros?
Another interesting thing about the timing issue is that some games aren't as effected by it. Like in Diddy Kong Racing, I can go up to 120VI/s (still not max speed) without using speedhack. It's kinda odd how it's capped at double speed when turning off the frame limiter.
I'll try to manage my time better, instead of spending hours trying to fix minor things lol. Hopefully I can start understanding more of Rice Video's code so I can make improvements.
I did more testing and I believe the slight speed loss was simply due to bug fixes / accuracy, so don't worry about the small change. I noticed the VI/s were more the same when i made a save state on the 2 day ago version and loaded it on today's version. Later on, you might want to investigate why the 2012 version is faster though. I guess the reason games like Diddy Kong Racing don't have the timing issue as severe is because it's naturally a 30 fps game lol. I'll try out other titles that aren't 60fps like Zelda and SM64.
Also, I guess I was wrong about Fzero being around the same speed as your 2012 version. This could very well be specific to my hardware, but your 2012 version seems to be faster for every game I've tested. I'll try out more games. I suspect maybe it has something to do with the video settings, I see less options in your newer version.
Hmmmmm okies cool glad to know the stack hash problems no longer exist then! Hmmm, hopefully after we get the code nice and clean optimizations will come hand in hand.
Ok and very glad to know there hasnt been any regressions that you have seen, new update made the code much better :P, thanks to the Daedulus team there is alot of things we can actually port back over from them that will help both our emulation compatibility and drawing accuracy. (Newest update is paving the way for proper lighting in game like Majoras mask and Conkers bad fur day that Daedulus team implemented)
Hmmmmm yes that timing issue is definitely becoming a large problem, especially if its game breaking. I may try and get in contact with Zilmar, Mudlord or Salvy again. They might have an idea on what could be going wrong to force the timing out of sync.
Be great if you started developing here! Finally give the plugin the attention it needs!
Haha its very easy to get carried away and spending hours on fixing one singular bug :P But you never know where it might end up helping elsewhere. Im not that aware of any games that suffer the same problem as Super Smash Bros, but then I haven't done that much testing, I usually just brush over a couple of games to make sure I havent stuffed them up majorly.
Hmmmm yeah, well emulation wise games like Diddy Kong should be more exact but dont quote me on that as theres still a fair few graphical issues here and there.
Hmm interesting theres a slowdown across the board, I wonder if that has anything to do with the depth buffer clearing we have been doing since thats a more intensive process :S Also dont turn on SSE >.< I screwed that up completely earlier on, probably might strip it out completely and let Visual Studio do the SSE optimizations itself. Compilers have come a long way since this code was originally written :) and a point where so many hacks were required to make things work on individual graphical cards
Lol i spent hours trying to tweak 1964. i was frustrated when i made a build that was faster by a few VI/s, despite the fact that I continued changing the code around. I had no idea what I did to make it fast, but I give up on that. I realized I'm better off cleaning the code and continuing to write better code, than spend countless hours backtracking previous code and testing different compiler settings.
It wouldn't be a bad idea to get rid of the SSE code, unless it was well written. Anyway, I'm more interested in gfx and audio now, rather than the core since it's good enough for now. I've been trying to compile different video plugins so i can learn from them. glN64 is buggy so I can't be bothered with that one. PJ64's Glide, I can't even compile because I'm unable to build wxbase29.lib. Fortunately I happen to like Rice Video, so I don't mind working with it.
If you have spare time, I'd appreciate it if you could help me get 1964 Video LLE to compile. I'm very curious to see the difference between using an RSP vs 1964's microcode implementation for GFX.
I've mentioned this before, but Rice's OpenGL seems to have less timing issues than the Direct X version. That means there's something wrong with the Direct X implementation. I wish I knew what part of the code to focus on. Ideally I think it would be good if I focused on a select few games at one given time. I do find it weird that your DX9, mudlord's DX9, and Direct64 all have this timing issue. I'll try learning DX9.
LOL wow, just tried LemDX9 and sure enough it had that timing issue as well. Do you know how you fixed the stack hash problem? I'm really curious to see what caused it.
haha yeah :P I know that feeling, clean code does sometimes tend to translate into faster code, or at least make it more obvious how you could potentially cut down its call time even if its only by a few millisecconds :P all adds up eventually
Hmmm yeah, well SSE is only really used for vector transformations, and i kinda want to actually rewrite Rice Video's Vector Shader so that properly works making all the SSE stuff useless as it would use the GPU rather than the CPU.
Rice Video is probably the easiest one to actually work with to be honest, its highly compatible and offers alot of features, doesn't quite have the same level as Glide 64 but I find glide64 to be a much more complicated graphics plugin, especially as it requires a wrapper to properly work as it was built for the defunct VOODOO graphics cards.
Link me to the code for it???? BEcause i swear my code dump didnt actually have it in there at all anymore >.< Hmmmmm yeah XD
Hmmm yeah, it appears to be some weird issue thats happening with Direct X, come to think of it I do remember a few people mentioning it years ago that DirectX 9 seemed to screw arround with particular features, I think i may have to go to forums and more knowledgable people to sort this one out :\
I wouldn't actually try to work on Glide64. I think it's honestly a waste to maintain something that wasn't even designed for my system lol. I wanted to use Glide as a reference so I can add some effects that Rice is missing. My biggest setback is not understanding what's responsible for the the things I want to add in. Since I play Super Smash Bros a lot, I get annoyed at looking at that slanted tree in Dream Land stage lol. Idk how I'll be able to fix it since it's hard to compare code of 2 versions of rice that are quite different from each other. Then there's these timing issues that Rice Video has been plagued with. Easy fix for some of it is just to not use PJ64 which I'm ok with doing :) ..
Here's the link http://emu-1964.googlecode.com/svn/src/RSP/ . I was the one who wrote Issue 114 btw. You'll need to download LLE Video and Shared.
Man you sure have a knack for fixing bugs! Your version of 1964 is the least buggy. I don't get why the binary release is more stable, than the one I compile though. Your binary release fixes the save state issue I have where sometimes if I make a save state in recompiler mode and try to load it in interpreter mode, it fails. When i compile your source, I get these weird message box error messages for Jabo's plugins. They still work, but it's annoying to have to press ok everytime lol. One reason why I prefer to compile things myself is that I like to max out the compiler settings + I like to tweak the source a little. I'll have to see what I did to make the save state fix not work on the my compiled version of your source.
Today, instead of wasting time on small stuff, I'll keep reading up on DX9 API. If you could assist me in compiling PJ64's Glide, I'd appreciate it as well. What I plan on doing is debugging and setting breakpoints to figure out what part of the code is responsible for the features Glide supports, that I want to add in Rice.
HMmmm yeah XD Even Gonetz admits himself it was overly complicated, but that was just due to the limited nature of the API's back in the day when he originally wrote it. Ahhhh yeah glide does everything well, just a challenge trying to rewrite it for it to properly function well for Rice Video, but definitely check it out!! haha I could imagine that being extremely irritating, I should look up what ucode its running off so it will be easier to track down whats going wrong with it to cause it to slant all funky like. Hmmmm yeah have to work that one out D:.
haha really?? im surprised I could of sworn mine was buggy as all hell :S, hmmm that is odd. What compiler / IDE are you using to compile these projects? Hmmm I think i may of broke jabo's plugin at one point, but gave up before I did. HMmmm yeah I could imagine, you shoud write down what the error message is :P be easier to work out whats going wrong. AHhhhh yeah I see why you comile it yourself then!
Goodluck with that :) some things seem oddly undocumented for the DX9 API to be honest :S. HMmm that compiled me straight out of the box from what I remember, what compiling errors are you getting? Ahhh yeah sounds like a good idea :)
It seems Ultrafast also doesn't have that save state problem. Still, you did something to make your GUI the most stable one. Only thing I can really complain about your build is Jabo's plugins when i compile your source. I tried adding features, some work good, others are somewhat buggy. One funny thing about 1964 1.1 is that screenshots only work in HLE. I fixed that in my own build though.
I use MSVC 2010. I have 2013 but I just didn't try it with 1964 lol. For Glide, I tried compiling with MSVC 2013. I get this error message "error C2039: 'WaitForInputIdle' : is not a member of '`global namespace''. Honestly if I could just download wxbase29.lib from the internet, I bet i'd be able to compile glide.
I'll try downloading pj64 from a different repository to see if I'm able to compile glide. I'm unable to compile the wx lib, which is required for Glide.
Lol right now I'm trying out Rice 6.1.1's debugger. I'm thinking there's something wrong with the triangle implementation. Do you know where / how I can learn about ucodes?
Hopefully we can fix this DX9 issue!
Edit: I got wxbase to compile. I cleaned WX, then tried compiling with MSVC 2013 and it worked. It's weird cuz I couldn't compile PJ64 2.1 with MSVC 2013, so thats why I was using 2010 lol.. Now I'm getting this error message when I try to compile Glide "error C1900: Il mismatch between 'P1' version '20100826' and 'P2' version '20081201' "
Ahhhhhhh odd XD haha yeah i think i actually spent a bit of time trying to fix up the GUI XD To be completely honest I dont remember that much of the work I did for 1964. Its been a long, long time XD
Hmmmmm weird it should compile fine from what I remember. I need to redump all the code but cant do it at the moment since only got mobile internet at the moment (like 3gb of data which ive already chewed up 1 gb of XD)
You downloading it straight out of Zilmars repo???? YOu do have to do a little bit of a work to ensure it compiles fine on newer compilers since he only ever used 2008 XD And in my repo I stripped out glide since I wanted to do work on it >.<
Ahhhhhh, what makes you think heres something wrong with the tri implementation?? Ummm, to be honest not particulary, the n64 SDK has a bit of explanation of certain functions of the N64 GPU but individual ucode information requries a fair bit of debugging from what I remember. Someone like gonetz, Rice, Mudlord, Salvy or a few others would have a lot better idea than i do :P
Yeah hopefully!!
Ohgawd XD sounds like a configuration problem though
I didn't download straight from Zilmar's repo. I found some other one that had it configured to work for MSVC 2010 and some things, even 2013.
The reason I think it's a triangle problem is simply because when I used Rice's debugger, and selected Triangle, then kept clicking pause at next, I saw parts of the tree showing.
Alright, I guess I'll try looking for some docs then. Hopefully I'll be able to compile Glide today. Also, by any chance, do you know why it only works for PJ64 2.1? When I compared it to Glide64Final, I noticed PJ64's version was a bit faster. Any speed difference is wonderful for Glide!
Ohhhhhh ok :P Ahhhh sounds interesting.
Hmmmm, it may also be related to the vertex clipper, the tri code should be functioning fine from what I remember. May be a weird issue occurring from the vertex clipper maybe?? SInce there have been a few problems with it, it could be culling it in a weird way.
Ok awesome!!, Hmmmm to be honest im not completely sure, though he could of re-written it to conform to the newest specs. I would actually have to re-check the git log. May have something to do with the way he combined the various separate libraries together into one build, removing the bit of speed lost by dynamic linking
I haven't really looked into DX9 yet unfortunately. Main reason is because I feel I need to learn a lot about the n64, before I can truly improve a gfx plugin. I'm trying to learn about the components of the hardware and stuff. I need to figure out what is responsible for the timing issues. Even in the DX8 version, the timing is more off than Jabo 1.6. Yet the OpenGL version doesn't have these timing issues. Makes no sense tbh. You know how I mentioned the intro desynching with DX, using any version of Rice Video for PJ64? Does this mean PJ64 has issues, since Mupen64 and 1964 don't have this problem? I also think it's odd PJ64 has the most problems with playing Super Smash Bros intro in general. Not that the intro is important to me, I just don't like when I see major problems with an intro lol. It makes me think something is seriously wrong with the plugin or emulator lol.
If I could just know where to focus on, I'd be able to at least do a better job debugging.
For Glide, I'll try changing settings to get it to compile. I think the main reason for the slight increase in speed is combining the libraries. Also I think he rewrote some of the ASM code too. I'll worry about getting it to work on other emulators later. Since I compiled Pj64 2.1 myself, I can use that for debugging. It's nice to have the pdb files :) .
I'll try looking at other plugin's code. What I really don't get is, when i compiled glN64, it has a similar problem with the trees being slanted, yet the official binary release doesn't have this problem! It's a shame because that plugin could be useful for learning from. I'll try looking at the vertex clipper code for both Rice 5.3.1 and 5.6.0. By any chance is there a source for RIce 5.5.1? I think it would be much easier to compare 5.5.1 to 5.6.0 than comparing 5.3.1 to 5.6.0.
Ahhh all good mate :) You will probably end up learning more than I do :), most of my work is fairly hacky or based off another persons work, studying a course in computing at University at the moment so hopefully that will boost my knowledge to help my improve the plugin as much as others have. Hmmmmm, yes it very well may be a Project 64 issue, or at least a requirement of the Project 64 plugin specifications that Rice Video isnt meeting to cause the problems.
On the note of Super Smash Bros, I'm glad to say that the latest commit solves your issue with the tree being oddly slanted. Had a look through the Daedulus commits to see if they ran into a problem similar and fixed it and turns out they did! So ported the fix across and hey presto. It all now displays as it should do.
Hmmmmmm yeah, Im fairly sure the interrupts is where alot of the timing comes from? But ummmmmm not sure on that, some guys on the project64 forums might have an idea, HatCat i think is one of the more knowledgeable people over there. (May of got his username wrong but shouldnt be to hard to find)
Hmmmmmm yeah agreed on that, and yeah he did from what I remember. Though you will have to port the latest commit over from the official Glide repo to fix up particular texture caching issues. Ahh yeah :)
Hmmmm weird, big chance the latest release of glN64 is different to the code that was released. Sad to see Orkin is no longer around the Nintendo64 scene, his plugins showed a great amount of promise.
I just compiled your latest revision and sure enough, the dream land tree is fixed!
DUDE, you gotta teach me your ways. I spent over an hour trying to fix stuff like this. I'd like to know how you fixed the stack hash error & this tree problem. It's quite sad, I debug all the time, yet it usually takes me a long time to fix things ;/ . For me, comparing different versions of a plugin is a hard thing to do.
So now we got to fix the timing issue. I'm RPGMaster at pj's forums btw. HatCat admits he's not very good with API's, but maybe Mudlord.might know a solution.
I'm curious, since you keep mentioning Deadalus Video. What emulator does it work on? I'd like to test it out.
Ya I wish he open sourced his Direct64 plugin.
Lol another interesting thing is that I had the same SSB64 intro desync problem on Apollo 1.0.
Anyway, I noticed something odd. When I had Enable Mip Maps on, it caused Kirby's eyes to look more blurry, probably his face too. What is that option supposed to do?
Lol I might have to just download a bunch of revisions to carefully monitor how you catch & fix bugs.
For Glide, I haven't compiled it yet. What version of MSVC did you get Glide to compile with? If it's > 2008, then I'm surely doing something wrong ;/ .
Glad to hear its all fixed then!!
Haha I wish I had something to actually teach :P Not the most knowledgeable person, I know the basic to get me by that's about it.
Hmmmm yeah I get the feeling fixing the timing issue isnt going to be as simple as looking back through the commit log of another plugin to fix this one >.< But yeah Mudlord is always quite a resourceful one, especially when it comes to API's even though hese more of an OpenGL person these days.
Daedalus Video works on Daedulus :P, its not really a PC emulator sadly, well at least the most recent versions of it aren't though they have been trying to make it compatible with PC lately. Daedulus Video is pretty much an older version of Rice Video, but the Daedulus team have worked a shiteload on it and fixed alot of problems and implemented a fair few features to increase compatibility or increase speed.
Hmmm yeah same here XD He had really clean code as well, just sadly not as developed :package: haha wow really?? XD Though that emulator is ancient now XD
Ahhhh yeah thats an expected outcome, it pretty much regenerates the texture to smaller versions so it makes tiling textures not look so harsh over longer distances and also gives a bit of a performance boost as it doesn't need to use the same large texture. Though it isnt really needed for games not running high-resolution textures.
But yeah as i was saying it has a down side, as games like SSB the characters and textures tend to be further away from the camera causing it to use these lower resolution generated copies its made making it look blurry and shitty.
haha :P Im surprised i fix as many bugs as i do, but ive had my fair share of making a shiteload of bugs and completely screwing the plugin over >.<
ummmmm from what I remember I used Visual Studio 2010, hacent tried it since i upgraded to Visual Studio 2013. I wont have access to proper decent internet till next tuesday so cant just quickly download it :|
Alright, I'll try downloading glide from zilmar's link.
Lol i get so caught up in trying to fix bugs. I really need to stop this habit! So for like 1-2 hours, i was trying to figure out why using Jabo's Direct Sound on 1964 doesn't work right. I give up, since even the official version has issues with it. Not like I use it anyway. My custom build broke it even more lol, but I should just give up on small things like this. Later on maybe when I actually know what I'm doing, I can just clean up the code.
Aw, so that means I can't really test it out. I'm curious if they implemented graphic effects that most HLE plugins don't have.
Ya this timing issue is going to take a while to be solved, I don't expect to see it fixed anytime soon. It's no coincidence that Mudlords DX9, Lem's DX9, your DX9, and Direct64 all have this timing issue. I'm thinking it's simply the API.
Lol I guess I'll disable mip maps. I should mess around with the settings to figure out the perfect setup. So ya, I'll continue reading up on things and try learning the DX9 api. Hopefully I won't run into too many issues.
So for fixing bugs, I guess it's better to focus on improving the overall code first, then if it's still not fixed, I'll do some detailed debugging.
haha yeah I know that feeling, gets even worse when you spend ages.... manage to fix it but turns out it breaks like every single other thing >.< Wait you are using Project 64 RSP with 1964 right?? Fairly sure Jabo's plugins rely on it for some reason :S
hmmmmm its still behind plugins like Glide but they have fixed quite a few things. It pays greatly to look through the commit logs of Daedulus though! Since they thankfully had already worked out the SSB problem.
Hmmmmmmm yeah XD And if its an API problem its probably not just a simple few line of codes fix :\
haha, it helps greatly in games like OOT, not so much in SSB. Goodluck with your reading!! I dont know much about the DX9 API at all, I just tend to google up on bits when I need it.
Hmmm yeah agreed, if we can clean and consolidate the code it should help fixing bugs or improving general speed in the progress.
Ya, I was using PJ64's rsp. Turns out the reason my version broke it more was because I removed some code that detects if you're running jabo's sound and sets CoreDoingAIUpdate to false if true. I honestly don't know why I erased it, rofl. Funny thing is, I found that out while looking for something else. I honestly don't even care about Jabo's Direct Sound, I just like testing many different sound plugins for various games.
Rofl, I forgot to try getting Glide to compile.. Hopefully soon, I'll be able to finally compile it. In the meantime, I'll also try looking at Daedulus.
So do you remember what you did to fix the stack hash problem? I'd like to fix the old DX8 version since DX8 doesn't have the timing issues.
I was playing SSB64 with a texture pack and your latest version of Rice Video. I must say I'm very pleased with the graphics and performance.
One other small thing about Rice Video I'd like to see fixed is the far right and bottom part of the game screen for SSB64. Any idea why it's glitched?
I haven't done much API work lately, but I'm trying to learn more about n64. One thing I'd like to see with rice, is implement some of the missing graphical effects in some games.
Hmmmmmmmmmm to be honest I would have no clue, i personally dont remember fixing it. May of been done by Microdev. But don't quote me on that.
"One other small thing about Rice Video I'd like to see fixed is the far right and bottom part of the game screen for SSB64. Any idea why it's glitched?" Ummm would you mind screenshotting this? dont quite have the time to check myself but would help give me an idea on whats going wrong
We fixed that in Daedalus by ignoring if the depth buffer is selected in fillrect https://github.com/salvy/daedalus/blob/CornTnL/Source/HLEGraphics/DLParser.cpp#L929
Here's a screenshot of the issue. http://puu.sh/a9NJg/54b85cf820.png
Thanks salvy. I have one issue though. Since your source uses different names for variables, I can't get it to work. What is the value of G_IM_FMT_RGBA ?
Also, one thing I'd like to see fixed, about Rice Video is fog. Fog doesn't work / is incomplete in SSB64.
Injecting this: // Fixes black box in SSB when moving far way from the screen and offscreen in Conker if (g_ZI.dwAddr == g_CI.dwAddr || g_CI.dwFormat != TXT_FMT_RGBA) { //DL_PF(" Ignoring Texrect"); return; } into DLParser_TextRect in my plugin is not enough to do justice. Then again, I'm not using any of the Daedalus depth buffer changes in this particular build. I'm a little behind and I have to solve a problem where the video thread exits using the current codebase. Probably some Xboxism got mixed up in the cleanup.
How does that work for you AIO/deathdroid?
