2014-11-29, 13:26
after hours of reading about opengl, libretro, talking to guys from retroarch and garbear I got rid of my initial crashes :-)
2014-11-29, 15:27
Its good to see that this project still has some activity on it with garbear being busy, I'm glad to hear that you have been making progress, I'm sure it was a steep learning curve 
2014-11-29, 19:46
i guess learning ain't over, but it's better to work on sth not crashing immediately :-)
2014-12-09, 12:24
hey folks!
not quite there but look at this
not quite there but look at this
2014-12-09, 12:37
sry will check again
edit: should work now
edit: should work now
I think that I just wet myself a little and might need a clean pair of pants.
What hardware are you running your test on and does it offload graphics to GPU now?
Keep up your great work!
What hardware are you running your test on and does it offload graphics to GPU now?
Keep up your great work!
2014-12-09, 15:24
I'm developing on a Lenovo X230 notebook with i5 CPU and ArchLinux installed.
Just wanted to share my progress but there's a lot left:
* Texture size seems odd to me
* broke libretro-cores that do not use the GL extension
* need a fix for gamepads with analog sticks
* most likely leaking memory
* not rendering depth right now
It should offload graphics to GPU, afaik.
Just wanted to share my progress but there's a lot left:
* Texture size seems odd to me
* broke libretro-cores that do not use the GL extension
* need a fix for gamepads with analog sticks
* most likely leaking memory
* not rendering depth right now
It should offload graphics to GPU, afaik.
2014-12-09, 15:39
Hey! This is amazing! As far as I know garbear has written some code to simplify joystick input. Maybe you can find it in his github repo 
2014-12-09, 16:07
I know, I had a crash when starting n64 games and fixed it by removing one line of code.
I guess this quick "fix" broke sth -but I focus on getting the rendering right for now and fix this later on.
I guess this quick "fix" broke sth -but I focus on getting the rendering right for now and fix this later on.
2014-12-09, 20:39
Nice!, good to hear u made progress. Do u think that the core could run/perform on a raspberry pi?
(In the future)
(In the future)
2014-12-09, 22:25
Honestly, I'm not sure - maybe there is a dev who can answer this.
As for my understanding, once it works with OpenGL ES it could technically work on a pi, but I have no idea how much performance this thing needs.
I currently focused GLX (because my system is using it by default) but it needs to work with EGL (OpenGL ES) anyway.
As for my understanding, once it works with OpenGL ES it could technically work on a pi, but I have no idea how much performance this thing needs.
I currently focused GLX (because my system is using it by default) but it needs to work with EGL (OpenGL ES) anyway.
2014-12-10, 18:31
Does retroarch run the Mupen64Core okay on the pi? If so, then there is a chance Kodi will as well, if not I can't see Kodi fairing much better.
What base are you currently working on, the 13.x base that garbear last released? Is this going to get rebased against 14 final when its released?
What base are you currently working on, the 13.x base that garbear last released? Is this going to get rebased against 14 final when its released?
2014-12-10, 19:37
I don't know if mupen64core does run on the pi, but if so you still need to offer OPENGL ES on the frontend side.
I work on the 13.1 base that garbear released last and I want to focus on getting this thing running no matter what version.
Can't say if there are any plans on rebasing but I guess so.
I work on the 13.1 base that garbear released last and I want to focus on getting this thing running no matter what version.
Can't say if there are any plans on rebasing but I guess so.
2014-12-12, 00:42
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...
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...
