Project

General

Profile

Actions

Emulator Issues #209

closed

OGL Was Changed in the 500's & It Caused Shading Blackness In SSBM Like DX9 Plugin

Added by josh.lar.JL about 16 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

What steps will reproduce the problem?

  1. Play Smash bros on latest rev
  2. Play in like corneria or something
  3. See black polygons in level like DX9
    Before that rev, it looked perfect, why was it changed, could it please be
    reverted or add an option to get both, I'de use the older version of the
    dll but that doesnt work... and I'de like to have sound so...

Thanks

Actions #1

Updated by Sonicadvance1 about 16 years ago

I will need an exact revision number that introduced this, or else I can't help.

Actions #2

Updated by jpeterson57 about 16 years ago

I'd say it's between 550 and 600. I compiled 500, 550 and 600 and it seems like it
was only 600 that had the problem. And it's not a texture per se, it seems like it
more of a shadow that cause almost total blackness. You can see it on the jungle
level with the platforms. I couldn't find any obvious revision that was reponsible
however. I guess I'll just have to compile 575 to, then 560 or 590 and so on, to
locate the exact revision. I can't deinately say that it's not a combination of exe,
but I tried several different exes, 500, 525, 550 so it seems to be the dll.

Actions #3

Updated by tommyhl2.SS about 16 years ago

DX9 has been like this since r1, surly that can be fixed as well.

DX9 - do nothing to fix it?

OGL - Fix it right away?

Actions #4

Updated by josh.lar.JL about 16 years ago

Hello,

I went through every revision and the exact revision that causes the problem is r484

  • casting, it also makes sense....
    r484
    casting
    Sep 08, 2008
    nakeee

The vertex shader was changed, try reverting this fix and see what happens

Actions #5

Updated by Anonymous about 16 years ago

i tried reversing just the changes in r484, and there was still blackness in ssbm.
just for the record...

Actions #6

Updated by josh.lar.JL about 16 years ago

Then maybe it's as jp said, multiple revisions,

Actions #7

Updated by jpeterson57 about 16 years ago

Yes I was way off when thinking it was around 550-600, it was probably rev 484 as
you said. However I didn't test rev 483 because then I would have to compile it
myself to try it. And the problem could be a combination of revisions, or a
combination of exe and dll. I guess a change in PixelEngine or VideoInterface could
also have these effects. However I don't know of any changes to those files.

Actions #8

Updated by jpeterson57 about 16 years ago

I mean 483. But I haven't tried 482.

Actions #9

Updated by slink_3_ about 16 years ago

yes it's r483 that kinda broke it, here is my post with the exact code that cause the
problem :
http://forums.ngemu.com/dolphin-discussion/112196-when-ogl-problem-going-fixed.html#post1468951

but here's some fact, earlier revs (300 to 482) already had some problems with SSBM
when res was higher than 1024x768, but didn't have problems with 640x480 and 800x600...

But unfortunately just reverting the code changed in r483 that caused the SSBM
Blackness (^see post) only fix the it while playing in 640x480. So i guess something
else was changed in newer revs that also caused some blackness with 800x600.

So, something was definitely wrong from the start, there's some bad scaling or
something, but anyway, SSBM now plays in default 640x480 res without blackness :D

Actions #10

Updated by josh.lar.JL about 16 years ago

How strange, so it is multiple revs, I wish there was a way of using the new sound
functions that jp added with rev < 483 because I wouldn't mind just having a special
rev that is only to play smash w/ 1680x1050 & sound, because now that it has sound,
graphics are messed up, replcing dll doesn't work.... so I think sonic (or a dev)
shoul start by reverting chanes made in 483 then we would ave to bruteforce and try
revertig each revision (thats relaed to video in some way)and pile them on until it
orks, then trt unreverting them and when it stops working,rerevert it until you have
an optimal solution....

Actions #11

Updated by nakeee about 16 years ago

// Line 208 of TextureMngr.cpp in OGL plugin :

// From

if((entry.isRenderTarget || ((u32 *)ptr)[entry.hashoffset] == entry.hash) && palhash
== entry.paletteHash) { ... }

// To

if(entry.isRenderTarget || ((u32 *)ptr)[entry.hashoffset] == entry.hash && palhash ==
entry.paletteHash) { ... }

What compiler are you using? || should have the same priority as &&

Actions #12

Updated by nakeee about 16 years ago

  • Status changed from New to Fixed

ok my bad,
&& comes before || :)

Fixed the line in SVN thanks!:)

Actions #13

Updated by jpeterson57 about 16 years ago

Do you really want to call this fixed? It only works when the resolution is exactly
640x480. So it almost never works when you render to main window unless you have
some very good windows resizing skills.

Actions #14

Updated by nakeee about 16 years ago

The other problem is in the resizing code, and is already attended to under a
different issue

Actions #15

Updated by jpeterson57 about 16 years ago

I added the old functionality option to the GUI now. So that's an easy way to get
SSBM to work. However the core problem is not solved since small alterations can
bring the bug back. For example the change to glViewport() in
VertexShaderManager.cpp for my aspect ratio option brings the bug back.

Actions

Also available in: Atom PDF