libretro / libretro/parallel-n64

Some questions regarding this core and it's future goals

Open
#491 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
407
Forks
151
Avg merge
11h 53m
Merged PRs (30d)
11

Description

Over the years, RetroArch has been made my go-to emulator for most retro systems. It was not long ago I finally ditched Project64 just to migrate to the libretro core alternatives. As of now I use the mupen64plus libretro core for games using the GLideN64 plugin, and in hacks like the Super Mario 64 Multiplayer 2 player hack I have to use the Parallel libretro core because I need a more "hackish" video plugin like rice to properly render the graphics there.

Recently there's been numerous updates to GLideN64 (WIP thread), and looking into the GLideN64 folder of the Parallel-plugin in the Code-section here it seems like the GLideN64 folder was updates two years ago. To my understanding (correct me if I'm wrong) there is no high texture-support included in this core, and to my knowledge this core started as Nintendo 64 Vulkan Low-Level emulator.

In the libretro news article I linked to above one of the quotes regarding Parallel is that it's going to have "a unified HLE video renderer that combines the best of Glide64, Gliden64, Rice, and GLN64, and offers optional runtime codepaths for performance".

Does that mean that in the long run, Parallel is more or less going to replace the mupen64plus libretro core? Is high resolution texture support planned for this core, and what about the newer versions of GLideN64? Are only elements of GLideN64 going to be implemented, or do we also get the option to use an unmodified newer version of GLideN64 as well in Parallel?

The reason for all those questions is that I can't find much documentation regarding this core (the readme.md file is somewhat empty if you as me, the libretro blog post has some info though).

I'm just curious, that's all.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with README.md and compare its coverage with the linked libretro blog post and the GLideN64 folder history. Clarify the core's future goals, relationship to mupen64plus, texture-support plans, and GLideN64 integration, then update the documentation so these questions have explicit answers.

Written by the indexing model from the issue text.

Assessment

Domain
documentation, game-dev
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.