Login at Kodi Home

athei · 2015-04-10, 19:58

I cloned and built your branch on OS X 10.10. I see that n64 and nestopia where included for an convenient in tree build. First I tried an N64 Rom:

1. Added the location with the roms as source under "Games".
2. Clicked the n64 rom file and select mupen64plus from the context menu.
3. kodi crashes (calling a null pointer which comes clear from the following screenshot)
Stacktrace: http://imgur.com/gl3P73f
Debug Log: http://pastebin.com/29BdegzU

Then I tried an NES Rom. I got no sound and no idea how to give input to the emulator. Do I have to put in a gamepad (I do have an xbox360 controller) since keyboard input is not working (I guess I have to configure keybindings in some config file?)
Debug Log: http://pastebin.com/6YAKu6dW

**a1rwulf** · 2015-04-10, 22:13

n64 needs the libretro-gl extension, I'm sporadically working on it since october last year Big Grin

http://forum.kodi.tv/showthread.php?tid=205571

You can have a look at:
https://github.com/a1rwulf/xbmc/commits/...5alpha2-gl

Note that I work on linux and cannot work on OSX as I have no hardware. So it will not work for you.
I think input is still in progress, but there are a lot of commits today:
https://github.com/garbear/xbmc/commits/...r-15alpha2

I have no idea about sound, though.

athei · 2015-04-11, 00:46

I am completely new to to kodi and really want to sink in my teeth. Despite the fact that I have a strong C++ background I gain understanding very slowly from reading the source code.

As far as I see it in garbears branch it is hardcoded that the game client has to to return a YUV420P pixel matrix. You generalized this to all supported formats and added a mode where the game client gets an OpenGL context to render into instead of returning pixel data. Is this correct?

I think this is a good idea. But I have to ask myself: Doesn't the mupen64plus creates it's own context for rendering since it originally was a standalone emulator.

I am especially interested in passing through encoded video and audio streams and let kodi handle the decoding for example for implementing a limelight game client (I know there is a gsoc application).

**a1rwulf** · (This post was last modified: 2015-04-11, 07:57 by a1rwulf.)

I was in the same situation last year and I still know very little about all this.
This is what I found out when trying to get n64 (thx to garbear, FernetMenta and the guys of libretro).
You are right mupen64 is a standalone emulator but we use mupen64libretro, it's the libretro port of it.
Libretro is designed to have a frontend (retroarch is the reference implementation), it does handle rendering, audio, input etc. and a backend, the libretro-cores.
They are loaded by the frontend as shared objects.
There is an API definition that must be implemented to clue them together.

The n64 core needs hardware acceleration and cannot be used like the other cores.
Libretro defines functions that allow you to feed a framebuffer into the backend.
The fact that the kodi renderer runs in a different thread then retroplayer results in a shared opengl context.

So I don't give the context into the mupen core I just let it render on my framebuffer. Then I share the rendered texture with kodi's renderer.
I did no change to the pixelmatrix part, at least not intended :-)

Hope this helps to understand.

athei · 2015-04-11, 08:43

So you mean there is an extra context for Retroplayer that shares a texture with the Kodi context which renders to screen.

I looked over your commits. At first glance I did not see any synchronization between the two contexts (i could easily overlooked ANYTHING). I have read about some flickering problems you have. Maybe they are coming from there. Easiest method to test would be calling glFinish() after rendering to the shared texture.

**a1rwulf** · 2015-04-11, 08:50

Exactly. In Opengl every thread needs its own gl context, afaik.
Flickering is fixed when switching to the gfx plugin rice within the mupen64 addon settings, so i'm not sure if it's my code or something else. When input is ready and we can actually play a game there will be lots of changes needed I guess. My code is still kind of a POC.
And yes there's no synchronisation (yet?, dunno if needed or not).

athei · 2015-04-11, 14:36

Synchronisation between contexts is definitely needed but I have no idea if it is already provided somehow by kodi. But the bug you are experiencing can be everything of course. Flickering often leads to the depth buffer (z fighting).

**a1rwulf** · 2015-04-12, 22:40

I didn't look into all this details yet - mostly because it's quite senseless until one can actually play a game.
Hunting bugs will be much more effective (and exciting) when we have more than a working intro.
I had a look at the retroarch project in the early stage of my research, but I couldn't really figure out how they synchronize.
IIRC it's single threaded there, so maybe it's not even needed there.
I think when input is ready (I don't know if it is already, but on my system something doesn't work out), it will be the right time to push further in this area too.

**garbear** · 2015-04-13, 05:24

input is working at a basic level now. you'll need to press "t" to launch ActivateWindow(GamePeripherals), and from there configure the keyboard for the NES controller. Then, in game.libretro.nestopia, the keys you've chosen will control the emulator

**garbear** · (This post was last modified: 2015-04-13, 06:00 by garbear.)

the generated button map is stored in userdata/addon_data/peripheral.joystick/buttonmap.xml. NES controller for keyboard input looks like this:

Code:
<?xml version="1.0" ?>

<buttonmap>

    <devices>

        <device name="Keyboard" provider="application">

            <profile id="game.controller.nes">

                <feature name="a" button="90" />

                <feature name="b" button="88" />

                <feature name="down" button="129" />

                <feature name="left" button="130" />

                <feature name="right" button="131" />

                <feature name="select" button="92" />

                <feature name="start" button="13" />

                <feature name="up" button="128" />

            </profile>

        </device>

    </devices>

</buttonmap>

the keyboard is emulated by a joystick with a large amount of digital buttons, 0 hats and 0 axes

eventually we will build a database of devices and how they map to each different kind of game controller. The layout for these controllers is stored here: https://github.com/kodi-game/kodi-game-p...ter/addons

**a1rwulf** · 2015-04-13, 08:00

thanks for your replay garbear.
I tried yesterday, but there are a few issues I have to investigate further on my system:
* my xbox360 joystick is not found (I hacked it in last night but it's not fixed)
* when trying to map buttons, kodi crashes
* the log says something like "there's no feature for button "x" in game.controller.default"

I don't want to hijack this thread - so I'll open a new one with logs, stacktrace, etc. when I have some time.

**garbear** · 2015-04-13, 08:27

i'm debugging controller input. use the keyboard for now. it emulators a joystick with many buttons and no hats or axes, so much of the same code gets hit.

**a1rwulf** · 2015-04-13, 09:25

ah ok, thx Smile

will try to help you and post my findings in a separat thread