SMB support

[GoogleCodeExporter]

Please provide a SMB Share Option like the other Emulators. Many people are
using NetworkStorages and it's a hillarious feature to load you ROM's from
a SMB Share.

Original issue reported on code.google.com by talant...@gmail.com on 13 May 2010 at 12:09

[GoogleCodeExporter]

Issue 15 has been merged into this issue.

Original comment by ekeeke31@gmail.com on 13 May 2010 at 2:24

[GoogleCodeExporter]

Original comment by ekeeke31@gmail.com on 13 May 2010 at 2:26

• Changed title: SMB support
• Changed state: Standby
• Added labels: Priority-Low, Type-Enhancement, Usability

[GoogleCodeExporter]

Yes if that could be possible!

Original comment by hielk...@gmail.com on 5 Dec 2010 at 7:04

[GoogleCodeExporter]

Megadrive had a lot of games, SMB support is very important

Original comment by pmagnu...@gmail.com on 19 Jan 2011 at 4:18

[GoogleCodeExporter]

The whole Megadrive library (zipped) takes less than 1.2 GB. And lucky for you, 
the Wii has SD/SDHC support and those cards are very cheap and easy to found so 
no, that's not really a good argument.

Seriously, I've yet to read one good and valid reason to implement this 
(besides the fact it's a cool feature for a few users that like having 
"everything in the same place" and don't mind having a noisy computer running 
just to stream a 2MB ROM file for less than 1s).

Original comment by ekeeke31@gmail.com on 19 Jan 2011 at 11:10

[GoogleCodeExporter]

Why keep your library in two or more places? Who, in 2010/11, doesn't have a 
computer running almost all of the time anyway? Some of us have gone completely 
discless and run centralized media servers. Can we burn a DVD of ROMs, or load 
an SD card? Sure, but why bother when everything already exists on a shared 
drive that the Wii can readily access? That's not to say we don't appreciate 
the emulator as is, we're just suggesting improvements that will bring it up 
the level of the NES and SNES emulators and would be grateful for an SMB 
feature add.

Original comment by Thomas.W...@gmail.com on 29 Jan 2011 at 10:46

[GoogleCodeExporter]

Maybe because I personally don't have a computer running "all the time" and 
especially not when playing on Wii (and i don't plan to change in 2011) so i 
don't see the interest of that feature.
It also means modifying the interface and adding a way to configure user/pwd 
which i don't want to do because it's the most boring task when working on an 
emulator and i would like to work on more interesting stuff in my limited time. 
That's also why the emulator is open-source so anybody coul code and submit a 
patch...

Original comment by ekeeke31@gmail.com on 30 Jan 2011 at 7:29

[GoogleCodeExporter]

Others emuletors have SMB, why not genplus gx??. SD memories are so fragile

Original comment by pmagnu...@gmail.com on 26 Mar 2011 at 12:35

[GoogleCodeExporter]

I have attached a patch for basic SMB support. It seems to work fine without 
much modification to the existing code, as it just uses the tinysmb that comes 
with libogc. It took me longer to set up my build environment then it took to 
steal Visual Boy Advance GX's network code.

I didn't include an icon for the SMB button, so if you want to test it just 
copy Load_usb.png to Load_smb.png for now. The samba share info is hard-coded, 
so you'll have to change that as well.

The biggest obstacle with adding SMB support is implementing an on-screen 
keyboard (and textbox) to allow the user to input the 
share/username/password/ip to set up SMB. There is a simple keypad for entering 
game genie codes, and I might even look into stealing VBA-gx's keyboard code 
like I stole their little bit of network code.

It looks like at least a few people are interested in this, so I'll start 
working on a keyboard. No promises though, as it sort of depends on how much 
time I can take away from school. I should be able to hack something together 
though.

Sorry I promised a patch a few years ago. Things came up and I didn't follow 
through. It's not like this patch is usable either, but I swear it works.

Original comment by auntieNeo@gmail.com on 26 Mar 2011 at 9:16

Attachments:

• basic_smb.patch

[GoogleCodeExporter]

I wrote some keyboard code and uploaded what I have so far to github.

There are a few issues with it. The d-pad control on the menu items I added is 
broken, and I don't know where to fix that. The network code doesn't reconnect 
when the config is changed. And I still don't have icons for the load or config 
menu.

I'll fix these issues hopefully soon, but you can check the code on github the 
url is:
https://github.com/auntieNeo/genplus-gx
I also put a genplus_wii.dol build there if anyone wants to test it. Use this 
at your own risk. I have added some things to the config, so don't be surprised 
if your config gets borked somehow. It works fine for me, though.

Original comment by auntieNeo@gmail.com on 29 Mar 2011 at 4:34

[GoogleCodeExporter]

About D-PAD issues, make sure the shift[] parameter of your buttons is not 
zero, this is what controls offsets applied to current selection when pressing 
D-PAD keys

shift[0] for up
shift[1] for down
shift[2] for left
shift[3] for right

About your patch, I see that network adds a running thread, is this thread 
terminated properly when running a game ? this could bring significant 
performance issues otherwise :-/

for an odd reason, it seems that adding libraries slightly & therefore 
increasing the binary size somehow impact emulation performances as well 
(another reason why I'm not a big fan of adding non vital features like this)

Original comment by ekeeke31@gmail.com on 29 Mar 2011 at 8:04

[GoogleCodeExporter]

Sorry, after actually reading your code it appears you are not using shift[] 
and gui.c help functions so this wouldn't help.

Try reading input keys (   p = m_input.keys;  ) AFTER refreshing the screen, 
not before. Calling gxSetScreen() indeed makes the program wait for next VSYNC, 
which is also when inputs get updated (during VSYNC callback).

Original comment by ekeeke31@gmail.com on 29 Mar 2011 at 8:19

[GoogleCodeExporter]

Thanks for the tips, I think I know how to fix the gui now.

The thread in networkop.c just initializes the network, and joins with the main 
thread when the network thread is done. As far as I can tell, the thread is not 
running once the network is initialized. But now that you mention it, it 
doesn't look like the thread is joined if it ever hangs somehow... I'll look 
into that.

Like I said, the network code is mostly ripped from VBA-gx, and I haven't 
touched hardly any of the existing file loading code. I still need to tweak 
that part of the gui so that it's more aware of network changes and timeouts.

As for the size of the tinysmb library, there's not much I can do. My 
libtinysmb.a is about 200KB. Correct me if I'm wrong, but that's like 0.3% of 
the Wii's 64MB of main memory. There would have to be a really odd reason if 
increasing the size of a binary causes it to run slower, if my understanding of 
computer architecture is correct. I'm not familiar with genplus-gx's memory 
situation. Does the emulator use some kind of cache that actively uses up the 
spare memory? Maybe I'll try some large roms and see if it ever runs out. In 
any case, even if you decide it's too big to include in the main distribution, 
I'll continue to maintain a patchset and binary on github in case anyone really 
wants it.

I'll post another .patch file here in a week or two once I think I've ironed 
out most of the gui/network bugs.

Original comment by auntieNeo@gmail.com on 30 Mar 2011 at 7:21

[GoogleCodeExporter]

The problem is actually not running out of memory (on Wii at least, though 200K 
seems a lot to just load a ROM file from network) but more general speed drop 
because of binary size.

Test case for emulation speed is Virtua Racing rolling demo. If sound starts 
scratching and framerate drops, then it means emulation runs too slow. I really 
don't understand why binary total size in memory would have any impact on code 
execution (maybe PowerPC experts would know better) but it seems it has. 

I'm ok with having a separated patch and eventually two versions. I'm going to 
release a new version soon though with many modifications to the core (and some 
to menus regarding controllers) so you will probably need to adapt your patch.

Regarding the thread, it seems to me it is only joined when calling 
StopNetworkThread but this function is itself only called by InitializeNetwork, 
which is a little odd. Seems to me that if you only call InitializeNetwork 
once, the thread will run endlessly in background.

Original comment by ekeeke31@gmail.com on 30 Mar 2011 at 8:22

[GoogleCodeExporter]

After further inspection, SMB support indeed creates two additional threads in 
libogc that keeps running in the background:

- one is created by net_init (network.c) when connecting to network (for 
example when calling if_config).

- one is created by smbInitDevice (smb_devoptab.c) which serves as devoptab 
caching (?) thread.

The major flaw in libogc design is that both threads can NEVER be terminated 
once they have been started, they just keep running in the background, even if 
you close SMB and shutdown network connection, taking CPU process time to more 
important things when emulation is actually very processor demanding (and 
therefore maybe increasing emulation latency, video lag, etc).

Original comment by ekeeke31@gmail.com on 31 Mar 2011 at 9:12

[GoogleCodeExporter]

I have faith in your coding ability, ekeek, that you can manage the SMB support 
(w/ auntieNEO's able assist) w/ little-to-no perceptible impact on speed--after 
all, if Tantric can manage it (on the SNES emu), surely you can handle it as 
well.

Original comment by ECMI...@gmail.com on 2 Apr 2011 at 6:52

[GoogleCodeExporter]

You didn't understand, there is nothing i can do on my side, this is already 
like this in libogc, which means that other emulators like snes9xgx ALREADY  
have one or two additional threads running in background while playing games, 
for no purpose. It does not mean it is perceptible or that slowdowns you can 
sometime notice in snes9xgx are caused by that (also keep in mind you cannot 
directly compare different emulators speed and make assumptions since they have 
different CPU requirements). What i am saying is that I don't want to add 
something that can potentially increase emulator latency for not much benefits 
in the end.

Original comment by ekeeke31@gmail.com on 2 Apr 2011 at 5:53

[GoogleCodeExporter]

USB Mouse support but not SMB Support?? This is unfair :S

Original comment by pmagnu...@gmail.com on 4 Apr 2011 at 5:58

[GoogleCodeExporter]

I don't see the relation between both of them but yeah, life is unfair...

Original comment by ekeeke31@gmail.com on 5 Apr 2011 at 6:52

[GoogleCodeExporter]

Its unfair because SMB support is more important than mouse support. Genplus GX 
doesnt update frequently. Maybe doesnt a next update exist :S

Original comment by pmagnu...@gmail.com on 5 Apr 2011 at 9:01

[GoogleCodeExporter]

Don't worry about it. I don't think ekeeke wants an SMB patch, but I'll have a 
decent patch probably this weekend, with network button graphics and all. I 
already have a half-working build, and any newer builds will show up at this 
link:
https://github.com/auntieNeo/genplus-gx/raw/master/genplus_wii.dol
Life isn't so unfair.

Original comment by auntieNeo@gmail.com on 5 Apr 2011 at 11:00

[GoogleCodeExporter]

Yeah, as I said 100x time now, I won't add SMB support in its current state 
because it adds more drawbacks than advantages in my opinion. I don't mind that 
a "mod" exists with SMB support as long as GPL is respected though.

@pmagnus: you must understand that this is not a scheduled project with goals 
and priority step to achieve. There is no "more important" feature in my eyes 
and I really do not work on this project to please user requests but for me to 
have fun coding interesting & challenging stuff. In short, better see the 
releases I do as a nice extra you get, not something you own. 

Original comment by ekeeke31@gmail.com on 6 Apr 2011 at 6:37

[GoogleCodeExporter]

Calm down, Dont shake your chocolate.

Original comment by pmagnu...@gmail.com on 6 Apr 2011 at 10:49

[GoogleCodeExporter]

I'm quite calm. Just trying to explain how things work and why there is no need 
to cry for a feature :)

Original comment by ekeeke31@gmail.com on 6 Apr 2011 at 2:04

[GoogleCodeExporter]

Oh Yeah!

Original comment by pmagnu...@gmail.com on 7 Apr 2011 at 11:01

[GoogleCodeExporter]

thx ekeek for the great work. but smb suport is important. all my stuff is on 
hdd, so why buy a new sd with more space. On the SD is other stuff, not only 
roms for your sega emu. its much easier to start the games over smb. so you 
dont have to put the stuff on the SD with limited space.

thx auntieNeo for your work. i tested it and it workes really good. just button 
icns arent right. smb button looks like usb button and the smb settings button 
looks like another one. i hope you can finish your work, i need it and i will 
test every new version. THX

Original comment by maddin1...@googlemail.com on 9 Apr 2011 at 12:09

[GoogleCodeExporter]

I made a button for loading the network with gimp, but I can't for the life of 
me get my pngs to render on the GUI, and I get a lot of core dumps. It does 
fine if I copy the existing pngs, but pngs I make with gimp or imagemagick, or 
even reference pngs, don't work. Is there something special I need to do to 
these pngs to get them to work? Maybe I'm missing something.

Attached is the png that's giving me problems, but most other pngs I've tried 
are just as problematic.

Original comment by auntieNeo@gmail.com on 11 Apr 2011 at 12:21

Attachments:

• Load_smb.png

[GoogleCodeExporter]

PNG image dimensions (width AND height) must be multiple of 4 pixels, this is a 
texture limitation of GX hardware.

Also, the format must be RGBA8 i.e 32 bits per pixels.

Original comment by ekeeke31@gmail.com on 11 Apr 2011 at 7:32

[GoogleCodeExporter]

@ekeek thx for help

@auntieNeo, tell me when the icon works, i will test it. thx

Original comment by maddin1...@googlemail.com on 11 Apr 2011 at 5:23

[GoogleCodeExporter]

any news? artwork working? i would do it myself, but i dont know how to use the 
makefile with windows

Original comment by maddin1...@googlemail.com on 14 Apr 2011 at 4:18

[GoogleCodeExporter]

If you don't have anything to say, stop posting to this thread. I appreciate 
the encouragement/prodding, but this thread has enough of those posts. I've got 
a semester project due in a week, and I'm sure ekeeke is busy at times too and 
doesn't need that in his inbox either.

The .dol file I posted works FINE if you enter the ip and everything correctly 
the first time, and click on the "load usb" icon. I'll post one with the new 
icon when it's ready. <_<

Original comment by auntieNeo@gmail.com on 14 Apr 2011 at 8:51

[GoogleCodeExporter]

sorry, and yes it works fine. now i shut up.... wasnt my intention to spam. thx

Original comment by maddin1...@googlemail.com on 15 Apr 2011 at 1:08

[GoogleCodeExporter]

This PNG should fix it, I opened one of the icons that do work and opened it as 
a layer and resized it to fit the canvas.  It also saved it as the exact same 
format as that other working icon.  I hope it works, but I can't figure out how 
to compile and it's killing me...  Here it is attatched.

Original comment by SonicXxRush@gmail.com on 25 Apr 2011 at 1:24

Attachments:

• Load_smb.png

[GoogleCodeExporter]

Compiled with your icon SonicXxRush

Original comment by reyd...@gmail.com on 11 May 2011 at 8:04

Attachments:

• genplus_wii.dol

[GoogleCodeExporter]

I can pretty much verify what ekeeke is saying about additional libraries 
causing performance problems - I've found this to be pretty much true on PS3 as 
well - it's the main reason why I mostly refrain from adding any bloated 
libraries unless it's absolutely necessary (in VBA PS3 I'm currently debloating 
it and taking out everything that me and the original porters put in - SFML, 
LibPNG, et al. I've even found that taking out the SFML code in VBA causes two 
games to start working again - Sonic Advance 1/2).

Ultimately, these emulators are meant to do one thing and only one thing only - 
play games - anything that hurts performance and is not absolutely necessary 
(as in - it has nothing to do with what the emulator/app is meant to achieve - 
as in this case, playing games) - it has no purpose in a console emulator port.

For the same reason I thought it was very smart of ekeeke not to bother with 
filters such as HQ2x - sure, SNES9x GX/FCEU GX has them included, but seeing it 
run with frameskip 2/3/4 only ends up exposing the inadequacies of the Wii CPU 
- therefore, a less is more approach is definitely better - if it can't be done 
at 60fps, then don't include it since it will only show your port in a bad 
light.

Original comment by danieldematteis@gmail.com on 12 May 2011 at 10:28

[GoogleCodeExporter]

About soft filters: that's really not about showing the emulator "in a bad 
light" (well, the NTSC filter might even be slower than HQ2x on that matter) 
but more that I am quite lazy and not very excited by porting video filters 
which code has already been copy-pasted in every possible emulators out there 
and which I have actually zero use for (I still have my good old Sony Trinitron 
CRT and in my opinion, real 15Khz beats up any of these filters anytime ;-))

Most likely, when I (finally) got a real HDTV I will see things differently and 
add HQ2x filter support but until then, it's just that I don't feel the need.

Original comment by ekeeke31@gmail.com on 13 May 2011 at 4:14

[GoogleCodeExporter]

HQ2x on the CPU is probably too much to handle for the Wii CPU though - it's 
too much for the PS3 PPU too - which is why we rely on the shaders - a much 
preferable route to take in the end.

Speaking of which, has anybody in the Wii homebrew scene ever attempted the 
equivalent of writing an image-enhancement shader? I know there's nothing like 
GLSL, HLSL or Cg available on Wii - I'm not too knowledgeable on the Wii but 
apparently the TEV allows you to do the equivalent of programmable shaders - 
has anybody in the homebrew scene ever attempted this?

Original comment by danieldematteis@gmail.com on 13 May 2011 at 4:40

[GoogleCodeExporter]

Ekeeke, if you like a real 15khz picture, like me, you better grab a PS3 too, 
because I also have my Wii hooked to a Sony Trinitron and the picture looks 
almost the same as the PS3 emulator using the CRT shader with my HDTV. A truly 
incredible achievement, that no other filter can match.

I've been playing emulators using 240p for years and I can't tolerate filters. 
But the CRT shader is so faithful that I'm considering give up CRT in favor of 
a LCD.

And thanks to our friend here, you can use the CRT shader with Genesis games 
too (something that you can't do using your PC). 

Original comment by thiagoalvesdealmeida@gmail.com on 13 May 2011 at 6:45

[GoogleCodeExporter]

Yeah shader seems cool but I always found that CRT shaders somehow did not look 
"right", either scanlines were too much visible or too regular (on a real CRT, 
scanline visible "intensity" varies depending on adjacent lines intensity) or 
they add features I have yet to see on my CRT (like phosphor "emulation" or 
vertical grid). Though, I admit I never seen one in action, only screenshots so 
I will have to believe you on that one ;-)

But as I said, SCART RGB with true 15kHz signal is for me the best experience I 
can have right now and I barely see any differences with my old Mega Drive so 
I'm happy with that :)

About doing shader filters using GX TEV, I believe it's not possible. As far as 
I understand it, TEV let you mix multiple textures through several stages, 
using output of previous stages, color/alpha channels or fixed values as inputs 
to get various effect through multiple pass. This is done for each pixel of the 
rendered screen, simultaneously for each color/alpha channels. The problem is 
that video filters require to perform operations on neighbor pixels from the 
SAME texture and I think TEV simply does not allow that. Also add the fact that 
TEV operation is somehow limited compared to programmable GPUs, with a fixed 
set of operation (add, scale,bias,clamping) that you can only configure, a 
limited number of registers for storing temporary results and no floating-point 
support.

That's said, I might be wrong, this part is not very well documented and not 
much used in Wii/GC homebrew (basically we only use one stage), people who 
might know the most are Wii64/WiiSX devs (tehpola especially) and I think that 
the initial port of M-Player did use TEV multiple stages for faster video 
decoding/rendering.

Original comment by ekeeke31@gmail.com on 14 May 2011 at 8:59

[GoogleCodeExporter]

You can also use the CRT shader with 
bsnes(https://gitorious.org/bsnes/bsnes/blobs/patches/snesshader/CRT.OpenGL.shad
er)

It's not perfect, but it's the first time that I can play old games on my LCD 
without wishing I was using my CRT instead. There is even some advantages, like 
perfect geometry, which my Sony Trinitron lacks.

Original comment by thiagoalvesdealmeida@gmail.com on 16 May 2011 at 4:13

[GoogleCodeExporter]

Issue 188 has been merged into this issue.

Original comment by ekeeke31@gmail.com on 19 Sep 2011 at 10:11

[GoogleCodeExporter]

Given that SEGA CD/ MEGA CD support is now implemented official SMB support 
would prove incredibly useful now..

Only question would it work with SEGA CD/ MEGA CD games ?

Original comment by mansell....@gmail.com on 3 Jul 2012 at 2:34

[GoogleCodeExporter]

Given that SEGA CD/ MEGA CD support is now implemented official SMB support 
would prove incredibly useful now..

Only question would it work with SEGA CD/ MEGA CD games ?

Original comment by mansell....@gmail.com on 3 Jul 2012 at 2:34

[GoogleCodeExporter]

No, it would probably be too slow to read CD image data in real time from 
network, not even worth the try.

Original comment by ekeeke31@gmail.com on 3 Jul 2012 at 3:09

[GoogleCodeExporter]

Sega CD had a 1x drive. That's just over 1Mb rate. The wireless-g adapter in 
the Wii is capable of up to 54Mb. 

I imagine streaming a standard definition movie would require a significantly 
faster data rate than a Sega CD emulator and there aren't any issues with that.

Original comment by Thomas.W...@gmail.com on 3 Jul 2012 at 3:29

[GoogleCodeExporter]

We are speaking about emulation here, not video streaming. The emulator needs 
much faster access speed than 1x drive speed to keep a playable framerate, 
remember this is a single CPU that must do much more tasks in 1/75 s than just 
reading a single block of CD data. 

Original comment by ekeeke31@gmail.com on 3 Jul 2012 at 3:37

[GoogleCodeExporter]

I think it would work.. based on the Thomas's theory..  WIIMC works brilliant 
in terms of streaming content via SMB without a hitch..  

But then what do I know about emulation..

Original comment by mansell....@gmail.com on 3 Jul 2012 at 3:43

[GoogleCodeExporter]

I would guess that how feasible this is depends on how effectively the emulator 
can anticipate (and then buffer) the data that it will need in advance. Unless 
I'm missing something here, at some point emulator has to read and buffer from 
a file on disk, using the same file API as it reads ROMs with? Network storage 
isn't too far off from a local file; they're both quite slow in CPU terms.

Converting the ROM reading code to use SMB was very trivial, and most of my 
work to patch it was getting familiar with the GUI code. I might just try doing 
it with CD, as an experiment.

Original comment by auntieNeo@gmail.com on 3 Jul 2012 at 3:49

[GoogleCodeExporter]

@auntieNeo It will certainly be interesting to see how that works out.. 

The only worry as ekeeke said previously the additional process running may 
reduce performance, more specifically for MEGA CD emulation..

Original comment by mansell....@gmail.com on 3 Jul 2012 at 4:03

[GoogleCodeExporter]

[deleted comment]