I am adding OpenGL hardware acceleration to XAMOS. On MorphOS it appears that TinyGL supports the OpenGL subset I have used, however I'm getting serious graphical corruption using oversized textures bigger than 1024x1024.

xamos_mos_bug.png

Post on XAMOS thread

Any suggestions? It appears I have plenty of VRAM left. Do I need to chop up the textures into smaller ones?

(The colour/alpha endianness issue here is likely to be easier to resolve than this graphical corruption.)

I haven't yet released the updated source, that will be pushed to SourceForge when it's working better on other platforms.


(Note: This isn't 3D graphics per se, however OpenGL/TinyGL is also used for accelerated 2D graphics, so I posted this here.)

[ Edited by Mequa 28.08.2012 - 03:12 ]

from what i remember the radeon in the mini doesn't support textures>1024

i suggest you to enable the tinygl debug option.

"To enable debug output from the library (can be grabbed with tools like
logtool or getramdebuglog) you can set TGLDEBUG environment variable to
something else than 0:

setenv TGLDEBUG 1
avail flush
"

with logtools you can read every operation the tinygl library is doing, also the max textures size of the cart or the available textures color format.

Perhaps one solution here would be to produce 4x 1024x1024 textures instead of 1x 2048x2048 texture from a 1440x1152 SDL surface (used for XAMOS scrolling background screen). Not exactly trivial to implement, however. I'd need an array or C++ vector of GL textures per converted surface.

Another general SDL OpenGL issue is that converting SDL surfaces to OpenGL textures seems dog-slow, even using glTexSubImage2D instead of glTexImage2D (where appropriate).

I'll probably leave MorphOS TinyGL support for a later version than the up-and-coming XAMOS 0.28. Software rendering with SDL is still supported of course, but is painfully slow on MorphOS (as anyone who's tried the current version of XAMOS can attest to).

Does the Powerbook G4's Radeon support bigger textures than 1024x1024?

Another thing: Is SDL_GL_SWAP_CONTROL not supported in TinyGL?

There is no 3D support for Powerbook atm.

Why do you need such big textures?
It's quite easy to split one texture, just don't know how fast it will work in your project.

Hmm, i'm not sure if it is not because of lack of vram. in theory there should be no problem with >1024x1024 textures (except memory usage). you have 64MB of vram. Such texture will need 16MB of unsplit memory block. Did You try to use 16bit texture? If You want TGL to automatically create one for You use glHint(TGL_LOWQUALITY_TEXTURES, GL_TRUE) (or something like that, i can't look it up now) before glTexImage2D. Obviously it shouldnt trash your screen tho. Problem with such textures is that they require big block of memory. If you used few separate ones they can be managed separately. Anyway, i will check it when i'm back at home in the evening so i can confirm if it is memory issue and why it trashes your screen.

BTW. In theory textures don't have to be power-of-two in size but i'm not sure i f we didn't put some silly safety check there;)

About this SDL flag i have no idea what it does or if PowerSDL supports it. GL support in SDL is bit outdated.

stefkos,
Quote:
For scrolling 2D backgrounds (implemented like oversized AMOS 'screens').
Using TinyGL is already much, much faster than unaccelerated PowerSDL.
Until you modify an SDL surface and convert to GL texture using glTexSubImage2D - then it slows down badly.

The problem with splitting textures is I'll need to store an array of textures for each 'screen', plus the number of vertical and horizontal sizes. Quite a fiddly hack to implement with current XAMOS GL code. That'll probably have to wait for XAMOS 0.29 or later.