[Topgun]

Remember kids, only you can prevent threadomancy.

Divination through threads?

[rsaxvc]

reviving an old forum topic

[rsaxvc]

So, it turns out there's a bug in solaris that makes SDL not work when you have certain environment vars set. Good news is that it got to the point of not finding the game files.

[rsaxvc]

Hey look.

Currently, the software believes it is running on a big endian machine. After hard coding a correction into pstypes.h, the game launches.

[attachment deleted by admin]

[chief1983]

So you're on Solaris on an UltraSparc?  Specs?  I may have to dig out my pimped out Ultra 10 or Ultra 2 now, dammit.  Or maybe find a way to get it onto that E250 in storage.

[rsaxvc]

Still rolling with Ultra 40 M2. (2xOpteron2214, 16gb ram, nvidia gts 250, 8x500 sataII)

I have an Ultra 5, but compiling scp on it takes hours, and X is super slow. I also have a SPARCClassic, but nobody supports Sparc32 anymore.

Once Solaris x86 works, I might move on to Solaris/Sparc64, since I know someone I think I can borrow a sun blade 150 for a few weeks or so. Or... I might start on getting it running on HP/UX. I got my J5000 running (1 gig of ram, 2x440mhz PARISC2)

I need to pull down a known good copy of FS2, as sometimes I have issues with FotG at tip revision.

Also, the INTEL_INT macros and stwbrx() somehow do the wrong thing on every platform except linux/littleEndian, OSX, and windows/x86. On Solaris/x86, solaris/x64, linux/sparc, solaris/sparc, and hpux/parisc they don't work right. I also worry about alignment faults on those archs. Hopefully supporting PowerPC will have cleared them out, but when they happen, they choke performance: [[http://x264dev.multimedia.cx/?p=51]]

[chief1983]

If you're still using the standalone subset of FS2 I released for FotG, you need asteroids.  I'm going to update it shortly anyway, and I try to keep the FotG as it is in SVN compatible with some common set of builds (currently should still work on 3.6.12 if you leave the .tbm.bck files named that way).

If they work on OSX/x86-64 and OSX/PPC without changes, then there's a possibility there's still a problem.  Plus we have sketchy PPC support at best these days anyway.  I wish we had a few devs with more combinations of G4/G5 and 10.4/10.5 around.

So ok, the endian issue you ran into wasn't because you were running on strange hardware though, but because of software issues on Solaris/x86?  Was just confused about that.  Still, might be interesting to try to get it running on a FFB2+ if it has the OpenGL support for it.

[rsaxvc]

OpenSolaris may be a dead end.(I know the OS won't get updates...) I just installed the latest Oracle update. It purged almost every fs2 dependency I had installed. gcc, libopenal,... all gone. Also, the update errata was deleted from oracle.com!

I wouldn't say the endianness bug was a Solaris issue. Our macros/functions like SWAP_FLOAT and INTEL_INT only work for the 4/5 platforms we support(Windows/x86, Linux/x64, Linux/x86, OSX/ppc, and OSX/x86). Every other platform I've played with somehow leaked STWBRX into the mix.

While I'm here I'd like to point out that STWBRX cannot store to a register, so if you're really worried about speed, and only doing it a few times, you might be better off using some simple bitshifting. Has anyone done benchmarks on it?

So, where do I get these asteroids?

[chief1983]

Sorry I didn't mean that it's a Solaris bug, just that different behavior is experienced on Solaris.  Where the bug is, I wouldn't know.  Asteroids are coming

[rsaxvc]

So, it works!

Touchy parts:

• The big-endian vs. little endian macro mess wasn't working for floats, so all the models crashed. Currently my version will only work on Solaris/x86. What we need, is better detection of what endianness we're using
• The configure script PKG_CHECK_MODULES doesn't work and has to be patch by hand right now
• if you run with LANG set, you'll get a weird xerror, followed by a segfault. Do we use LANG right now?

http://rsaxvc.net/blog/doku.php?id=building_fs2_on_solaris has been update accordingly.

[attachment deleted by admin]

[chief1983]

I don't think we use LANG, not certain.  Grep would probably know.

If Sun Lua is lacking features, could we use the Lua that's in the code base already?

Edit: Patch of some of the changes you mentioned in the blog post is available.

[rsaxvc]

Yep, it works pretty well. I can make you a nice diff if you like.

Also, I got the old HP-UX box running, with OpenGL.

We could add a call to unsetenv("LANG"); before SDL init. 

[chief1983]

Ok, we've already committed the 'sun' var renaming stuff to trunk, but I took some of your other changes and tweaked some things.  What could you do with this patch, rsa?  I thought creating a SCP_SOLARIS define might be useful, unless you know another equivalent define that would already exist for use in the code.  But I used it to wrap the filio include, because apparently including it will break every other platform besides Solaris since they don't split out ioctl into different includes.

[rsaxvc]

SCP_SOLARIS is probably the way to go.

However, all of that work was done with OpenSolaris. I recently started playing with Oracle Solaris, which has some differences.

[chief1983]

I have a feeling the filio stuff will still apply on Solaris.  Have you gotten it running on that platform yet?

[rsaxvc]

Yep, filio stuff still applies for oracle solaris.

The current problem is 3fold- Oracle Solaris ships with a slightly outdated version of OpenGL (OpenSolaris is up to date); however, OpenSolaris only supports the XVR-100 video card, which is not very fast( And I don't have one) on SPARC PCI systems. So normally I would just patch together pieces of each OS until it ran...but Oracle Sparc Solaris uses a different X implementation, XSUN, instead of XORG (which everything else uses), so you can't just copy modules around.

[rsaxvc]

By copying bits from Solaris/x86/nvidia, I got it compiling and linking. However, launching responds with an error about missing GL_ARB_multitexture, which the XVR-600 video card does not support.

I did find this document from sun, which has a big table of cards and features:http://www.sun.com/software/graphics/opengl/1.3/SolImpPerfGuide1.3.pdf

That being said, I might be in the market for http://cgi.ebay.com/Sun-Microsystems-XVR-1200-graphics-card-XVR1200-/360300135537?pt=PCC_Video_TV_Cards&hash=item53e38fc471 or http://cgi.ebay.com/Sun-XVR-100-graphics-card-X3770A-375-3181-/190458920050?pt=PCC_Video_TV_Cards&hash=item2c583c7c72

Unless multitexturing is something we could compile-switch out, but I really doubt that it is.

[chief1983]

The Blade has a XVR-100 already right?  I was thinking about getting the XVR-2500 myself.  Want to see how the Blade runs first though.  Does this affect the Xorg situation on Solaris for you?

[rsaxvc]

The blades came with XVR-600s, which are better than XVR-100s.  XVR-2500s are pretty awesome, but PCIE only.

If I want to go for OpenSolaris/SPARC, I should buy an XVR-100
If I want to continue with Oracle Solaris/SPARC, I should buy an XVR-1200

[rsaxvc]

I went with the XVR-1200. It was cheaper and does more OpenGL ops, although unsupported on OpenSolaris.

I almost wonder if porting the ATI OpenSource driver over to OpenSolaris would be the thing to do. You'd still need at least one Sun video card to access OpenBoot ( maybe not, if you plan on not reconfiguring your system once it is set up), but after that, Xorg should be good to go. Hopefully, this solution would support PCIE cards easily enough going forward.


Newegg has a one that is kinda expensive for what it is:
http://www.newegg.com/Product/Product.aspx?Item=N82E16814129063

I've never ported a driver though, so it might be fun.

edit: fixed link / misread hcl