Game Concept + Npot Textures Support?


dsh

Still Fresh
Joined
Apr 23, 2008
Messages
53
Location
Cracow, Poland
Website
byteboy.x25.pl
I am writing a 2D game using SDL+OpenGL. Maybe will port it to pandora. I am curious if non-power-of-two textures will be supported?

Either by the texture_rectangle_arb or non_power_of_two gl extension.

Of course I can rewrite the graphics part using software blitting but then some effects are lost. If the cpu turns out to be too slow to support alpha-channeled blitting then even more effects (and gfx quality) will be lost...


I don't want to spam the board with two topics but I'm also curious what would you think about this kind of game. It will be a MrDriller total remake. I don't want to be original. I think this game has great playability is available for most consoles, but has no PC version.

It's my second attempt to write this game, previously I produced such a crappy code that it needed a complete rewrite (at the stage of splash + menu), I was so disappointed by my skills that I abandoned the project. Now, I use OpenGL for better looking graphics. After 2 days of coding I've got splash + menu + framework (incl. simple sprite engine). If I maintain this speed (it's rather impossible in my case) game should be at beta stages somewhat in 2 weeks.

f_md1m_8a2ccf4.jpg
f_md2m_27bb05e.jpg
 
When I wrote my game engine I just made a software linear filter to up the size of the textures to a power of 2 anyway, that's probably an easier option so long as you have enough memory.
 
Non-power-of-two textures are part of the OpenGL ES 2.0 core specification. However they are limited to the GL_CLAMP_TO_EDGE wrap mode and cannot have mipmaps. The poorly named OES_texture_npot extension removes these limitations.

Note that using NPOT textures might be slower than using POT textures, though.
 
Holokauston said:
Thanks :) been looking for something exactly like that for a few days now =D
No problem ;)

Xmas said:
Note that using NPOT textures might be slower than using POT textures, though.
Yes. Just recently I stumbled upon a drive issue on MAC ATI cards where using npot textures enabled the fallback software mode (this for desktop OpenGL) and the frame rates end up on the 2-3 fps. So strange things can happen :blink:

Edit: Xmas is here! How cool, this guy knows his OGL ES :)
 
Last edited by a moderator:
DDd said:
Yes. Just recently I stumbled upon a drive issue on MAC ATI cards where using npot textures enabled the fallback software mode (this for desktop OpenGL) and the frame rates end up on the 2-3 fps. So strange things can happen :blink:
Heh... Indeed they can.

NPOT texture usage causes the drivers to punt to software on MacOS? Niiice.
 
Last edited by a moderator:
Svartalf said:
NPOT texture usage causes the drivers to punt to software on MacOS? Niiice.

It's not limited to MacOS, I saw the same thing happening on a Radeon X1600 on WinXP recently.

Anyway, I wasn't referring to software rendering – NPOT textures may be (slightly) slower than POT textures in hardware.
 
Last edited by a moderator:
Xmas said:
Anyway, I wasn't referring to software rendering – NPOT textures may be (slightly) slower than POT textures in hardware.
Yes, but take into account the Vram you save by using NPoT texs. Sprites usually weigh a bit, especially when they're 32bit and each has few tens of animation frames + maybe a backdrop or two for the bcg (depending on if you free & load all sprites for each game screen).

I've read that GL_ARB_texture_rectangle was supported back to riva tnt2... :)
And as I mentioned in the first post (and as far as I know) GL_ARB_texture_non_power_of_two isn't supported at all by ATI cards.

All I wanted to know (yes, I know I'm lazy) if both hardware & software of OpenPandora will be able to support NPoT texs in any way.

I briefly read through document stating differences between OGL & OGL ES. And I don't feel like digging into this topic anymore.

Anyways, thanks for response!

flatmush said:
When I wrote my game engine I just made a software linear filter to up the size of the textures to a power of 2 anyway, that's probably an easier option so long as you have enough memory.
gluBuild2dMipmaps already resizes the texs to nearest POT dimensions, but of course then more Vram is needed to store the mipmaps.

I assume GLU comes with OGL ES ?

BTW I've read that OGL ES is part of the official programming API for PS3. Why so - when PS3 is perfectly capable of utilizing the non-stripped OGL?
 
Last edited by a moderator:
So are NPOT textures slower because the GPU has to use multiplication rather than bitshifts when working with the texture?

Or is there some other reason?

Because in software, you can use bitshifts so long as the width is a power of two; height can be whatever you want without slowing things down.
 
dsh said:
Yes, but take into account the Vram you save by using NPoT texs. Sprites usually weigh a bit, especially when they're 32bit and each has few tens of animation frames + maybe a backdrop or two for the bcg (depending on if you free & load all sprites for each game screen).

If you have lots of sprites to render you should group them into one or a few big texture atlases in order to minimize render state changes. In that case it usually doesn't matter much whether the texture is padded to the nearest POT.

Anyway, all I'm saying is that there can be a performance difference. Be aware of the tradeoff.

QUOTE
I assume GLU comes with OGL ES ?

It doesn't.

Kramy said:
So are NPOT textures slower because the GPU has to use multiplication rather than bitshifts when working with the texture?

Or is there some other reason?

There are other reasons, but I can't go into details.

Arialia said:
Be careful the Powervr texture for SGX has an own format "PVR" i doubt it is the same than NPOT ....

PVR is a file format. NPOT means that the dimensions of a texture are not powers of two. Those are completely unrelated things (but a PVR file is able to store an NPOT texture).
 
Last edited by a moderator:
Back
Top