gc-forever - Gamecube/Wii Forums

hi emu_kidid its good to hear from you...........

roger that . i have done some more testing with your suggestions


i just tested one of my Wii's with an Original Gamecube game inserted instead of a full Wii disc as suggested , then tried HBC>WSB0.2 and Swiss boots , i then select the Virtua_Striker_3_2002_USA_NGC-USA iso

settings........

-16mhz
-Stop DVD Motor , No


VS3 2002 loads all the way to the menu and i can select an option , i played VS3 2002 in game for about 10 minutes ........nobody scored so it went down to a Penalty shoot out. No error messages popped up like before


i am very impressed with the results , thanks for the suggestions in not to use SDML disc...... and for coding Swiss !


chat soon

s8n

Hey,
I just created a gui demo for swiss powered by libwiigui.
executable and screenshot attached.

Tell me what you think about it.

And yes, I know that it is a crappy screenshot, but my lcd is broken currently. :/

The demo picture looks really neat Is it really working on gamecube? I tried the gcube emulator and I just get a black screen

andzlay wrote:The demo picture looks really neat Is it really working on gamecube? I tried the gcube emulator and I just get a black screen

This is the wrong way of testing. If you want to know if this works on a gamecube, you would have to compile a gamecube executable 1st. Well i'm assuming the demo is a wii app. It all depends if libwiigui is gamecube compatible or not, but i hope it is.

Of course it works on GameCube.

looks nice, I'll have a look at merging something in soon.

so you don't like emu's GUI infact?

infact wrote:Hey,
I just created a gui demo for swiss powered by libwiigui.
executable and screenshot attached.

Tell me what you think about it.

And yes, I know that it is a crappy screenshot, but my lcd is broken currently. :/

Have not tried it yet, but I gotta say that I'm a big fan of libwiigui. Will try it when I'm home.

liquitt wrote:so you don't like emu's GUI infact?

It's not that, I'm happy if a gui is useable (I'm a linux gui ).
The reason I tried this is that I was messing around with libwiigui since some time now.
I was working on a rewrite of gcmm, basically a sdcard <-> memcard file manager with banner and icon support for gamecube called cardman-gx (and implement some features in swiss later).
So I was looking for a nice and clean gui solution myself. And i think libwiigui is nice and clean.

Darkmystery wrote:Have not tried it yet, but I gotta say that I'm a big fan of libwiigui. Will try it when I'm home.

It's only a demo... only the credits, settings and exit buttons are working

libwiigui is definetly nice and clean, i was messing around with it too.

...but since you're doing this now here's my idea:
why not have the buttons to the right changed for the menu you're in? e.g. in the main menu it doesn't make sense to have an "execute file" or "file info" button because there are no files (yet). so in the main menu an "open" button would make much more sense. or "browse"

and the image ripping buttons are not needed when browsing a hdd or sd card and so on and on...anybody thinks the same? or even gets what i'm talking about?

Of course liquitt, the demo menu is just based on the menu options available in the current version of swiss.

I thought of removing the execute file button entirely, cause pressing button (A) has the same effect (so the menu size fits the browser size).

And you are absolutely right with hiding the image buttons when not needed.

somebody finally understands me
and i wasn't even talking about your demo menu (which is obviously based on the original swiss menu) just about the logic behind it all you know.

i'd love to have more time because when i looked into libwiigui is was quite happy to see that its so neat

emu_kidid i have something else to discard:
I guess Swiss will get the ability to save/load a configuration file eventually. I'd like stuff like hiding the ide exi/SD Gecko/disc options, and a "Load default device" button, which directly loads the configured device. Like SD Gecko in slot B, 32 Mhz mode. Or "Load last device", which might be much quicker to implement. Auto detection of the device might be better, but i don't know if there are any compilcations with it. And i'm aware that without auto detection, loading a config file is difficult or limited(device not part of the config).

Anyways, i assme you have more than enough ideas about a config file yourself already, but i'm always think about running Swiss on a Wii, so:
Once the config is implemented, it would be nice if a config file could be preloaded into a certain memory location. With at least 2 extra options: Use/ignore config file on SD Gecko/ide exi and autoboot device xy, path z. This way you could skip writing some extra boot parameter interpretation code*. I know that this forwarder function is somewhere at the bottom of the TODO list, but when doing one of these things, adding them all might save some time in total.

*Or is it possible to boot homebrew on a GC with some nice&easy to use solution? Or more important, do you use one method that would support it?

Well SD load which was bassically just an action replay code that loads files from an SD Gecko is very clean and easy.

Hells Guardian wrote:Well SD load which was bassically just an action replay code that loads files from an SD Gecko is very clean and easy.

SDload is not better than Wii Swiss Booter since it's a gc homebrew and thus requires another application that boots into gc mode and launches SDload.

WiiPower wrote:emu_kidid i have something else to discard:
"Load default device" button, which directly loads the configured device. Like SD Gecko in slot B, 32 Mhz mode. Or "Load last device", which might be much quicker to implement. Auto detection of the device might be better, but i don't know if there are any compilcations with it. And i'm aware that without auto detection, loading a config file is difficult or limited(device not part of the config).

Anyways, i assme you have more than enough ideas about a config file yourself already, but i'm always think about running Swiss on a Wii, so:
Once the config is implemented, it would be nice if a config file could be preloaded into a certain memory location. With at least 2 extra options: Use/ignore config file on SD Gecko/ide exi and autoboot device xy, path z. This way you could skip writing some extra boot parameter interpretation code*. I know that this forwarder function is somewhere at the bottom of the TODO list, but when doing one of these things, adding them all might save some time in total.

*Or is it possible to boot homebrew on a GC with some nice&easy to use solution? Or more important, do you use one method that would support it?

My idea is to have two stages of configuration that is saved. We can store the device to look at by default on the SRAM that a Gamecube and Wii has.. it's 64 bytes in size only but there's some bits (3 bytes) or more that we can use for this. It would get rid of the problem of how to look at a device to for a config file since you'd save the last used device/preferred device/etc.

Here's the strategy:
1. If there is a saved/preferred device in SRAM, use that and look for the full config on that device.
2. If that device fails to open, just list the devices in the file browser by default.
3. Full config on the device will store preferred directory/etc.

infact wrote:Of course liquitt, the demo menu is just based on the menu options available in the current version of swiss.

I thought of removing the execute file button entirely, cause pressing button (A) has the same effect (so the menu size fits the browser size).

And you are absolutely right with hiding the image buttons when not needed.

Yeah, originally sd-boot needed to do a lot on its own so I was constantly validating what a user was doing at every stage - i.e. press A to boot, etc. Single (A) button pushes on a menu entry should boot them, I agree, there's no point of a "Boot" button anymore.

emu_kidid wrote: My idea is to have two stages of configuration that is saved. We can store the device to look at by default on the SRAM that a Gamecube and Wii has.. it's 64 bytes in size only but there's some bits (3 bytes) or more that we can use for this. It would get rid of the problem of how to look at a device to for a config file since you'd save the last used device/preferred device/etc.

Here's the strategy:
1. If there is a saved/preferred device in SRAM, use that and look for the full config on that device.
2. If that device fails to open, just list the devices in the file browser by default.
3. Full config on the device will store preferred directory/etc.

I agree that it is a great idea to have a configuration that can be saved.
In snes9x-gx for example it is done like this: "Let us mount all devices available and look for our config in the list, then use the first one found".
This could cause trouble, for example when you have two config files (one sdcard in sdgecko a and one ide-exi in slot b).

One question: How do you want to save the config byte(s) in the sram, before swiss is started?
Some kind of loader?

My idea was like integrating the first stage of config in the swiss executable and patch it over when needed.
But, that can cause problems as well.

I was thinking the first time swiss is ever booted up it won't have a certain flag set in SRAM that we'll look for (like a 10101010 byte or whatever) and it'll welcome the user to swiss/etc and tell them to pick a device.

Thats not a half bad idea. In fact it should work quite nicely.

I want to thank you emu_kidid for working on a tool like Swiss and making it into what it is; highly appreciated! I have a question though... with the games I try there is always jittery motion/cutscene/audio glitches, even if it is not an audio-streaming game (and confirmed working; "Mario Kart Double Dash!!" is an example). Just curious if this normal or I am the only one having this issue... it appears I have a Gamecube that doesn't support games like Star Fox Adventures either with Swiss (error on boot-up) if that's of any help. This is turning out amazingly well and I want to thank you for taking the time and effort to work on something like this, by the way!!

xro998, jitter in cutscenes is expected on most titles, there's only a few rare cases where it doesn't happen.. I'm always of course trying to speed up the code but it can only get so fast

Your saved state idea is ace.
I was wondering, is there any chance you can fix the Audio streaming problem in WODE from Swiss?
If you could access the hardware from Swiss?
guess I'm just grasping straws =)

justNer wrote:Your saved state idea is ace.
I was wondering, is there any chance you can fix the Audio streaming problem in WODE from Swiss?
If you could access the hardware from Swiss?
guess I'm just grasping straws =)

It's not a problem, it's not implemented. When i 1st heard of WODE, i thought audio streaming from usb HDD would be its killer-feature, but instead well... I heard it was the choice between dumping game discs to usb and audio streaming, and the team made that bad decision. Yep:

TheArtificer wrote:
Unfortunately streaming audio is not supported There just aren't enough pins on the FPGA (the chip that interfaces Wode to the Wii) to have streaming audio and passthrough/disk ripping mode. We spent a lot of time trying to get around this limitation but we are stuck with it - most users will probably agree it was the correct choice

Streaming audio is audio (typically background music) that plays directly from the disk instead of being synthesized/played back from game data by the GC itself.

source:
http://www.wodejukebox.org/viewtopic.php?f=4&t=753

Since there are so many pages i have to ask and sorry if this has already been brought up, however:
How would this work, and will it work on Wii? I have SD Media Launcher that can have a SD/SDHC card. Also, what is a IDE-EXI ?

WiiPower wrote:
It's not a problem, it's not implemented. When i 1st heard of WODE, i thought audio streaming from usb HDD would be its killer-feature, but instead well... I heard it was the choice between dumping game discs to usb and audio streaming, and the team made that bad decision. Yep:

I guess you haven't read :
http://www.wodejukebox.org/viewtopic.ph ... 0&start=10

TheGuru:
yep, the connections from GC/Wii mainboard to Wode-mainboard are enough; I never said that the implementation of GC-audio streaming is not doable, but only that it require an heavy code rearrangement on MCU side and FPGA side;

em_kid, we can speak about on IRC, maybe we can found a more feasible solution.


TG