Egoboo Wii Port
Moderator: Developers
Re: Egoboo Wii Port
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:
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:
-
- {]-[0{0|307 (Developer)
- Posts: 1864
- Joined: Wed Jul 23, 2008 4:22 am
- Location: Minnesota, USA
Re: Egoboo Wii Port
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.
Let me know if you come up with something awesome.
Re: Egoboo Wii Port
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.
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.
Re: Egoboo Wii Port
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:
A lot of ambient lighting:
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!
Very little ambient lighting:
A lot of ambient lighting:
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!
Re: Egoboo Wii Port
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!
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!
-
- {]-[0{0|307 (Developer)
- Posts: 1864
- Joined: Wed Jul 23, 2008 4:22 am
- Location: Minnesota, USA
Re: Egoboo Wii Port
In the old code, "blocks" were 4x4 tile areas which were used to limit who could collide with whom. TheWhat 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).
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.
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.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).
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".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.
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:
- if a background is to be used (like the star background in the shadow palace) it is drawn
- all the non-reflective tiles are drawn
- all the reflective tiles are drawn, but invisibly, to set the z-buffer depth of the reflective flooring
- all reflected fans, objects, and particles are drawn under the floor (back to front)
- all solid objects and particles are drawn (front to back )
- all transparent objects are drawn (back to front)
- penguinflyer5234
- Sheep (Developer)
- Posts: 3025
- Joined: Wed Jul 23, 2008 1:39 am
- Location: Best Southwest
Re: Egoboo Wii Port
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
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
...
Re: Egoboo Wii Port
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 .
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 .
- penguinflyer5234
- Sheep (Developer)
- Posts: 3025
- Joined: Wed Jul 23, 2008 1:39 am
- Location: Best Southwest
Re: Egoboo Wii Port
Thanks, that worked. (now, time to fix some blending errors)Veiva wrote:Try and transpose the Matrix produced by Matrix::LookAt. I believe the row/column order is different between the Wii and OpenGL.
Spoiler: SDL port of Egoboo-Wii as of now
...
- Maxaxle
- Darkshine Knight (Extremist fanatic)
- Posts: 4035
- Joined: Fri Jul 25, 2008 8:16 pm
- Location: San Diego, CA
- Contact:
Re: Egoboo Wii Port
If all else fails, you could try using the Classic Controller.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.
"Failing to plan is planning to fail."
Bug me if you want to play a game.
Bug me if you want to play a game.
- penguinflyer5234
- Sheep (Developer)
- Posts: 3025
- Joined: Wed Jul 23, 2008 1:39 am
- Location: Best Southwest
Re: Egoboo Wii Port
The first post, Maxaxle. The FIRST post.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.
...
Re: Egoboo Wii Port
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!
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!
- penguinflyer5234
- Sheep (Developer)
- Posts: 3025
- Joined: Wed Jul 23, 2008 1:39 am
- Location: Best Southwest
Re: Egoboo Wii Port
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.
If I knew somewhat how git and github worked, I would do the fork thingy.
...
Re: Egoboo Wii Port
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:
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!
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:
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!
- penguinflyer5234
- Sheep (Developer)
- Posts: 3025
- Joined: Wed Jul 23, 2008 1:39 am
- Location: Best Southwest
Re: Egoboo Wii Port
I just noticed WiiTexture.cpp:96 is incorrect, it frees the memory incorrectly (using free() instead of allocator->deallocate)
...