GemRB

IRIX and IRIX software discussion including open source and commerical offerings.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
emachine
Posts: 57
Joined: Sun Aug 14, 2005 3:26 pm

GemRB

Unread postby emachine » Wed Sep 19, 2007 6:52 pm

Hello all,

For the hell of it I tried to build the latest sources for GemRB (http://en.wikipedia.org/wiki/GemRB) on my Fuel (Planescape Torment was a kick ass game lol). Mipspro compiled almost straight away with very little tweaking - just some Makefile gorp.

That said when I run I get the following:

GemRB Core Version v0.2.9 Loading...
[Core]: Initializing Variables Dictionary...[OK]
[Config]: Trying to open GemRB.cfg
[OK]
[Core]: Starting Plugin Manager...
[PluginMgr]: Loading Plugins...
[PluginMgr]: Searching for plugins in: /usr/nekoware/gemrb/lib/gemrb/
[PluginMgr]: Loading: /usr/nekoware/gemrb/lib/gemrb/libGUIScript.so...[OK]
[PluginMgr]: Checking Plugin Version...[OK]
[PluginMgr]: Loading Exports for GUI Script Engine (Python)...[OK]
[PluginMgr]: Loading: /usr/nekoware/gemrb/lib/gemrb/libSDLVideo.so...[OK]
<snip>

all this is goodness until:

[KEYImporter]: Opening /usr/people/mejdrich/PST/CHITIN.KEY...[OK]
[KEYImporter]: Checking file type...[OK]
[KEYImporter]: Reading Resources...
[KEYImporter]: BIF Files Count: 1946222592 (Starting at 402653184 Bytes)
[KEYImporter]: RES Count: 1731133440 (Starting at 924975104 Bytes)
[Streams]: Invalid seek position: 402653184 (limit: 178649)
[Streams]: Invalid seek position: 402653184 (limit: 178649)
[Streams]: Invalid seek position: 796226418 (limit: 178649)
[Streams]: Invalid seek position: 402653196 (limit: 178649)
[Streams]: Invalid seek position: 796226418 (limit: 178649)
<goes on forever>
<snip>

Does this look familiar to anyone? I'm suspecting Endianness or iostream issues, etc, but thought I'd see if anyone had experienced anything similar...

Best regards,
Eric

User avatar
necron2600
Posts: 279
Joined: Tue May 26, 2015 10:38 pm
Location: Boston

Re: GemRB

Unread postby necron2600 » Sun Dec 13, 2015 4:46 pm

I just spent a weekend on this but never tried the 0.2.x version you tried. I started with the latest 0.8.x and went down to 0.3.0 and then up to 0.7.0 and then 0.6.0.

Some errors in cmake or autogen.sh logs seem to be "Identifier va_list is undefined" .. since this is GNU-style code being built. I assume including stdarg.h may help this but im at a loss with using cmake and/or autogen.sh. The original poster used a much older version that probably didnt use these build tools.

versions newer than 0.6.0 seem to work with cmake (or autogen.sh but its not maintained anymore).

Newer versions cant seem to get past cmake.. ld32: FATAL I/O error (-lpthreads) .. and I know IRIX has some porting issues with pthreads but not sure how to solve that through cmake or autogen.sh.

Tried GCC 4.7 too but had different errors in cmake and/or autogen (or older versions with configure)

Can anyone help take a look at this software? It would really make my year (maybe my past decade) to be able to play Baldurs Gate, and the other Infinity engine games, on an SGI. SO much so.. maybe some monatary value can be placed on this ;)

FYI, I did create a neko_cmake-2.8.6.tardist and uploaded to /incoming (should be moved to my dir sometime soon) as gemrb needed this version or later.

Links:
http://www.gemrb.org/wiki/doku.php?id=installation
http://www.gemrb.org/wiki/doku.php?id=i ... t_yourself

-Kevin

User avatar
vishnu
Donor
Donor
Posts: 3189
Joined: Sun Mar 18, 2007 3:25 pm
Location: Minneapolis, Minnesota USA

Re: GemRB

Unread postby vishnu » Sun Dec 13, 2015 5:26 pm

necron2600 wrote:Some errors in cmake or autogen.sh logs seem to be "Identifier va_list is undefined"

The problem there is that variable argument lists aren't implemented in MIPSPro C++. Depending on how much they're used in GemRB that can be either a slight pain in the ass or a complete show stopper, which for example it was with Dillo. What we should probably do is get the gnu va_list source code and compile it into a library and stick it in /usr/nekoware/lib and document in the wiki that you have to link against it to get va_lists to work in MIPSPro C++. I'd be willing to do that but I won't be able to get to it until the first week in January since my year-end todo list is at the total nightmare level this year. :cry:
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...

:Tezro: :Octane2:

User avatar
thegoldbug
Posts: 384
Joined: Sat Jul 12, 2003 8:36 pm
Location: AZ, hot like Crematoria
Contact:

Re: GemRB

Unread postby thegoldbug » Sun Dec 13, 2015 9:36 pm

I loved playing Baldur's Gate and other like it and I agree it would be fun to play on IRIX.
thegoldbug
:ChallengeXL: :ChallengeXL: :ChallengeXL: :OnyxR: :ChallengeL: :ChallengeL: :ChallengeL: :ChallengeL: :Onyx: :O200: :Fuel: :Fuel: :Octane2: :Octane: :Octane: :Octane: :Octane: :Indigo2IMP: :Indigo2IMP: :Indigo2IMP: :Indigo2IMP: :O2: :Indigo2: :Indigo2: :Indigo2: :Indigo2: :320: :320: :320: :320: :Indy: x5 :Indy: x2 :1600SW: x5 :Indigo: x7
Vault L, 6-1200s, Fibre Hub, Dials, Boards, spares, 3 Sun Blade 2000s, Sun Fire V480, 2-Hero 2000 Robots, 5-Hero 1 Robots

User avatar
dexter1
Moderator
Moderator
Posts: 2743
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: GemRB

Unread postby dexter1 » Mon Dec 14, 2015 2:43 pm

This is from /usr/include/internal/stdarg_core.h, redirected form /usr/include/CC/cstdarg

Code: Select all

/* Define the va_list type: */
__SGI_LIBC_BEGIN_NAMESPACE_STD
#ifndef _VA_LIST_%)
#define _VA_LIST_
typedef char *va_list;
#endif /* !_VA_LIST_ */

__SGI_LIBC_END_NAMESPACE_STD
In other words, it is there, but it does need proper preprocessing. I'm using 7.4.4m and C-style headers are still not properly supported which necessitates me to use odd options in CXXFLAGS.
I do get somewhere in gemrb 0.8.3.1 : i reach 15% with an error in:

Code: Select all

cc-1132 CC: ERROR File = /usr/people/everdij/gemrb/gemrb-0.8.3.1/gemrb/core/Game.cpp, Line = 1886
  The class "std::vector<GemRB::Injured, std::allocator<GemRB::Injured>>" has no
          member "at".

                restingSpell.caster->DirectlyCastSpell(wholeparty.at(spelltarget).character, restingSpell.resref, 0, 1, true);
which is strange since wholeparty is a std::vector<Injured> template and std::vector does have the .at() class function. So this needs weeding through code.

For peeps wondering what setenv i used:

Code: Select all

setenv CC cc
setenv CXX CC
setenv CFLAGS '-O2 -mips4 -woff 1174 -signed'
setenv CPPFLAGS '-I/usr/nekoware/include'
setenv LDFLAGS '-L/usr/nekoware/lib'
setenv LIBS '-lm'
setenv PERL /usr/nekoware/bin/perl
setenv SDLDIR /usr/nekoware
setenv CXXFLAGS '-O2 -mips4 -woff 1110,1171,1201,1355,1460,3201,3625,3649 -LANG:std=off -LANG:libc_in_namespace_std=off'
and two hacks in neko_cmake modules in /usr/nekoware/share/cmake-2.6/Modules

Code: Select all

--- FindSDL.cmake.save  Mon Dec 14 22:39:37 2015
+++ FindSDL.cmake       Mon Dec 14 22:40:36 2015
@@ -59,6 +59,7 @@
   PATHS
   ~/Library/Frameworks
   /Library/Frameworks
+  /usr/nekoware/include/SDL
   /usr/local/include/SDL
   /usr/include/SDL
   /usr/local/include/SDL12

--- FindThreads.cmake.save      Mon Dec 14 22:28:57 2015
+++ FindThreads.cmake   Mon Dec 14 22:29:17 2015
@@ -11,9 +11,9 @@
 SET(Threads_FOUND FALSE)
 
 # Do we have sproc?
-IF(CMAKE_SYSTEM MATCHES IRIX)
-  CHECK_INCLUDE_FILES("sys/types.h;sys/prctl.h"  CMAKE_HAVE_SPROC_H)
-ENDIF(CMAKE_SYSTEM MATCHES IRIX)
+#IF(CMAKE_SYSTEM MATCHES IRIX)
+#  CHECK_INCLUDE_FILES("sys/types.h;sys/prctl.h"  CMAKE_HAVE_SPROC_H)
+#ENDIF(CMAKE_SYSTEM MATCHES IRIX)
 
 IF(CMAKE_HAVE_SPROC_H)
   # We have sproc
Since if it finds sproc, it ignores pthreads alltogether which in modern day code is certainly not what you want.

So it definitely needs some work, we're not there yet.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

User avatar
vishnu
Donor
Donor
Posts: 3189
Joined: Sun Mar 18, 2007 3:25 pm
Location: Minneapolis, Minnesota USA

Re: GemRB

Unread postby vishnu » Mon Dec 14, 2015 11:39 pm

dexter1 wrote:...which is strange since wholeparty is a std::vector<Injured> template and std::vector does have the .at() class function. So this needs weeding through code.

Sometimes you can fix that by moving the #include <vector> line to a different place in the source code file, for example try moving it to be the first #include directive in the file. For some reason the preprocessor gets confused if it's already read in a bunch of headers and the compiler starts calling non-member errors on things that definitely are members... :shock:
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...

:Tezro: :Octane2:

User avatar
dexter1
Moderator
Moderator
Posts: 2743
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: GemRB

Unread postby dexter1 » Wed Dec 16, 2015 5:53 am

Yeah indeed, Thanks for that tip! By adding (or moving) a C++ header above the C-headers (<cmath>,<cstring>) most undefined type-errors disappear. I found the same fix on an old thread.

This fix also enables me dropping the -LANG:libc_in_namespace_std option in CXXFLAGS since it broke std::vector::at() : it turns out that std::vector does have ::at() as per c++03 standard which MIPSPro supports. Yay.

However i got this:

Code: Select all

cc-1132 CC: ERROR File = /usr/people/everdij/gemrb/gemrb-0.8.3.1/gemrb/core/Interface.cpp, Line = 2384
  The class "std::map<GemRB::ResRef, GemRB::Font *, std::less<GemRB::ResRef>,
          std::allocator<GemRB::Font *>>" has no member "at".

                return fonts.at(ResRef);
                             ^

I initially thought this was the same error as the one previously, but unfortunately the error is about missing ::at() in std::map. Even worse, this is added in the c++11 standard :( MIPSPro CC compiler version 7.4.4m doesn't support c++11 so that's end of the line.

But before i start crying and drag this code through gcc 4.6 or 4.7, it is however easily fixed in MIPSPro, due to the nature of that specific function:

Code: Select all

Font* Interface::GetFont(const ResRef& ResRef) const
{
   if (fonts.find(ResRef) != fonts.end()) {
      return fonts.at(ResRef);
   }
   return NULL;
}

by doing this:

Code: Select all

Font* Interface::GetFont(const ResRef& ResRef) const
{
   std::map<GemRB::ResRef,Font *>::const_iterator i = fonts.find(ResRef);
   if (i != fonts.end()) {
      return i->second;
   }
   return NULL;
}

Basically i used a map::const_iterator for the fonts class, so i can find the font pointer via the iterator instead of ::at()
There are other solutions on the internet by overloading the ::at() function for std::map and build a small function using one loop, ::find() and an exception handler.

Well, let's hope i do not encounter more c++11 specific language syntax...
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

User avatar
vishnu
Donor
Donor
Posts: 3189
Joined: Sun Mar 18, 2007 3:25 pm
Location: Minneapolis, Minnesota USA

Re: GemRB

Unread postby vishnu » Wed Dec 16, 2015 10:35 pm

That's top notch investigative coding dexter, nice work! :P
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...

:Tezro: :Octane2:

User avatar
necron2600
Posts: 279
Joined: Tue May 26, 2015 10:38 pm
Location: Boston

Re: GemRB

Unread postby necron2600 » Thu Feb 25, 2016 1:53 pm

Hi Dexter... any updates/status on your efforts for GemRB? Just wondering if it has gone anywhere or not.
Thanks

User avatar
dexter1
Moderator
Moderator
Posts: 2743
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: GemRB

Unread postby dexter1 » Tue Mar 01, 2016 2:37 pm

Sorry for not replying sooner, necron2600. I had another look last week and the problems at 82% was in GUIScript.cpp which basically boils down to include header hell. The solution is to compile the offending code with the -E option and sift through the output. That took a bit of time...

I did some more work on the code today and i patched it up to the point that gemrb and its plugins compile. The SDL plugin gets stuck with gettimeofday() so i have to revisit the #include <sys/time.h> fix i did for that.

Here is the patch file for gemrb-0.8.3.1
gemrb-0.8.3.1.patch
(14.97 KiB) Downloaded 29 times

It's probably my ugliest patch file i have ever made sofar. Feel free to mock it :)

I'll get around to building something useful in the coming days. I'm still not sure if there are endian issues. Also no idea how to test this. Pointers are welcome.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

lynx
Posts: 17
Joined: Fri Oct 14, 2016 9:15 am

Re: GemRB

Unread postby lynx » Fri Oct 14, 2016 9:34 am

hey guys, gemrb dev here.

I've amended and merge about half of Dexter's patch and this is what remains:
http://sprunge.us/TPJi?diff

So four things:
1. The mentioned time hacks, which seem more like something to be changed in your libc?
2. Unfinished changes I don't fully understand, since I have no way of testing:
- why the token change?
- why are only some str(n)icmp calls problematic and why? We define them to be the same everywhere but on windows.
- what tripped you up in Holder.h?

It'd be great if someone took git HEAD for a spin and report any other problems. For a trivial test just run with -c gemrb/tests/minimal/test.cfg . There's also one that pops up a window and loads a game, but we apparently don't ship a config (set GameType=demo): demo/data .

Btw, the code should already be endian-safe.

User avatar
dexter1
Moderator
Moderator
Posts: 2743
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: GemRB

Unread postby dexter1 » Sat Oct 15, 2016 5:06 am

lynx wrote:hey guys, gemrb dev here.

I've amended and merge about half of Dexter's patch and this is what remains:
http://sprunge.us/TPJi?diff

So four things:
1. The mentioned time hacks, which seem more like something to be changed in your libc?
2. Unfinished changes I don't fully understand, since I have no way of testing:
- why the token change?
- why are only some str(n)icmp calls problematic and why? We define them to be the same everywhere but on windows.
- what tripped you up in Holder.h?

It'd be great if someone took git HEAD for a spin and report any other problems. For a trivial test just run with -c gemrb/tests/minimal/test.cfg . There's also one that pops up a window and loads a game, but we apparently don't ship a config (set GameType=demo): demo/data .

Btw, the code should already be endian-safe.

Hello Lynx,

Thanks for coming here and looking into my patch. I'm currently installing and preparing my gemRB environment on a spare O2, since i have decided to rebuild part of our Nekoware distribution on my current workstations at home. My former gemRB dev machine, a O200 at work, is down for the moment so it will take me a bit of time to set everything up and start again.

I'll be back with some more info as soon as i have a compile in progress.
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

lynx
Posts: 17
Joined: Fri Oct 14, 2016 9:15 am

Re: GemRB

Unread postby lynx » Sat Oct 15, 2016 2:20 pm

Ok, no rush, we have some major stuff to finish before it's worthy of a new release (mostly random bugfixes so far).

necron: the same applies to you. If you had to massage it in any way to get it to run on Solaris, show me the diff.

Too bad you guys didn't talk to us sooner.

User avatar
necron2600
Posts: 279
Joined: Tue May 26, 2015 10:38 pm
Location: Boston

Re: GemRB

Unread postby necron2600 » Sat Oct 15, 2016 6:36 pm

Lynx,
Solaris 10 compiled without any mods.. I was actually surprised at how smoothly the compile went. I had a full Solaris10/sparc OpenCSW stack (www.opencsw.org) installed and compiled GemRB with gcc.

I had posted the compiled binary for solaris 10 (sparc) here on nekochan.net:
viewtopic.php?f=17&t=16730822&p=7391249&hilit=gemrb&sid=bf95f103daf4682fc1b44e199499c336#p7391249

It plays well (not slow at all) on a SUN Ultra 2 workstation from the 1990's with Solaris 10. I also had it playing through a thin-client SUN Ray with its 'host' being a mid 2000's SPARC server.

Just 1 minor issues on Solaris (SPARC):
Once in awhile when roaming around, gemrb will just hang. If I save often, its easy enough to restart the game and load. No errors or signs of why it hangs shows anywhere. And it is randomly anywhere on a map. Could be triggered by sounds, footsteps, an enemy, etc..? Its not too bad, maybe 2 hangs in one map while exploring, etc..

Thanks again!

lynx
Posts: 17
Joined: Fri Oct 14, 2016 9:15 am

Re: GemRB

Unread postby lynx » Sat Oct 15, 2016 10:48 pm

Great, thanks. :)

Nobody reported any hanging, so it could be platform specific. Or perhaps a memory problem. No matter, it's a pretty obvious problem that should crop up during pre-release testing if it is generic.


Return to “IRIX and Software”

Who is online

Users browsing this forum: Yahoo [Bot] and 1 guest