You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@gonetz I thoroughly enjoyed your posts about how framebuffer emulation and auxiliary buffers work, N64 emulation wise. I've paid close attention to your work for many years now. N64 emulation has always intrigued me, as far back as even it becoming a deciding factor on whether I should get a Radeon or Nvidia Video Card, to best handle Golden Eye on Project 64!
In any case, I have been doing fix ups of Cores, such as MAME and N64, etc, for usage on lower spec platforms, such as the NES/MD/SNES Classics. The caveats are that image textures and depth buffer rendering do not work properly, which causes issues...of course, with games like Pokemon Snap "detection", and "proper display of FOG" in Beetle Adventure Racing.
One big issue these lower spec platforms has is a "memory leak", which causes the RAM to essentially run out of memory pretty fast, depending on the game. Metro Madness track in BAR, in particular, is a memory hog!
So, then, the subject of this particular issue, is directly related to me and me doing Debug testing with Beetle Adventure Racing. There is a Debug Menu you can unlock in BAR, which gives you access to many key components of what the Developers originally used when optimizing the final product. What I quickly noticed was how "disabling" fog completely in the Debug Menu ALSO alleviated overall RAM usage. And, there was also an option to increase or lower draw distance, which was uniquely cool, too.
I have seen this sort of perimeter used to great effect in the Mario 64 port, where fog was completely removed and draw distance increased!
I thank you so much for reading this far. What would be greatly appreciated, so very much, is your input on "disabling" fog within the Core coding, itself, as well as "altering draw (clipping?) distance", for debug testing purposes. I'd mostly like to use Turok and Beetle Adventure Racing as case test scenarios, to see how effectively RAM usage increases/lowers with these changes!
Thanks so much!
P.S.: I am testing on GLES, which does not allow me to utilize Parallel RDP, etc. I am strictly using GlideN64 Plugin, with Cores such as Mupen64Plus and Mupen Plus NX! Thanks again!
The text was updated successfully, but these errors were encountered:
@gonetz I thoroughly enjoyed your posts about how framebuffer emulation and auxiliary buffers work, N64 emulation wise. I've paid close attention to your work for many years now. N64 emulation has always intrigued me, as far back as even it becoming a deciding factor on whether I should get a Radeon or Nvidia Video Card, to best handle Golden Eye on Project 64!
In any case, I have been doing fix ups of Cores, such as MAME and N64, etc, for usage on lower spec platforms, such as the NES/MD/SNES Classics. The caveats are that image textures and depth buffer rendering do not work properly, which causes issues...of course, with games like Pokemon Snap "detection", and "proper display of FOG" in Beetle Adventure Racing.
One big issue these lower spec platforms has is a "memory leak", which causes the RAM to essentially run out of memory pretty fast, depending on the game. Metro Madness track in BAR, in particular, is a memory hog!
So, then, the subject of this particular issue, is directly related to me and me doing Debug testing with Beetle Adventure Racing. There is a Debug Menu you can unlock in BAR, which gives you access to many key components of what the Developers originally used when optimizing the final product. What I quickly noticed was how "disabling" fog completely in the Debug Menu ALSO alleviated overall RAM usage. And, there was also an option to increase or lower draw distance, which was uniquely cool, too.
I have seen this sort of perimeter used to great effect in the Mario 64 port, where fog was completely removed and draw distance increased!
I thank you so much for reading this far. What would be greatly appreciated, so very much, is your input on "disabling" fog within the Core coding, itself, as well as "altering draw (clipping?) distance", for debug testing purposes. I'd mostly like to use Turok and Beetle Adventure Racing as case test scenarios, to see how effectively RAM usage increases/lowers with these changes!
Thanks so much!
P.S.: I am testing on GLES, which does not allow me to utilize Parallel RDP, etc. I am strictly using GlideN64 Plugin, with Cores such as Mupen64Plus and Mupen Plus NX! Thanks again!
The text was updated successfully, but these errors were encountered: