27 replies to this topic

[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.

Edited by fusion_power, 16 January 2010 - 06:47 PM.

[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.

Edited by mcobit, 16 January 2010 - 07:35 PM.

[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
- ...

Edited by JayFoxRox, 17 January 2010 - 11:23 AM.

[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.o.../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)

[JayFoxRox]

When I was talking about plugins I actually meant classes or modules. Like the current system, but with stricter rules.
The system shouldn't have pre-defined platforms like it has right now, but things like video_ogl, video_ogles, video_gx, .. as you could just mix w/e you need for one platform (Just see how similar most systems are.. Pandora only needed its own renderer while its fine with something like input_sdl (which is input_pc right now)).

I also had a look at the current stage format but I would like to modify it even more.
I'm currently busy writing my own stage code (based on the existing one to some degree) which also accepts "stage options" (numeric values, strings, colors, ..).
These options could be used to load the current stage format for example, creating some backwards compatibility or for more powerful and artistic things like light colors of the stage.

OBJ as model format sounds fine to me (even if I'm not a friend of text formats, I like binary stuff more). I think its best if the mesh class would have a pointer where the renderer could store its own private data, then callback the renderer when a model is initialized, modified or unloaded so it can update the private data (a list with drawcalls, compiled mesh, padded vertices, .. whatever the renderer needs).
In the most simple case the game would request a "test.obj" which is parsed, the renderer gets the data passed in, changes its private data pointer to point to the raw data read from the file, the renderer would then use the immediate rendering to draw the mesh at runtime (like it does right now).
In an optimized case the renderer would be notified about new data from "test.obj", compile a vertexbuffer, generate the drawcalls and optimize the mesh structure, unload the raw data (unless the raw data are supposed to be readable / changeable afterwards) and only keep the mesh in the private data for fast rendering.

The same should happen for textures. Right now the renderer (video_pc.cpp for example) has to load the PNG file on its own while it would make much more sense to load the PNG in a texture class, then tell the renderer that a texture should be prepared for rendering.

- 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...

How about waiting for the last midi note or just waiting a bit after the song has stopped?
The wrong start doesn't seem to happen anymore. However one thing I noted is that the loading bar sometimes has a duck in it, is that intended (http://jayfoxrox.bpl...263720070-1.jpg)?



video_pandora.cpp is still REALLY dirty, I already started to clean it up, but there are still some stupid things in it. It should just stay where it is for now
However, are you on IRC or MSN so we can discuss design questions?

[Daid]

The duck is an Easter egg don't worry about it.

And I get your plugin system now. Guess that would be a good way to go. The new Makefiles should make that easy. Was not needed before because there was just Wii and PC, which has difference in everything.

If you are going to change stuff on the stages, take a look at http://creators.rockband.com/spec/Authoring it contains a lot of information about special effects contained in the midi file.

OBJ was a simple selection, almost every piece of 3D software exports them and they are very easy to read. And not using binary formats skips the endian problem

Waiting for the last note as well as the audio ending sounds like an idea.

EDIT: Btw, I'm no longer on MSN due to... issues. But you can find me on irc. Best bet would be at irc.tweakers.net/#guitarsonfire (I hang out on that server for other channels, but those are dutch)

Edited by Daid, 18 January 2010 - 11:49 PM.

[Tensuke]

Looks great! After looking at the Wiki, am I safe to assume that FoF songs more or less work with this? And as you say you're a GH3 fan, would it be possible to make a GH3 theme? Obviously not included with the game, but as a separate download...
Anyway, it's pretty awesome that you've got so much working already. I realize that without an actual controller the game isn't quite the same, but for those without one I was thinking of a control scheme for the Pandora. Perhaps the L/left/down/right/R buttons for the frets, and the lower action button for strumming? IIRC the dpad/gaming buttons don't have the two-button restriction that the keyboard has, and this way the only combinations you couldn't really hit would be left/right at the same time. Without a Pandora in my hands I'm not really sure how that'd feel, but it's just one idea...
Good luck!

[Mr.Confuzed]

@Tensuke, I haven't found a FoF song that hasn't worked.

The problem I see with your key configuration is that the second and fourth fret are commonly used together. I'd suggest L/left/up/X/Y and R for strumming, or something similar to that.

[Nova]

I could have a go at gfx if you tell me what kinda things you're looking for?

[Daid]

@Tensuke, I haven't found a FoF song that hasn't worked.

I have two songs that don't work. 99% of the songs are saved as 44.1kHz OGG files, but some saved at different sample rates, and GuitarsOnFire does not cope with that

I could have a go at gfx if you tell me what kinda things you're looking for?

Well, I gave the notes a nice update for the next version. (I'll try to make a nice screenshot)
But what I really could use are some nice stages or even menu gfx. Right now the menus are pretty plain and boring, but I can go in any direction with those. There is this fire effect in the background, and it's only there for 1 real reason. Some TVs see black as no picture and start switching between different screen modes because of it. So with a proper background on the menus I could remove it.

I follow a very simple rule on this. I use what I have, I don't beg for things. And if people create something I will do my very best to add it. Don't worry about the details/formats/sizes. Create something that looks awesome and you will make the game look awesome
(Take notice of the "create", I won't accept stuff ripped from the official GuitarHero/Rockband games)

Edited by Daid, 19 January 2010 - 05:13 PM.

[Daid]

I guess a status update wouldn't hurt.

I've revamped the input system, this should allow for better configurable Pandora support.
I've revamped some of the video system, mainly the texture and model support. The new models are textured and look a bit better. This will require some changes in the port by JayFoxRox, but nothing I cannot handle.

The network code has gotten a few updates, but that's preparation for bigger things. Like downloadable songs/stages/mods.
Added a 'mod' feature which allows users to change the looks of the game without overwriting the default game files.

Working on stuff like starpower and new gametypes. But this code is a mess and it will take a bit of time.

[JayFoxRox]

This looks somewhat better (//Edit: code wise, didn't compile it yet)! Going to port it next weekend probably, but another project takes most of my time right now.

Edited by JayFoxRox, 25 January 2010 - 01:10 PM.