linuxssn-devel — Discuss the planning and development of the game

[LinuxSSN-devel] CVS Id tag

[Michael B. <mic...@ve...>]

Hi guys, I've had a request, which does not seem at all unreasonable.
Whenever we get around to committing source files for the OpenGL branch
to CVS, if we could add a line like this:

// $Id$

somewhere near the top of the file. CVS will automatically expand this
to something like:

// $Id: adcap.h,v 1.6 2003/04/14 05:23:14 mbridak Exp $


I've already changed all source files in the original branch.

While I was there, I changed the sonar.cpp file. As it turns out I
didn't need to use a temp SDL_Surface as an intermediate holder for the
blitted data. I just blit from and to the same surface. Also removed
several Updaterects commands since they had no real affect.

Mike

Re: [LinuxSSN-devel] Re: More Updates

[Joe V. <jo...@ve...>]

> So I guess a similar effect in OpenGL would be to use replace
> the pixel drawing with a function similar to the following:
> 
> void drawDot(GLint x, GLint y, GLfloat red, GLfloat green, GLfloat blue)
> // Draw a color dot at (x,y)
> {
> 	glColor3f(red, green, blue);
> 	glBegin(GL_POINTS);
> 		glVertex2i(x, y);
> 	glEnd();
> }
> 
> My first thought is that it would be slower to draw pixels directly to a
> screen, rather than bitmaps.  But I'm new to OpenGl, so my knowledge is
> limited. 
> 
> The code that advances the sonar screen and make the waterfall effect is
> the hard part.  I think it sort of does a cut and paste.  It cuts part
> of the screen, moves it down and blits it back.  Is there a way to do
> the same thing in OpenGL?

No, using GL_POINTS is totally not the way to go.  Let me explain:

You can copy SDL surfaces to OpenGL textures every frame.  So, you could do the exact same sonar code where you're using a temp surface and then the two final surfaces, and instead of blitting them to the screen (which is the last step in what the old code does) just send them to the textures for two quads which are positioned where you want the waterfall displays.

Does this make sense how I'm explaining it?  I recently switched to gentoo linux (gentoo.org) and am only now getting around to re-installing Anjuta, but I'll try to make up a short little bit of example code:


// So, the init code is something like this:
int waterfall1_opengltex;
SDL_Surface *waterfall1_sdltex[1];
glGenTextures(1, &waterfall1_opengltex);

// And then every loop you'd do something like this:
while (loop)
{
// ... do stuff to update the SDL surface waterfall1_sdltex
glBindTexture(GL_TEXTURE_2D, waterfall1_opengltex);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR_MIPMAP_NEAREST);
gluBuild2DMipmaps( GL_TEXTURE_2D, 3, waterfall1_sdltex[0]->w, waterfall1_sdltex[0]->h, GL_BGR, GL_UNSIGNED_BYTE, waterfall1_sdltex[0]->pixels );
// And then draw our output quad
glBegin(GL_QUADS);
glVertex3f(0,0,0); glNormal3f(0,0);
glVertex3f(10,0,0); glNormal3f(1,0);
glVertex3f(10,10,0); glNormal3f(1,1);
glVertex3f(0,10,0); glNormal3f(0,1);
glEnd();
}


Or something like this.  I haven't actually tested this, but I think this is definitely the way to do it.

Joe Venzon

Re: [LinuxSSN-devel] Re: More Updates

[Michael B. <mic...@ve...>]

I believe the only thing you left out was to initialize the timer sub
system in SDL. So in the main.cpp code you would replace the SDL_Init
call    =20

if ( SDL_Init( SDL_INIT_VIDEO ) < 0 )

with

if ( SDL_Init(SDL_INIT_VIDEO|SDL_INIT_TIMER) < 0 )

and the timers should work....

I think ;-)


On Tue, 2003-04-08 at 15:32, MCDANIEL RICKEY D wrote:
> Posted latest changes to OpenGL code on web site.  This week I'm adding
> all the old classes to the new code.  Hopefully, I have everything back
> in its proper place. =20
>=20
> Mike, I'm having trouble getting the timer1 function to call
> ShipHandeling() and UpdateSensors().  It will work if I just add those
> two subroutines to the main loop.  The main loop code is as follows:
>=20
> if (timer1 + (1000 / timecompression) < SDL_GetTicks())
>           {
>             timer1 =3D SDL_GetTicks();
>             ShipHandeling();
>             UpdateSensors();
>             // Testing
>             cout << Subs[0].BearingToTarget(Subs[1]) << endl; =20
>           } =20
>=20
> The bearing to the first target seems to be updating, but when you get
> time take a look and see what I'm missing.
>=20
> Also, I've been thinking about the sonar display and think that if we
> call a routine similar to the DisplayWidgets() routine in maim.cpp, we
> will able to "paste" trace bmps, at an (x,y) on the sonarscreen.bmp that
> corresponds to the correct bearing.  I've attached a couple of sonar
> trace bmp's for the sonar that I think will work.  The other bmp that we
> will need is a background or noise bmp.  I think that if we paste the
> trace and noise bmp together with some blending, it might look right. =20
>=20
> Rick
>=20

Re: [LinuxSSN-devel] Re: More Updates

[Michael B. <mic...@ve...>]

On Mon, 2003-04-07 at 22:06, Joe Venzon wrote:
> > I think that if we paste the
> > trace and noise bmp together with some blending, it might look right. =20
> How did the old code do it?  I'm curious why you don't just use the old c=
ode and render the SDL surface to the texture every frame or so.
>=20
> Joe Venzon
>=20

Basically it currently works like this.

Setup three different SDL surfaces, two of these are the waterfall
displays, the third is a scratch surface used for copies.

Step one. Start by plotting 360 (minus the baffle area) background noise
pixels. this is done six times (3 timescales * 2 displays).

Step two. Every 1/5th second plot one pixel per contact on each
timescale on each display applicable display with a slight random
variance to get a nice swath for the trace.

Step three. Every second blit into the scratch surface the contents of
the 0-60 second history window, minus the last line. Turn around and
blit it back to the display surface one line lower, and erase the first
line and fill it backup with background noise.
Every 30 seconds do the same for the 0-30 minute display.
Every 2 minutes do the same for the 0-2 hour display.

Duplicate Step three for the second sonar window.

Divide the times above by what ever timescale we are at.

All this happens even when you are not "in" the sonar station via a
thread. When you are at the sonar station add blitting the sonar screens
too the station.

[LinuxSSN-devel] Re: Linuxssn-devel digest, Vol 1 #31 - 3 msgs

[Rick M. <ri...@sw...>]

>How did the old code do it?  I'm curious why you don't just use the old
>code and render the SDL surface to the texture every frame or so.
 
Hi Joe,

The part of the code in question is located in sonar.cpp in Sonar(bool
center) and in AdvanceSonarDisplay().  

Maybe Mike can correct me if my description is wrong, but part of the
old sonar code in Sonar(bool center) drew pixels directly to an SDL
surface.  So I guess a similar effect in OpenGL would be to use replace
the pixel drawing with a function similar to the following:

void drawDot(GLint x, GLint y, GLfloat red, GLfloat green, GLfloat blue)
// Draw a color dot at (x,y)
{
	glColor3f(red, green, blue);
	glBegin(GL_POINTS);
		glVertex2i(x, y);
	glEnd();
}

My first thought is that it would be slower to draw pixels directly to a
screen, rather than bitmaps.  But I'm new to OpenGl, so my knowledge is
limited. 

The code that advances the sonar screen and make the waterfall effect is
the hard part.  I think it sort of does a cut and paste.  It cuts part
of the screen, moves it down and blits it back.  Is there a way to do
the same thing in OpenGL?  


On Tue, 2003-04-08 at 22:00,
lin...@li... wrote:
> Send Linuxssn-devel mailing list submissions to
> 	lin...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/linuxssn-devel
> or, via email, send a message with subject or body 'help' to
> 	lin...@li...
> 
> You can reach the person managing the list at
> 	lin...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linuxssn-devel digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: More Updates (Rick McDaniel)
>    2. Re: Re: More Updates (Joe Venzon)
>    3. Re: More Updates (MCDANIEL RICKEY D)
> 
> --__--__--
> 
> Message: 1
> From: Rick McDaniel <ri...@sw...>
> To: lin...@li...
> Date: 07 Apr 2003 23:37:55 -0500
> Subject: [LinuxSSN-devel] Re: More Updates
> 
> 
> --=-iR89iIOfxQFgswMn3kIU
> Content-Type: text/plain
> Content-Transfer-Encoding: 7bit
> 
> Posted latest changes to OpenGL code on web site.  This week I'm adding
> all the old classes to the new code.  Hopefully, I have everything back
> in its proper place.  
> 
> Mike, I'm having trouble getting the timer1 function to call
> ShipHandeling() and UpdateSensors().  It will work if I just add those
> two subroutines to the main loop.  The main loop code is as follows:
> 
> if (timer1 + (1000 / timecompression) < SDL_GetTicks())
> 	  {
> 	    timer1 = SDL_GetTicks();
> 	    ShipHandeling();
> 	    UpdateSensors();
> 	    // Testing
> 	    cout << Subs[0].BearingToTarget(Subs[1]) << endl;  
> 	  }  
> 
> The bearing to the first target seems to be updating, but when you get
> time take a look and see what I'm missing.
> 
> Also, I've been thinking about the sonar display and think that if we
> call a routine similar to the DisplayWidgets() routine in maim.cpp, we
> will able to "paste" trace bmps, at an (x,y) on the sonarscreen.bmp that
> corresponds to the correct bearing.  I've attached a couple of sonar
> trace bmp's for the sonar that I think will work.  The other bmp that we
> will need is a background or noise bmp.  I think that if we paste the
> trace and noise bmp together with some blending, it might look right.  
> 
> Rick
> 
> 
> 
> 
> 
> --=-iR89iIOfxQFgswMn3kIU
> Content-Disposition: attachment; filename=sonar1.bmp
> Content-Type: image/bmp; name=sonar1.bmp
> Content-Transfer-Encoding: base64
> 
> Qk02AwAAAAAAADYAAAAoAAAAEAAAABAAAAABABgAAAAAAAADAAASCwAAEgsAAAAAAAAAAAAAAAAA
> AC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8A
> AF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8A
> AI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8A
> AG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8A
> AD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAA
> AAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8A
> AE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8A
> AH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8A
> AH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8A
> AE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8A
> AAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8A
> AD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8A
> AG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8A
> AI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAA
> 
> --=-iR89iIOfxQFgswMn3kIU
> Content-Disposition: attachment; filename=sonar2.bmp
> Content-Type: image/bmp; name=sonar2.bmp
> Content-Transfer-Encoding: base64
> 
> Qk32AAAAAAAAADYAAAAoAAAACAAAAAgAAAABABgAAAAAAMAAAAASCwAAEgsAAAAAAAAAAAAAAB8A
> AD8AAF8AAH8AAH8AAF8AAD8AAB8AAB8AAD8AAF8AAH8AAH8AAF8AAD8AAB8AAB8AAD8AAF8AAH8A
> AH8AAF8AAD8AAB8AAB8AAD8AAF8AAH8AAH8AAF8AAD8AAB8AAB8AAD8AAF8AAH8AAH8AAF8AAD8A
> AB8AAB8AAD8AAF8AAH8AAH8AAF8AAD8AAB8AAB8AAD8AAF8AAH8AAH8AAF8AAD8AAB8AAB8AAD8A
> AF8AAH8AAH8AAF8AAD8AAB8A
> 
> --=-iR89iIOfxQFgswMn3kIU--
> 
> 
> 
> --__--__--
> 
> Message: 2
> Date: Mon, 7 Apr 2003 22:06:50 -0700
> From: Joe Venzon <jo...@ve...>
> Cc: lin...@li...
> Subject: Re: [LinuxSSN-devel] Re: More Updates
> 
> > I think that if we paste the
> > trace and noise bmp together with some blending, it might look right.  
> How did the old code do it?  I'm curious why you don't just use the old code and render the SDL surface to the texture every frame or so.
> 
> Joe Venzon
> 
> 
> --__--__--
> 
> Message: 3
> Date: Tue, 08 Apr 2003 17:32:15 -0500 (CDT)
> From: MCDANIEL RICKEY D <MC...@hs...>
> To: lin...@li...
> Cc: ri...@sw...
> Subject: [LinuxSSN-devel] Re: More Updates
> 
> 
> --Boundary_(ID_O/t1bzL95e6kJkQU66nIjg)
> Content-type: text/plain
> Content-transfer-encoding: 7BIT
> 
> Posted latest changes to OpenGL code on web site.  This week I'm adding
> all the old classes to the new code.  Hopefully, I have everything back
> in its proper place.  
> 
> Mike, I'm having trouble getting the timer1 function to call
> ShipHandeling() and UpdateSensors().  It will work if I just add those
> two subroutines to the main loop.  The main loop code is as follows:
> 
> if (timer1 + (1000 / timecompression) < SDL_GetTicks())
>           {
>             timer1 = SDL_GetTicks();
>             ShipHandeling();
>             UpdateSensors();
>             // Testing
>             cout << Subs[0].BearingToTarget(Subs[1]) << endl;  
>           }  
> 
> The bearing to the first target seems to be updating, but when you get
> time take a look and see what I'm missing.
> 
> Also, I've been thinking about the sonar display and think that if we
> call a routine similar to the DisplayWidgets() routine in maim.cpp, we
> will able to "paste" trace bmps, at an (x,y) on the sonarscreen.bmp that
> corresponds to the correct bearing.  I've attached a couple of sonar
> trace bmp's for the sonar that I think will work.  The other bmp that we
> will need is a background or noise bmp.  I think that if we paste the
> trace and noise bmp together with some blending, it might look right.  
> 
> Rick
> 
> 
> --Boundary_(ID_O/t1bzL95e6kJkQU66nIjg)
> Content-type: image/bmp; name=sonar1.bmp
> Content-transfer-encoding: base64
> Content-disposition: attachment; filename=sonar1.bmp
> x-cp-file-size: 822
> 
> Qk02AwAAAAAAADYAAAAoAAAAEAAAABAAAAABABgAAAAAAAADAAASCwAAEgsAAAAAAAAAAAAAAAAA
> AC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8A
> AF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8A
> AI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8A
> AG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8A
> AD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAA
> AAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8A
> AE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8A
> AH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8A
> AH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8A
> AE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8A
> AAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8A
> AD8AAE8AAF8AAG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8A
> AG8AAH8AAI8AAI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAAAAAAAC8AAD8AAE8AAF8AAG8AAH8AAI8A
> AI8AAH8AAG8AAF8AAE8AAD8AAC8AAAAA
> 
> --Boundary_(ID_O/t1bzL95e6kJkQU66nIjg)
> Content-type: image/bmp; name=sonar2.bmp
> Content-transfer-encoding: base64
> Content-disposition: attachment; filename=sonar2.bmp
> x-cp-file-size: 246
> 
> Qk32AAAAAAAAADYAAAAoAAAACAAAAAgAAAABABgAAAAAAMAAAAASCwAAEgsAAAAAAAAAAAAAAB8A
> AD8AAF8AAH8AAH8AAF8AAD8AAB8AAB8AAD8AAF8AAH8AAH8AAF8AAD8AAB8AAB8AAD8AAF8AAH8A
> AH8AAF8AAD8AAB8AAB8AAD8AAF8AAH8AAH8AAF8AAD8AAB8AAB8AAD8AAF8AAH8AAH8AAF8AAD8A
> AB8AAB8AAD8AAF8AAH8AAH8AAF8AAD8AAB8AAB8AAD8AAF8AAH8AAH8AAF8AAD8AAB8AAB8AAD8A
> AF8AAH8AAH8AAF8AAD8AAB8A
> 
> --Boundary_(ID_O/t1bzL95e6kJkQU66nIjg)--
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Linuxssn-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxssn-devel
> 
> 
> End of Linuxssn-devel Digest

[LinuxSSN-devel] Re: More Updates

[MCDANIEL R. D <MC...@hs...>]

Posted latest changes to OpenGL code on web site.  This week I'm adding
all the old classes to the new code.  Hopefully, I have everything back
in its proper place.  

Mike, I'm having trouble getting the timer1 function to call
ShipHandeling() and UpdateSensors().  It will work if I just add those
two subroutines to the main loop.  The main loop code is as follows:

if (timer1 + (1000 / timecompression) < SDL_GetTicks())
          {
            timer1 = SDL_GetTicks();
            ShipHandeling();
            UpdateSensors();
            // Testing
            cout << Subs[0].BearingToTarget(Subs[1]) << endl;  
          }  

The bearing to the first target seems to be updating, but when you get
time take a look and see what I'm missing.

Also, I've been thinking about the sonar display and think that if we
call a routine similar to the DisplayWidgets() routine in maim.cpp, we
will able to "paste" trace bmps, at an (x,y) on the sonarscreen.bmp that
corresponds to the correct bearing.  I've attached a couple of sonar
trace bmp's for the sonar that I think will work.  The other bmp that we
will need is a background or noise bmp.  I think that if we paste the
trace and noise bmp together with some blending, it might look right.  

Rick

Re: [LinuxSSN-devel] Re: More Updates

[Joe V. <jo...@ve...>]

> I think that if we paste the
> trace and noise bmp together with some blending, it might look right.  
How did the old code do it?  I'm curious why you don't just use the old code and render the SDL surface to the texture every frame or so.

Joe Venzon

[LinuxSSN-devel] Re: More Updates

[Rick M. <ri...@sw...>]

Posted latest changes to OpenGL code on web site.  This week I'm adding
all the old classes to the new code.  Hopefully, I have everything back
in its proper place.  

Mike, I'm having trouble getting the timer1 function to call
ShipHandeling() and UpdateSensors().  It will work if I just add those
two subroutines to the main loop.  The main loop code is as follows:

if (timer1 + (1000 / timecompression) < SDL_GetTicks())
	  {
	    timer1 = SDL_GetTicks();
	    ShipHandeling();
	    UpdateSensors();
	    // Testing
	    cout << Subs[0].BearingToTarget(Subs[1]) << endl;  
	  }  

The bearing to the first target seems to be updating, but when you get
time take a look and see what I'm missing.

Also, I've been thinking about the sonar display and think that if we
call a routine similar to the DisplayWidgets() routine in maim.cpp, we
will able to "paste" trace bmps, at an (x,y) on the sonarscreen.bmp that
corresponds to the correct bearing.  I've attached a couple of sonar
trace bmp's for the sonar that I think will work.  The other bmp that we
will need is a background or noise bmp.  I think that if we paste the
trace and noise bmp together with some blending, it might look right.  

Rick

[LinuxSSN-devel] Updates to OpenGL Code

[Rick M. <ri...@sw...>]

Posted latest changes to OpenGL code on web site.  

Radar code changes: More clean up the radar class code.  I changed the
sweep color to orange to match the display.  Today, I had a thought that
it would be useful to add a few icons to the left and right of the radar
screen.  The icons could be a pencil, eraser, etc to mark on the radar
screen and plot contacts.  Its really easy to get Closest Point of
Approach (CPA) data for targets.  

Periscope class:  Implementing blending and masking so that we can see
water/targets through panel.  Right/Left arrow to swivel scope. 

Re: [LinuxSSN-devel] Torpedo Blender Tutorial

[Michael B. <mic...@ve...>]

On Sat, 2003-03-29 at 13:04, Joe Venzon wrote:

> Hmm, I'd really like to be using Blender for my modelling because it's free and all that, but does anyone know how to use a 2d image for the viewport background?  When modelling submarines and stuff, I often use schematics I find on the internet to get the shape correct, and I never found a way to do that in Blender.  Also, I had trouble finding a good tutorial on texturing.  Anyway, if Blender exports and ascii format it'd probably be really easy to write a file reader for my engine.
> 
> Joe
> 
> 

Please excuse the HTML.

place the mouse cursor in the 3d editing window that you wish to add the
background picture to. Press SHIFT-F7.

A button group will appear.



 Click on "BackGround Pic". A couple more buttons will appear. Click on
the "LOAD" button.. it is limited i believe to jpg and tga files.



Then change this icon  back to  and your set.

Re: [LinuxSSN-devel] Re: Response to Mike

[Joe V. <jo...@ve...>]

> The idea of using a vertex array and color array to store the data seems
> like a good idea.  Also, modifying the color array as the signal changes
> seems like the fastest way to go. 

What do you mean?  I'm not really sure how you'd use a vertex array and color array to do that, unless you mean by having some super high res vertex grid... but I don't think that's necessary, because with OpenGL you can actually copy an SDL surface onto a texture every frame and it's not much of a slowdown... so I figure if the current code already renders the output to an SDL surface we can just copy that surface onto the texture of a polygon that's sitting there.  (by calling glTexImage2d every frame, I think)

Joe Venzon


On Sun, 23 Mar 2003 20:07:04 -0600
Rick McDaniel <ri...@sw...> wrote:

> 
> > I've looked over your code, and it looks workable. I've been thinking
> > about the waterfall display (while skimming my redbook PDF file) and was
> > thinking I could use vertex and color arrays to hold the data. Actually
> > the vertex array would be something I could setup and leave unmodified
> > and just work on the color array. Let me know if you think this is
> > reasonable.=20
> > 
> > Mike
> 
> I made some changes today to the code (working on sonar widgets), so
> I'll upload it to my website.  Also, if you or Joe see any way to do
> things better, lets do it.
> 
> The idea of using a vertex array and color array to store the data seems
> like a good idea.  Also, modifying the color array as the signal changes
> seems like the fastest way to go. 
> 
> > I've been messing around with a Submarine and Screw model for a bit.
> > I've included DXF files. (The closest thing Blender will export that I
> > thought you guys could use).
> 
> Thanks, I'll take a look at it.  We can't have enough models.  
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Linuxssn-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxssn-devel

Re: [LinuxSSN-devel] Torpedo Blender Tutorial

[Joe V. <jo...@ve...>]

Hmm, I'd really like to be using Blender for my modelling because it's free and all that, but does anyone know how to use a 2d image for the viewport background?  When modelling submarines and stuff, I often use schematics I find on the internet to get the shape correct, and I never found a way to do that in Blender.  Also, I had trouble finding a good tutorial on texturing.  Anyway, if Blender exports and ascii format it'd probably be really easy to write a file reader for my engine.

Joe


On 28 Mar 2003 19:49:28 -0600
Rick McDaniel <ri...@sw...> wrote:

> Found this googling the net:
> http://www.digitalproducer.com/pages/torpedo_tutorial_for_blender.htm
> 
> The tutorial shows how to build a torpedo that emits particles, spins
> using blender.  At the end of the tutorial, he makes a mpg showing the
> torpedo moving through the water.  Good Stuff.
> 
> Rick  
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:
> The Definitive IT and Networking Event. Be There!
> NetWorld+Interop Las Vegas 2003 -- Register today!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
> _______________________________________________
> Linuxssn-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxssn-devel

[LinuxSSN-devel] Masking

[Rick M. <ri...@sw...>]

I've spent a few days working on masking for the Periscope.  After days
of pounding on the keyboard, I've made a lot of progress.  I've attached
a demo file that shows the progress.  The good news is that we can now
see ocean through the periscope.  

The demo program works as follows:  left and right arrow to rotate the
scope view, up arrow to magnify, space bar for night vision.

Its not much of a ocean, but its a start. Maybe we need to add a target
and little fog too.  :-)


Rick

[LinuxSSN-devel] Torpedo Blender Tutorial

[Rick M. <ri...@sw...>]

Found this googling the net:
http://www.digitalproducer.com/pages/torpedo_tutorial_for_blender.htm

The tutorial shows how to build a torpedo that emits particles, spins
using blender.  At the end of the tutorial, he makes a mpg showing the
torpedo moving through the water.  Good Stuff.

Rick  

Re: [LinuxSSN-devel] 688 and screw model

[Bernhard K. <ber...@gm...>]

Hi,

On Sun, 23 Mar 2003, Michael Bridak wrote:

> I've been messing around with a Submarine and Screw model for a bit.
> I've included DXF files. (The closest thing Blender will export that I
> thought you guys could use).

I've just typed "submarine" into the search box at libsdl.org and found:

http://www.libsdl.org/games.php?match_id=1169

submarine - OpenGL demo with submarines
http://kvik.sh.cvut.cz/~fidlej/eng_c.html
Contact: i.danihelka sh.cvut.cz

License: GNU GPL

I compiled the tarball and worked, looks nice ;-)

Bernd

[LinuxSSN-devel] Radar Sweep

[Rick M. <ri...@sw...>]

More updates to the radar code.  Finally, got the sweep effect working
again.

Rick

[LinuxSSN-devel] Re: Response to Mike

[Rick M. <ri...@sw...>]

> I've looked over your code, and it looks workable. I've been thinking
> about the waterfall display (while skimming my redbook PDF file) and was
> thinking I could use vertex and color arrays to hold the data. Actually
> the vertex array would be something I could setup and leave unmodified
> and just work on the color array. Let me know if you think this is
> reasonable.=20
> 
> Mike

I made some changes today to the code (working on sonar widgets), so
I'll upload it to my website.  Also, if you or Joe see any way to do
things better, lets do it.

The idea of using a vertex array and color array to store the data seems
like a good idea.  Also, modifying the color array as the signal changes
seems like the fastest way to go. 

> I've been messing around with a Submarine and Screw model for a bit.
> I've included DXF files. (The closest thing Blender will export that I
> thought you guys could use).

Thanks, I'll take a look at it.  We can't have enough models.  

[LinuxSSN-devel] 688 and screw model

[Michael B. <mic...@ve...>]

I've been messing around with a Submarine and Screw model for a bit.
I've included DXF files. (The closest thing Blender will export that I
thought you guys could use).

Re: [LinuxSSN-devel] New Web Site

[Michael B. <mic...@ve...>]

On Fri, 2003-03-21 at 19:48, Rick McDaniel wrote:
> Hi Guys,
>=20
> I got the radar widget working.  Also, I started a new web site on my
> linuxbox at work:  http://198.16.19.65/ for our project.
>=20
> Rick
>=20

I've looked over your code, and it looks workable. I've been thinking
about the waterfall display (while skimming my redbook PDF file) and was
thinking I could use vertex and color arrays to hold the data. Actually
the vertex array would be something I could setup and leave unmodified
and just work on the color array. Let me know if you think this is
reasonable.=20

Mike

[LinuxSSN-devel] New Web Site

[Rick M. <ri...@sw...>]

Hi Guys,

I got the radar widget working.  Also, I started a new web site on my
linuxbox at work:  http://198.16.19.65/ for our project.

Rick

[LinuxSSN-devel] Weekend Work

[Rick M. <ri...@sw...>]

I'll get started this weekend on striping out main.cpp and adding in new
stuff.   

>Well, I'm probably the least familiar with the code as it currently is,
>but perhaps you could modify the main.cpp to use OpenGL, and then we
>could just take it from there... I might make a class to make the
>loading and display of 2D graphics a bit easier, for example.  Or I
>could probably convert over one of the other stations... or I could
>work on implementing some aspect of the code I've got in that ssn3d
>bundle.

[LinuxSSN-devel] Re: OpenGL Branch

[Joe V. <jo...@ve...>]

Ah, you should take a look at my font.cpp file in the ssn3d bundle I sent you... I switch to ortho mode to draw the text... gluOrtho2d is just calling glOrtho with near and far set to -1 and 1, respectively, which isn't really much of a reason to use it instead of glOrtho (just pass -1 and 1 into it!) because glut sometimes isn't distributed along with OpenGL (like with windows) and since we're already using SDL for our window creating and event handling, there's no real reason to add GLUT.  That's my two cents anyway....

Well, I'm probably the least familiar with the code as it currently is, but perhaps you could modify the main.cpp to use OpenGL, and then we could just take it from there... I might make a class to make the loading and display of 2D graphics a bit easier, for example.  Or I could probably convert over one of the other stations... or I could work on implementing some aspect of the code I've got in that ssn3d bundle.

Joe Venzon


On Wed, 5 Mar 2003 21:04:47 -0600 (CST)
MCDANIEL RICKEY D <MC...@hs...> wrote:

> Yes, modifying the OpenGL branch main.cpp file to just display the 
> radar screen sounds like a good plan.  Once we get that done, adding 
> the other screens shouldn't be that diffcult.  
> 
> For the sonar screen, I might have to get Mike to explain how the sonar 
> display does its plotting.  The other screens aren't as difficult.
> 
> As for the radar code, if you, Mike or Q see a better way to do things 
> lets do it.  For example, I was kind of wondering in the init.cpp code 
> that I should have used gluOrtho2D instead of glOrtho since the only 
> place where 3D is really called for is in the periscope view or maybe 
> the map view for displaying DEM.  So when we want to use the periscope 
> we can change our projection mode from 2D to 3D.  
> 
> I have time this weekend too.  So, we should all decide on what parts 
> we are willing to tackle.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Linuxssn-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxssn-devel

[LinuxSSN-devel] Re: OpenGL Branch

[MCDANIEL R. D <MC...@hs...>]

Yes, modifying the OpenGL branch main.cpp file to just display the 
radar screen sounds like a good plan.  Once we get that done, adding 
the other screens shouldn't be that diffcult.  

For the sonar screen, I might have to get Mike to explain how the sonar 
display does its plotting.  The other screens aren't as difficult.

As for the radar code, if you, Mike or Q see a better way to do things 
lets do it.  For example, I was kind of wondering in the init.cpp code 
that I should have used gluOrtho2D instead of glOrtho since the only 
place where 3D is really called for is in the periscope view or maybe 
the map view for displaying DEM.  So when we want to use the periscope 
we can change our projection mode from 2D to 3D.  

I have time this weekend too.  So, we should all decide on what parts 
we are willing to tackle.

Re: [LinuxSSN-devel] OpenGL Branch

[Joe V. <jo...@ve...>]

Thanks!  I took a more in-depth look at your opengl radar code, Rick, and it looks like it's fairly finished code (except changing the jpeg stuff to the easy-to-load bmp stuff) and is ready to get put into the opengl branch of the CVS.  Probably the best way to do that would be to modify the main.cpp from the opengl branch to use just the opengl radar screen and all of your other modified code, and then work convert all of the other classes after that... and then after all that's working and back up to speed, possibly adding some of the bells and whistles from the code I sent you.  Hopefully I'll get some time this weekend to work on it a bit.

Joe Venzon


On Tue, 04 Mar 2003 22:57:40 -0600
Rick McDaniel <ri...@sw...> wrote:

> Joe,
> 
> The ssn3d code looks really good.  Lots of good stuff already built in.
> 
> Rick

[LinuxSSN-devel] OpenGL Branch

[Rick M. <ri...@sw...>]

Joe,

The ssn3d code looks really good.  Lots of good stuff already built in.

Rick