Egoboo Wii Port

The development of the game itself or new resources for it. Any new stuff you're working on would go here, as well as the discussion of in-development stuff.

Moderator: Developers

User avatar
Veiva
Acid Blob (New member)
Acid Blob (New member)
Posts: 18
Joined: Tue Feb 28, 2012 11:13 pm

Re: Egoboo Wii Port

Post by Veiva »

Big update again,

I have implemented lighting. Right now I only have specular and diffuse. The lighting system will allow future expansion for special effects (such as enchantments that change the color of a player). Here are the results of the Mana Sword and Loggy drawn with appropriate lighting:

Image
Image
bgbirdsey
{]-[0{0|307 (Developer)
{]-[0{0|307 (Developer)
Posts: 1864
Joined: Wed Jul 23, 2008 4:22 am
Location: Minnesota, USA

Re: Egoboo Wii Port

Post by bgbirdsey »

I can say that using multiple OpenGL-type lights to implement the global lighting system sounds interesting, but it is really computationally intensive if you have more than one light and a variation of lighting across the scene (think of a dark module with the player holding a torch and a campfire nearby).

Let me know if you come up with something awesome.
User avatar
Veiva
Acid Blob (New member)
Acid Blob (New member)
Posts: 18
Joined: Tue Feb 28, 2012 11:13 pm

Re: Egoboo Wii Port

Post by Veiva »

Yes, lighting is very computationally expensive, especially on the Wii (there are no vertex/pixel shaders; light must be done primitively using GX or through software lighting, the latter of which is the route I chose).

The good news is that a two-pass rendering of each object for diffuse and specular, in combination with animation, can be done at a solid 60 FPS with ~64 dynamic objects rendered per frame. Terrain, for example, will only be a single pass: diffuse. Players that aren't shiny will also be rendered with one diffuse pass.

Of course, I haven't factored in other stuff like AI and game management, but I am saying a good ~32 dynamic objects can be rendered per frame.
User avatar
Veiva
Acid Blob (New member)
Acid Blob (New member)
Posts: 18
Joined: Tue Feb 28, 2012 11:13 pm

Re: Egoboo Wii Port

Post by Veiva »

I've optimized lighting a bit more as well as have a (hopefully, and at this point in time...) 100% working pooled allocator for efficient memory usage.

Very little ambient lighting:
Image

A lot of ambient lighting:
Image

I can render Loggy/adventurer about 196 times with one light pass. Obviously, as I've said before, this is no way to gauge how much the game will be able to handle. It's more of a graphics benchmarking test, I guess...

I'm working on terrain loading now and hope to have that done in a couple days. Should be neat seeing Egoboo levels!
User avatar
Veiva
Acid Blob (New member)
Acid Blob (New member)
Posts: 18
Joined: Tue Feb 28, 2012 11:13 pm

Re: Egoboo Wii Port

Post by Veiva »

Hey, bgbirdsey:

I have a few questions about drawing terrains (by terrain I mean the MPD files). After pouring through the code, a few things remain unclear:

1. What is a mesh block and how is it used? I am referring to the block* variables in the MeshInfo_t. Is it for collision detection/path finding? This is what I am assuming, as it does not pop up in any rendering code (from what I can tell).

2. Are fans basically on a grid? E.g., it appears that the fans are stored row-major (if one goes by the Tile_X member in MeshInfo_t).

3. Exactly how is an individual fan drawn? I am going to look over the code more, but if you could provide insight, it would be much appreciated.

I think that's it. Thanks in advance!
bgbirdsey
{]-[0{0|307 (Developer)
{]-[0{0|307 (Developer)
Posts: 1864
Joined: Wed Jul 23, 2008 4:22 am
Location: Minnesota, USA

Re: Egoboo Wii Port

Post by bgbirdsey »

What is a mesh block and how is it used? I am referring to the block* variables in the MeshInfo_t. Is it for collision detection/path finding? This is what I am assuming, as it does not pop up in any rendering code (from what I can tell).
In the old code, "blocks" were 4x4 tile areas which were used to limit who could collide with whom. The
collisions were stored using a kind of linked list of characters for each block in the mesh.

The collision detection (and many other things) are now handled by the binary space partitioning (BSP) code. Currently it is a quad-tree, but could easily be upgraded to an octree if 3d position ever becomes important.
Are fans basically on a grid? E.g., it appears that the fans are stored row-major (if one goes by the Tile_X member in MeshInfo_t).
For some maps they are, some maps not so much. For instance the ships in bishopia harbor are a very warped grid, as are the houses in zippy city. Most everything else is grid-like, but not exactly on a grid.
Exactly how is an individual fan drawn? I am going to look over the code more, but if you could provide insight, it would be much appreciated.
It is drawn using OpenGL fans, with the vertex order given in the fans.txt file. The tile-type info in this file is also required to parse the vertices for each "fan".

The renderer actually draws the fans and character meshes in multiple passes, which are determined by a variety of sources. Actually, it is a bit of a mess. Here are the passes:
  1. if a background is to be used (like the star background in the shadow palace) it is drawn
  2. all the non-reflective tiles are drawn
  3. all the reflective tiles are drawn, but invisibly, to set the z-buffer depth of the reflective flooring
  4. all reflected fans, objects, and particles are drawn under the floor (back to front)
  5. all solid objects and particles are drawn (front to back )
  6. all transparent objects are drawn (back to front)
This is from memory, so it might not be accurate.
User avatar
penguinflyer5234
Sheep (Developer)
Sheep (Developer)
Posts: 3025
Joined: Wed Jul 23, 2008 1:39 am
Location: Best Southwest

Re: Egoboo Wii Port

Post by penguinflyer5234 »

So I've decided to port the Wii "port" back into SDL/OpenGL. (I need to learn C(++) anyway, so why not?)
Two problems I've come up with; one is that your pooled allocator isn't 100% accurate, for some reason block 207 always points to 209 when it should point to 210 in the standard pool, and two is that your Matrix LookAt and such doesn't seem to be compatible with OpenGL :|
...
User avatar
Veiva
Acid Blob (New member)
Acid Blob (New member)
Posts: 18
Joined: Tue Feb 28, 2012 11:13 pm

Re: Egoboo Wii Port

Post by Veiva »

Try and transpose the Matrix produced by Matrix::LookAt. I believe the row/column order is different between the Wii and OpenGL.

Also, the pooled allocator may be a bit buggy; I will look at it soon. I may have fixed this in my local repository (haven't yet pushed it).

On a side note, sorry I haven't worked on it all that much in the past couple days. I have been busy finishing another project of mine, Algae (an OpenGL 3 forward compatible game framework). I switch between them as to not get burnt out :P.
User avatar
penguinflyer5234
Sheep (Developer)
Sheep (Developer)
Posts: 3025
Joined: Wed Jul 23, 2008 1:39 am
Location: Best Southwest

Re: Egoboo Wii Port

Post by penguinflyer5234 »

Veiva wrote:Try and transpose the Matrix produced by Matrix::LookAt. I believe the row/column order is different between the Wii and OpenGL.
Thanks, that worked. (now, time to fix some blending errors)
Spoiler: SDL port of Egoboo-Wii as of now
Image
...
User avatar
Maxaxle
Darkshine Knight (Extremist fanatic)
Darkshine Knight (Extremist fanatic)
Posts: 4035
Joined: Fri Jul 25, 2008 8:16 pm
Location: San Diego, CA
Contact:

Re: Egoboo Wii Port

Post by Maxaxle »

Veiva wrote:I am not sure about input yet... The Wii remote may provide enough buttons I'm smart about it, if the nunchuk attachment is used.
If all else fails, you could try using the Classic Controller.
"Failing to plan is planning to fail."
Bug me if you want to play a game.
User avatar
penguinflyer5234
Sheep (Developer)
Sheep (Developer)
Posts: 3025
Joined: Wed Jul 23, 2008 1:39 am
Location: Best Southwest

Re: Egoboo Wii Port

Post by penguinflyer5234 »

Veiva wrote:Also, you will need a classic Wii (one that has GameCube ports, etc) in order to play at first. Classic controller support will come later.
The first post, Maxaxle. The FIRST post. :|
...
User avatar
Veiva
Acid Blob (New member)
Acid Blob (New member)
Posts: 18
Joined: Tue Feb 28, 2012 11:13 pm

Re: Egoboo Wii Port

Post by Veiva »

penguinflyer, how goes fixing the blending problems?

I've been relatively inactive because of hectic life with school and all. I'll continue on Egoboo-Wii when I get the chance, though!
User avatar
penguinflyer5234
Sheep (Developer)
Sheep (Developer)
Posts: 3025
Joined: Wed Jul 23, 2008 1:39 am
Location: Best Southwest

Re: Egoboo Wii Port

Post by penguinflyer5234 »

It's not perfect, but I guess it'll have to do for now :|
If I knew somewhat how git and github worked, I would do the fork thingy. :?
...
User avatar
Veiva
Acid Blob (New member)
Acid Blob (New member)
Posts: 18
Joined: Tue Feb 28, 2012 11:13 pm

Re: Egoboo Wii Port

Post by Veiva »

Hi everyone,

Long time no see again. I am continuing development on Egoboo-Wii, at least on the weekends.

I fixed a small bug and sped up the rendering code by eliminating an extraneous GX_Flush. Tomorrow I hope to work on terrain loading again.

On the weekdays I'm working on a more ambitious project, a video game of my own design. It looks like this so far:

Image

It features resolution-independent graphics. For example, the water is created on the GPU on the fly via noise, and the character is entirely made of quadratic Bezier curves (aka, an image made in InkScape). But I digress.

Cheers!
User avatar
penguinflyer5234
Sheep (Developer)
Sheep (Developer)
Posts: 3025
Joined: Wed Jul 23, 2008 1:39 am
Location: Best Southwest

Re: Egoboo Wii Port

Post by penguinflyer5234 »

I just noticed WiiTexture.cpp:96 is incorrect, it frees the memory incorrectly (using free() instead of allocator->deallocate)
...
Post Reply