Ideas for new Wiird

[agrs700]

I have some ideas for any new wiirdgui vesion, here i go:

- Changing gct code names (New code 1 and so on) and being possible to import .txt (from code manager)

- Fixing screenshots for panoramic TV, coz doesnt works

- Being able to make videos with it!!!(with panoramic support)

- Any way to make the sound mute when paused, to aboid the BIIIIIIIIIIIP!!! sound.

- More wiird commands

[biolizard89]

I have some ideas for any new wiirdgui vesion, here i go:

- Changing gct code names (New code 1 and so on) and being possible to import .txt (from code manager)

- Fixing screenshots for panoramic TV, coz doesnt works

- Being able to make videos with it!!!(with panoramic support)

- Any way to make the sound mute when paused, to aboid the BIIIIIIIIIIIP!!! sound.

- More wiird commands

How would videos work?  I haven't messed with WiiRD's screenshot feature, but seeing as the USB Gecko is the same speed as the GameCube BBA, and seeing as GCNrd took much more than 16ms to dump a screenshot, trying to take videos using the screenshot feature would almost certainly slow down the game, probably making it unplayable.

[Igglyboo]

Videos would be impossible without EXTREME slowdowns, you would probably get >5fps doing this.
What kind of wiird commands? Maybe you should elaborate.

You can already change gct code names....

[agrs700]

You can already change gct code names....

Rly?? how?

[Link]

You can already change gct code names....

Rly?? how?

simply clicking on them.. they should be renamable like files in Windows Explorer by clicking on their file names.

For videos: no probably not, sorry.. even if we optimized the screenshot feature.. by just sending over the necessary YV data (meaning 614400 Bytes per Screenshot).. we have a about 1.5 MB/s - so it's 2.5 FPS... not feasable.. really :(

For widescreen: you can select "Resize screenshot".. by default WiiRd takes the native Wii image.. which is always 4:3 ..

the beep sound is unfortunately not directly a WiiRd fault.. it's caused by pausing the game..

however: more commands.. sure?  like what?

[sarkwalvein]

Maybe it's possible to make some quick JPEG compression routine on the Wii side, so you could compress each frame to 32KB, and take only the odd frames, making a 640x480 30fps video. That way you can fit it into the 1.5MB/s bandwidth.

The video quality will sure go down, but the possibility to take videos using usbgecko would be great anyway.

I think I will make a short video with that compression settings to see if the quality is still acceptable... But I think it will be pretty acceptable, with some JPEG artifact noise but good anyways..

[Igglyboo]

Link, could you make it so wiird mutes the wii when you do a dump or have a breakpoint?
If its possible, make it be able to be toggled. Some games like super paper mario dont have the beep, the music is nice.

[biolizard89]

Maybe it's possible to make some quick JPEG compression routine on the Wii side, so you could compress each frame to 32KB, and take only the odd frames, making a 640x480 30fps video. That way you can fit it into the 1.5MB/s bandwidth.

The video quality will sure go down, but the possibility to take videos using usbgecko would be great anyway.

I think I will make a short video with that compression settings to see if the quality is still acceptable... But I think it will be pretty acceptable, with some JPEG artifact noise but good anyways..

If you could make a fast JPEG compression function fit in the Wii's RAM without interfering with the game's RAM usage, that would work.  But I'm guessing that isn't possible; the WiiRD code handler only uses 4KiB or so, and I would guess that many games don't leave much more than that available.

[Igglyboo]

How much of the wiis ram could we use without seeing major slowdowns?

[biolizard89]

Link, could you make it so wiird mutes the wii when you do a dump or have a breakpoint?
If its possible, make it be able to be toggled. Some games like super paper mario dont have the beep, the music is nice.

I wouldn't be surprised if this could be done by poking a sound register or something like that.  Or it could be impossible.  But if it's possible, I would like it to be optional, rather than doing it all the time.  I find the beeping noise to be a useful nonvisual indicator that the dump is done, so that I don't have to pay thorough attention.  Yes, I'm probably the only one.

How much of the wiis ram could we use without seeing major slowdowns?

I don't know much about Wii games' RAM usage.  On the GameCube, the standard amount of reliable free RAM was 32KiB.  I recall that Link said that it was much less on the Wii.  But if we use too much RAM, the problem won't be slowdown, it will just crash the game at random times depending on what the memory allocation routines of the game are doing.

[Link]

Wait wait wait.. the Gamecube used 32 KiB.. however, technically it didn't have them.. there are games which tend to crash with GCNrd.. like Starfox Adventures PAL.. try Star Fox Adventure Gamecbe in WiiRd.. WiiRd is running completely in the head ram.. and we do not really want to put it out of that.. because it's fast and safe that way.. on the GC.. there were GC games where the FST interfeered with GCNrd.. many games required special master codes.. ths is simply because GCNrd is sharing memory with the game.. WiiRd technically isn't .. WiiRd runs completely off the head memory..

[Igglyboo]

So if we increased the ram usage, it would overflow and use more than the head memory?
Couldnt we just make a master code then?

[Link]

a master code could not really solve it..

the main problem was: GCNrd uses: 817F8000 to 81800000 and marks that memory as unusable.. many games obey that.. however there are games with hardcoded addresses.. like Starfox Adventures.. you have would have to reprogram entire memory to tell the game not to use it.. other games use that memory for their FST.. that's also hardcoded and very very hard to relocate.. and therefore we were quite happy that WiiRd is running at 80001800 until 80003100 (including codes) and therefore at least that problem does not exist..

[Igglyboo]

would turning off the code handler while recording allocate any more memory?

[Link]

that might theoretically work but it will be complicated.. as the code handler is inside the USB Gecko communication part (meaning even Ocarina communicates with the USB Gecko as we were lazy).. though I doubt we could add JPEG compression for something like MJPEG compression to the handler.. and then in the end.. if wouldn't fix audio issues:

-what if games use Direct Audio? Then we'd have to capture the audio while it's being sent to the hardware.. otherwise we'd record BEEEEEEEEEEEEEEEEEEEEEEP..
-what if games use streamed audio? then the music would just continue playing .. and it would go completely off-sync