Google Summer of Code Ideas

What do you think about a repo for Centos /Fedora and rpm retroarch , and a appimage or flatpack ?

Good idea, but not a one time job, it’s something that requires staying in the team for years.

If that isn’t too complex, it would be worthwhile. A lot of engines that would be nice to have as core use SDL, and it’s a popular library so for some it might be easier to work with libretro through it. Is the libretro-sdl repo an attempt to do that for SDL-1.2?

since OpenTyrian is mentioned, is OpenTTD also an option?

There are a bunch of great clones and user-driven-content engines, and pretty much all of them are built around SDL. I know Twinaphex had started an SDL-to-libretro wrapper at some point but I don’t know how far he got. If a student could either build/extend that or just start from scratch, it would make shallow forks (and therefore, the possibility of upstreaming) much more realistic.

What is “Zelda Classic”? Any ressources?

~2 months ago, Lugaru HD became fully open source (C++ code). Suitable for a gamepad and with support for custom campaigns and missions (not many in there, but there are more in wolfire forums). So maybe it’s a good candidate for a content-loading core.

If that isn’t too complex, it would be worthwhile. A lot of engines that would be nice to have as core use SDL, and it’s a popular library so for some it might be easier to work with libretro through it. Is the libretro-sdl2 repo an attempt to do that for SDL-1.2?

I believe that was some of Twinaphex’s goals behind https://github.com/libretro/libretro-sdl . He unfortunately didn’t get through it all, as there is so much to do.

I worry that this list will be forgotten about in the future. I think that the github issue tracker is a better place for such lists once the discussion is through. Am I crazy on this?

No, you’re right. We didn’t get approved for GSoC, but these are still good possibilities for bounties.

I love the sound of all these ideas, make me excited for the future of RetroArch <3

integrate the GLSL optimizer library into Retroarch permits significant shader performance increases at shader compile time. would especially help low-performance devices (raspberry pi, android phones, etc). i tried to do this but it was a bit beyond my C++ :slight_smile: see GLSL optimizer for shaders on GLSL-only devices

it would be an awesome thing to have, though. XMB and shader performance got a tasty bump in my tests.

Not to hard for 1.2
In the past have done a POC of it ,but very wip/buggy/bad coding so can’t share code for now :slight_smile: maybe a day if i have some spare time.

here an sample of a core that can be build with http://dl.free.fr/ormBVARl4 (tips: data folder goes to retroarch system directory)

  • libretro wrapper for byuu’s Emulator:: interface that would let us port all of his cores at once

In my opinion, this is a really cool idea. Hopefully someone will tackle this. It seems that the current bsnes/higan libretro ports are a bit outdated compared to the current higan upstream…

I’m starting to see the term “outdated” thrown around more and more, which I guess was inevitable as higan’s version numbers tick up, but if you look at the changes, very little has been done to the SNES core since v094, and only one thing affects a commercial game, AFAIK (that is, a minor visual glitch that occurs in Star Ocean while a certain spell is cast).

Don’t expect to much , except crash or freeze :slight_smile: it’s only a POC of opentyrian using my sdl-lbretro POC.

put the tyrian data(data folder from official bundle) inside retroarch system directory in a folder named tyrian-data. sound is bad and it freeze in some part of menu ('but start arcade game or demo should work)

http://dl.free.fr/oOnjo2zYy

2 Likes

lol I compile official mame0.139 with it (meaning sdl osd) and it work fine .

Man, that’s great! Carving SDL out of the runloops is always a huge hassle, so being able to just libco it opens a lot of possibilities.

EDIT: we might want to try upstream DOSbox with sdl-libretro to see if it works any better than our current fork.

Not sure it work better than libretro one , but surely more buggy at this point :slight_smile: eg:toggle fullscreen segfault … libretro-sdl is only a poc. but if you want check