The collected works of skip

skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of Danger from the Deep! at Dec. 30, 2006, 2:56 a.m...
Hi,
It seems like an interesting game. :)
I don't know scons or GL, but I've managed to hack it enough that it compiles (patch below). It doesn't link (errors below) and I somehow think this was a bit too easy (there are lots of warnings too, most of which I disabled). scons does some strange things, but it does finish eventually. Running it a second time (after it fails) shows the command used to link (which needs -lm added to it).
Linking fails with the following symbols undefined: fftw_execute (which is in /usr/nekoware/lib/libfftw* but those don't get linked for some reason), glActiveTexture, fftw_plan_dft_c2r_2d, fftw_destroy_plan, glBindProgramARB, glProgramLocalParameter4fARB, glLockArraysEXT, glUnlockArraysEXT, glClientActiveTexture, glGenProgramsARB, glProgramStringARB, glGetProgramivARB, glDeleteProgramsARB.
That's after adding -lm manually. Anyone know what these symbols are and if they're usable on IRIX? Google didn't seem to be of much help (although I didn't search for all of them). I think the fftw things shouldn't be too hard to fix, but I don't know what to do with the gl ones.
Patch 5329 may be needed (it was for me).

This is also at http://rafb.net/p/RRqjNE41.html but that will expire after 24 hours. That should work if copying the following doesn't apply cleanly.

Code: Select all

diff -ur dangerdeep-0.2.0//SConstruct dangerdeep-current//SConstruct
--- dangerdeep-0.2.0//SConstruct   Fri Oct 13 03:44:44 JST 2006
+++ dangerdeep-current//SConstruct   Sat Dec 30 19:14:41 JST 2006
@@ -118,12 +118,12 @@
else:
print "Compiling for Unix/Posix/Linux Environment"
env = Environment(ENV = os.environ)
-   env.Append(CPPPATH = ['/usr/include/SDL', '/usr/include/GL'])
+   env.Append(CPPPATH = ['/usr/nekoware/include','/usr/nekoware/include/SDL','/usr/include/GL'])
libpath = ['/usr/X11R6/lib']
gllibs = ['GL', 'GLU']
sdllibs = ['SDL', 'SDL_image']
-   ccflags = '-Wall `sdl-config --cflags` `pkg-config --cflags x11`'
-   env.Append(LINKFLAGS = '`pkg-config --libs-only-L x11`')
+   ccflags = '-Wall `sdl-config --cflags`'
+   env.Append(LINKFLAGS = '-lm -L/usr/nekoware/lib -lGL -lGLU -lX11 -lXext')
if (debug >= 3):
ccflags += ' -g -pg -O3'   # profiling
elif (debug == 2):
@@ -139,7 +139,8 @@
elif (debug == -3):   # special g++4.0+ auto vectorization
ccflags += ' -g -O3 -march=athlon64 -mfpmath=sse -mmmx -msse -msse2 -m3dnow -ftree-vectorize -ftree-vectorizer-verbose=2'
else:
-      ccflags += ' -g -O2' # debug symbols will be stripped by the linker for a debian package
+      ccflags += ' -O3 -mips4 -n32 -woff 3649,3625,3201,1209,1174,1201,3554,1171 -I/usr/nekoware/include'
+
if (useefence >= 1):
extralibs += ['efence']
print 'Linking to ElectricFence library!'
@@ -146,17 +147,18 @@
if (cvedit == 1):
env.Append(CPPDEFINES = ['CVEDIT'])
# check for mmx/sse support
-   cpuinfof = open('/proc/cpuinfo', 'r')
-   cpuinfol = cpuinfof.readlines()
+#   cpuinfof = open('/proc/cpuinfo', 'r')
+#   cpuinfol = cpuinfof.readlines()
mmxsupported = False
ssesupported = False
-   for i in cpuinfol:
-      if i.startswith('flags'):
-         m = Split(i)
-         if 'mmx' in m:
-            mmxsupported = True
-         if 'sse' in m:
-            ssesupported = True
+#   for i in cpuinfol:
+#      if i.startswith('flags'):
+#         m = Split(i)
+#         if 'mmx' in m:
+#            mmxsupported = True
+#         if 'sse' in m:
+#            ssesupported = True
+   usex86sse = 0
if (usex86sse == 0) and (mmxsupported and ssesupported):
usex86sse = 1
if usex86sse >= 1:
@@ -174,7 +176,7 @@
print 'Using x86 SSE/MMX optimizations.'
env.Append(CCFLAGS = ccflags)
datadir = '/usr/local/share/dangerdeep'
-   build_dir = 'linux'
+   build_dir = 'irix'
# check for broken libGL, ignore undefined symbols then
if (os.system('grep glBindProgram /usr/include/GL/gl*.h > /dev/null') == 0):
gllibdirs = ['/usr/X11R6/lib/', '/usr/lib/', '/usr/local/lib/']
@@ -190,8 +192,8 @@
if (os.system('grep glBindProgram '+gllibdir+'libGL.so > /dev/null') != 0):
print 'GL headers declare glBindProgram, but libGL.so has no such symbol! Ignoring all undefined symbols...'
# I'm not sure which option will hopefully fix the problem... so i use both...
-         env.Append(LINKFLAGS = '--unresolved-symbols=ignore-all')
-         env.Append(LINKFLAGS = '-Xlinker --unresolved-symbols -Xlinker ignore-all')
+#         env.Append(LINKFLAGS = '--unresolved-symbols=ignore-all')
+#         env.Append(LINKFLAGS = '-Xlinker --unresolved-symbols -Xlinker ignore-all')

###### optionally change install and data dirs
if ARGUMENTS.get('datadir', 0):
@@ -208,7 +210,7 @@

################ configure
conf = Configure(env)
-if (devel == 0):
+if (1 == 0):
if not conf.CheckLibWithHeader('GL', 'gl.h', 'C'):
print 'GL library must be installed!'
Exit(1)
@@ -232,11 +234,11 @@
Exit(1)
if conf.CheckLibWithHeader('fftw3f', 'fftw3.h', 'C'):
print 'fftw3 library supports float type. Using it...'
-      fftwlib = 'fftw3f'
-      conf.env.Append(CPPDEFINES = ['WITH_FLOAT_FFTW'])
+      fftwlib = 'fftw3'
+#      conf.env.Append(CPPDEFINES = ['WITH_FLOAT_FFTW'])
else:
-   fftwlib = 'fftw3f'
-   conf.env.Append(CPPDEFINES = ['WITH_FLOAT_FFTW'])   # developers always use float...
+   fftwlib = 'fftw3'
+#   conf.env.Append(CPPDEFINES = ['WITH_FLOAT_FFTW'])   # developers always use float...
env = conf.Finish()

######################### source file lists
diff -ur dangerdeep-0.2.0//src/bspline.h dangerdeep-current//src/bspline.h
--- dangerdeep-0.2.0//src/bspline.h   Fri Oct 13 03:16:09 JST 2006
+++ dangerdeep-current//src/bspline.h   Sat Dec 30 19:12:34 JST 2006
@@ -26,12 +26,12 @@
#include <vector>
#include <cmath>

-#if (defined(__APPLE__) && defined(__GNUC__)) || defined(__MACOSX__)
+#if defined(__sgi) || (defined(__APPLE__) && defined(__GNUC__)) || defined(__MACOSX__)
#include <complex.h>
#ifndef isfinite
#define isfinite(x) finite(x)
#endif
-#elseif defined(WIN32)
+#elif defined(WIN32)
#ifndef isfinite
#define isfinite(x) _finite(x)
#endif
diff -ur dangerdeep-0.2.0//src/coastmap.cpp dangerdeep-current//src/coastmap.cpp
--- dangerdeep-0.2.0//src/coastmap.cpp   Fri Oct 13 03:16:12 JST 2006
+++ dangerdeep-current//src/coastmap.cpp   Sat Dec 30 19:12:34 JST 2006
@@ -38,6 +38,10 @@
#include <fstream>
#include <list>
#include <vector>
+#ifdef __sgi
+extern double round(double);
+#pragma optional round
+#endif
using namespace std;


@@ -1190,6 +1194,7 @@

// try to connect segcls that were made from the same global cl
unsigned erased = 0;
+      vector<coastsegment::segpos>::iterator i1; /* for mipspro */
for (unsigned i = 0; i < cs.segcls.size(); ++i) {
coastsegment::segcl& cl0 = cs.segcls[i];
if (cl0.global_clnr == -1) continue;
@@ -1204,7 +1209,9 @@
ASSERT(cl0.next == -1, "strange paranoia1 next != -1");
ASSERT(cl1.next == -1, "strange paranoia2 next != -1");
//connect the segcls.
-               cl0.points.insert(cl0.points.end(), ++cl1.points.begin(), cl1.points.end());
+               i1 = cl1.points.begin();
+               i1++;
+               cl0.points.insert(cl0.points.end(), i1, cl1.points.end());
//               cl0.points += cl1.points;
cl0.endpos = cl1.endpos;
cl1.global_clnr = -1;   // mark as erased.
diff -ur dangerdeep-0.2.0//src/faulthandler.h dangerdeep-current//src/faulthandler.h
--- dangerdeep-0.2.0//src/faulthandler.h   Fri Oct 13 03:16:09 JST 2006
+++ dangerdeep-current//src/faulthandler.h   Sat Dec 30 19:12:34 JST 2006
@@ -23,7 +23,7 @@
#ifndef FAULTHANDLER_H
#define FAULTHANDLER_H

-#ifndef WIN32
+#if !defined(WIN32) && !defined(__sgi)

#include <execinfo.h>
#include <stdio.h>
diff -ur dangerdeep-0.2.0//src/global_data.h dangerdeep-current//src/global_data.h
--- dangerdeep-0.2.0//src/global_data.h   Fri Oct 13 03:16:09 JST 2006
+++ dangerdeep-current//src/global_data.h   Sat Dec 30 19:12:34 JST 2006
@@ -32,7 +32,7 @@
#include <SDL.h>
#include <string>
#include <list>
-#include <cmath>
+#include <math.h>
#include "objcache.h"

// fixme: remove this ugly crap, move to .cpp
diff -ur dangerdeep-0.2.0//src/make_mesh.cpp dangerdeep-current//src/make_mesh.cpp
--- dangerdeep-0.2.0//src/make_mesh.cpp   Fri Oct 13 03:16:12 JST 2006
+++ dangerdeep-current//src/make_mesh.cpp   Sat Dec 30 19:12:34 JST 2006
@@ -23,12 +23,12 @@
#include "make_mesh.h"
#include <cmath>

-#if (defined(__APPLE__) && defined(__GNUC__)) || defined(__MACOSX__)
+#if defined(__sgi) || (defined(__APPLE__) && defined(__GNUC__)) || defined(__MACOSX__)
#include <complex.h>
#ifndef isfinite
#define isfinite(x) finite(x)
#endif
-#elseif defined(WIN32)
+#elif defined(WIN32)
#ifndef isfinite
#define isfinite(x) _finite(x)
#endif
diff -ur dangerdeep-0.2.0//src/model.cpp dangerdeep-current//src/model.cpp
--- dangerdeep-0.2.0//src/model.cpp   Fri Oct 13 03:16:12 JST 2006
+++ dangerdeep-current//src/model.cpp   Sat Dec 30 19:12:34 JST 2006
@@ -28,12 +28,12 @@
#endif

#include <cmath>
-#if (defined(__APPLE__) && defined(__GNUC__)) || defined(__MACOSX__)
+#if defined(__sgi) || (defined(__APPLE__) && defined(__GNUC__)) || defined(__MACOSX__)
#include <complex.h>
#ifndef isfinite
#define isfinite(x) finite(x)
#endif
-#elseif defined(WIN32)
+#elif defined(WIN32)
#ifndef isfinite
#define isfinite(x) _finite(x)
#endif
@@ -259,8 +259,8 @@
meshes[0]->compute_bounds();
min = meshes[0]->min;
max = meshes[0]->max;
-
-   for (vector<model::mesh*>::iterator it = ++meshes.begin(); it != meshes.end(); ++it) {
+   vector<model::mesh*>::iterator it = meshes.begin();
+   for (++it; it != meshes.end(); ++it) {
(*it)->compute_bounds();
min = (*it)->min.min(min);
max = (*it)->max.max(max);
@@ -283,7 +283,8 @@
if (vertices.size() == 0) return;
min = max = vertices[0];

-   for (vector<vector3f>::iterator it2 = ++vertices.begin(); it2 != vertices.end(); ++it2) {
+   vector<vector3f>::iterator it2 = vertices.begin();
+   for (++it2; it2 != vertices.end(); ++it2) {
min = it2->min(min);
max = it2->max(max);
}
diff -ur dangerdeep-0.2.0//src/sonar.h dangerdeep-current//src/sonar.h
--- dangerdeep-0.2.0//src/sonar.h   Fri Oct 13 03:16:09 JST 2006
+++ dangerdeep-current//src/sonar.h   Sat Dec 30 19:12:34 JST 2006
@@ -58,8 +58,11 @@
// base^dB_val = real noise, dB = 10 * log10(real) -> dB/10 = log10(real)
// -> 10^(dB/10) = real -> (10^0.1)^dB = real,  10^0.1 = dB_base
// so dB_base^dB = real
+#ifndef __sgi
static const double dB_base = 1.25892541179;
-
+#else /* MIPSpro doesn't like initializing the static const */
+   const double dB_base = 1.25892541179;
+#endif
// limits of frequency bands in Hertz
static const double frequency_band_lower_limit[NR_OF_FREQUENCY_BANDS];
static const double frequency_band_upper_limit[NR_OF_FREQUENCY_BANDS];
@@ -79,8 +82,11 @@
static const double typical_frequency[NR_OF_FREQUENCY_BANDS];

// additional extra noise constant for cavitation, when running at full/flank speed, in dB
+#ifndef __sgi
static const double cavitation_noise = 2;
-
+#else
+   const double cavitation_noise = 2;
+#endif
static double dB_to_absolute(double dB) {
return (dB < 0) ? 0.0 : pow(dB_base, dB);
}
diff -ur dangerdeep-0.2.0//src/sonar_operator.h dangerdeep-current//src/sonar_operator.h
--- dangerdeep-0.2.0//src/sonar_operator.h   Fri Oct 13 03:16:09 JST 2006
+++ dangerdeep-current//src/sonar_operator.h   Sat Dec 30 19:12:34 JST 2006
@@ -54,11 +54,15 @@
// fixme: good idea, but a contact is reported many times then while the sub turns, fixme!
std::map<double, contact> contacts;
bool active;   // disabled, when user does the work
-
+#ifndef __sgi /* MIPSpro doesn't like initializing static const */
static const double turn_speed_fast = 6.0;   // degrees per second.
static const double turn_speed_slow = 2.0;   // degrees per second.
static const double simulation_step = 0.1;   // in seconds
-
+#else
+   const double turn_speed_fast = 6.0;      // degrees per second.
+   const double turn_speed_slow = 2.0;      // degrees per second.
+   const double simulation_step = 0.1;      // in seconds
+#endif
double last_simulation_step_time;

angle find_peak_lower_limit, find_peak_upper_limit;
diff -ur dangerdeep-0.2.0//src/system.h dangerdeep-current//src/system.h
--- dangerdeep-0.2.0//src/system.h   Fri Oct 13 03:16:09 JST 2006
+++ dangerdeep-current//src/system.h   Sat Dec 30 19:12:34 JST 2006
@@ -46,12 +46,15 @@
#endif

// a helpful macro
+#ifndef __sgi /* MIPSpro doesn't like ... in macros */
#ifdef DEBUG
#define ASSERT(a,...) {if(!(a)){sys().error(__VA_ARGS__);}}
#else
#define ASSERT(a,...)
#endif
-
+#else
+#define ASSERT
+#endif
class font;
class texture;

diff -ur dangerdeep-0.2.0//src/tone_reproductor.cpp dangerdeep-current//src/tone_reproductor.cpp
--- dangerdeep-0.2.0//src/tone_reproductor.cpp   Fri Oct 13 03:16:12 JST 2006
+++ dangerdeep-current//src/tone_reproductor.cpp   Sat Dec 30 19:12:34 JST 2006
@@ -21,7 +21,7 @@
#include "tone_reproductor.h"

#ifndef pow10
-#define pow10(x) pow(10.0, x)
+#define pow10(x) pow((float)10.0, x)
#endif

// Set some values to prevent bugs in case of bad use
diff -ur dangerdeep-0.2.0//src/water.cpp dangerdeep-current//src/water.cpp
--- dangerdeep-0.2.0//src/water.cpp   Fri Oct 13 03:16:12 JST 2006
+++ dangerdeep-current//src/water.cpp   Sat Dec 30 19:12:34 JST 2006
@@ -1068,7 +1068,7 @@
const float VIRTUAL_PLANE_HEIGHT = 25.0f;   // fixme experiment, amount of reflection distorsion, 30.0f seems ok, maybe a bit too much

// maximum height of waves (half amplitude)
-   const double WAVE_HEIGHT = std::max(double(curr_wtp->maxh), fabs(curr_wtp->minh));
+   const double WAVE_HEIGHT = std::max(double(curr_wtp->maxh), (double)fabs(curr_wtp->minh));

//   cout << "Wave height is: " << WAVE_HEIGHT << "\n";

@@ -1381,7 +1381,7 @@

// compute dynamic normals
// clear values from last frame (fixme: a plain memset(...,0 ) may be faster, or even mmx memset
-   fill(normals.begin(), normals.end(), vector3f());
+   std::fill(normals.begin(), normals.end(), vector3f());

// compute normals for all faces, add them to vertex normals
// fixme: angles at vertices are ignored yet
skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of Danger from the Deep! at Dec. 30, 2006, 5:21 a.m...
lhaza wrote: dangerdeep 0.2 uses libfftw 3.1 while nekoware is at 3.0.1. This could be the problem here.

Thanks - that seems to work okay. Linking to a static libfftw 3.1 fixes the two fftw symbols.

Brombear wrote: These are all calls to OpenGL that deal with newer type of extensions like GLSL etc. If these calls are used directly within the code it is very bad style, typically you query those as function pointers and use them only if they are defined.

squeen wrote: Brombear is right. The game used OpenGL Shading Language with IRIX graphics don't support. You'd have to whack that part of the code (for the water it looks like).

Ah, that's too bad. :( And indeed, none of them are in glGetString(GL_EXTENSIONS). Thanks to both of you - I didn't know anything about GL (but now I know one tiny thing :D ).
skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of Danger from the Deep! at Dec. 30, 2006, 6:23 a.m...
squeen wrote: You'd have to whack that part of the code (for the water it looks like).

(edited: I fixed the patch so it really does apply cleanly now :oops: )
I #ifdef'ed out all references to the undefined GL symbols, and the game runs now. Sound/title screen/etc seem fine. Viewing vessels works, although some of them are simple white models (the #ifdef probably broke them).
It seems to play missions now, although I don't know how to do anything. :oops:
The new patch (includes the previous ones, so this is the only one needed) is larger. It's at http://www.nekochan.net/wiki/ ... deep.patch which seems to apply cleanly. The link line needs to be manually modified again - I removed the -lfftw3 and added -lm and ../fftw-3.1.2/.libs/libfftw3.a to link a static version of fftw-3.1.2.
Performance is almost passable for me (Fuel/500/V10). The scons file says that it should be linked against an --enable-float build of fftw for performance which I haven't done yet.
I'm really off to bed now, but thanks again. :D
skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of Danger from the Deep! at Dec. 30, 2006, 8:40 a.m...
nuclear wrote: Your best bet is to check out if there are compile or run time switches that disable the use of shaders and multitexturing in the aforementioned game, otherwise you have a lot of rewriting to do :)

Wow, thanks for the details. :D Unfortunately I'm really not capable of rewriting the rendering :wink: , but there are a couple of configuration variables that can be changed. I have the following in ~/.dangerdeep/config (created the first time that dangerdeep is run):

Code: Select all

<use_shaders value="false" />
<use_shaders_for_water value="false" />
<usex86sse value="false" />

These are referenced in the code, but I haven't really read enough to make sure they're always used. But, with the patch linked above it seems basically playable. Pounding on the keyboard gets me "Crash dive!" "Engines ahead flank" and the like and then the bridge view becomes dark. 8)
skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of Danger from the Deep! at Dec. 31, 2006, 3:58 a.m...
(edit: I also put a binary with -O3 -mips4 -n32 at http://skipfiles.googlepages.com/dangerdeep2 as that fixes the issues with other subs/etc. But, it's noticeably slower. So that one works a bit better, but the next one is faster. 6268K)
I compiled a binary using the patch from before with -Ofast=ip27 -mips4 -n32 and put it at http://skipfiles.googlepages.com/dangerdeep if anyone would like to try it. It's 6036K.
It requires SDL, SDL_image, SDL_net, SDL_mixer, libiconv, libpng, libjpeg, libtiff, libz, libvorbisfile, libvorbis and libogg from Nekoware. It also requires the 0.2.0 data files from http://www.dangerdeep.net in the default location (/usr/local/share/dangerdeep). I -think- the binary is sufficient, everything required should be linked statically, but I only have a single machine to test on. :(
Performance is better (than the -O3 build) for me. Some things are broken, but the training missions (in historical missions), and I think all convoy battles with the VIIC (the first) sub seem to basically work. The other subs worked before, but somehow I broke them I guess. Destroyers are rather dangerous, but it's possible to hide. Some ships have become invisible and/or invincible. 8) I'd love to hear if it doesn't work at all, or if it does. Some textures look a bit odd, but morning and evening are pretty.

Anyways, happy New Year everyone (in 3 hours here :) )
skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of Danger from the Deep! at Dec. 31, 2006, 10:27 p.m...
lhaza wrote: It works here on fuel v10. I had no luck with your patch (-lm needs to be in last place, how to do that with scons??).

I don't know how to use scons, but I run it once, wait for linking to fail, then run it again. The second time it shows the command used to link (with -lm at the start). I copy and paste that, removing -lfftw3 and adding "-lm ../fftw-3.1.2/.libs/libfftw3.a" to the end. I really need to patch SConstruct properly at some point.
I'm really glad to hear that it works. :D
funny:

Code: Select all

console log: Unable to play WAV file: Couldn't open /usr/local/share/dangerdeep/objects/torpedoes/TI/standard/g7a_torpedo_color.jpg


Haha - that is funny. I wonder if it's broken in 0.2.0 in general, or only on IRIX. Thanks for trying it. :)
skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of Danger from the Deep! at Jan. 4, 2007, 2:39 a.m...
UrbanHero wrote: Ouch! I was hoping lumbering boats wouldn't tax the system so much; apparently there's a lot of heavy stuff going on behind the scene...my Octane's gonna have a tough time with this :?

It's playable for me, really it's only the periscope, bridge, free 3d and UZO views that are a bit less smooth. The lead developer wrote on their forums:
System requirements in general: 1.0GhZ+ better 1.5Ghz, 256mb+ better more, a modern graphic card (DX8 or OpenGL 1.4 with shaders).

So I guess it's a bit intense.
Alver wrote: Has it improved since then?

This is the first time I've tried it - 50% of the game still isn't implemented, but the implemented half seems stable for me (in the -O3 build I linked). I haven't tried any of the official releases, but the biggest issue for me is that whacking the unsupported extensions without adding anything makes the game somewhat less pretty than the screenshots. That and I still haven't hit a moving target with a torpedo. :wink:
fzalfa wrote: both executable crash on my octane2 (r12k and r14k)
i have the main mene, mission choice, but after had loaded the mission, it crash
the message is obscure.... "Caught exception: "

Sorry about that. :(
I don't really know what would cause that (and I don't have an Octane unfortunately, they seem a bit uncommon on the secondhand market near me). When you start the mission, there should be another initialization screen (white text on black, like the startup one). If you get that far, what is the last line it shows?
lhaza posted that it worked for him, but I have the same hardware. Anyone have ideas?
There is an error posted on their forums about the Windows build (but is probably in all the builds) here that has a "Caught exception: St9bad_alloc" at startup (not mission loading) when the data files aren't installed. The data files are installed in the proper spot? (/usr/local/share/dangerdeep/convoys should exist)
skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of Danger from the Deep! at Jan. 5, 2007, 6:32 a.m...
fzalfa wrote: allways crashing with my octane2... i have the main menu, i can choose mission, watch boat 3d models , but when i start a mission.....

Hi, if you have dbx installed and can ssh to the octane, could you try the following?
(If you can't ssh to it, you'll lose display and/or keyboard focus when it crashes and have to reboot)
1) ssh to the machine and either export DISPLAY=:0.0 in bash or setenv DISPLAY :0.0 in csh .
2) run dbx /path/to/dangerdeep
3) switch to the octane and start a mission that would crash it.
4) go back to the ssh session, hit Ctrl-C and type where
5) Once that's done, type quit .
And then post the output from the where command?
skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of Danger from the Deep! at Jan. 6, 2007, 11:40 p.m...
AX wrote: Any ideas? I also noticed that my data folder in the share directory is empty. There should be files I would believe.

/usr/local/share/dangerdeep/data is not used, the original data zip extracts to a "data" directory, which needs to be /usr/local/share/dangerdeep (by default) on *nix builds. The empty directory is probably a remnant from that. This is really odd, but deleting that empty directory (rmdir /usr/local/share/dangerdeep/data as root) seems to help. I had trouble with vanishing ships until I removed it.

AX wrote: Downloaded the tat.bz2 file with data on this second page. installed all the SDL*'s. When I run ./dangerdeep or bin/dangerdeep I get this error.

Code: Select all

Trace/BPT/RangeErr/DivZero/Overflo Trap

I just tried the .tar.bz2, but it doesn't crash for me. The binary in it seems to be an -Ofast build, which is somewhat broken (but faster :? ) as I noted earlier. I use the simple "-O3" build, which is noticeably slower. With the -Ofast build, only the VIIC is usable in some stations, some ships are invisible and invincible. It does have better performance. I've actually replaced it with a build using flags suggested by hamei (adding -INLINE -OPT:Olimit=0:roundoff=3 -TARG:platform=IP35:proc=r14000), which seems to work okay. So both of my binaries linked on the previous page now work for me. I don't recommend the -Ofast build; it seems to be broken in many ways.

The error you get is actually similar to one I had while porting it (using round() from C++ is apparently not okay, so I wrote it as a macro using floor()). I wonder if floor() or something else is causing a problem?

The list of required packages is: libSDL, libSDL_mixer, libSDL_net, libSDL_image, libpng, libjpeg, libiconv, libtiff, zlib, libvorbisfile, libvorbis and libogg. But I'm sure that you have all those, or it shouldn't execute at all.
skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of Danger from the Deep! at Jan. 7, 2007, 8:15 p.m...
joerg wrote: 2. Most of the models doesnt shown with textures (something misssing/incomplete game or just broken?)
3. On my system the colors looks very 'purple'

The game requires multitexturing and other GL bits not supported (at least on my machine) in IRIX. The patch simply removes those, which is probably causing both of these. The water is also much less pretty than the screenshots of official builds. nuclear posted about the GL extensions, it seems that fixing these is likely to be quite involved. :(
skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of neko_axene-2.0.1 in /incoming at Jan. 2, 2016, 7:15 p.m...
I've been running my Fuel recently and noticed hamei's request for Axene .

I put an initial tardist in /incoming (sha1 07f185a28c203744c2be14ac08457c296f16b39e). This includes XAllWrite (word processor), XQuad (spreadsheet), and Xclamation (run /usr/nekoware/bin/{xallwrite,xquad,xclamation}). I tried to follow the follow the guide for packaging software and the tardist works for me - I hope it's useful.
skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of neko_axene-2.0.1 in /incoming at Jan. 4, 2016, 5:43 a.m...
Thanks for the interest, and to nekonoko for moving it to /beta! Release notes, patch and source are in the tardist as usual.

I'm afraid I hurried to make the tardist before vacation ended so there are a few bugs I noticed only after uploading (sorry):
1) Color doesn't work when printing or exporting Postscript (it's black, annoying with graphs and plots in XQuad)
2) Edit->undo doesn't work in XAllWrite (hangs)
3) It's easy to crash Xclamation

#1 can be fixed by compiling -o32 and avoiding the incompatible redeclarations in the (axene-provided) src/X*/Headers/types.h (you need at least #define LONG_IS_xxBIT with appropriate xx (32) when compiling) . I'd be happy to hear of other problems -- Axene was supported on IRIX 5.3 so hopefully it won't be hard to get everything working in a second tardist. Patches or fixes are even better of course. :-)
skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of neko_axene-2.0.1 in /incoming at Jan. 12, 2016, 8:36 a.m...
Source is still available from a mirror: http://linuxmafia.com/pub/linux/apps/axene/
skip
From Hokkaido, Japan
Who joined Dec. 25, 2006, 4:35 a.m.
Wrote on the subject of neko_axene-2.0.1 in /incoming at June 28, 2016, 1:12 a.m...
Yes, run /usr/nekoware/bin/{xallwrite,xquad,xclamation}.