gonetz / GLideN64

A new generation, open-source graphics plugin for N64 emulators.
Other
754 stars 175 forks source link

'Error while setting pixel format' if switching midgame from other OGL plugin on Windows #921

Open oddMLan opened 8 years ago

oddMLan commented 8 years ago

https://github.com/project64/project64/issues/1030#issuecomment-199026146 Same issue.

cxd4 comments:

It's the GDI pixel format used to create the context on Windows.

With WGL you can only set a pixel format for OpenGL exactly one time, unless you are able to destroy and recreate the entire window which is not something the plugin specs for Project64 would conceive.

Can't remember whether my fork of angrylion is affected or not. I remember just reading for any existing pixel formats and just trying to use those, which has a higher chance of dodging the issue.

Since this is a Windows limitation, Is it viable for GLideN64 to attempt to use already existing pixel-formats to dodge the problem?

gonetz commented 8 years ago

Ok, who will take that task?

oddMLan commented 8 years ago

Um, well, I guess you are asking because I also opened a ticket in Project64's repo. But in fact, these are two different approaches to eliminate or dodge the issue. The emulator itself could destroy and create another window to reinitialize the pixel formats the plugin requires, but for extra safety, the plugin could (to the extent possible) read from the already existing pixel formats if other plugin has set those before. I think the emulator side approach is the most correct, but I was just asking if it's viable for GLideN64's to just read from existing pixel formats, unless that could cause more issues or it's just not worth to code. This is not a problem on Linux, just on Windows, so hypothetically if zilmar did code the solution in Project64, coding it into the plugin might seem redundant, but other emulators on Windows could benefit from the extra safety from the plugin's side.

gonetz commented 8 years ago

No, I'm asking because I don't have time on it. This task does not require skills in N64 emulation. Anyone can take it. I'm overloaded with bugfixes. So, who will take that task?

AmbientMalice commented 8 years ago

Zilmar has said he can look at the issue down the track. https://github.com/project64/project64/issues/1030#issuecomment-199053708 It's not a HUGE problem currently, so I think it should be sat on for now.

olivieryuyu commented 6 years ago

is is still happening?

gonetz commented 6 years ago

I believe it is fixed in PJ64 2.3

olivieryuyu commented 6 years ago

@oddMLan

can you please check and close? I have no more issue with this message error.

oddMLan commented 6 years ago

Open config while game is open and change plugin to PJ64Glide or press F12 while ROM is playing change to or switch from GLideN64 to PJ64Glide (or vice versa)

image

Tested with the latest nightly build from http://www.pj64-emu.com/nightly-builds v2.4.0-522-gb5c8a0f

oddMLan commented 6 years ago

Apparently it regressed on PJ64's side. Hm. GLideN64 could always use the extra safety tho. Not super high priority though.