Hi all

When I try to run Myst III Exile..I got following error:
(Same data files work with Windows port of Residual)

WARNING: GL_ARB_texture_non_power_of_two is not available.

Do we need this fix applied to OS4 port ?

https://github.com/residualvm/residual ... ines/myst3/gfx_opengl.cpp

@SinanSam460

That's a warning, not an error. So in theory it should still run. Of course, there may be other problems that prevent it from working.

Hans

@SinanSam460

Turn the gfx render to SW. I think some cards lack these features.
I have a Radeon 9250, and it`s unplayable with sw rendering (Sam440@800).Maybe another version that is more compatible with older cards?

@Cass

Only SW rendering is "supported".

Reasons;

1) I'm no coder, so i couldn't for the life of me change anything about it
2) I don't have a 3D capable card, so again, in no way, could i do anything about it
3) I'm looking for someone to take over caring and developing (AmigaOS4 specific) ResidualVM
(The codebase is nice and shiny and should build out of the box - it's the 3D stuff that scares me - once available i wouldn't know what to do to support it)

Right now, if i run into problems, i bug the residualvm devs to fix it...for now this works

@Cass

Quote:
Warp3D doesn't support non-power-of-two textures, so it's not necessarily the hardware.

@SinanSam460 and Cass
What happens when you switch to HW accelerated rendering mode? Does it simply fail? Or do you see something?

Hans

@Raziel

Quote:
I'm afraid not. I thought that I'd have a quick go at building it, but the configure script failed after claiming that no C++ compiler could be found. My AmigaOS machines all have the SDK installed, so there most certainly is a C++ compiler installed.

I also briefly tried Myst III myself, and it looks like the textures are failing to load. At least, Warp3D never receives any texture data.

Hans

@Hans

Okay, some good news and some not so good news:
First, the reason that it didn't work is due to an unsupported texture format:
internalFormat = GL_RGBA;
sourceFormat = GL_UNSIGNED_INT_8_8_8_8_REV;
That'll be fixed in the next version of MiniGL.

Unfortunately, playback of the video sequences is rather stuttery (tested on an A1-X1000), including the audio. So, that's something that needs to be worked on.

A quick scan of the code suggests that it uses the bink video format. Does the bink decoder make use of altivec at all? Maybe there's room for improvement there.

Either way, it would help if the code could at least keep the audio smooth even if the video is playing back at a lower frame-rate (i.e., frameskipping would help).

Hans

@Hans

What compiler line did you use to test?

I have the SDK installed with no further changes (i think) and a simple ./configure under the bash shell (or was it abc shell?) does what it should do

edit: wrong, i obviously have the following two files in ENVARC

CPPFLAGS
with this
-I/sdk/local/common/include/freetype2 -I/sdk/local/common/include/SDL

and

path
with this
/GCC/bin:/SDK/C:/SDK/local/c:/SDK/local/newlib/bin:/cmake/bin/

@Hans

I know it's a little OT but.. if you are the current mantainer of MiniGL can you add also this little patch on trunk ?

http://forum.hyperion-entertainment.biz/viewtopic.php?f=26&t=2162

@samo79

Quote:
AFAIK, that patch has been in there for a while now. No, not in the trunk, but in the current branch.

I'm not going to add small patches to the trunk. At some point, karlos' branch will be merged back to the trunk. In the meantime, you're welcome to checkout the branch.

@Raziel
Quote:
I simply did a ./configure in the bash shell. Other configure scripts can detect the C++ compiler just fine without needing ENV vars, so the configure script really should be fixed.

Hans

@Hans

Sorry of course i meant the branches not the main trunk .. i can't verify myself but according to the changelog (http://www.hyperion-entertainment.biz ... ranches/updates-kc/README) the patch i mentioned doesn't seems to be included ... that's why i ask if you can commit it or atleast if you can verify if it was included or not

@samo79

If you don't believe me, then why don't you do a quick search through the MiniGL code for "GL_UNSIGNED_INT_8_8_8_8_REV" and "unpack_argb_b". You should be able to confirm quickly enough whether Spirantho's patch is included.

Hans


P.S., Readme files rarely list every single patch, fix or other change that has been made

@Hans

I trusted you, only i wanted to be sure if the patch was implemented or just forget, didn't know where to check .. but i found a reference of that "GL_UNSIGNED_INT" in pack.c so i presume it is implemented now

Aniway do you know when the new MiniGL will be officially released ?

@Raziel
Getting back to the topic of Myst III, I'm now pretty certain that the stuttery audio is residualVM's own fault. I ran a test where I disabled glTexSubImage2D(), thereby completely eliminating the overhead of uploading the video frames to VRAM for display. The stuttering remained.

ResidualVM uses SDL for audio, right? Well, that could be part of the problem. Here are three reasons why I think this:
1) ResidualVM's own FAQ mentions possible stuttering on Windows, with an SDL workaround (link).

2) When I tried the WIP Homeworld port (also SDL based), disabling the AHI driver caused Homeworld's framerate to jump from 2 to 20 fps on my system. That's a pretty extreme change.

3) Quote from Spirantho on aw.net
Quote:

Now, the above doesn't guarantee that SDL's audio is the cause, but it does indicate that SDL audio may be problematic.

Of course, I still think that it would be worth looking at optimising the bink video decoder, including using altivec. The CPU usage remains unchanged even with glTexSubImage2D() disabled when video clips are playing (it's clamped at ~90% in both cases). I think that the video decoder could do better than that; the resolution isn't that high.

Hans


P.S., I randomly get the game failing on startup with an assertion failure at line 679 of engines/myst3/state.cpp. This suggests that there's an uninitialised variable bug somewhere (other OSes zero newly allocated memory, which makes it easy for such bugs to remain hidden).

For me the "assertion failure at line 679 of engines/myst3/state.cpp" error is a CD insertion/detection bug i'm have the same error if i'm forget to insert the CD-1

@FabienJ

Quote:
I never have the CD/DVD inserted (NOTE: I have the DVD version).

Hans

Does myst iii start on your setups..?

It stops with a biank screen (warp3d or software renderıng does not matter)

Data fıles are ok since it runs with wimdows version of residualvm

@SinanSam460

Quote:
Yes, unless I get that assertion failure printed in the console window.

Hans

@Hans

Nice that so many people are interested in residualvm

the fact remains that i can't code and can't do anything about it unfortunately...not even fixing configure

The assertion is a known bug and can be blamed to the menu of myst iii being used as zip-destination (which shouldn't happen) ... i'm just parroting the residualvm devs here, don't be fooled

A fix is in place already iirc (if you download the latest daily build it should be gone), but that doesn't fix all the other drawbacks and bugs, mind you

I know you haven't got the time and i wouldn't ask you to, i'm happy that you took the time to look at the code at all


I'd be happy to find one that will start caring and maintaining residualvm though...as said, once 3D kicks in it will fall behind very quickly, because i'm not capable of maintaining it myself

@Raziel

>A fix is in place already iirc (if you download the latest >daily build it should be gone), but that doesn't fix all >the other drawbacks and bugs, mind you

I tried 24th of March daily build, and I couldn't run Myst III

I will try 26th of March daily build, I hope that update fixes it.

On the other hand, I am trying to run Monkey Island 4 with ResidualVM. After credits screen in the beginning of the game, it stalls with a blank white screen..

Anybody tried Monkey 4 with ResidualVM ?

Thanks.