Which resolutions do you use/want to use?

[MaxSt]

It shouldn't be a problem at all for any platform.

http://sdldoc.csn.ul.ie/sdllistmodes.php

But that link doesn't mention anything about current desktop resolution...

[Nach]

It shouldn't be a problem at all for any platform.

http://sdldoc.csn.ul.ie/sdllistmodes.php

But that link doesn't mention anything about current desktop resolution...

Is that a problem?
And perhaps we just need a different function for that.

[Player1]

I use 80x600 Stretched with interpolation.

I just wanted to mention that this modes should be good explained in the read me, because noobs don't know which resolution to choose.

[Nightcrawler]

It shouldn't be a problem at all for any platform.

http://sdldoc.csn.ul.ie/sdllistmodes.php

But that link doesn't mention anything about current desktop resolution...

Is that a problem?
And perhaps we just need a different function for that.

I don't think it will be. By listing all available resolutions, the current one should be in the list. If SDL can do this, than that is probably a good solution.

I havne't used SDL, so I'm not sure how easy or hard it will be to write some code to handle all the resolutions. Since SDL ultimately uses OpenGL(right?) I imagine it wouldn't be too bad.

[MaxSt]

Is that a problem?

Since I don't care about Linux, it's not a problem for me.

My idea is to add only one "CURRENT" mode to the end of the list.
I'm sure it would be very easy to implement in Windows. I see it as a good compomise.

MaxSt.

[neutrino]

I'd find a 1152x864 fullscreen mode swell, seeing as though that's my desktop resolution. :L

Otherwise I use 768x672 windowed w/ Super 2xSai.

[Nightcrawler]

Is that a problem?

Since I don't care about Linux, it's not a problem for me.

My idea is to add only one "CURRENT" mode to the end of the list.
I'm sure it would be very easy to implement in Windows. I see it as a good compomise.

MaxSt.

Why do you want a 'current' mode if all available vido modes would be listed? The current one would appear in the list somewhere already.

[Agozer]

Is that a problem?

Since I don't care about Linux, it's not a problem for me.

My idea is to add only one "CURRENT" mode to the end of the list.
I'm sure it would be very easy to implement in Windows. I see it as a good compomise.

MaxSt.

Why do you want a 'current' mode if all available vido modes would be listed? The current one would appear in the list somewhere already.

Maybe to help all the übernoobs that don't really know what resolution they use...

[creaothceann]

Maybe to help all the übernoobs that don't really know what resolution they use...

If they can't manage to know what resolution they use, they shouldn't be up to SNES emulation.

[Agozer]

Maybe to help all the übernoobs that don't really know what resolution they use...

If they can't manage to know what resolution they use, they shouldn't be up to SNES emulation.

My thought exactly.

[MaxSt]

Why do you want a 'current' mode if all available vido modes would be listed?

Who said that all available modes will be listed?
As far as I know nobody promised to implement such thing yet.

I propose a compromise - my small idea, which I'm actually willing to implement.

MaxSt.

[Pulsewidth]

ZSNES running windowed at 768x240, with no window border, on a blank desktop of 864x240, overscanned so ZSNES fills the whole screen. All bilinear filtered and kitchensynced at 120Hz, using a custom build.

[Misogynist]

I would like 1600x1200 fullscreen for my LCD since it looks like crap at a non-native resolution and scaling it down to 800x600 isn't much better.

[Jipcy]

We are divorcing windowed/fullscreen from the video modes thing.

What does this mean?

Also, is there currently or will there be a capability to have a Windowed mode with DR? (Locked aspect ratio, graphics filtering?) EDIT: Stupid me, I never noticed the DR windowed modes on the lower resolutions.

Also, can someone explain to me color depth? For example, 16bit and 32bit are common color depths for Windows machines. But (I assume) ZSNES runs in 16bit. So when I switch to 1024x768 DR Full, my monitor flips to 16bit color (making a nice loud clicking sound). Why is it necessary for programs using a lower color depth to switch to that depth? Aren't all the necessary colors already contained in a higher depth? If a program uses 16bit color, and you are in 32bit color, why must it switch down to 16bit color, if all the necessary colors are already available?

[Agozer]

I'm not sure, but I think that it has to do with the amount of memory each color value uses.

[Aerdan]

We are divorcing windowed/fullscreen from the video modes thing.

What does this mean?

It means that, at some point, we're going to make fullscreen a toggle, rather than part of the video mode listing. It will reduce the number of video modes by about 50%, since we basically have duplicate modes for no particular reason.

Also, is there currently or will there be a capability to have a Windowed mode with DR? (Locked aspect ratio, graphics filtering?)

There are already such modes.

Also, can someone explain to me color depth? For example, 16bit and 32bit are common color depths for Windows machines. But (I assume) ZSNES runs in 16bit. So when I switch to 1024x768 DR Full, my monitor flips to 16bit color (making a nice loud clicking sound). Why is it necessary for programs using a lower color depth to switch to that depth? Aren't all the necessary colors already contained in a higher depth? If a program uses 16bit color, and you are in 32bit color, why must it switch down to 16bit color, if all the necessary colors are already available?

The SNES uses a 16-bit palette. The click you hear is ZSNES changing video modes from whatever your current resolution is to the resolution you told ZSNES to use. 24-bit tends to cause problems, since it basically requires more work than 32-bit, as 32-bit colour provides double the SNES palette, whereas 24-bit colour provides 1.5x the SNES palette.

[Feel free to expand upon this, and/or correct me, someone who knows more about this than I.]

[Esturk]

Well on my monitor, the clicking sound is from changing of the refresh rate. I run Zsnes at 640x480DR Full at 60Hz with Triple Buffering enabled. No tearing or any of that crap. My desktop is 1024x768 at 90Hz.

[grinvader]

The SNES uses a 16-bit palette.

More like 15, 555 RGB. :þ
The extra bit is for colour substraction/addition (the snes 'transparency').

[Gil_Hamilton]

The SNES uses a 16-bit palette.

More like 15, 555 RGB. :þ
The extra bit is for colour substraction/addition (the snes 'transparency').

I thought it was just to get things aligned along byte thresholds.
...
Well, that and the fact that most PC video cards don't support 15-bit color.

[grinvader]

The SNES uses a 16-bit palette.

More like 15, 555 RGB. :þ
The extra bit is for colour substraction/addition (the snes 'transparency').

I thought it was just to get things aligned along byte thresholds.
...
Well, that and the fact that most PC video cards don't support 15-bit color.

Sure you can align stuff, but might as well use the bits you're able to use, don't you think ?

Besides, SNES games weren't designed for use on PCs (so they could use non-compatible bit depth), but that's not a real point, since they were probably developped on PCs with a snes sdk...
Overall, any processor runs better when it transfers and works with their registers. So, you have to fit all the required data in those if you want optimal execution times.

[Gil_Hamilton]

The SNES uses a 16-bit palette.

More like 15, 555 RGB. :þ
The extra bit is for colour substraction/addition (the snes 'transparency').

I thought it was just to get things aligned along byte thresholds.
...
Well, that and the fact that most PC video cards don't support 15-bit color.

Sure you can align stuff, but might as well use the bits you're able to use, don't you think ?

Besides, SNES games weren't designed for use on PCs (so they could use non-compatible bit depth), but that's not a real point, since they were probably developped on PCs with a snes sdk...
Overall, any processor runs better when it transfers and works with their registers. So, you have to fit all the required data in those if you want optimal execution times.

I was under the impression that the SNES actually used 15 bits per pixel, and the 16bpp requirement was placed by emus.
I'm not sure how 1 bit would be useful for transparency effects, if you'd care to elighten me.


Adn SNES games were, as I recall, developed on personal computers, but not IBM-compatible ones, at least at first.
Apple 2GS was a common dev system at the beginning, I believe.

[grinvader]

I was under the impression that the SNES actually used 15 bits per pixel, and the 16bpp requirement was placed by emus.
I'm not sure how 1 bit would be useful for transparency effects, if you'd care to elighten me.

The SNES doesn't do real transparency ala RGBA 4444 (for 16 bits). It uses 15 bits for the colour (RGB 555 - each channel varies between 0 and 31 -> 32768 possible colours) and the last bit as pseudo-transparency indicator, meaning that the pixel colour must be added/substracted to the background colour, which is already pretty good for transparency (after all, it works).

I'm not sure exactly, but I think the substraction/addition thing is set in the layer attributes. For example, in a layer set as substraction, all pixels with last bit as '1' will substract to whatever' behind them.
Substraction: with / without BG1 layer [i *think* it's substraction :þ]


Addition: with / without BG2 layer - check the waterfalls


I think only one layer can be set as either substraction/addition at a time. BG2 is enabled here, but there are no waterfalls because the addition is already set to the other layer.

[Gil_Hamilton]

I was under the impression that the SNES actually used 15 bits per pixel, and the 16bpp requirement was placed by emus.
I'm not sure how 1 bit would be useful for transparency effects, if you'd care to elighten me.

The SNES doesn't do real transparency ala RGBA 4444 (for 16 bits). It uses 15 bits for the colour (RGB 555 - each channel varies between 0 and 31 -> 32768 possible colours) and the last bit as pseudo-transparency indicator, meaning that the pixel colour must be added/substracted to the background colour, which is already pretty good for transparency (after all, it works).

I'm not sure exactly, but I think the substraction/addition thing is set in the layer attributes. For example, in a layer set as substraction, all pixels with last bit as '1' will substract to whatever' behind them.

Ah.
I knew about the addition/subtraction. Didn't realize there was a bit to turn it on/off on a per-pixel basis.

[Jipcy]

Also, is there currently or will there be a capability to have a Windowed mode with DR? (Locked aspect ratio, graphics filtering?)

There are already such modes.

Sorry about that. I found those modes AFTER I posted. There were near the bottom and top of the resolution list, far from any of the modes I use.

The click you hear is ZSNES changing video modes from whatever your current resolution is to the resolution you told ZSNES to use.

Case 1: My desktop mode is 1024x768, 16bit color (on a CRT monitor). I set ZSNES to use 1024x768 Full. I start ZSNES, and there is NO click (meaning the monitor has not changed modes).
Case 2: Desktop: 1024x768, 32bit color. ZSNES mode is the same as before. Now when I start ZSNES, the monitor clicks. I assume this is because it is changing from 32bit to 16bit color.

My question is, WHY do monitors change color modes in this case? Aren't all the necessary colors for 16bit already in 32bit color? Is it because of this:

Overall, any processor runs better when it transfers and works with their registers. So, you have to fit all the required data in those if you want optimal execution times.

?

[grinvader]

Overall, any processor runs better when it transfers and works with their registers. So, you have to fit all the required data in those if you want optimal execution times.

?

Let me rephrase.

Processors are good at working with their registers. That's the point of having a computer, fast operations/transfers.
If for some reason one day a processor using 20-bit registers is made, it will work very well with 20/10/5-bit values. But not with 32/16/8-bit ones.

That's what I meant by 'you have to fit all the required data in those [registers] if you want optimal execution times'. Working with 20-bit values on a 32-bit registers processor isn't very efficient (you waste 12 bits at each transfer, and operations won't max the usefulness/time ratio), as is working with 16-bit values on a 20-bit registers processor.

For best results, the amount of data to work with has to match the processor's registers.