[SirKnightly]

Here is the nightly for FreeBSD on 05 Nov 2012 - Revision 9326

Group: Inferno
fso-FREEBSD-Inferno-20121105_r9326.tar.bz2
MD5Sum

Code: [Select]

------------------------------------------------------------------------
r9302 | karajorma | 2012-11-03 01:08:22 -0500 (Sat, 03 Nov 2012) | 1 line
Changed paths:
   M /trunk/fs2_open/code/parse/sexp.cpp

Object numbers are not guaranteed to the same on the client. Sent the net_sig instead.
------------------------------------------------------------------------
r9303 | karajorma | 2012-11-03 03:25:27 -0500 (Sat, 03 Nov 2012) | 1 line
Changed paths:
   M /trunk/fs2_open/code/mission/missiontraining.cpp
   M /trunk/fs2_open/code/network/multi.cpp
   M /trunk/fs2_open/code/network/multi.h

Clear out some cruft from the multiplayer code. Make sure Macros are being used.
------------------------------------------------------------------------
r9304 | karajorma | 2012-11-03 04:01:17 -0500 (Sat, 03 Nov 2012) | 1 line
Changed paths:
   M /trunk/fs2_open/code/network/multi.h

Turns out you do need some of those after all. No idea why grep didn't find them.
------------------------------------------------------------------------
r9305 | The_E | 2012-11-03 04:23:23 -0500 (Sat, 03 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/anim/animplay.cpp
   M /trunk/fs2_open/code/camera/camera.cpp
   M /trunk/fs2_open/code/cutscene/mveplayer.cpp
   M /trunk/fs2_open/code/graphics/2d.cpp

PVS Studio fix: Add checks against NULL pointer dereferences

------------------------------------------------------------------------
r9306 | The_E | 2012-11-03 04:24:25 -0500 (Sat, 03 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/graphics/gropenglstate.cpp

PVS Studio suggestion: Use ++it for iterators

------------------------------------------------------------------------
r9307 | The_E | 2012-11-03 04:25:48 -0500 (Sat, 03 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/graphics/gropengltnl.cpp

PVS Studio suggestion: Create a reference instead of repeated vector access

------------------------------------------------------------------------
r9308 | The_E | 2012-11-03 04:28:49 -0500 (Sat, 03 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/hud/hud.cpp

PVS Studio fix: String play_callsign is not used anywhere

------------------------------------------------------------------------
r9309 | The_E | 2012-11-03 04:31:54 -0500 (Sat, 03 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/hud/hudparse.cpp

PVS Studio suggestion: Create a reference to avoid multiple vector access operations

------------------------------------------------------------------------
r9310 | The_E | 2012-11-03 04:33:54 -0500 (Sat, 03 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/hud/hudsquadmsg.cpp

PVS Studio fix: "!none_valid" is always true

------------------------------------------------------------------------
r9311 | The_E | 2012-11-03 04:35:46 -0500 (Sat, 03 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/jpgutils/jpgutils.cpp

PVS Studio fix: Really confusing code

------------------------------------------------------------------------
r9312 | The_E | 2012-11-03 04:36:44 -0500 (Sat, 03 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/model/modelinterp.cpp

PVS Studio fix: Pointer shipp is not checked against NULL

------------------------------------------------------------------------
r9313 | The_E | 2012-11-03 04:37:29 -0500 (Sat, 03 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/network/multi_obj.cpp

PVS Studio fix: Pointer not checked against NULL

------------------------------------------------------------------------
r9314 | The_E | 2012-11-03 04:38:34 -0500 (Sat, 03 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/starfield/starfield.cpp
   M /trunk/fs2_open/code/weapon/muzzleflash.cpp

PVS Studio suggestion: Create a reference to avoid repeated vector access

------------------------------------------------------------------------
r9315 | The_E | 2012-11-03 04:39:11 -0500 (Sat, 03 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/network/multi_pxo.cpp

PVS Studio fix: string last_portion is not used anywhere

------------------------------------------------------------------------
r9316 | Echelon9 | 2012-11-03 18:11:41 -0500 (Sat, 03 Nov 2012) | 1 line
Changed paths:
   M /trunk/fs2_open/code/graphics/2d.cpp

Re: r9305 - while NULL pointer checks in non-Debug are useful, ensure we don't lose the better check in Debug as well.
------------------------------------------------------------------------
r9317 | The_E | 2012-11-04 02:25:53 -0600 (Sun, 04 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/graphics/generic.cpp

Compiler warning removal: ubyte/int comparison

------------------------------------------------------------------------
r9318 | The_E | 2012-11-04 02:27:50 -0600 (Sun, 04 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/hud/hudtarget.cpp

Compiler warning removal: Unused variable, float-to-int cast

------------------------------------------------------------------------
r9319 | The_E | 2012-11-04 02:29:46 -0600 (Sun, 04 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/model/modelcollide.cpp

Compiler Warning removal: int-to-ubyte conversion

------------------------------------------------------------------------
r9320 | The_E | 2012-11-04 02:30:20 -0600 (Sun, 04 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/radar/radardradis.cpp

Compiler warning removal: Variable initialized but not used

------------------------------------------------------------------------
r9322 | Zacam | 2012-11-04 09:44:11 -0600 (Sun, 04 Nov 2012) | 1 line
Changed paths:
   M /trunk/fs2_open/projects/Xcode/English.lproj/InfoPlist.strings

One more spot to update Build revision from .13 to .15
------------------------------------------------------------------------
r9323 | Zacam | 2012-11-04 15:50:34 -0600 (Sun, 04 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/model/modelinterp.cpp

Lets see if this handles Mantis 2724.
On Valathil's suggestion, pulled the code added in 9312 from 'model_render_glow_points' and 'model_render_thrusters'
------------------------------------------------------------------------
r9325 | Goober5000 | 2012-11-04 23:43:28 -0600 (Sun, 04 Nov 2012) | 2 lines
Changed paths:
   M /trunk/fs2_open/code/mission/missionlog.cpp
   M /trunk/fs2_open/code/mission/missionparse.cpp
   M /trunk/fs2_open/code/parse/sexp.cpp

a ship that is self-destructed should have the same behavior as one that is destroyed, if going by mission log entries
(c.f. thread: http://www.hard-light.net/forums/index.php?topic=82718.0)
------------------------------------------------------------------------
r9326 | Goober5000 | 2012-11-05 02:31:39 -0600 (Mon, 05 Nov 2012) | 1 line
Changed paths:
   M /trunk/fs2_open/code/graphics/2d.h
   M /trunk/fs2_open/code/graphics/gropengltnl.cpp
   M /trunk/fs2_open/code/graphics/gropengltnl.h
   M /trunk/fs2_open/code/graphics/grstub.cpp
   M /trunk/fs2_open/code/lab/wmcgui.cpp
   M /trunk/fs2_open/code/lab/wmcgui.h
   M /trunk/fs2_open/code/network/multi_sexp.cpp
   M /trunk/fs2_open/code/network/multi_sexp.h

inspired by recent change to multi_sexp.cpp... in most cases, SCP_string should not be passed by value
------------------------------------------------------------------------



[jg18]

Whoa.

[Dragon]

What's FreeBSD?

[niffiwan]

surely you're trolling?

http://www.freebsd.org/

[SypheDMar]

I was expecting this when I saw the Linux Nightly today. Goes to show that FSO is scaling!

[FreeSpaceFreak]

Curious how many people will be using this

[chief1983]

I was expecting this when I saw the Linux Nightly today. Goes to show that FSO is scaling!

?  Really?  We've had Linux nightlies and supported it for a long time, FreeBSD support is brand new, thanks to some work by a Diaspora player.  I ran with his findings and got the changes made in trunk to support it without additional hackery.

[SypheDMar]

No, I mean this:

Code: [Select]

r9298 | chief1983 | 2012-11-02 15:36:53 -0400 (Fri, 02 Nov 2012) | 1 line
Changed paths:
   M /trunk/fs2_open/code/windows_stub/stubs.cpp
   M /trunk/fs2_open/configure.ac

More tweaks for FreeBSD support, and cleanup of configure.ac.  Slightly experimental.
I saw it on the Linux Nightly build and thought that you guys were trying to make a FreeBSD build. This was all before SirKnightly posted the FreeBSD build. I hope that clarifies things.

[chief1983]

Ah, much more sense then.  Yeah, each platform kind of had a couple local tweaks I'd been meaning to commit, so I sat down and fired each one up and committed them one at a time, so I could sync them up with each other.

Anyway, proof this build at least initializes:

Diaspora on FreeBSD nightly VM (VirtualBox)

[nbspjr]

WOW!
You're awesome, guys Thank you!

[chief1983]

WOW!
You're awesome, guys Thank you!

Wouldn't have been able to get it going without all your hard work getting Diaspora to run.  If you get a chance, please let me know how the nightlies work out for you, I don't have a native FreeBSD machine to test on at the moment, although I might re-purpose one of the machines in the basement for that in the future.

[nbspjr]

Wouldn't have been able to get it going without all your hard work getting Diaspora to run.  If you get a chance, please let me know how the nightlies work out for you, I don't have a native FreeBSD machine to test on at the moment, although I might re-purpose one of the machines in the basement for that in the future.

Thank you. Well, patching configure.ac wasn't a actually a hard work

Anyway, I have a silly question about testing nighty builds. Could I just use Diaspora distribution from the RELEASE topic (plus patches) with fso2 binary replaced by the nighty one?

PS: oh, sorry. You've built x86 binaries, looks like it wants x86 dependencies too:

Code: [Select]

fs2_open_diaspora:
$ ldd fs2_open_diaspora
        libSDL-1.2.so.11 => not found (0)
        libvorbis.so.4 => not found (0)
        libvorbisfile.so.6 => not found (0)
        libtheora.so.0 => not found (0)
        libogg.so.8 => not found (0)
        libopenal.so.1 => not found (0)
        libpng15.so.15 => not found (0)
        libGL.so.1 => not found (0)
        libGLU.so.1 => not found (0)
        liblua-5.1.so.1 => not found (0)
        libm.so.5 => /usr/lib32/libm.so.5 (0x285b4000)
        libjpeg.so.11 => not found (0)
        libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0x285ce000)
        libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0x286c2000)
        libthr.so.3 => /usr/lib32/libthr.so.3 (0x286cd000)
        libc.so.7 => /usr/lib32/libc.so.7 (0x286ed000)

I'm going to export files the appropriate revision from the fs2open trunk and build it on my own.

[nbspjr]

I have played one mission so far using the binary I built from r9326 (x86_84). Is there anything specific I should test?

[Echelon9]

...
Anyway, I have a silly question about testing nighty builds. Could I just use Diaspora distribution from the RELEASE topic (plus patches) with fso2 binary replaced by the nighty one?
...

I think just about all of our Diaspora-specific code patches are now in trunk, so theoretically it should work.

[chief1983]

Yeah I built 32bit, wasn't sure how FreeBSD was about trying to support a 32bit userland on a 64bit setup.  Guess not very good at it.  I can't think of anything specific to test, this will just give you the ability to continue testing the latest trunk changes that will be in the next stable release, just like any Windows user.  And also make building your own builds much easier now I hope, not having to keep local hacks around.

[nbspjr]

Yeah I built 32bit, wasn't sure how FreeBSD was about trying to support a 32bit userland on a 64bit setup.  Guess not very good at it.

It is good enough as the 32bit support is built into GENERIC kernel (I have 32bit wine to run windows games). I think I should have some 32bit shared libraries to be able to run x86 Diaspora.

I can't think of anything specific to test, this will just give you the ability to continue testing the latest trunk changes that will be in the next stable release, just like any Windows user.  And also make building your own builds much easier now I hope, not having to keep local hacks around.

Yea, thanks a lot for this. I'm trying to create a port for Diaspora. I managed to successfully buid fso from the port but now I'm learning how to install the game  properly from the portstree. I'm not familiar with this stuff, maybe I could ask FreeBSD community for help.

[MatthTheGeek]

The only thing that needs porting is the executable. All other files can just be straight copy-pasted from any other platform.

(The launcher is optional, you can do everything from command line)

[nbspjr]

The only thing that needs porting is the executable. All other files can just be straight copy-pasted from any other platform.

(The launcher is optional, you can do everything from command line)

Sorry for confusing you. I'm not going to port anything to FreeBSD as it's not needed. The FreeBSD third-party software distribution collection is called "Ports and Packages" (think of Gentoo portage). I just want to bring the Diaspora to the ports tree, i.e. make a port for it. The port it's just an item in the collection with instructions, so port management tools could use these instruction to install/remove software in FreeBSD-way.