Briquolo


sebt3

homebrew player (P. & C.)
Joined
Sep 9, 2008
Messages
4,886
Age
43
Location
France
Website
sebt3.openpandora.org
Hi there,

Thanks to the awesome Pickle, I've started my first conversion of a GL game to GLES. I picked up briquolo, because, well I like it ;)
Using Pickle eglport.*, his GLUES built and his instructions, I managed to get the game start with a correct EGL context.
I've converted all the immediates modes (once again, using pickle instructions and his gish and ken's sources). And I've some success.
Here are the remaining problems :
- if you try to start the game, the game freeze (I'll gdb this once the others issues are fixed) ; The level editor work well though.
- Text background seems to have an alpha problem, so in the menu all the entries are enlighted the same way (that doesnt help to see which item is selectionned :D)
- There are no textures !

My main problem is the last part, i've spend 2 days hacking around for that, whithout any results and I'm basically clueless.
I've looked, the games does found the right path for the files. All textures are square (largest is 256x256).
After the glTexImage2D and the following glTexParameteri, glGetError reports no errors.
Oh, there are text displayed so the glyph textures are loaded correctly. but this is not the same part of the code loading these.
The texture are created at the initialisation of the game, but are binded to surfaces later on. As there are not so many textures, I'm pretty sure the SGX memory isnt overloaded.
Beside for the texts, there are 3 pairs of functions to load/bind the textures :
- one for the game overlay where you see how many live left you have (I cant test that, see 1st issue, but that's only one texture so...)
- one for semi-transparants textures (water, some effects)
- one for opaque textures
The last too are really look-alike :
Go through a first list of texture and bind these to surfaces.
Go through a second list of texture, bind them to surfaces doing this strange thing :
Code:
    glRasterPos3f(it->x, it->y, it->z);
    GLboolean positionValide;
    glGetBooleanv(GL_CURRENT_RASTER_POSITION_VALID, & positionValide);

    if (positionValide)
    {
      glMatrixMode(GL_PROJECTION);
      glPushMatrix();
      glLoadIdentity();
      gluOrtho2D(0,_Largeur,0,_Hauteur);

      float pos[4];
      glGetFloatv(GL_CURRENT_RASTER_POSITION, pos);
Then the vertex coords are build around the values of pos.
I tried to cheat doing :
Code:
       pos[0] = it->x;
      pos[1] = it->y;
      pos[3] = it->z;

But this is obviously flawed.

You can get my current code here. Be sure to define PANDORA in your CFLAGS before configuring (as all my edit are inside #ifdef PANDORA blocks ; yep, autotools have been cheated for GL discovery). If you prefer reading a patch, see here. the stuff discussed earlier are in MOGL_Afficheur::_AfficherImageOpaque.

Any help would be welcome. I would even be pleased to see someone finishing my work (as long as I can get a look at the resulting code ;P)
 
Are all the texture sizes being converted to power of two? I was having an issue where textures where just showing up as white blocks. Once I converted everything to be power of 2 everything took off correctly.

Edit: I'm referring the the width and height of the texture being passed to glTexImage2D

My source code is on PC at home, take a look in Cpasjuste's GLES2D:
https://github.com/Cpasjuste/GLES2D/blob/master/src/GLES2D_texture.c
 
I have :
Most are :
32x32
64x64
128x128
256x256

But there a few odd : (one of each, and only used in game)
256x64
158x98
should I convert these 2 ?
 
sebt3 said:
I have :
Most are :
32x32
64x64
128x128
256x256

But there a few odd : (one of each, and only used in game)
256x64
158x98
should I convert these 2 ?

I would just modify the code to always load as the next highest power of 2. Are you just seeing white blocks where the textures should be?
 
Last edited by a moderator:
MUMBL35 said:
I would just modify the code to always load as the next highest power of 2. Are you just seeing white blocks where the textures should be?
I'm seeing white stuff, but the objects look fine (in white).
I would have believed that those squared (and in power of 2) textures would have loaded anyway. And only got the wrongly sized one in white.
But thanks for your time, advices and code ;)

EDIT : here it is :
Code:
static __inline__ int GLES2D_p2( int input )
{
	int value = 1;

	 while (value < input)
	{
		value <<= 1;
	}
	return value;
}

I'll try this ;)
 
Last edited by a moderator:
I've got the alpha-blended text working, haven't #ifdef'd my alterations.
It basically renders the text to a 16bit RGBA4444 texture format.

diff for MOGL_PoliceTTF.cpp in spolier
Code:
34,37c34,41
< #define    rmask 0x000000ff
< #define    gmask 0x0000ff00
< #define    bmask 0x00ff0000
< #define    amask 0xff000000
---
> //#define    rmask 0x000000ff
> //#define    gmask 0x0000ff00
> //#define    bmask 0x00ff0000
> //#define    amask 0xff000000
> #define rmask 0x000f
> #define gmask 0x00f0
> #define bmask 0x0f00
> #define amask 0xf000
48c52
< #define GL_UNSIGNED_INT_8_8_8_8                 GL_UNSIGNED_BYTE
---
> #define GL_UNSIGNED_INT_8_8_8_8                 GL_UNSIGNED_SHORT_4_4_4_4
358c362
<   SDL_Surface *text_surface = TTF_RenderUNICODE_Shaded(_Font, c, sdlColorFg, sdlColorBg);
---
>   SDL_Surface *text_surface = TTF_RenderUNICODE_Blended(_Font, c, sdlColorFg);
440c444
<   SDL_Surface * SurfaceSDL = SDL_CreateRGBSurface(SDL_SWSURFACE, TEXTURE_SIZE, TEXTURE_SIZE, 32, rmask, gmask, bmask, amask);
---
>   SDL_Surface * SurfaceSDL = SDL_CreateRGBSurface(SDL_SWSURFACE, TEXTURE_SIZE, TEXTURE_SIZE, 16, rmask, gmask, bmask, amask);
Hope that helps, my Pandora's battery is empty now... Time for a rest.

Paeryn.
 
sebt3 said:
MUMBL35 said:
I would just modify the code to always load as the next highest power of 2. Are you just seeing white blocks where the textures should be?
Code:
static __inline__ int GLES2D_p2( int input )
{
	int value = 1;

	 while (value < input)
	{
		value <<= 1;
	}
	return value;
}

Maybe there is a faster way, along the lines of:

Code:
static __inline__ int GLES2D_p2( int v )
{
    v--;
    v |= v >> 1;
    v |= v >> 2;
    v |= v >> 4;
    v |= v >> 8;
    v |= v >> 16;
    return ++v;
}

Or maybe not? I don't know.

Steve
 
Last edited by a moderator:
paeryn said:
I've got the alpha-blended text working, haven't #ifdef'd my alterations.
It basically renders the text to a 16bit RGBA4444 texture format.
It works like a charm now

paeryn said:
Hope that helps, my Pandora's battery is empty now... Time for a rest.
Sure it helped !!
Thanks a brunch for that

MUMBL35 said:
I would just modify the code to always load as the next highest power of 2. Are you just seeing white blocks where the textures should be?
I've done that, but that did not helped :(
 
Last edited by a moderator:
sebt3 said:
paeryn said:
I've got the alpha-blended text working, haven't #ifdef'd my alterations.
It basically renders the text to a 16bit RGBA4444 texture format.
It works like a charm now
I've played around a bit more, all it needed was a bit of colour swizzling. This is against your original version of MOGL_PoliceTTF.cpp
Code:
33a34
> #if !defined(PANDORA)
37a39,44
> #else
> #define    rmask 0x0000ff00
> #define    gmask 0x000000ff
> #define    bmask 0xff000000
> #define    amask 0x00ff0000
> #endif
353a361
> #if !defined(PANDORA)
354a363,365
> #else
>   SDL_Color sdlColorBg = {255,255,  0, 255};
> #endif
I've fixed some of the places where it's trying to create float textures, but there's more to do.
It's hard work remembering what functions and variables do when you can't understand foreign words :blink:
 
Last edited by a moderator:
paeryn said:
I've played around a bit more, all it needed was a bit of colour swizzling. This is against your original version of MOGL_PoliceTTF.cpp
I'm loving my lesson so far.
Text looks much better than it was with 16bpp. So the mask are shifted in gles ? sound and look strange. But well it works now, so I guess, that's how it is supposed to work ;)

paeryn said:
I've fixed some of the places where it's trying to create float textures, but there's more to do.
It's hard work remembering what functions and variables do when you can't understand foreign words :blink:
I'll be glad to help you with the French in there.
 
Last edited by a moderator:
I've had a long night at this...

The swizzling in PoliceTTF isn't needed as such, it just needs amask and rmask swapping so that when TTF glyph is rendered in red it gets blitted as alpha.
The full diff (from original) is now
Code:
439a440
> #if !defined(PANDORA)
440a442,445
> #else
>   // Need to swap Red and Alpha to allow TTF to render red into alpha channel
>   SDL_Surface * SurfaceSDL = SDL_CreateRGBSurface(SDL_SWSURFACE, TEXTURE_SIZE, TEXTURE_SIZE, 32, amask, gmask, bmask, rmask);
> #endif

I spent ages trying to figure out why some of the textures were garbled, I'd managed to write a for loop with the condition and iterator swapped. :wacko:

Now the only problem texture is the transparent one - herbe (the grass texture), when the colours were mixed up the transparency worked, now all the colours are okay it renders as a solid block (still transparent, but it's as though the whole texture has the same value).
I'm trying to figure out if it's due to a flakey gl->gles conversion.
It's drawn by the first part of MOGL_Afficheur::_AfficherAbonnementsNonOpaque when it loops through ItText.

I'll upload my changes later - some of it isn't very neat and it's bedtime for me - I'm off out at 14:30 and it's 10:13 now... I need sleep -_-
 
just a quick thought have you checked how much texture memory you're using...
 
Fixed it... I wasn't making sure the float->int texture conversions wasn't overflowing.
(255 / 255.0) * 255.0 = 256

The conversion could really be scrapped and just store the texture as integers for the Pandora but it's a quick fix solution.

You still can't play the game but the editor seems to work and altering the video settings doesn't crash it.
I haven't got a copy of the glu library so I added glesu.cpp (&.h) that defines the functions used.

Briquolo 0.5.7 test for Pandora
 
Thanks a lot for your hard work.

I applied your changes to my own tree yesterday (I've done this manually as I wanted to analyze your changes).
Good to know that my cheating (see first post) was right. I've learn a "few" things in the process that's cool.

Pickle provided me his v-sync feature he made while working on frogatto. So this looks now very nice already.

There is only the game start hang problem left" I said I'll track this one down. That's for my next hacking session ;)
 
Impressive, but it scares me a little bit how hard it is to make such a little game run onto the Pandora. ^^""""
I din't know much from coding but I guess we shouldn't ecpect to many OpenGL Game-Ports for the Pandora. :unsure:
 
fusion_power: That's where all the fun is... Okay, I admit, it's a PITA :wacko:

More fixes...
briqolo-0.5.7-pandora.tar.bz2

In Curseur.cpp you #ifdef'd out two glDisable() calls on lines 44-45, these are still valid for gles and are needed to render the cursor properly.
I wondered why it was red on the pc but black on the Pandora :)

I've put in a bit of code to draw approximate outlines in MOGL_Afficheur.cpp (where glPolygonMode is set to GL_LINE).

Also I've found what is crashing when selecting play. SDL_GrabInput and SDL_ShowCursor are both locking up.
For a quick fix in MOGL_Fenetre.cpp change SetGrabCurseur() and SetCacherCurseur() to only accept false.
Calling either with true is causing the lock up.
Since these SDL calls usually work I'm guessing there's a conflict with egl binding to SDL's window.

Oops, there's something locking it up when you run out of lives too... Not fixed this.

Added code to convert imageplateau.png into an int texture (missed this as it's a separate function) in MOGL_ImageFacade.cpp

This is the only texture that's not a power of 2 that works. The other (herbe.png) I re-sized the png which isn't the best, but the main rendering code doesn't cope with just extending the borders (it draws the border too).
 
paeryn said:
In Curseur.cpp you #ifdef'd out two glDisable() calls on lines 44-45, these are still valid for gles and are needed to render the cursor properly.
I wondered why it was red on the pc but black on the Pandora :)
Ahhh, black was fine for me ;)

paeryn said:
I've put in a bit of code to draw approximate outlines in MOGL_Afficheur.cpp (where glPolygonMode is set to GL_LINE).

paeryn said:
Also I've found what is crashing when selecting play. SDL_GrabInput and SDL_ShowCursor are both locking up.
For a quick fix in MOGL_Fenetre.cpp change SetGrabCurseur() and SetCacherCurseur() to only accept false.
Calling either with true is causing the lock up.
Since these SDL calls usually work I'm guessing there's a conflict with egl binding to SDL's window.
I did have found that too yesterday. But I added a crash (freeing a transparant cursor in a destructor :blink: )


paeryn said:
Oops, there's something locking it up when you run out of lives too... Not fixed this.
Ho, I dont have this issue in my code.

paeryn said:
Added code to convert imageplateau.png into an int texture (missed this as it's a separate function) in MOGL_ImageFacade.cpp

This is the only texture that's not a power of 2 that works.
I was about to use the functions MUMBL35 suggested here for this texture

paeryn said:
The other (herbe.png) I re-sized the png which isn't the best, but the main rendering code doesn't cope with just extending the borders (it draws the border too).
Ahh, that's why you had grass and I only get white block for grass.

Ok I'll merge the 2 code this evening (EST time) and publish a final PND. and push our changes to the original author.
I also fixed properly the autoconf mechanics (added --enable-gles) and a few others things I can remember now.

I'll publish my final code tommorow (I hope).
 
Last edited by a moderator:
fusion_power said:
Impressive, but it scares me a little bit how hard it is to make such a little game run onto the Pandora. ^^""""
I din't know much from coding but I guess we shouldn't ecpect to many OpenGL Game-Ports for the Pandora. :unsure:
This one was a bit hard. But :
- Pickle, with his eglport.c file provide a realy easy solution for a big problem : getting the gles/egl window easy to integrate into the original code
- this one had a lot's of techniques we dont find in many other games.
- Some textures were'nt even valid for gles (paeryn had to resize them)
- This was my first GL or GLES experience ever. All I needed was the sources pickle provide (and his help/cheering) and the help of this awesome community
- Before having my pandora in my hands, my last C or C++ was 12 years ago (already ???) at school learning these for 6 months

And even with all these barriers, the game is now near release ready. So I think more GL -> GLES port will come.
Sure that's a lot's of work, way more then just recompiling , but yet doable. The work is in 4 phases :
1) #ifdef out all the GL specific code (these functions that have no GLES equivalent) so the code actually build
2) get the EGL context working. Thanks to pickle, that's 30mn of works at max. And this point the code run on the pandora (but display nothing :D)
3) convert all the immediate mode (glBegin/glEnd) to something GLES grok. That's long but completely mechanical : you use plain and simples rules to do so. I finished this when I openened this thread. So far there is no GL nor GLES knowledge requierement. Requesting for help after this point is realy acceptable (imho) as you've put 80%-90% of the work requiered to gets everything running in shape.
4) fix the remaining problems : textures, some lockups etc. Some games wont even requiere this step.
 
Last edited by a moderator:
Back
Top