GP32 I Got Yeti3d To Compile!


Its no big deal, actually. Curved/bumpy/oddly-shaped walls/floors/platforms can be implemented by replacing the cube used for transformation with something else, nobody has really done it much in the GPL version though because its a pain (due to crappy interface). So really the only useful extra I see in the "pro" version is the more accurate and less choppy lighting, which I hope to be able to implement perhaps. But I'm getting ahead of myself here.

What I actually want to do first is improve the interface, and document the API's.
I want to make the interface involve more things like sdl_rects and sdl_surfaces and etc. Also, once I figure out how SDL_RWOPS works, I am going to make file loaders for the various data.

Also, the game.c file is an EXAMPLE, people. An improved interface (and your own game.c for your engine) would allow for alot more flexibility.

@Rtb7: I would like to see the modified editor and java tools, it could help alot.
 
Do you need the modified editor too ?
The java tools (MD2 transformation and Texture set editor) ?


Yes, please anything will help. thank you!


What I actually want to do first is improve the interface, and document the API's.
I want to make the interface involve more things like sdl_rects and sdl_surfaces and etc. Also, once I figure out how SDL_RWOPS works, I am going to make file loaders for the various data.

that's it! keep us informed and when you need help drop me a line even though I have no 3d expertise at all.
 
Last edited by a moderator:
Tools :

Yeti Editor : http://www.geocities.com/rtb7/files/gp32/editor_code.zip
(128*128 256 colors textures)

Texture tool : http://www.geocities.com/rtb7/files/gp32/yeti_tex.zip
(Java tool to generate compatible .RAW and .PAL files from jpg/gif/png images)

3D tool : http://www.geocities.com/rtb7/files/gp32/3d_tools.zip
to export MD2 to my yeti anim format.

little help to export md2s :

Launch tool
On the tree, right click on "Objects" node, "Load object" in popup menu.
Select <file>.md2
Choose correct zoom factor
mouse wheel to view animation frames
menu on object :
Smooth to insert interpolated animation frames
Yeti to export object to yeti format :
select target name in file chooser
window with animation frames appear
uncheck/check what you want to export
close window : the file is generated

use http://www.geocities.com/rtb7/files/gp32/adic2k4_src.zip example to play with your exported md2s

These tools are not really user friendly, as they were done for my own usage.
Some part may not run correctly because I'm currently rewritng some features.

JDK1.5 mandatory.

Thor
 
Does anyone have a paletted bitmap version of some Yeti textures and the map that goes to it?

I need it so I can test the loading of external textures and palettes using the standard SDL image loading features.

Thanks in advance.
 
I did a modified version of yeti last year (http://www.geocities.com/rtb7/files/gp32/ADIC2K4.zip) with some extra features : MD2s like animations and 256 colors textures.

I can share my sources too if someone is interrested.
I just recompiled it with devkitarm_r17 and it still works fine.

Thor

Now you done, but if is GPL, you must.
Thanks for your sources and your great stuff ;)
 
Last edited by a moderator:
Okay, I've found the BMP texture I asked for. Thanks to google's translation of Angelsoftware.org and no thanks to any of you :p.

I've yet to test on that as I just downloaded it, but since I'm here anyway, here's the progress so far:

yeti_init now accepts SDL_Surface* instead of framebuffer_t*

lua_rgb function (from Thunderz's port) now used so that Yeti renders natively in 16bit color and no longer needs to convert. I modified it so it works on PC as well.

map, palette, and texture loading features (from Thunderz's port) ported and added to SDL version.

That's it, but theres more to come.

Its not ready for another release yet, though, but possibly soon.
 
Okay, I've found the BMP texture I asked for. Thanks to google's translation of Angelsoftware.org and no thanks to any of you :p.

I've yet to test on that as I just downloaded it, but since I'm here anyway, here's the progress so far:

yeti_init now accepts SDL_Surface* instead of framebuffer_t*

lua_rgb function (from Thunderz's port) now used so that Yeti renders natively in 16bit color and no longer needs to convert. I modified it so it works on PC as well.

map, palette, and texture loading features (from Thunderz's port) ported and added to SDL version.

That's it, but theres more to come.

Its not ready for another release yet, though, but possibly soon.

Why not using rtb7 fork instead ThunderZ one? It seems has interesting improvements...
 
Last edited by a moderator:
Thunderz and Rtb7's code are about the same. All that Rtb7 adds is 128x128 textures (IMO they are ugly and slow) instead of 64x64.

His "MD2 loader" does not actually load MD2's but instead sprites made from MD2's (I can already do that).

The SDL version comes with a model loader (model.c), I haven't figured out how to use it, buts its actually 3D instead of 2D.

Today, I am working on making it use SDL_Surfaces to get the palette and textures. I've got the textures working already, but I still have to figure out how to make a LUA from a SDL palette, instead of a yeti pallete.

If I do that, textures can be loaded from images of any 8bit format, and the palettes would load with them so you don't need separate palettes.

Now the sprite displaying function (bullets, 2d monsters) is broken from making it render natively in 16bit color, but I hope to replace that completely with SDL's blitting and scaling functions.
 
Can anybody tell me what the variables mean here? I know what it does but not how it does it:

YETI_ROM s8 cube[] =
{
1, // Number of vertex lists (Animation Frames)
8, // Number of verices per list.
-100, 100, 100, // Vertex X, Y, Z. Range (-120..120)
100, 100, 100,
100, 100, -100,
-100, 100, -100,
-100, -100, 100,
100, -100, 100,
100, -100, -100,
-100, -100, -100,
6, // Number of faces in the polygon mesh.
// Each face is (NPoints, VID, U, V) + texture id.
4, 0, 0, 63, 1, 63, 63, 2, 63, 0, 3, 0, 0, 8,
4, 3, 0, 63, 2, 63, 63, 6, 63, 0, 7, 0, 0, 8,
4, 2, 0, 63, 1, 63, 63, 5, 63, 0, 6, 0, 0, 8,
4, 0, 0, 63, 4, 63, 63, 5, 63, 0, 1, 0, 0, 8,
4, 0, 0, 63, 3, 63, 63, 7, 63, 0, 4, 0, 0, 8,
4, 4, 0, 63, 7, 63, 63, 6, 63, 0, 5, 0, 0, 8
};
 
Can anybody tell me what the variables mean here? I know what it does but not how it does it:

YETI_ROM s8 cube[] =
{
  1,              // Number of vertex lists (Animation Frames)
  8,              // Number of verices per list.
  -100,  100,  100, // Vertex X, Y, Z. Range (-120..120)
  100,  100,  100,
  100,  100, -100,
  -100,  100, -100,
  -100,  -100,  100,
  100,  -100,  100,
  100,  -100, -100,
  -100,  -100, -100,
  6,              // Number of faces in the polygon mesh.
                  // Each face is (NPoints, VID, U, V) + texture id.
  4, 0, 0, 63, 1, 63, 63, 2, 63, 0, 3, 0, 0, 8,
  4, 3, 0, 63, 2, 63, 63, 6, 63, 0, 7, 0, 0, 8,
  4, 2, 0, 63, 1, 63, 63, 5, 63, 0, 6, 0, 0, 8,
  4, 0, 0, 63, 4, 63, 63, 5, 63, 0, 1, 0, 0, 8,
  4, 0, 0, 63, 3, 63, 63, 7, 63, 0, 4, 0, 0, 8,
  4, 4, 0, 63, 7, 63, 63, 6, 63, 0, 5, 0, 0, 8
};

Isn't it just a simple displaylist?
 
Last edited by a moderator:
I know that its defineing what a cube is by its vertices in 3D space, but how?
If I knew that, I could make a shape editor and allow for curved walls like in the pro version.
 
MYGPCONV doesn't do any magic to your palette, does it? If it does, that would explain why loading palettes from the BMP itself using the SDL_Surface's palette looks a little off.
 
and I don't use sprites from MD2s, I just translate MD2s to a format I can use more easily. I use the code from the cube to display my 3D models.
The 128x128 textures look ugly because the texture are ugly... I know that.
But I tested the quality, and when you go near a wall, it's really better than a 64x64 texture.
 
Rtb7 is true.
That is the reason why i say that i was the only man that really show the code.

You can use hte format you want to store your 3D models but you can easily display it using the same function as the cube. ;)
 
Yeah, I was just about to post that I figured out that its an example entity, not a wall transformation matrix.

Anyway, thats not what I'm working on right now. I'm trying to make a function to make a LUA from the palette in an SDL_Surface, but it doesn't look right. Its all screwed up.

Anyway, to do it, I modified this function (originally from Thunderz's version):
Code:
void yeti_pal2lua() {
  
  //Make LUA from pallete
  int a,i;
  for(a=0;a<64;a++)
    {
     for(i=0;i<256;i++) 
     {
  lua[a][i]=lua_rgb(palette[i][0]*a/16,palette[i][1]*a/16,palette[i][2]*a/16); 
     }
    }
}

to this:

Code:
void yeti_spal2lua(SDL_Surface* tex) {
u8 *r = &tex->format->palette->colors->r;
u8 *g = &tex->format->palette->colors->r;
u8 *b = &tex->format->palette->colors->r;

  //Make LUA from pallete
  int a,i;
  for(a=0;a<64;a++)
    {
     for(i=0;i<256;i++) 
     {
       lua[a][i]=lua_rgb(r[i]*a,g[i]*a,b[i]*a);      
     }
    }
}

both use this function, also from Thunderz's version:

Code:
int	lua_rgb (int r, int g, int b )
{
	int	r1 = (MIN (r, 255) * 31) / 255; 
	int	g1 = (MIN (g, 255) * 31) / 255; 
	int	b1 = (MIN (b, 255) * 31) / 255;

#ifdef __GP32__
return ( ( ( r1 ) << 11 )  |  ( ( g1 ) << 6 )  |  ( ( b1 ) << 1 ) ); //GP32 handles color differently...
#endif

#ifndef __GP32__
return ( ( ( r1 ) << 11 )  |  ( ( g1 << 6) )  |  ( ( b1 ) ) );
#endif
}

@Rtb7: But 128x128 textures seem to slow down things quite a bit, right?

It doesn't matter anyways, as when I'm done you'll be *may* able to use SDL_Surfaces for textures, which will allow for whatever palette you want (you could do paletteing tricks), textures of any size as long as they are all the same size, and load your textures from whatever format using the SDL_Image lib.
 
void yeti_spal2lua(SDL_Surface* tex) {
u8 *r = &tex->format->palette->colors->r;
u8 *g = &tex->format->palette->colors->r;
u8 *b = &tex->format->palette->colors->r;

Shouldn't that be:

void yeti_spal2lua(SDL_Surface* tex) {
u8 *r = &tex->format->palette->colors->r;
u8 *g = &tex->format->palette->colors->g;
u8 *b = &tex->format->palette->colors->b;
 
I forgot to tell everyone that now SDL_SURFACE's as textures work, as well as their pallettes (a new function makes a LUA using them). This has been this way for about 2 weeks.

Today I got 256x256 textures (old ones are 64x64) to work, it was easy (quick hack). They look really nice, but unfortunately it runs too slowly on my GP32.

I do however hope to even further integrate SDL into this. Textures and skins will have a new struct format which allows them to each have their own pallette, movement, resolution, and lighting table. There will probably be more stuff too.

I also hope to eventually convert it to a real engine library, port it to GP2X and have it be able to run on the 2nd core. 3D games could use it and not have to be statically linked to it. Games would also be allowed the 1st core and 1st 32mb of RAM to themselves. TV out could later be supported and run at 640x480. Then Yeti could enjoy fame as the official 3D engine of the GP2X! :)

^^

Heh, like I'd ever get THAT done. :lol:
 
Back
Top