Discussion in 'no$psx Discussion' started by SolisX, Dec 4, 2013.
Ok no problem. I wil try and retest again when the new vesrion comes out.
Well it does appear to be more sporadic in no$psx then other emulators, true.
I didn't compare it to other emus. I wonder is making that difference... and which emulation behaviour is closer to real hardware. If no$psx is more unpredictable: that sounds bad. On the other hand, if other emus do more constantly fail on the timing, that sounds bad too : - )
Btw. what is that "Risk" feature in that game about? Could that affect the problem? For example, at high risk, the game might intentionally show the exclamation marks at the wrong time?
Of course in that case, the question would be why it's also happening at low risk (one guess would be a mis-initialized random seed).
Thanks. Current snapshot hotkeys should be F7 and F8. When using F1, that would be traditionally showing a Help screen.
For an audio volume option. How should that be implemented? I could think of several ways: Either by the mixer hardware (as used for the speaker symbol in windows task bar), or by software.
1) Mixer main volume - that would be probably rather uncommon.
2) Mixer Wav volume - common for mp3 players (eg. qmp or winamp)
3) Software multiply - also common (eg. the youtube volume control in browsers)
4) Software shift right - similar as multiply (but faster & offering only normal, div2, div4, div8, div16)
Mixer hardware would be fastest. The downside is that it would also affect all other tasks (such like browsers, mp3 players, other games etc).
Software would affect only the no$psx volume. Downsides are that it would be slower (especially multiply; unless one could combine it with the PSX's own master volume factor), and after multiplying 16bit audio by small factors (or same for right shifting): The result would be less than 16bit, so it'd slightly drop audio quality.
I don't think overall performance will take a noticeable hit by adding a volume control (number 3, software multiply).
With higher risk your attack decreases along with your defense. It doesn't affect timing however.
ePSXe seems to have a constant timing, but still way shorter then on actual PS1.
Don't worry if you can't get it working. It must be something exotic as no one managed to reproduce it accurately.
Multiplications always hurt me. Doing that 88200 multiplications per second (for 44.1kHz/stereo) on a Gameboy Classic emu would be fatal to its performance. But a PSX emu needs quite CPU load anyways, so won't make up too much of the overall performance.
And in PSX, I can probably really merge it with master volume calculatation, ie.
old version ---> output = output*MasterVolume
new version ---> output = output*(MasterVolume*UserSelectedVolume)
which won't affect performance at all (when precalculating MasterVolume*UserSelectedVolume).
Only problem is that, in the next step is, output gets saturated to -8000h..+7FFFh.
To be most accurate that should be changed to saturating to -8000h*UserSelectedVolume..+7FFFh*UserSelectedVolume.
But I guess... I'll be lame and simply ignore that issue.
So, the preferred solution would Software multiply? And not to use the PC's hardware mixer?
My preferred solution would be to just use the per-application volume slider, if using Vista or newer Windows OS. No need to code anything, and you get a pretty slider. =D
I've never heard of a per-application volume slider.
Do you mean something like this http://howto.cnet.com/8301-11310_39...-volume-levels-for-applications-on-windows-7/ saying "Step 3: Find the application whose sounds are offending your ears in the list and adjust its associated slider to a more reasonable volume"?
According to that info, it should already work automatically, at least on windows 7, and I really won't need to code anything?
Or do I need to add something in my executable to support that feature?
PS. I am using win98. It doesn't matter too much too me if the volume control is working on my computer, but of course no$psx itself must be kept compatible with win9x.
Yeah, that's the thing. A device volume and per-application volume sliders that work automagically for every application. I have a reset .reg file that removes all the saved volumes, cuz I sometimes forget I had mutted an application. So no need to code anything for that, unless you want the slider to respond to multimedia keys.
What are you using for sound API? Shouldn't it have some sort of instance / channel volume thing?
Whatta hell! That explains why all your emulators have a not so good looking Win98 GUI. O_O
Let's see I got it right: no$psx volume control does already work perfectly when doing the "Step 3: Find the application..." stuff. But there are users who are unable to complete that step (how stupid is that?) - so I would need to add an equivalent slider in the no$psx options screen.
I am using "waveOutWrite" http://msdn.microsoft.com/en-us/library/windows/desktop/dd743876(v=vs.85).aspx
There appears to be also a "waveOutSetVolume" function, but I don't know what it does. The description http://msdn.microsoft.com/en-us/library/windows/desktop/dd743874(v=vs.85).aspx doesn't mention that its setting could be also changed via the windows volume control screen - but as you said it's happening "automagically" maybe it's just happening that way.
This page http://www.codeproject.com/Questions/337900/Volume-control-in-Windows-7 is hinting that it does actually behave as so (ignore the question & solution 1, and instead look only at solution 2).
If I do use waveOutSetVolume (and waveOutGetVolume), I guess I could save the volume setting in the no$psx.ini file (maybe useful on older windows versions, with didn't have per-application sliders; and it shouldn't conflict with newer versions which do have them).
Maybe. Or might be because I didn't use skins or such stuff.
The main difference that I know of is that WinXP and up defaults to using candy-colored captions, and throwing cartoon bubbles about service pack updates in the taskbar (which both happens even when running no$psx, unfortunately).
Or are there further differences? Like using different fonts in dialog boxes, or using a different GUI in fileselection screens? Ie. stuff that shows up only for executables that are somehow marked as "compatible with newer windows gui"?
For multimedia keys, there seem to be these ones
VK_VOLUME_MUTE = 0ADh
VK_VOLUME_DOWN = 0AEh
VK_VOLUME_UP = 0AFh
I guess they are working in no$psx debug window? I know that they are of not much use in that window, but they do work, right?
And they are NOT working in no$psx game window? That would be because I using the VK_xxx messages for keyboard/joypad emulation.
For fixing that issue, I would just need to check if keycode is 0ADh..0AFh, and get those messages passed on to the OS instead of treating them as joypad keys.
Or would I need to handle those VK_VOLUME stuff myself (like by calling that waveOutSetVolume function manually)?
Hmmm, or are the VK_VOLUME keys currently owned by something else, like your favorite mp3 player? Then it might be not desired if no$psx would steal those keys for it's own purposes.
PS. My keyboard is older than my OS. An old DOS keyboard. I've kept it when those new "Windows 95 Keyboards" with new Microsoft keys and short Space bars came up. Meanwhile, there seem to be a bunch of other new keys like VK_BROWSER_xxx and VK_MEDIA_xxx and VK_ZOOM, see here for more: http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx should any of those be handled (or NOT be handled) differently as done currently in no$psx?
The other differences are the style/size of the buttons like "Ok and "Cancel" and the color of the GUI itself.
@nocash: I think you're overthinking the volume slider thing.
Forget about the keys, forget about the vista+ mixer. If you really want a volume control, I would try the waveOutSetVolume thing, as it seems to be the simplest option.
Sorry nocash, I never thought my idea about Volume slider cause too much problems for you...
Relax and rest, you can complete it later. No problem!
No problem here. Some other people also requested that feature. I am just trying to figure out the best way to implement it.
Does your Operating System allow you to change per-application volume as described here: http://howto.cnet.com/8301-11310_39...-volume-levels-for-applications-on-windows-7/ ? And if yes, does it memorize the setting so you get the desired volume each time when loading no$psx?
Win9x was using very huge Ok/Cancel buttons. I've adapopted that big buttons in the file selection menues. But I am using slightly smaller buttons in my own dialog boxes, eg. in the Options screen. I hope that isn't causing problems... I remember once having seen a screenshot with the Ok/Cancel text being vertically mis-centered within the button field.
No idea why the GUI colors could be different. In most cases I don't touch them at all (and just let windows do the coloring). In some owner drawn windows I am using the Color Scheme settings (eg. in windows Display preferences, you could change the black-text-on-white-background which being used in the debuggers code/data windows).
This is how volume slider looks in Windows 7 (it's also similar in Vista and Win 8).
Settings are remembered after closing and running the application again.
As for GUI, I don't know why Felipefpl is having problems, it's working fine here.
Color scheme is right and there are no "big buttons"...
To use "fancy buttons" common controls ver. 6+ needs to be used along with .manifest.
Personally I don't mind this look.
i never said anything about having problems, i mentioned the appearance only.
also, in all emus of nocash i tried (nopsx, nosns and no$gba) i miss the feature of maximizing the window, in no$gba i (personal opinion) dont like the fact i have to start a game if i just want to see the GUI and its options.
I have a tiny bug to report. GsLine is one pixel short.
Separate names with a comma.