GemRB 2.9 and SVN

[Slader]

I installed gemrb 2.9 at Linux (Kubuntu 7.10) and run BG2:ToB. It look interesting. But there are some bugs that described in First impressions

 

Hm, I dont know, may be my computer is so slow (Pentium-m 1500@600MHz, 1280Mb Ram), but the game there is so slow to When I set resolution to 800x600, I getting freezes and the mouse pointer moving slow.

(Yes, I use my computer at low freq. because it is laptop and I dislike when its hot. )

 

How can I compile svn version of the gemrb? I downloaded sources by using this command:

svn co https://gemrb.svn.sourceforge.net/svnroot/gemrb gemrb

And I have many subdirs. Which of them contain the newest up-to-date sources?

[Avenger]

gemrb/trunk contains the engine source

 

Please check the console, if it is scrolling too much, it gets slow.

You can probably redirect console output to /dev/null, that can speed up performance

And you can compile the newest source with speed optimalisation.

Is the mouse pointer slow or jumping?

If it is just slow, but movement is smooth, then it isn't a CPU speed issue.

 

Do you have any experiences with the original game on the same machine?

Or any other game? Just because this isn't a 3d game, it has some computing requirements.

[Slader]

gemrb/trunk contains the engine source

 

Please check the console, if it is scrolling too much, it gets slow.

You can probably redirect console output to /dev/null, that can speed up performance

And you can compile the newest source with speed optimalisation.

Is the mouse pointer slow or jumping?

If it is just slow, but movement is smooth, then it isn't a CPU speed issue.

 

Do you have any experiences with the original game on the same machine?

Or any other game? Just because this isn't a 3d game, it has some computing requirements.

 

Hm, i dont know what it was, but I rebooted my computer and all worked fine. Game ran smoth and mouse pointer too.

 

Ps. Hm, in gemrb/trunk there is no configure script... Should I get it from gemrb-2.9 sources?

[Guest Guest]

run autogen.sh and configure will be summoned.

[Avenger]

Yep, as was written by guest.

autogen.sh will create ./configure

 

It is a good idea to run the latest version, because it optimises ambient sound loading.

The tarball version load ALL area sounds at load time, while the SVN version loads/caches them on demand.

[Slader]

I compiled and ran SVN-version.

Bugs:

1) I toggle FPS-counter, and see, that when I move my mouse to dialog window, fps in game fall down to 20. But when I return my mouse to main window (point to hero, or imoen for example), FPS=60.

2) Interface disappear or flashing when in battle.

[Avenger]

The first is probably not a bug.

The second could be many things, but it doesn't happen to me.

I have seen it happen when there was some problem with the guiscript.

 

Check your console output, and copy&paste lines with [ERROR] in them.

There will be some missing files that are not a problem. (wmaplay, font).

 

If there is any error starting with [GUIScript], then it will surely give a clue what's the real cause.

[zefklop]

Do you have any experiences with the original game on the same machine?

Or any other game? Just because this isn't a 3d game, it has some computing requirements.

 

Well, when SDL is initialized, you create display with the SDL_SWSURFACE flag, as every other surface you create later. Why not create it with SDL_HWSURFACE ? The display would then be managed by the graphics card, and this will result in a speed improvement (The processor would care only about guiscrpits, sound, etc...)

 

Even with 2D, graphics hardware is better than a single CPU, even if it was built a long time ago.

[Avenger]

I don't know the pros and cons of hardware surface.

 

Ok, the pro is probably faster performance

But will it cause graphical glitches or use more memory?

I believe once it was using hardware surfaces, but for some reason it was removed.

[Guest Guest]

we should try it then and time the results. I agree that it seems like a logical move. -lynx

[zefklop]

I've never seen any glitches/artifact with the hardware management of the display. If SDL_HWSURFACE is used, the best would be to enable SDL_DOUBLEBUF. This might permit to get rid of the "BackBuf" surface.

 

See here libsdl.org wiki to know what's going on. If you use SDL_LockSurface, it seems to be a better idea to keep SDL_SWSURFACE.

 

I don't know whether it's a good idea to blit HW/SW surfaces together. Probably not.

 

Edit : Note that SDL can initialize OpenGL too. This would permit to get rid of those considerations, and to plenty profit of 3D acceleration present in every PC built after 1998 (and even before). The events (mouse moving, keyboard, etc...) are still managed by SDL.

[Guest wjp]

Well, when SDL is initialized, you create display with the SDL_SWSURFACE flag, as every other surface you create later. Why not create it with SDL_HWSURFACE ? The display would then be managed by the graphics card, and this will result in a speed improvement (The processor would care only about guiscrpits, sound, etc...)

 

Even with 2D, graphics hardware is better than a single CPU, even if it was built a long time ago.

 

Using hardware surfaces will seriously slow down gemrb, since we do lots and lots of direct pixel access and alpha blending. The way to use hardware to speed up rendering is switching to a native opengl renderer. There's a work-in-progress opengl renderer, but I haven't seen the author in a while.

[zefklop]

So where is the code ? I thouht to make an opengl renderer some time ago, but I finally did not feel brave enough to do it. Having a base like this might be helpful fo anyone wanting to work on this task.

[Guest wjp]

So where is the code ?

 

Waywocket wrote it, and should still have it, but I haven't seen him around in a while.