Nintendo 64 Emulator
#31
(2014-12-12, 00:42)garbear Wrote: First things first - the RPi isn't fast enough to run a N64 core. even the most optimized code will probably never exceed a playable FPS. however, given moore's law, a (distant) future RPi might have enough oomph to make this a reality.

Second, I'm thinking of adding a TCP transport to the Game API. this would have two benefits: multiplayer support, and the ability to run a libretro core on a different machine. so you could run a core on a fast computer, and either do multiplayer - by sending the video/input to a RPi client - or simply run the core in the background and do single player on the RPi

not sure how well this would work for 3D rendering, maybe the host could render the graphics and loopback the RGB data so it could be sent to a client...

Most exciting post of 2014, maybe ever.
Reply
#32
(2014-12-12, 05:22)tdhz77 Wrote: Most exciting post of 2014, maybe ever.

haha that reminds me, i've definitely had a lack of exciting updates this year. i'd make the busy excuse, but i constantly stay busy with something. for work i'm managing a big project, in the many tens of thousands of source lines, and i don't have the mental bandwidth to deal with two massively large and complex projects at the same time. so it's really a concentration issue.

natethomas convinced me to give a talk on RetroPlayer at SCALE 13x in february (stop by if you're in LA). i took a look at the retroplayer code for the first time in a while, and it almost looks foreign to me. not a good sign for something I'm supposed to be an expert on Smile anyways, now I have a strong impetus for diving back into the RetroPlayer code, and I'm already working on the input re-write i promised so many months ago.

The more code i look over between now and february, the better. if you, airwulf, or anyone else is working on a fix/feature, feel free to ask about the code - i'm happy to explain, both to you and to myself Smile
Reply
#33
(2014-12-12, 00:42)garbear Wrote: I'm thinking of adding a TCP transport to the Game API. this would have two benefits: multiplayer support, and the ability to run a libretro core on a different machine. so you could run a core on a fast computer, and either do multiplayer - by sending the video/input to a RPi client - or simply run the core in the background and do single player on the RPi

not sure how well this would work for 3D rendering, maybe the host could render the graphics and loopback the RGB data so it could be sent to a client...
Edit: Started a new thread here about Game Streaming / Cloud Gaming to not hijack this topic http://forum.kodi.tv/showthread.php?tid=211150
Reply
#34
(2014-12-12, 05:40)garbear Wrote: The more code i look over between now and february, the better. if you, airwulf, or anyone else is working on a fix/feature, feel free to ask about the code - i'm happy to explain, both to you and to myself Smile

I appreciate your support, garbear.
Still looking forward to playing n64 in kodi/xbmc Smile
Reply
#35
(2014-12-12, 00:42)garbear Wrote: First things first - the RPi isn't fast enough to run a N64 core. even the most optimized code will probably never exceed a playable FPS. however, given moore's law, a (distant) future RPi might have enough oomph to make this a reality.

Second, I'm thinking of adding a TCP transport to the Game API. this would have two benefits: multiplayer support, and the ability to run a libretro core on a different machine. so you could run a core on a fast computer, and either do multiplayer - by sending the video/input to a RPi client - or simply run the core in the background and do single player on the RPi

not sure how well this would work for 3D rendering, maybe the host could render the graphics and loopback the RGB data so it could be sent to a client...

Whoah, you just made me cry a little. You should definitely keep this feature in mind while you solidify all the infrastructure.
Reply
#36
hey guys,
for anyone who wants to give it a try:
https://github.com/a1rwulf/xbmc/tree/libretro-gl

Code is far from perfect and most likely rebased!
I have a weird renderbug when playing mario kart 64.
Super Smash Bros is flickering and rendering looks odd - don't know why yet.
Only GLX is supported right now.
Feel free to post how it works for you - thanks.
Reply
#37
Hi guys,
wanted to share a video which shows one of my render troubles:
https://www.youtube.com/watch?v=ocTFyS6KGAI

Maybe anyone has an idea why the background is missing and the beard of mario is flickering.
Any help is appreciated.
Reply
#38
I compiled the mupen64plus core from the latest git sources - with this version i can see the background but there is still a lot of flickering. The core works fine when I use it with RetroArch.
Reply
#39
hey dippo - thanks for your feedback.
Seems someone fixed my render problems entirely - try Mario Kart it works kinda good for me (no flickering) Smile
I guess the flickering is something i need to look into - but the problems with camera view and weird rendering are gone.
Reply
#40
(2015-01-01, 18:52)a1rwolf Wrote: Hi guys,
wanted to share a video which shows one of my render troubles:
https://www.youtube.com/watch?v=ocTFyS6KGAI

Maybe anyone has an idea why the background is missing and the beard of mario is flickering.
Any help is appreciated.

Great to see maro clean shaven Wink
Reply
#41
If you change the gfx plugin to "rice" in the addon settings you can even see the beard in its full splendour Smile
Reply
#42
hey guys,

it's been a while now - but as garbear has announced his stable 15alpha2 branch, I decided to try a rebase.
Seems to work - however it's not a stable branch and not force-push save.
For those interested:
https://github.com/a1rwulf/xbmc/tree/ret...5alpha2-gl
Reply
#43
Thumbs Up 
Maybe a little offtopic, but in case somebody missed the news (I just stumbled upon it): a new major version (v2.5) of mupen64plus has just been released after almost 2 years: http://www.emutalk.net/threads/55485-Mup...le-Code%29

A lot of nice fixes and changes have been merged into this release: https://code.google.com/p/mupen64plus/wiki/ReleasePage

For the RetroPlayer/Kodi part: I am not sure if and/or how many changes from this 2.5 release have been merged already in the libretro repo: https://github.com/libretro/mupen64plus-libretro

So in the long run, it would be great if RetroPlayer could benefit from this release, once 2.5 has been fully merged into the libretro core.
Reply
#44
twinaphex is commiting lot's of changes every day into the libretro core - bumping to a newer version of mupen64-libretro is no big deal, so I'd say RetroPlayer will benefit from all this.
Reply
#45
(2015-05-08, 06:24)a1rwolf Wrote: twinaphex is commiting lot's of changes every day into the libretro core - bumping to a newer version of mupen64-libretro is no big deal, so I'd say RetroPlayer will benefit from all this.

That's great, I see Dolphin has been getting some new development builds over last couple of days do you think Retroplayer will eventually support that too?
Reply

Logout Mark Read Team Forum Stats Members Help
Nintendo 64 Emulator3