Hi everyone.

I have done a quick update to test wiimote, keyboard and mouse support under SDL and wiilinux, using cwiid and wminput. This is a test version, to see if wmintput is good enough to manage wiimote events, or if i have to look for another option (implement the wiimote envents inside SDL). At this moment, wiimote works pretty well, i didn´t added support for nunchuck nor classic controller, but it should work in a future.

The good point of cwiid is that it enables to access to the wiimote events already translated in keyboard, joystick or mouse events, but it is still limited in some ways. If this version of opentyrian is good enough, i will try to grow up its functionalities.

With this release i´m looking to test wiimote, keyboard, mouse and gamecube pad performance. I couldn´t try by myself if the usb mouse works, but some people told me that it works. Some common problems:

- Pay attention when the progam asks you to press 1+2 buttons, to connect it to the wiimote. You only have 5 seconds
- Use the wiimote in horizontal position
- In 576i mode (pal 50Hz) the screen is draw in 640x480, so you will see it enlaged.
- Couldn´t test how it works in cable component mode, but spect to have weird colours.


This version is also 100% homebrew channel compatible, thanks to the latest wii-linux kernel.

Bushing and I took time thinking about doing a program to change the region a Wii. Let's see what brings change the region a console:

Edit setting.txt to change the region of the console
Install menu system corresponding
Clear all channels "internal" corresponding to a region and install them on the other

The most complicated part is the second since installing a menu system (particularly if the version is lower, which for technical reasons occurs during certain changes in region) is a rather dangerous action. We had the idea in mind quite a while parked more or less, we were hoping to secure some form of do.

Some time ago, Waninkoko drew a utility to install different versions of the menu system (the downgrade). The interesting thing about this is that it does so through a patch of IOS, bringing the facility is more or less equivalent to an update and as safe. This corresponds to the second part of the list. We knew how to make the first, which is relatively easy (if you do). Waninkoko do you know the third. Therefore, and as Waninkoko already had 90% of the work done (in the form of downgrades), Bushing setting.txt of what he said and told him that it would be nice to incorporate it in the downgrade, in order to turn it into a changer regions.

Today comes the downgrade, and I'm going to post all happy, commenting that now we are working (something) with Waninkoko, pleased that we've given it a good idea and that every time we have saved in this way. Then, begin to appear semibricks news. I, of course, I am surprised, and my first reaction (and that of Bushing) was asking how is this possible. Take our surprise when we download the changer region and we find that: the only region changer changes the setting.txt.

Even more disappointing is the content of the readme:

Waninkoko wrote:
It allows you to completely change the region Wii console.

This application is a semibrick guaranteed for anyone who use it without somehow imagine that you must also change the menu system by other means. Even worse, some semibricks combined with certain other actions resulting in a total brick, unrecoverable.

Waninkoko well aware that this utility is only one third of the process of changing the region. Why has drawn in this way, without explanation, implying that it is a region full changer? I will assume that this was no malice, so the only conclusion that I have is that is an irresponsible and does not think before doing things. We intend to discuss what it was that of setting.txt incorporated into its downgrade, and do so explicitly Bushing said. Change setting.txt are a few lines of code - both for and for us. For this application would have cost us less (better known setting.txt), but the combination with an installer menu system much more. That was what made Waninkoko. Rather than add setting.txt and document everything a bit, which would have meant a job more or less reduced (as we do so much more), has drawn only one part of the process, fast and evil. The idea was to reduce the work necessary for everyone, and instead has proved the opposite, plus a utility dangerous. And it's not because it was not what happened to integrate, because in fact Bushing told to do so in this way.

It is the story of FS dumpers again. In its day, I told how Waninkoko dump all Flash files. The result was the FS Dumper and the beginning of piracy VC, on which already warned him. In fact, not what I asked him to draw up at least able to speak a little more with him, and I ignored by saying that "nobody will know how to use the archives of the FS for pirating games CV." We all know what happened just after he left. Assuming that was not a deliberate act in favour of piracy (and by what he said Waninkoko, private and publicly, it was not), then was another act of irresponsibility. Users pro-piracy: why not defend (and re-discuss piracy). He has said publicly that it was a mistake.

And hence, although I though, until we came here. From now on, we will not give any information to Waninkoko. But not because we fall ill, or because we want to draw the things we take for the "reputation", but because Waninkoko has shown us that can not be relied on to draw and secure applications with a minimum documentation. You can not do things quickly and without thinking, and that is precisely what makes Waninkoko. We have made a second attempt, and has returned to spend the same thing, so there will be a third party.

Greetings.

Mods: if this turns into another debate on piracy in the penultimate paragraph, please close the thread.

This is a port of Wargus for GP2X, an engine re-implementation of warcraft II based on the Stratagus v2.2.4 engine.

It's a bit tricky to install so be patient and post on the gp32x forums if you have trouble. If at any point the game does not work look at the "stderr.txt" and "stdout.txt" files for clues, they're generally pretty informative.

Notes:
- Beta Testers have been experiencing some saving inconsistancies, so far i have been unable to track down the problem. From my experience it seems to only screw up when you haven't built any buildings beyond what is initially on the map. So, for now, make sure you've built a building before you attempt to save.
- Loading the campaign screen with the scrolling text can take a little while, maybe 30 sec, so don't assume its crashed.
- If the screen begins flickering (and it bothers you) goto preferences and move the game speed slider down. It seems to be related to attempting to updating the
screen too fast for the graphics system to keep up with.
- There are some inconsistancies with the objectives and what the actually need to finish a map. Usually when this occurs you just need to kill all the enemy units.

Originally Zdoom was a source port of Doom based on ATB Doom and NTDOOM, however its been significantly extended and now supports Heretic, Hexen, Doom, Doom 2 & Strife, aswell as almost every mod made for these games. It is probably considered the defacto standard doom port and hence most modders strive to support it. Some interesting total conversions are: Blood, Wolfenstein 3D, Half-life, Quake, Quake 2, Duke Nukem, Golden Eye, Hell Raiser, HacX....

Notes:
- I have implemented an SDL sound renderer. So sound and music should be supported in all games.
- There are some strange graphical glitches (a few flickering walls, nasty menu text, etc). However it is very playable in its current state. I will look to improve this.
- So far I've tested the Strife, Doom 1, Hexen & Heretic demos. Its up to you guys to test the rest. I suspect some of the more complicated mods might not be playable.
- Don't forget to read 2xZdoom220.txt and go to the "customize controls" menu to set the controls for each game.