Guitarsonfire

[Daid]

Hello,

I'm pretty sure I've seen the request somewhere. So here I am.

I own a GP2X and have followed the development of the Pandora for a 'while' now. And now it finally looks that it will ship in less then 2 months. So time to get some software plans ready.

For the last half year or so I have been developing a GuitarHero clone for the Wii, called GuitarsOnFire. And I think this will make a nice port to the Pandora. For those not familiar with it, information can be found here: http://wiibrew.org/wiki/GuitarsOnFire

Why would this make a nice port?
Well, the code is pretty clean C/C++ code, with very few dependencies. The code is for 90% platform independent, and all platform specific functions have separated from the rest. The code already builds and runs for Windows, Linux and the Wii. The Wii has less power then the Pandora, so it will run for sure.
And of course the game itself is also awesome (But that might just be my opinion)

Other alternatives for open source GuitarHero games are FretsOnFire and GuitarFun. FretsOnFire is very good, but it depends on python and a whole load of libraries. Making a porting effort quite hard. (And for the Wii almost impossible)
GuitarFun is a POS, it was made for the PSP or something, and has some nasty bugs. Don't even think about it, you'll just hurt yourself. It's what made me make GuitarsOnFire.

What needs to be done
The porting effort will consist out of a few things:

• Using most of the 'PC' code for the Pandora, effortless, as the PC version is build to run on windows with mingw, and compiled fine on linux some time back. Effort here is minimal.
• Reimplementing "video_pc.cpp" for the Pandora, this makes use of OpenGL in the PC version. And thus has to be redone with OpenGL ES. This will require quite some effort, zero experience with OpenGL ES. And from what I understand it's quite different from OpenGL
• Reimplementing "input_pc.cpp" for the Pandora, this contains all the functions to read controllers. The PC version maps this to keyboard keys for testing. But the Pandora has a unique set of gaming controls. And not to forget, bluetooth, which could be used to hook up a Wii guitar. Shouldn't be too hard, once we figure out what works best. Bluetooth might be some work, but that's just extra.
• Testing... kind of a issue for me.

Now, I can do most of this myself. But I don't own any Pandora myself. So I cannot test it. Which is a shame, but that's how it is.
So I'm looking for:

• Ideas, tips, hints. What do you think will work as controller settings? What features would you like to see? Any other brilliant ideas?
• Best case, a developer willing to help me. Just with full repository access, you get to do what developers do best. Make stuff. Because porting effort will be minimal, the code can remain in the same repository. I just need someone to spend a bit time on it and make a good release. Of course with my assistance where needed. And this person will be free to do extra features and just about everything he wants. But could also stick to just a port and new versions when they are ready.
• Worst case, a tester willing to help me. I can manage to compile and package a application, but this will take more time. Especially in the beginning where I need to get a first version working.

 

[CCmachined]

I'm an interested dev and could help a fair bit I imagine (C++, done a bit of work with SDL, and playing with VB, Java, JavaScript, nothing really serious to be honest), I don't have a testing unit though. My Pandora is coming from the second batch, so that'll probably take a while to get here.

However, some thoughts:

• How would the controls work?
• Are you using OpenGL ES or OpenGL?
• Does Guirarsonfire have GH1,2,3/RB etc etc import capability? (I realise this isn't a priority, but it's nice nonetheless)

 

[JayFoxRox]

It looks kinda complete already, I could possibly help porting, work on graphics for the background like in the original guitar hero or some other things.

 

[alucart1984]

SNIP The Wii has less power then the Pandora, so it will run for sure.
SNIP

Are you serious? The Pandora is quite a bit less powerful then the Wii. I believe that this will work for the Pandora, but I just don't think the Pandora has the same amount of computing power the Wii has.

 

[Daid]

I'm an interested dev and could help a fair bit I imagine (C++, done a bit of work with SDL, and playing with VB, Java, JavaScript, nothing really serious to be honest), I don't have a testing unit though. My Pandora is coming from the second batch, so that'll probably take a while to get here.

However, some thoughts:

• How would the controls work?
• Are you using OpenGL ES or OpenGL?
• Does Guirarsonfire have GH1,2,3/RB etc etc import capability? (I realise this isn't a priority, but it's nice nonetheless)

Best way to get serious is by getting your hands dirty Just try to compile the PC version for starters, which might be quite a feat already.

"How do the controls work" - Good question. On my laptop I use F1-F5 as 'fret' keys, and up/down keys to strum. And I got scary good with it because of all the testing I do. But for the Pandora this needs some thought, one of the reasons why I made this topic. Maybe it would work to tilt the pandora sideways, strum with the DPad and use a few letter keys as frets...
"Are you using OpenGL ES or OpenGL?" - PC port uses OpenGL. On the Wii there is something called GX (which works a bit like OpenGL) but all of it is abstracted by a few simple functions. With a bit of luck, only this: http://pastebin.com/m32b8f1aa needs to be ported to OpenGL ES.
It doesn't do any importing. But I think there are converters to FretsOnFire for those songs already. And I just use FretsOnFire compatible songs

It looks kinda complete already, I could possibly help porting, work on graphics for the background like in the original guitar hero or some other things.

Graphics work would be awesome. I'm not a great artist. I ripped gfx where I was legally allowed, and made my own where needed, but it still looks kinda dull I think.

SNIP The Wii has less power then the Pandora, so it will run for sure.
SNIP

Are you serious? The Pandora is quite a bit less powerful then the Wii. I believe that this will work for the Pandora, but I just don't think the Pandora has the same amount of computing power the Wii has.

Not want to ruin this topic with this discussion. So, ok. Fine.

 

[Aimless_E]

SNIP The Wii has less power then the Pandora, so it will run for sure.
SNIP

Are you serious? The Pandora is quite a bit less powerful then the Wii. I believe that this will work for the Pandora, but I just don't think the Pandora has the same amount of computing power the Wii has.

Not want to ruin this topic with this discussion. So, ok. Fine.

I think Daid wasn't referring to the hardware specs of both systems, but rather to the genius of the Pandora's design and the inherit power of an open system that allows for both commercial and non-commercial endeavors.

Best of luck with the port and I hope that you or whomever adds bluetooth guitar support.
Oh and if you plan on putting it in the papp store you might want to look into fair use music or try to contact ColdStorage to arrange a "Free" mix or two to distribute with the title.

 

[conso]

wow, I'm amazed! All of my family and friends love playing guitar-hero and rockband. We used to play a lot of fretsonfire, but for some reason it got very sluggish on our family-pc a while back. Still have a lot of selfmade songs for it that I'd love to play with friends again.
We have 3 guitars (2gh3 1rb1), 3 mics (1rb,2ss) and (rb1-)drums.
Would it be possible to use all 3 guitars and the drums and the same time with your game? Having a pandora-release would be even more awesome then, as rock-band doesn's support 3 guitars and I hate taking my ps3 to friends.

 

[Caine]

How would the controls work?

If you also support the Wiimote over bluetooth you can actually use the Wii guitars if you own any. Useful for when you hook up the Pandora to the TV.

 

[conso]

How would the controls work?

If you also support the Wiimote over bluetooth you can actually use the Wii guitars if you own any. Useful for when you hook up the Pandora to the TV.

well, probably the same applies to ps3-guitars as those work basically on every linux-desktop-distribution. Still, it would be nice to have a more portable solution. Keyboard should be fine, but for the max-2-buttons-at-same-time restriction.

 

[Mr.Confuzed]

Maybe it would work to tilt the pandora sideways, strum with the DPad and use a few letter keys as frets...

Won't work: the keyboard only recognizes two simultaneous presses. Your best bet will be a guitar controller or a usb keyboard. The gaming controls should work, but I can't imagine that not being awkward. You could call it hardcore mode.

I've built the game and it seems to work, except that it seems to think that there is another player. This prevents me from playing because I can't control the other player. Any ideas?

 

[Daid]

wow, I'm amazed! All of my family and friends love playing guitar-hero and rockband. We used to play a lot of fretsonfire, but for some reason it got very sluggish on our family-pc a while back. Still have a lot of selfmade songs for it that I'd love to play with friends again.
We have 3 guitars (2gh3 1rb1), 3 mics (1rb,2ss) and (rb1-)drums.
Would it be possible to use all 3 guitars and the drums and the same time with your game? Having a pandora-release would be even more awesome then, as rock-band doesn's support 3 guitars and I hate taking my ps3 to friends.

Well, it supports up to 5 players. On the wii that can be 4 guitars or drums (in any mix) and a single USB keyboard. We can use whatever controls we can get working

How would the controls work?

If you also support the Wiimote over bluetooth you can actually use the Wii guitars if you own any. Useful for when you hook up the Pandora to the TV.

The wiiuse library should make this pretty easy. So, that was the plan yes.

How would the controls work?

If you also support the Wiimote over bluetooth you can actually use the Wii guitars if you own any. Useful for when you hook up the Pandora to the TV.

well, probably the same applies to ps3-guitars as those work basically on every linux-desktop-distribution. Still, it would be nice to have a more portable solution. Keyboard should be fine, but for the max-2-buttons-at-same-time restriction.

Guess those work as basic HID devices then. I don't own any of those but I guess someone who has one will figure it out

Maybe it would work to tilt the pandora sideways, strum with the DPad and use a few letter keys as frets...

Won't work: the keyboard only recognizes two simultaneous presses. Your best bet will be a guitar controller or a usb keyboard. The gaming controls should work, but I can't imagine that not being awkward. You could call it hardcore mode.

I've built the game and it seems to work, except that it seems to think that there is another player. This prevents me from playing because I can't control the other player. Any ideas?

Only 2 keypresses, well, that should work for most songs on easy/medium. And a few on hard. Just supporting as much controller settings as possible would be the best I guess

Oh, yeah, the PC version input_pc.c has some 'debugging' tweaks. It acts as if player 2 has connected wii-drums. Solution is simple, just press '5', that's the drum cancel button. Or remove the 'buttons |= INPUT_HAS_DRUMS;' lines from input_pc.c
It has a few more wierd button things, like slash tilting the guitar, blackslash being the whammy bar, 'y' should show a low battery warning for player 1 ingame. And 'z' does 'ok/select' on players 3 to 5 at once. This config allowed me to test a lot of features but was not indented for general playing.

I've setup an SVN repository here: http://daid2.mine.nu/svn/Wii/GuitarsOnFire/ which contains a few fixes for a linux build. And a Makefile for linux.

 

[Mr.Confuzed]

Looks like a solid game... Personally, I'd like to be able to see the notes when they're a bit further away. Maybe the guitar neck could be tilted down more?

In terms of porting, it looks good and modular, but you're using immediate mode rendering. That'll have to be changed to vertex buffers. Sounds like fun. It should make your game run faster too. You'll probably need to add a function or two though, which might cause compatibility issues with the Wii version.

By the way, I'm sure I'll be able to test eventually, if not develop.

edit: I think some of the work should be offloaded onto the vertex shader, assuming you want to use openGL ES 2.

 

[JayFoxRox]

Hey there again.
I'm looking at the GX documents (even tho I don't have a stationary nintendo console, I'll see if an emulator works for me) right now and I'll probably rewrite the renderer, add a menu stage (for the main menu) and a new stage format (/ commands) which supports skeletal animation, bumpmapping, lights, fog and shadows (features which work on both, Pandora and Gamecube / Wii).
I also created a makefile and made some changes as typecasting was necessary in some parts.
It should be fairly easy to port this to the Pandora.

http://jayfoxrox.bplaced.net/pandora/public/GuitarsOnFire
http://jayfoxrox.bplaced.net/pandora/testing

should have some data in them soon.

Daid: In which direction would you like to go? (I would personally like if the guitars were more GH style (more 3D elements / more complex shape), but I don't want that I'm writing this update for nobody else than me because you wanted something different )

//Edit: Also, is it normal that there are no notes at times? And where is the stricmp defined, its not included in my string.h anymore so I just defined stricmp as strcmp

 

[Rockthesmurf]

And where is the stricmp defined, its not included in my string.h anymore so I just defined stricmp as strcmp

stricmp is a case insensitive version of strcmp, so it's results aren't guaranteed to be the same. I know you get a deprecation warning with Visual Studio 2005 when using stricmp, it says you now need to use _stricmp instead - perhaps that would work for you?

//Edit - also, I think it is exciting you are taking a look at this project.

Steve

 

[JayFoxRox]

video_pandora.cpp, first hacked together version using OGLES2.0

I'll have to change some things tho as SDL seems to be initialized in the video code (meaning input doesn't work as I create my own X window), this should be changed imo.

//Edit: I know what stricmp is, but as I said: its not defined anymore. I also figured out _stricmp does work (not for me tho, I thought it would but I just didn't recompile that part), yet I wonder where stricmp (without leading underscore) comes from if he uses mingw32.

 

[fusion_power]

I hope, this game will be able to played without special, external Controllers. Guitar Hero also works onto the NDS so I think a system like there is the best way to play such a game onto a Handheld. Pandora has a large Touchscreen so it could be used somehow. ^_^

 

[mcobit]

I hope, this game will be able to played without special, external Controllers. Guitar Hero also works onto the NDS so I think a system like there is the best way to play such a game onto a Handheld. Pandora has a large Touchscreen so it could be used somehow. ^_^

But on the DS you need a special controller that you stick under the unit to press the buttons. Just the strings you have to hit on the touchscreen.

Edit: If anyone wants to know, I will try to create such a controller when the Pandora arrives.
Now it is just a prototype made from an old usb gamepad and a plasticbox. But i will try to make something wooden, when i know the exact proportions of the pandora.

 

[JayFoxRox]

I would say the port is complete for now.
The renderer has no known problems but its REALLY slow because it has to malloc a buffer for every draw call to store the vertex data. Another problem is that the color comes in integer format (and then also split in color / alpha, who thought this was a good idea?) while its needed as 4 seperate floats to be used effectivly.

The real problem is that these draw calls are used all over the place it seems.

The game works the way its supposed to right now, but it has lots of cons at the moment.
- The graphics seem like they were thrown together
- The menu system can be confusing (How do you escape the change controls dialog for example, without messing up your settings? How to change the second players controls?)
- Why not input username with keyboard?
- Very few informations about what each button does in the menu
- Why does it always think I have 2 players connected
- The song sometimes starts that soon after loading that I miss notes
- Loading time depends on the renderer I use (Why not skip frames while loading?)
- The SDL initialization is in the video_pc.cpp, meaning that if you can't / don't want to use SDL for the video nothing else works because input is linked to the SDL window (which doesn't exist in this case)
- The freestyle mode is not too good, why not a sound studio where you can record/edit your own tracks?
- Not translateable that easily
- ...

I think its a much better idea to take the core and re-write most things from scratch:
- New menu system (with the option to configure each players control on its own more easily)
- New stage format to have the ability for what I mentioned above, modifiers, effects, .. as scripts
- Use of VBOs in the renderer and more features in general
- Dummy plugins for input, audio, video, .. to make porting even easier (as the existing video_pc for example has redundant code all over the place)
- Network play
- ...

 

[Mr.Confuzed]

@JayFoxRox, I agree with most of what you said in the long run. I'd like to see a quick port that runs fairly well first because it's pretty solid as is.

JayFoxRox said:The real problem is that these draw calls are used all over the place it seems.
If we make the gameplay elements script-customizable, that should solve the problem. Would we want to include the menu system as well?

- The song sometimes starts that soon after loading that I miss notes
I've seen it quit before I can play the last note.

- Why does it always think I have 2 players connected
It's a debugging feature, see a few posts above for details.

- Dummy plugins for input, audio, video, .. to make porting even easier (as the existing video_pc for example has redundant code all over the place)
Are plugins really necessary? I don't know how much use they'll be. How often would you want to switch between video plugins, for example?

 

[Daid]

I would say the port is complete for now.
The renderer has no known problems but its REALLY slow because it has to malloc a buffer for every draw call to store the vertex data. Another problem is that the color comes in integer format (and then also split in color / alpha, who thought this was a good idea?) while its needed as 4 seperate floats to be used effectivly.

Yeah, figured the model drawing was going to be a problem. Because the whole .raw model format was giving more people problems I have replaced it with .OBJ formats.
The color/alpha split is because the alpha is usually calculated because of some effect while the color is static. Ints instead of floats has no reason at all. The wii and OpenGL can handle both as far as I know. So if OpenGL ES needs floats then I'll convert them to floats.

(Using bold instead of quotes, as amount of quotes per post is limited)
The real problem is that these draw calls are used all over the place it seems.
I'm so familiar with the code that that shouldn't be a problem for me. The color always comes from the color arrays defined in model.cpp/model.h. I'll have a look at the video_pandora to see where the boot does not fit and what I can change to make it better.

The game works the way its supposed to right now, but it has lots of cons at the moment.
I'll comment on each one.

- The graphics seem like they were thrown together
They where. The new notes look a bit better. But I'm no artist at all. I use what I have, but I could use some serious contributions here.
- The menu system can be confusing (How do you escape the change controls dialog for example, without messing up your settings? How to change the second players controls?)
This mostly has to do with the fact that it has been made for the Wii, where only the USB keyboard is configurable, and not the first priority.
- Why not input username with keyboard?
Good question. Something I should add.
- Very few informations about what each button does in the menu
Documented on http://www.wiibrew.org/wiki/GuitarsOnFire/ for the Wii version and if you have played a GH/RB game it comes quite natural. But for a good pandora port this could be better. Maybe even touchscreen for the menus.
- Why does it always think I have 2 players connected
Simple debug 'feature' easy to fix.
- The song sometimes starts that soon after loading that I miss notes
I've seen it quit before I can play the last note.
Quit is easy to explain, it quits when the music stops. Guess your last note was not in the music.
The wrong start is strange, I never had that...

- Loading time depends on the renderer I use (Why not skip frames while loading?)
Not an big issue on the Wii, but a serious issue on anything else. So this will change. Tried to use a 2nd threat for loading, but this didn't work very well on the Wii.
- The SDL initialization is in the video_pc.cpp, meaning that if you can't / don't want to use SDL for the video nothing else works because input is linked to the SDL window (which doesn't exist in this case)
The whole SDL library usage was just for debugging, so that didn't matter to much. Also, why not use SDL?
- The freestyle mode is not too good, why not a sound studio where you can record/edit your own tracks?
Freestyle was a last minute addition. Not really a planned feature. So no wonder it's kinda sucky
- Not translateable that easily
I love the english language. While I'm native dutch, I hate dutch translations it saves me time. I rather work on other things then make it translatable.

I think its a much better idea to take the core and re-write most things from scratch:
- New menu system (with the option to configure each players control on its own more easily)
I think this just needs a few changes in the settings menu.
- New stage format to have the ability for what I mentioned above, modifiers, effects, .. as scripts
Could fit in the current format. The stages are scriptable... what should be better is to add 3D model support. Which would be easier with the new OBJ code.
- Use of VBOs in the renderer and more features in general
VBO? Vertex buffers? New OBJ code should be more suitable for that.
- Dummy plugins for input, audio, video, .. to make porting even easier (as the existing video_pc for example has redundant code all over the place)
Yeah, the PC ports where not made for quality, but just to test the Wii version on the PC. So they ain't that pretty.
- Network play
Would be a whole new feature. Cool feature, but the game.cpp is something on my list of "needs major rewrite for new gametypes"

See the SVN for the new OBJ files with code btw
I'll also add your video_pandora.cpp to SVN if you want.

And, 'plugins' is not something I can support on the Wii, and overcomplicated things IMHO. I'm not saying the code is pretty, well structured and great. But it works, is pretty stable. I took a lot of shortcuts to get it done. But I rather have bad code working then pretty code unfinished. I am cleaning up (the menu code gone trough a major rewrite in 1.1, 1.0 was copypasta all over the place) but it's not a huge 20 man project supporting 10000 options. It's a 1 man project with main platform the Wii (which has 1 hardware configuration)

(And stricmp works for me with mingw. If it doesn't in some compiler, then strfunc.h would be the best place to make a define for it to work (#define stricmp strcasecmp for example)