BSzili port requests

Definitely. You can even copy them between different operating systems as long as the endianness matches. That's how I've been testing the MOS and OS4 versions

@BSzili

Excellent, this port has really impressed me! Good performance and great support from BSzili.

Only major issue I have is the flickering and corruption along the bottom of the screen in fullscreen mode. Is this the same for other people?

I just tried it (until now I was playing in a window, DH0:!), and I also have some flicker on the bottom of the screen. I don't really know what causes this, but it only affects certain parts of the menu.

@BSzili

I get it in game and on menus.
It occurs in hunoppcs port of star trek holodeck to. Perhaps it is a driver issue rather than a specific port issue?

@BSzili

Quote:
Is the game using a double-buffered screen? If not, then that's the most likely cause of flickering at the bottom of the screen.

Windowed mode inherently involves a back-buffer, as Warp3D can't render directly to the window.

Hans

I use double buffered screens, the MiniGL context is set up with these tags:

@BSZili
The same kind of "blink in menu" happens in Quake3 port too. So that probably another fault of our current 3d implementation. I didn't have any blinks in game through.

Also what i notice, is that if i disable "sync with video" in openjk, then that blinks happens all over the places. But if it enabled, i almost didn't have them, only in menu a bit.

@kas1e

Quote:

That is a good suggestion. I will try it out.

@kas1e
Thanks for mentioning vertical sync. Changing it currently only takes effect when you do a video restart. I'll make it so it does that right after you change it, so you can see the results immediately.

@kas1e

Quote:
Strange. I don't remember ever experiencing that.

Quote:

That really sounds like it double-buffering isn't used, even though the code that BSZili showed has the number of buffers set to two. It isn't rendering to the directly to the front buffer, is it?

@BSzili

This shouldn't make a difference, but try adding a glFinish() call just before you swap the buffers.

Hans

@Hans
Quote:

If i remember right it happens in m3x build of ioquake

@Hans
This is what I do to swap the buffers:


I can add a glFinish, but RB_SwapBuffers alredy does that before calling calling the code above.

@kas1e

It happen on every build (HunoPPC version included)

I updated my port to have on-the-fly v-sync changing. Turning off v-sync (called Video Sync in the game) is definitely the problem, it causes the flickering.

Thanks your latest port with vsync option fixed the flickering. Sound is still corrupted but as I am only getting 7-11fps, I suspect there is nothing you can do about that.

I was trying to get out of 3rd person view by pressing P but it has no effect. Just me?

@kas1e

Quote:

Ah, okay. I never tried that one. IIRC, I tried http://capehill.kapsi.fi/" rel="external" title="">Capehill's OpenArena. It's the same engine but with open-source data files.

@BSzili

You don't need to call mglUnlockDisplay() before mglSwitchDisplay().

Hans

@BSzili

Quote:

I just figured out why that is. The problem lies in the way that buffer swaps are handled. Without vsync, MiniGL swaps the buffers, and allows you to render to the new back buffer right away. However, that new back buffer could still be displayed because the screen isn't swapped until the VBlank period is reached. So, the bottom of the screen flickers because you're rendering new stuff to it.

I don't like MiniGL's vsync method; it calls IGraphics->WaitBOVP() (see video.c/cgl_SwitchDisplay()), which forces your game/app to wait until the VBlank period. While this prevents you from rendering to the buffer too soon, your game/app could have been doing useful calculations in that time (like physics and game logic, if those run in the same thread). So, this can slow things down. In a worst case scenario, it could wait for almost an entire frame. A better method would be to wait for the "safe to render" message, ideally just before the first render operation to the next frame.

Using triple-buffering should avoid this issue (at the cost of extra VRAM usage), i.e., set MGLCC_Buffers to 3.

Hans

@Hans
Thanks for the suggestions. I intended to use just double buffering to conserve VRAM, but I guess I can't avoid it. BTW, which is the fastest locking method? In the MiniGL sources I noticed a third one in addition the smart and manual: MGL_LOCK_AUTOMATIC. I'm currently using smart locking, is automatic faster?

@ddni
You need at least 10-15 FPS to have continuous audio, otherwise the mixer function won't get called often enough to update the buffer. I can't increase the size of the buffer any more, because it starts to cause stuttering even when you have higher FPS.
As Hans suggested I'm going to revert to triple buffering for graphics, so you won't have to use vsync. This will increase your framerate a little.
The lightsaber mode is restricted to the 3rd person view. Jedi Outcast had some 1st person lightsaber mode, but it looked like crap, so they took it out in Jedi Academy. You can switch to 1st person for other weapons.

Thanks BSzili. Has to be said, the 33mhz pci slots in the X1000 are crap! Shame as the rest of the machine is awesome. Bring on Gallium3D!