Opengl for zsnes under win.

wah_wah_69 · Post by **wah_wah_69** » Sat Feb 12, 2005 5:05 pm

Hi I've added support for opengl in the win version of zsnes, thanks for the recent work related to mingw use.

I just adapted the linux gl code changing the gl_start/gl_end as needed, in the file winlink.cpp I changed the calls to drawscreen to gl_drawwin.

Gl_start is called in the initwinvideo function I left the directx code untouched as I don't know directx.

Bilinear filtering is on by default, if you change the resolution and/or filter function the picture of the game will be showed in a corner if the display is bigger and if the display is smaller the picture will not be completely shown (there are some vars to be updated when you change resolutions).

Speed? , well it seems to be slower than directx but as I said before I left the directx code untouched and just avoided calling drawscreen, I get ~86 fps while with the official build I get "A0" (100 fps , vsync is turned on).

So is there any use for opengl at all ?
The filter functions could be implemented with shaders (I've been told xmame already does this) , opengl could be used in mode 3 (I think snes9x already does it ).

I based my changes in a cvs checkout from saturday past week , I tried to checkout today and it seemed to be disabled for anon. users.

get it here:http://www.telefonica.net/web2/wahwah69/gl_zsnes.zip (includes both binary and sources)

Jipcy · Post by **Jipcy** » Sun Feb 13, 2005 4:22 pm

I don't know why anybody hasn't replied, but it sounds great to me. Have fun with it.

Aerdan · Post by **Aerdan** » Sun Feb 13, 2005 4:28 pm

Note: Current OpenGL code is slated to be updated eventually with an implementation that didn't come directly from Hell [aka hpsolo].

Clements · Post by **Clements** » Sun Feb 13, 2005 5:31 pm

I got it working. It asked for zlib1.dll though, so popped one in and it started. Buggy, but very nice. Looking forward to seeing OpenGL in the official build.

Dead · Post by **Dead** » Sun Feb 13, 2005 7:53 pm

Wow, this is great news! I like it when somebody drops by with their own build of ZSNES with cool stuff added. Although you seem to claim that you didn't have to put much effort into this, your work is nevertheless appreciated.

I can remember a few years ago when some independent-type fella added his own code to ZSNES. The emulator has never been the same.

Sometimes stuff like this will kick start a revolutionary development phase, we'll have to wait and see. (There's kinda one going on right now)

wah_wah_69 wrote:The filter functions could be implemented with shaders (I've been told xmame already does this)

Hmm... maybe Linux is the OS of choice for MAME now. ...should go check it out...

MaxSt · Post by **MaxSt** » Sun Feb 13, 2005 8:34 pm

Sorry, I don't see the point of doing this. OpenGL is for manipulating 3D stuff mostly. DirectDraw have all the tools for implementing blitting/stretching/vsyncing/page-flipping/triple-buffering/setting-the-video-mode/whatever already.

You've got IDirectDraw7 interface - you've got all the tools you need.

DirectSound and DirectInput are already used for sound and input anyway, so why not continue using DirectDraw for graphics?

bohdy · Post by **bohdy** » Sun Feb 13, 2005 9:42 pm

MaxSt wrote:Sorry, I don't see the point of doing this. OpenGL is for manipulating 3D stuff mostly. DirectDraw have all the tools for implementing blitting/stretching/vsyncing/page-flipping/triple-buffering/setting-the-video-mode/whatever already.

You've got IDirectDraw7 interface - you've got all the tools you need.

DirectSound and DirectInput are already used for sound and input anyway, so why not continue using DirectDraw for graphics?

I suppose that you haven't seen the fragment shader version of your own HQ algorithm yet then? I'd link you, but I can't find xmame's CVS website

Point is, offloading some effects onto the GPU is quite useful.

Another idea to expand upon snes9x's bilinear mode 7 is to actually use polygons for mode7 effects. Run a scaler over the source art, map it onto a quad complete with bilinear/aniso and you have sharp mode7 effects free of aliasing. There is a lot of petential in this area.

MaxSt · Post by **MaxSt** » Mon Feb 14, 2005 5:40 am

bohdy wrote:I suppose that you haven't seen the fragment shader version of your own HQ algorithm yet then?

I don't believe it's possible. HQ algorithms are too complicated.

bohdy wrote:Point is, offloading some effects onto the GPU is quite useful.

Not much. You can't save a lot on small stuff.

MaxSt.

bohdy · Post by **bohdy** » Mon Feb 14, 2005 9:34 am

MaxSt wrote:
bohdy wrote:I suppose that you haven't seen the fragment shader version of your own HQ algorithm yet then?
I don't believe it's possible. HQ algorithms are too complicated.

Have a look: http://www.mail-archive.com/xmame@toybo ... 07945.html

Nightcrawler · Post by **Nightcrawler** » Mon Feb 14, 2005 2:31 pm

MaxSt wrote:Sorry, I don't see the point of doing this. OpenGL is for manipulating 3D stuff mostly. DirectDraw have all the tools for implementing blitting/stretching/vsyncing/page-flipping/triple-buffering/setting-the-video-mode/whatever already.

You've got IDirectDraw7 interface - you've got all the tools you need.

DirectSound and DirectInput are already used for sound and input anyway, so why not continue using DirectDraw for graphics?

We've had several discussions on this board to several advantages using D3D or OpenGL can bring to the table for ZSNES.

Just to reiterate, one of the biggest was much easier mass resolution and aspect ratio handling which I think you were even involved in that conversation.

I wouldn't be so quick to dismiss OpenGL or D3D as they can do alot for 2d material. It sounds to me as if you really haven't used them. If you have and still hold this opinion, then I apologize.

Clements · Post by **Clements** » Mon Feb 14, 2005 4:50 pm

Perhaps we could finally lose this bit of windows specific code. This however is a longshot as people still use video cards not capable of OpenGL due to drivers and would whine about it.

Dead · Post by **Dead** » Mon Feb 14, 2005 6:48 pm

Clements wrote:Perhaps we could finally lose this bit of windows specific code. This however is a longshot as people still use video cards not capable of OpenGL due to drivers and would whine about it.

How about polling the zboard on this issue?

creaothceann · Post by **creaothceann** » Mon Feb 14, 2005 7:00 pm

If support for these machines is dropped, then the resolutions below 512x448 could also be removed... IMO.

kieran_ · Post by **kieran_** » Mon Feb 14, 2005 7:04 pm

creaothceann wrote:If support for these machines is dropped, then the resolutions below 512x448 could also be removed... IMO.

Then you would not be able to play with the native resolution of the snes.

creaothceann · Post by **creaothceann** » Mon Feb 14, 2005 7:08 pm

Sure you would... you'd just have to stretch the output from 256x224 -> 512x448.
Doesn't work the other way 'round.

Noxious Ninja · Post by **Noxious Ninja** » Mon Feb 14, 2005 9:23 pm

Is this such a good idea? Grin says the current OpenGL code makes baby Jesus cry.

MaxSt · Post by **MaxSt** » Mon Feb 14, 2005 11:06 pm

bohdy wrote: Have a look: http://www.mail-archive.com/xmame@toybo ... 07945.html

It's just a chat. I don't see it in the official "changes" list.
Beisdes, it would only make sense for hq4x. hq2x is fast enough already, in CPU implementation.

MaxSt.

MaxSt · Post by **MaxSt** » Mon Feb 14, 2005 11:21 pm

Nightcrawler wrote:We've had several discussions on this board to several advantages using D3D or OpenGL can bring to the table for ZSNES.

Just to reiterate, one of the biggest was much easier mass resolution and aspect ratio handling which I think you were even involved in that conversation.

Capabilities to handle resolutions and aspect ratios are pretty much the same in DX and OGL.

Do you know how it's handled now? You just need to specify the input rectangle (like 512x448 after 2x filter), the output rectangle (like 1024x768 screen), and IDirectDraw7->Blt() function does the rest.

It can't be more simple than that.

MaxSt.

Reznor007 · Post by **Reznor007** » Tue Feb 15, 2005 12:15 am

MaxSt wrote:
bohdy wrote: Have a look: http://www.mail-archive.com/xmame@toybo ... 07945.html
It's just a chat. I don't see it in the official "changes" list.
Beisdes, it would only make sense for hq4x. hq2x is fast enough already, in CPU implementation.

MaxSt.

http://users.ox.ac.uk/~newc2303/gpupatch.txt

Edit-that might only be the scale2x fragment program, but the author says he can do hqx algorithms.

MaxSt · Post by **MaxSt** » Tue Feb 15, 2005 5:33 am

Reznor007 wrote: http://users.ox.ac.uk/~newc2303/gpupatch.txt

Nothing about hq here.

Reznor007 wrote: but the author says he can do hqx algorithms.

As I said, it's just a chat.

Bahamut_ZERO_Clue · Post by **Bahamut_ZERO_Clue** » Sat Feb 19, 2005 3:37 am

Well it did prove it COULD be workable. Anyway...

DirectDraw is hardware accelerated under Windows. OpenGL would have a minimal positive effect except in the case of stretch and filter as Snes9x does. Linux/X11 was the only real beneficiary of OpenGL accelerated graphics as X11 itself is NOT hardware accelerated.

The effect on the HQ modes would be next to nothing as it still would require CPU power for the software filtering. HQ would have to be written directly into OpenGL itself.

The only people who would complain about OpenGL are those who use various onboard video graphics chips, old outdated unsupported graphics cards, and Matrox video cards.

OpenGL on Windows would only offload the effect of stretching the screen, the interpolated video post-processing, and the page flipping (double/triple buffering). A minimal gain and one only benefiting someone running a very low end Pentium2 or Celeron with a 3D acceleration video card.

I do have to say though, while the impliementation was crude and buggy, when properly applied it will work flawlessly. BTW make sure you DO include an option in the GUI selection of video modes to select OpenGL or Normal rendering even at higher resolutions.

MaxSt · Post by **MaxSt** » Sat Feb 19, 2005 5:05 am

Bahamut_ZERO_939 wrote: DirectDraw is hardware accelerated under Windows. OpenGL would have a minimal positive effect except in the case of stretch and filter as Snes9x does.

Not "minimal", but "zero".
OpenGL would have zero positive effect over DirectDraw.

DirectDraw is more "low-level" then OGL.

MaxSt.

Reznor007 · Post by **Reznor007** » Sat Feb 19, 2005 5:14 am

MaxSt wrote:
Bahamut_ZERO_939 wrote: DirectDraw is hardware accelerated under Windows. OpenGL would have a minimal positive effect except in the case of stretch and filter as Snes9x does.
Not "minimal", but "zero".
OpenGL would have zero positive effect over DirectDraw.

DirectDraw is more "low-level" then OGL.

MaxSt.

In current DirectX releases DDraw is a part of Direct3D. So using D3D would be just as fast(at least for non-crappy video chips).

Bahamut_ZERO_Clue · Post by **Bahamut_ZERO_Clue** » Thu Feb 24, 2005 1:45 am

As of DirectX 8.0 this has how it's been. Well when I meant minimal I meant next to no gains really.

MaxSt · Post by **MaxSt** » Thu Feb 24, 2005 5:24 am

Reznor007 wrote:In current DirectX releases DDraw is a part of Direct3D.

It only matters if you use new interfaces.
ZSNES uses IDirectDraw7 interface (from ddraw.dll), which is not a part of any 3D.

MaxSt.

ZSNES board

Opengl for zsnes under win.

Opengl for zsnes under win.

Re: Opengl for zsnes under win.