Developer's wanted

[Squall-Leonhart]

for now heh heh

there is a way though, just like Fusion does, to output a 16bit image, while in a 32bit display mode.

might be worth looking into

[mudlord]

Indeed so, but I rather not use hacks.

There is a way though, to force the renderers to use 16 bit in a 32bit desktop, so that your desktop settings don't get affected. Tried this out today while rewriting some GFX code, and suffice to say, worked quite well as a workaround. Might add it as a extra INI setting....

[Squall-Leonhart]

it wouldn't be a hack

the GBA has a 15bit colour output, rendering it in 32bit is the hack

[mudlord]

...And if thats the case, why do we need 32-bits precision when the GBA needs only 16-bit? Thats whats got me thinking. Honestly, I'm starting to think 32-bit usage in this emulator is only the placebo effect working, unless I get objective evidence to prove 32-bit is "better". Afterall, isn't it the point of any emulator to do it accurately?

[Squall-Leonhart]

just do it how Fusion does
render a 16bit image (and make it do so while still maintaining 32bpp depth)
it Kega did it, it shouldn't be hard.

[djrobx]

Again, I would like to repeat: Kega Fusion filters ONLY work in 16-bit colour modes.

What I'd do is force the emulator to render to 16 bit, then convert the output to 32 bit. The code is already there to force the input to 16 bit (used by HQ3x and HQ4x). I can implement this if you'd like, should be pretty easy.

[mudlord]

Yeah, I seen your colour hacks for HQ3x/HQ4x. First time around they didnt work. I might have a relook again.

EDIT: Second time around, failed too. Sigh, I found the only effective manner, like VBASmooth, was to enforce 16-bit rendering.

[djrobx]

Forcing 16 bit rendering just forces the emulator to produce a 16 bit source regardless of the display mode. We will need to add code to convert the 16 bit output of the filter to 32 bits. Don't worry, I'll take care of it.

-- Rob

Ok, committed (SVN 95).

I had to add some strange math to the height values in order for the RPI filter to render the full frame (in either 16 or 32 bit mode).

New glitch I noticed when testing this: Once in 32 bits, sometimes the emulator doesn't want to go back to 16 bits. The only way I could get D3D to go back to 16 bits was to switch to DirectDraw mode. Will investigate later.

[mudlord]

I had to add some strange math to the height values in order for the RPI filter to render the full frame (in either 16 or 32 bit mode).

Yeah, I seen the funky math you did in rpi.cpp. Thanks for helping me implement this, btw .

New glitch I noticed when testing this: Once in 32 bits, sometimes the emulator doesn't want to go back to 16 bits. The only way I could get D3D to go back to 16 bits was to switch to DirectDraw mode. Will investigate later.

Does it change when you go to fullscreen, or choose the OpenGL renderer? Speaking of which, I am working on a new texture-based D3D9 renderer, instead of it writing to surfaces. It most likely will be implemented as a extra renderer object, instead of a replacement.

[djrobx]

Yeah, I'm going to have to see if I can find the source to an RPI filter to find out what's up with that height parameter. The behavior is consistent across all the various filters, and everything seems to work OK but the possibility of overshooting buffers makes me nervous.

Does it change when you go to fullscreen, or choose the OpenGL renderer?

The current OpenGL renderer only supports 32 bits (BGR pixel format). Picking one of the listed fullscreen modes is supposed to set it to 16 bits in D3D9 mode. But as it stands even picking a mode from the full list of video modes ("Select...") sticks at 32 bits in D3D9 mode. It's probably something simple, I just had never noticed this issue until now.

I am working on a new texture-based D3D9 renderer, instead of it writing to surfaces

Cool! We still need to add full-screen modes to the OpenGL renderer, too.

-- Rob

[TheCloudOfSmoke]

Originally Posted by djrobx

Yeah, I'm going to have to see if I can find the source to an RPI filter to find out what's up with that height parameter. The behavior is consistent across all the various filters, and everything seems to work OK but the possibility of overshooting buffers makes me nervous.

Index of /Files/Emulation

Welcome to the official 2XPM Homepage!

Eidolon's Inn : Plugins

[djrobx]

Thanks, Cloud!

That makes the problem pretty clear.

lq3x:
for (y = 3; y < rpo->SrcH; y++)

lq4x:
for (y = 4; y < rpo->SrcH; y++)

scale2x:

for (y = 2; y < rpo->SrcH; y++)

Makes no sense at all why you'd skip "scaleFactor" lines of the source. I hope all rpi's are implemented with this "feature" uniformly. :/

-- Rob

[Squall-Leonhart]

the save type detection is broken on Pokemon Blue, Red Yellow and Green
it disables saving because of this.

also
Borders are not loaded from Gold or Silver
this dates back to the 1.8wip source but is not an issue in the official beta 3

[mudlord]

Uploaded builds of SVN 104

Includes new SDL-based Win32 build. Note that it is command-line based for commands.

[MasterPhW]

Btw: again the message:
"Error:
Couldn't create socket!"
if I want to use my old VBA.INI...

[djrobx]

Btw: again the message:
"Error:
Couldn't create socket!"
if I want to use my old VBA.INI...

It means you have bad network play settings. You probably have a port specified that your system can't bind to. Go into the netplay settings and disable the TCP/IP netplay. It should just show an error and let you continue whatever you were doing. If you can post your VBA.INI I can take a look to see exactly what your issue is.

[MasterPhW]

Originally Posted by djrobx

It means you have bad network play settings. You probably have a port specified that your system can't bind to. Go into the netplay settings and disable the TCP/IP netplay. It should just show an error and let you continue whatever you were doing. If you can post your VBA.INI I can take a look to see exactly what your issue is.

The funny thing about that is, I've never changed anything in these network settings! I've started VBA-M and after a new version was released I've replaced the binary with the new binary and then I've got this message. And I can't even start VBA-M, after this message appears, so I can't change anything in the config. Have to create a clean install to get it working. Just deleting won't work!
Btw, here's my INI:

[preferences]
language=0
languageName=
frameSkip=1
gbFrameSkip=0
autoFrameSkip=0
vsync=0
synchronize=1
stretch=0
video=0
defaultVideoDriver=1
fsAdapter=0
fsWidth=0
fsHeight=0
fsColorDepth=0
fsFrequency=0
renderMethod=1
windowX=0
windowY=0
useBios=0
skipBios=0
soundEnable=783
soundOff=0
soundQuality=2
soundEcho=0
soundLowPass=0
soundReverse=0
soundVolume=0
soundInterpolation=0
ddrawEmulationOnly=0
ddrawUseVideoMemory=0
tripleBuffering=1
d3dFilter=0
glFilter=0
glType=0
filter=0
LCDFilter=0
disableMMX=0
disableStatus=0
showSpeed=0
showSpeedTransparent=1
gbPrinter=0
pauseWhenInactive=1
useOldSync=0
captureFormat=0
removeIntros=0
recentFreeze=0
autoIPS=1
disableSfx=0
saveType=0
ifbType=0
flashSize=131072
agbPrint=0
rtcEnabled=0
autoHideMenu=0
skinEnabled=0
skinName=
borderOn=0
borderAutomatic=0
emulatorType=0
colorOption=0
priority=2
autoSaveCheatList=0
gbPaletteOption=0
gbPaletteCount=48
gbPalette=FF7FB5568C310000FF7FB5568C310000FF7FB5568C310000FF7FB5568C310000FF7FB5568C310000FF7FB5568C310000A4
rewindTimer=0
recent0=
recent1=
recent2=
recent3=
recent4=
recent5=
recent6=
recent7=
recent8=
recent9=
joypadDefault=0
autoLoadMostRecent=0
cheatsEnabled=1
fsMaxScale=0
throttle=0
pluginName=
saveMoreCPU=0
LinkTimeout=1000
Linklog=0
RFU=0
linkEnabled=0

[diediedie]

I was able to sucessfully compile vba-m with vs2008 i thought you would like to know that it worked

[mudlord]

So VBA-M now compiles with Orcas....Is there any chance you can send us the VC2008 project files for integration?

[diediedie]

VS 2008 Project Files

There you go didn't have to make any changes at all for it to work.
Project files are the rtm version