www.jpct.net

jPCT - a 3d engine for Java => Projects => Topic started by: EgonOlsen on April 10, 2008, 11:08:22 pm

Title: Finally...
Post by: EgonOlsen on April 10, 2008, 11:08:22 pm
...i managed to start my new game project, a multiplayer game inspired by Bomberman (http://en.wikipedia.org/wiki/Bomberman (http://en.wikipedia.org/wiki/Bomberman)). Currently, the code is largely based on the "advanced example" available in the download section with some fixes and additions. What works already is the network support, you can start a server, login, logout, shoot other players, place bombs, blow them up, get blown up...
The art is all placeholder art. It doesn't even have a name ATM. Anyway, this is how is looks right now:

(http://www.jpct.net/img/proj/wip/wip2.jpg)

(http://www.jpct.net/img/proj/wip/wip1.jpg)
Title: Re: Finally...
Post by: Melssj5 on April 10, 2008, 11:49:42 pm
It reminds me to paradroidz for the escene and the balls!
Title: Re: Finally...
Post by: fireside on April 11, 2008, 04:37:10 am
Network support sounds cool.
Title: Re: Finally...
Post by: EgonOlsen on April 11, 2008, 09:27:26 am
It reminds me to paradroidz for the escene and the balls!
As said, it's all placeholder stuff ATM. Albeit the level structure will be based on ASCII-files again, to ease level editing. I simply don't have the time nor talent to do this in Blender or where ever. Plus it enables other people to create their own levels with a simple text editor.
Title: Re: Finally...
Post by: Jonas on April 11, 2008, 10:48:50 am
Cool stuff, I love bomberman!!!

I guess the levels will be simple enough that ASCII works well.

Defnitly needs stuff added that can be blown up ;D
Title: Re: Finally...
Post by: JavaMan on April 11, 2008, 01:51:19 pm
Awesome! Those figures are really cool with their pumpkin heads. Well, thats what they look like to me.
Title: Re: Finally...
Post by: EgonOlsen on April 11, 2008, 04:11:46 pm
Awesome! Those figures are really cool with their pumpkin heads. Well, thats what they look like to me.
It's some Quake2-model that i'm using as a placeholder. I haven't decided yet which way to go with the models. Maybe i'll reuse the ones from Paradroidz or simply put in some MD2s and allow people to use their own if they like. This particular model is a "snork": http://en.wikipedia.org/wiki/Snorks (http://en.wikipedia.org/wiki/Snorks)
Title: Re: Finally...
Post by: EgonOlsen on April 12, 2008, 08:05:56 pm
Defnitly needs stuff added that can be blown up ;D
I had to make the network stuff stable enough to handle this first  ;D:

(http://www.jpct.net/img/proj/wip/wip3.jpg)
Title: Re: Finally...
Post by: JavaMan on April 14, 2008, 09:53:25 pm
Awesome! Those figures are really cool with their pumpkin heads. Well, thats what they look like to me.
It's some Quake2-model that i'm using as a placeholder. I haven't decided yet which way to go with the models. Maybe i'll reuse the ones from Paradroidz or simply put in some MD2s and allow people to use their own if they like. This particular model is a "snork": http://en.wikipedia.org/wiki/Snorks (http://en.wikipedia.org/wiki/Snorks)

That would be nice to able to put in a personal model. I read about snorks; never heard about them but thats a funny name. IMHO...
Title: Re: Finally...
Post by: Hrolf on April 15, 2008, 01:56:16 am
Tsk! Does no-one know what snorks are? What do they teach in schools nowadays? *mutter, mumble*

Created by the wonderful Finnish authoress Tove Jansson in 1946: http://www.geocities.com/lindashippert/moomin/moominnf.html#extended (http://www.geocities.com/lindashippert/moomin/moominnf.html#extended)

(game looks good BTW :))
Title: Re: Finally...
Post by: paulscode on April 15, 2008, 02:28:11 am
Tsk! Does no-one know what snorks are? What do they teach in schools nowadays? *mutter, mumble*

Created by the wonderful Finnish authoress Tove Jansson in 1946: http://www.geocities.com/lindashippert/moomin/moominnf.html#extended (http://www.geocities.com/lindashippert/moomin/moominnf.html#extended)

(game looks good BTW :))

 :D Ahh, yes.  The Snorks.  Short lived cartoon created by Hanna-Barbera due to the success of the Smurfs. The Snorks had a snorkle (a breathing tube) protruding from the tops of their heads, which made "Snork" sounds when they got excited.  They lived in "Snorkland" (as original sounding as Smurf Village) led by Allstar Seaworthy.
Title: Re: Finally...
Post by: JavaMan on April 15, 2008, 02:49:57 am
Tsk! Does no-one know what snorks are? What do they teach in schools nowadays? *mutter, mumble*


What do they teach in school? Well, in highschool most what I've learned I'll never use.  >:( >:( (IMHO)

Title: Re: Finally...
Post by: fireside on April 15, 2008, 03:29:48 am
Quote
Well, in highschool most what I've learned I'll never use.

Yeah, and what people need, they don't teach, like financial sense.  They come out and go into debt up to their ears and never come out, not to mention congress or the Presidency, which also have no idea how to balance a budget.  Maybe no one in America knows how to balance a budget.  I'm not really sure anymore.
Title: Re: Finally...
Post by: paulscode on April 15, 2008, 03:40:30 am
not to mention congress or the Presidency, which also have no idea how to balance a budget.  Maybe no one in America knows how to balance a budget.  I'm not really sure anymore.
I have the solution!  Kidnap congress and the Presidency and replace them with simulated versions rendered in jPCT!! ;D
Title: Re: Finally...
Post by: fireside on April 15, 2008, 04:20:08 am
LOL   I think that might work. I bet hardly anyone would notice the difference.  They look like mannequins, anyway!

By the way, Egon, if you need some low poly models and you have some ideas, I do that kind of thing.  Only thing is I have to export 3ds key frames in Blender.  The mouse in Labyrinth Z is one example and I can post some more if you want to see some of the stuff I do.  I don't offer very often, but being you made the engine, I figure it's worth it.
Title: Re: Finally...
Post by: JavaMan on April 15, 2008, 02:12:12 pm
not to mention congress or the Presidency, which also have no idea how to balance a budget.  Maybe no one in America knows how to balance a budget.  I'm not really sure anymore.
I have the solution!  Kidnap congress and the Presidency and replace them with simulated versions rendered in jPCT!! ;D

That would be great. Let us program the simulation, and the country will run perfectly! Since, our fine leaders continue to put money into who knows what.
Title: Re: Finally...
Post by: EgonOlsen on April 15, 2008, 08:52:22 pm
By the way, Egon, if you need some low poly models and you have some ideas, I do that kind of thing.  Only thing is I have to export 3ds key frames in Blender.  The mouse in Labyrinth Z is one example and I can post some more if you want to see some of the stuff I do.  I don't offer very often, but being you made the engine, I figure it's worth it.
I think i'll go with the snorks for now and maybe add an option to load custom md2-files. However, a crate would be cool. Basically, just a simple box but with some nice textures and an animation if it gets destroyed by an explosion. So that the crate collapses or something. It shouldn't look like an explosion of its own but it should somehow visualize that the crate has been destroyed and it should look reasonable to remove the crate entirely after the animation has been played once. That would be cool... ;D
Title: Re: Finally...
Post by: fireside on April 15, 2008, 09:31:44 pm
O.K.  The animation will be fun, I'll see what I can do about a texture.  I'll try to do something that fits with your screen shot.  Would the explosion come from the inside or the outside?  I'm sort of picturing a more or less intact bottom of the crate with some jagged edges for a final.  Would the explosion be particle or something, so something I wouldn't be concerned with?
Title: Re: Finally...
Post by: EgonOlsen on April 15, 2008, 09:41:33 pm
The explosion comes from the outside and doesn't have to be part of the animation. Just the destruction of the crate. The crate has to be quite low poly, because there will be many of them in the level.
Title: Re: Finally...
Post by: raft on April 16, 2008, 12:30:39 am
i love BomberMan too, can't wait to see the adapted version ;)
Title: Re: Finally...
Post by: fireside on April 16, 2008, 12:33:49 am
OK.  The way I would do it is to have a crate, this could have edges or not, up to you.  Without edges it could have as few as eight vertices and use textured edges, etc.  Then during an explosion it would be replaced by a somewhat higher poly model which would fly off into little pieces and then be deleted at the end of the animation so the space was clear where it was.  The pieces would just about have to fly off in all directions, but they would need to be three dimensional or if they turned a certain way they would disappear, so I might need about 200 vertices for that.  You could make it so one side fit a texture, that way you could change textures for variety. You could also have the pieces only fly off in three directions if you knew the placement of the bomb from the box.
Title: Re: Finally...
Post by: EgonOlsen on April 16, 2008, 08:01:07 am
Replacing the model during explosion with a detailed one and making the pieces fly away from the impact side sounds great.... ;D
Title: Re: Finally...
Post by: fireside on April 17, 2008, 03:02:20 pm
Would it be better to have the pieces be separate objects in the 3ds file for the animation, or one object?
Title: Re: Finally...
Post by: EgonOlsen on April 17, 2008, 04:20:57 pm
One would be better. I'll merge them anyway.
Title: Re: Finally...
Post by: EgonOlsen on April 18, 2008, 12:07:41 am
Dummy crates are in...with no animation but you can already destroy them with the bombs.

(http://www.jpct.net/img/proj/wip/wip4.jpg)
Title: Re: Finally...
Post by: fireside on April 18, 2008, 03:03:22 am
O.K.  I have no idea how this is going to work out.  I'm going to do about six key frames with texture uv's covering one side of the crate.  If I moved too far with my mouse animation it turned into a mess so I'm just completely guessing and I'm not sure what happens with location either.  I'll zip them and leave the address.  If it doesn't work out, I got some experience anyway.  There won't be a texture, just uv coordinates.
Title: Re: Finally...
Post by: fireside on April 18, 2008, 03:47:12 am
You can get it here. (http://dodownload.filefront.com/10028128//4e21a220ff088588b7c6040cd6ef2a486885c1f77b91b0261cfe1c709bd36ab1b7c5fa52706026b7).
Title: Re: Finally...
Post by: EgonOlsen on April 18, 2008, 01:52:21 pm
Cool, thanks. I hope i manage it somehow to try it this weekend.
Title: Re: Finally...
Post by: EgonOlsen on April 19, 2008, 01:47:35 pm
The download link doesn't seem to work.... ???
Title: Re: Finally...
Post by: fireside on April 19, 2008, 08:06:52 pm
Oh, I thought you had it already so I deleted it.  I'll see if I can get it back up.

edit:

You can get it here. (http://dodownload.filefront.com/10038316//4e21a220ff088588b7c6040cd6ef2a486885c1f77b91b0261cfe1c709bd36ab1b7c5fa52706026b7)
Title: Re: Finally...
Post by: EgonOlsen on April 20, 2008, 12:14:51 am
Thanks. Now i have downloaded it, so you can delete it again.
Title: Re: Finally...
Post by: EgonOlsen on April 23, 2008, 04:50:26 pm
I haven't had the time to try the animation yet. I'm still working on the server browser to set up games, define map rotation...that kind of stuff. It's really annoying. I would rather continue with the actual game, but i think that this has to be done first.
Title: Re: Finally...
Post by: EgonOlsen on April 23, 2008, 08:35:09 pm
The game is now using raft's GLFont class for doing the text blitting (http://www.jpct.net/forum2/index.php/topic,1074.0.html (http://www.jpct.net/forum2/index.php/topic,1074.0.html)). Looks much better than the VGA font that i was using before.

(http://www.jpct.net/img/proj/wip/wip5.jpg)
Title: Re: Finally...
Post by: fireside on April 23, 2008, 10:05:06 pm
Looks great!  I'm all for keeping the library as small as possible for applets and so on, but that code would be a really nice addition if raf was willing to donate it.
Title: Re: Finally...
Post by: raft on April 24, 2008, 12:51:54 pm
Looks great!  I'm all for keeping the library as small as possible for applets and so on, but that code would be a really nice addition if raf was willing to donate it.
you can anything with it  ;)
Title: Re: Finally...
Post by: EgonOlsen on May 06, 2008, 07:55:03 pm
I haven't had the time to try the animation yet...
Now i've added the animation. I skipped the last frame, because it somehow looked strange when using it plus i tweaked the translation of the object while playing the animation to compensate for the shifting in the keyframes, which was a bit too heavy to look good IMHO. But now it looks pretty good. Thanks again for doing the models, fireside. I really appreciate it.
Title: Re: Finally...
Post by: fireside on May 06, 2008, 10:27:14 pm
No problem, glad you could use them.
Title: Re: Finally...
Post by: EgonOlsen on May 13, 2008, 09:33:36 pm
Here's a small video that shows how the game looks like ATM. Gameplay itself is still rather limited and the video doesn't even show it. Anyway: *download removed*
Title: Re: Finally...
Post by: Jonas on May 13, 2008, 09:59:06 pm
hey thats looking quite good alrdy :).

How are you handling collision on the server(to define which boxes explode)? some kind of headless jpct mode?
Title: Re: Finally...
Post by: EgonOlsen on May 13, 2008, 10:08:59 pm
How are you handling collision on the server(to define which boxes explode)? some kind of headless jpct mode?
Collision is detected on the client, which sends an event to the server. The server verifies, if this collision can actually take place (a very rough distance check ATM). Then, the server sends an event to all clients (including the client which triggered the event at first) to inform them about the collision. The clients then start to play the animation or whatever.
This approach violates the "never trust the client" principle, but i think it's a reasonable approach for that kind of game.
Title: Re: Finally...
Post by: fireside on May 14, 2008, 03:14:44 pm
Pretty cool. Looking at it, though, I should have made the pieces continue out and up instead of caving down.
Title: Re: Finally...
Post by: Melssj5 on May 14, 2008, 03:44:51 pm
looks good!
Title: Re: Finally...
Post by: EgonOlsen on May 17, 2008, 08:26:45 pm
Collectable items are in:

(http://www.jpct.net/img/proj/wip/wip6.jpg)
Title: Re: Finally...
Post by: EgonOlsen on May 21, 2008, 07:33:13 pm
The model has been replaced with another one and zooming via the mouse wheel has been added. I just have to ask the author of that one for permission to use the model in the game. Here's a shot of two game instances running:

(http://www.jpct.net/img/proj/wip/wip7.jpg)

And another shoot:

(http://www.jpct.net/img/proj/wip/wip8.jpg)
Title: Re: Finally...
Post by: Melssj5 on May 21, 2008, 10:54:43 pm
Really great!
Title: Re: Finally...
Post by: JavaMan on May 23, 2008, 10:02:38 pm
Sweet. Awesome looking characters!

Just real quick, how did you get the fire exploding from the box?
Title: Re: Finally...
Post by: EgonOlsen on May 23, 2008, 11:33:56 pm
The bombs explode, not the boxes...but anyway: It's a texture with 16 explosions in different stages (from small to big) that i'm using to texture billboarded planes that move away from the center of the bomb as it explodes. The center itself is a larger plane that uses the same texture. I'm constantly changing texture coordinates for all planes to make each of them grow and go back to a small fire ball again.
Title: Re: Finally...
Post by: paulscode on May 24, 2008, 02:02:49 am
Your quote from the Melssj5's Flier Match project gave me a thought:

... i'm already transfering an event to the clients to inform them about sound type and location. I'm just not playing any sound right now.

It sounds like for this situation, it would be useful to have a method that creates a temporary sound source at a specified 3D location, which automatically deletes itself from memory when it is finished playing.  I thought I would add this capability into my sound library.

I just thought I would get your feedback on the idea before I add it to the library, because I think your concept of sending an event with a sound type and location is likely to be the way a lot of people will want to handle 3D sounds.  I was thinking I would make two different methods for creating temporary sources.  One method would play the source at the specified point from start to end (quick and easy way to play a short sounds, but might not be good for lengthy sounds).  In the second method, you would pass an Object3D as an arguement.  The source would bind itself to the Object3D (follow its position) until the sound finished playing.

Do you have any ideas or requirements from the sound library, specifically for your game?
Title: Re: Finally...
Post by: JavaMan on May 25, 2008, 03:31:00 am
The bombs explode, not the boxes...but anyway: It's a texture with 16 explosions in different stages (from small to big) that i'm using to texture billboarded planes that move away from the center of the bomb as it explodes. The center itself is a larger plane that uses the same texture. I'm constantly changing texture coordinates for all planes to make each of them grow and go back to a small fire ball again.

Thanks for the explanation. I've wondered what billboarding is, this is a good use for it.

Jman
Title: Re: Finally...
Post by: EgonOlsen on May 25, 2008, 10:02:39 am
It sounds like for this situation, it would be useful to have a method that creates a temporary sound source at a specified 3D location, which automatically deletes itself from memory when it is finished playing.  I thought I would add this capability into my sound library.
Sound expensive to me...why do you have to delete the sournd from memory after playing? I haven't used 3D sound myself, but the simple sound stuff using OpenAL that i wrote for Paradroidz doesn't do this. It gets itself some channels, loads the sounds and plays it once on demand. That would be what i have in mind for Bomberman clone too. I need to place the sound source, but it doesn't have to move. It's sufficient if it stays where it started IMHO....at least for the sounds that i have in mind. I don't think that i'll add any ambient sounds. However, having the option would be nice.

Anyway, here are the sources for the Para-sound-stuff to show what i'm talking about in the above:

The Manager:
Code: [Select]
package naroth.sound;

import java.util.*;

import com.threed.jpct.*;

public class SoundManager {

   private Map sounds=null;
   private String lastName=null;
   private Sound lastSound=null;
   private boolean mute=false;

   public void setMute(boolean mute) {
      this.mute=mute;
   }

   public void disableSound(String name) {
      if (mute) {return;}
      Sound s=getSound(name);
      s.setMute(true);
   }

   public void enableSound(String name) {
     if (mute) {return;}
     Sound s=getSound(name);
     s.setMute(false);
  }


   public void addSound(String name, Sound sound) {
      if (!sounds.containsKey(name)) {
         sounds.put(name, sound);
      }
   }

   public SoundManager() {
      sounds=new HashMap();
   }

   public void playIfStopped(String name) {
      if (mute) {return;}
      Sound s=getSound(name);
      if (!s.isRunning()) {
         s.play();
      }
   }

   public void play(String name) {
      if (mute) {return;}
      getSound(name).play();
   }

   public void stop(String name) {
      if (mute) {return;}
      getSound(name).stop();
   }

   public boolean isRunning(String name) {
      if (mute) {return false;}
      return getSound(name).isRunning();
   }

   public void endLoop(String name) {
      if (mute) {return;}
      getSound(name).endLoop();
   }

   public void loop(String name) {
      if (mute) {return;}
      getSound(name).loop();
   }

   public void destroy() {
      Collection c=sounds.values();
      for (Iterator itty=c.iterator(); itty.hasNext();) {
         Sound s=(Sound) itty.next();
         s.destroy();
      }
      Logger.log("SoundManager destroyed!", Logger.MESSAGE);
      sounds=new HashMap();
   }

   private Sound getSound(String name) {
      if (name.equals(lastName)) {
         return lastSound;
      }
      Sound sound=(Sound) sounds.get(name);
      if (sound==null) {
         Logger.log("Sound with this name doesn't exists!", Logger.ERROR);
      }
      lastName=name;
      lastSound=sound;
      return sound;
   }

}


The interface:
Code: [Select]
package naroth.sound;

public interface Sound {

   boolean playedFine();
   boolean isRunning();
   void stop();
   void play();
   void endLoop();
   void loop();
   void destroy();
   void setMute(boolean is);
}

The OpenAL implementation:
Code: [Select]
package naroth.sound;

import java.io.*;
import java.nio.*;
import javax.sound.sampled.*;

import org.lwjgl.*;
import org.lwjgl.openal.*;
import com.threed.jpct.*;


public class OpenALSound implements Sound{

   private int buffer=-1;
   private boolean ok=false;

   private int lastIndex=-1;
   private int currentLoopIndex=-1;

   private static IntBuffer scratchBuffer = BufferUtils.createIntBuffer(256);
   private static int[] sources;
   private static int[] buffers=null;
   private static int sourceIndex;
   private static int channels=16;
   private static int instanceCount=0;
   private boolean mute=false;

   static {
      try {

         boolean ok=false;
         do {
            AL.create();
            sources=new int[channels];
            Logger.log("Trying with "+channels+" channels!", Logger.MESSAGE);
            scratchBuffer.limit(channels);
            AL10.alGenSources(scratchBuffer);
            if (AL10.alGetError()==AL10.AL_NO_ERROR) {
               scratchBuffer.rewind();
               scratchBuffer.get(sources);
               ok=true;
            } else {
               //AL10.alDeleteSources(scratchBuffer);
               AL.destroy();
               channels=channels>>1;
            }
         } while (!ok&&channels>0);

         if (channels!=0) {
            Logger.log("OpenAL initialized using "+channels+" channels!", Logger.MESSAGE);
         } else {
            Logger.log("Can't initialize one single channel!?", Logger.WARNING);
         }

      } catch (Exception e) {
         Logger.log("Unable to initialize OpenAL!", Logger.WARNING);
      }
   }

   public OpenALSound(InputStream is) {
      try {

         instanceCount++;
         IntBuffer scratchBuffer=BufferUtils.createIntBuffer(256);
         scratchBuffer.rewind().position(0).limit(1);
         AL10.alGenBuffers(scratchBuffer);
         buffer=scratchBuffer.get(0);

         byte[] data=null;

         Logger.log("Loading sound (OpenAL) from InputStream", Logger.MESSAGE);
         AudioInputStream soundStream=AudioSystem.getAudioInputStream(is);
         AudioFormat format=soundStream.getFormat();

         int len=(int) (format.getFrameSize()*soundStream.getFrameLength());
         data=new byte[len];
         int l=0;
         int lp=0;
         do {
            l=soundStream.read(data, lp, len);
            lp+=l;
         } while (l!=-1);

         // Welches Format?
         int chans = 0;
         boolean bit16=false;

         if (format.getChannels()==1) {
            if (format.getSampleSizeInBits()==8) {
               chans=AL10.AL_FORMAT_MONO8;
            } else if (format.getSampleSizeInBits()==16) {
               chans=AL10.AL_FORMAT_MONO16;
               bit16=true;
            }
         } else if (format.getChannels()==2) {
            if (format.getSampleSizeInBits()==8) {
               chans=AL10.AL_FORMAT_STEREO8;
            } else if (format.getSampleSizeInBits()==16) {
               chans=AL10.AL_FORMAT_STEREO16;
               bit16=true;
            }
         }

         ByteBuffer bb = ByteBuffer.allocateDirect(data.length);
         bb.order(ByteOrder.nativeOrder());
         ByteBuffer src=ByteBuffer.wrap(data);
         src.order(ByteOrder.LITTLE_ENDIAN);
         if (bit16) {
            ShortBuffer destShort=bb.asShortBuffer();
            ShortBuffer srcShort=src.asShortBuffer();
            while (srcShort.hasRemaining())
               destShort.put(srcShort.get());
         } else {
            while (src.hasRemaining())
               bb.put(src.get());
         }
         bb.rewind();

         AL10.alBufferData(buffer, chans, bb, (int) format.getSampleRate());

      } catch (Exception e) {
         Logger.log("Error loading sound: "+e, Logger.ERROR);
      }
   }

   public boolean playedFine() {
      return ok;
   }

   public boolean isRunning() {
      return lastIndex!=-1 && AL10.alGetSourcei(sources[lastIndex], AL10.AL_SOURCE_STATE) == AL10.AL_PLAYING;
   }

   public void stop() {
      if (isRunning()) {
         AL10.alSourceStop(sources[lastIndex]);
         lastIndex=-1;
      }
   }

   public void setMute(boolean is) {
      mute=is;
   }

   public void play() {
      if (mute) { return; }
      int channel=getNextChannel();
      if (channel!=-1) {
         AL10.alSourcei(sources[channel], AL10.AL_BUFFER, buffer);
         AL10.alSourcePlay(sources[channel]);
      }
   }

   public void endLoop() {
      if (currentLoopIndex!=-1) {
         AL10.alSourcei(sources[currentLoopIndex], AL10.AL_LOOPING, 0);
         currentLoopIndex=-1;
      }
   }

   public void loop() {
      if (mute) { return; }
      if (currentLoopIndex==-1) {
         currentLoopIndex=getNextChannel();
         if (currentLoopIndex!=-1) {
            AL10.alSourcei(sources[currentLoopIndex], AL10.AL_BUFFER, buffer);
            AL10.alSourcei(sources[currentLoopIndex], AL10.AL_LOOPING, 1);
            AL10.alSourcePlay(sources[currentLoopIndex]);
         }
      }
   }

   private int getNextChannel() {
      int cnt=0;
      boolean ok=false;
      while (cnt<channels && !ok) {
         sourceIndex=(sourceIndex+1)%sources.length;
         cnt++;
         ok=AL10.alGetSourcei(sources[sourceIndex], AL10.AL_SOURCE_STATE) != AL10.AL_PLAYING;
      }

      if (cnt>=channels) {
         ok=false;
         return -1;
      }
      ok=true;
      lastIndex=sourceIndex;
      return sourceIndex;
   }


   public synchronized void destroy() {

      if (buffers==null) {
         buffers=new int[instanceCount];
      }
      // Einsammeln der Buffer...
      buffers[instanceCount-1]=buffer;

      instanceCount--;
      if (instanceCount==0) {

         // Absolute Grütze, aber aufgrund der static-Eigenschaft der OpenAL-Anbindung
         // leider nicht anders zu machen.

         Logger.log("Destroying OpenAL!", Logger.MESSAGE);

         scratchBuffer.position(0).limit(sources.length);
         scratchBuffer.put(sources).flip();
         AL10.alSourceStop(scratchBuffer);

         AL10.alDeleteSources(scratchBuffer);
         sources=null;

         // Die Buffer selber löschen
         for (int i=0; i<buffers.length; i++) {
            scratchBuffer.position(0).limit(1);
            scratchBuffer.put(buffers[i]).flip();
            AL10.alDeleteBuffers(scratchBuffer);
         }

         buffers=null;
         AL.destroy();
      }
   }
}

Title: Re: Finally...
Post by: paulscode on May 25, 2008, 04:41:37 pm
Sound expensive to me...why do you have to delete the sournd from memory after playing?

The sound would not be deleted from memory, just the source.  Sources, from what I can tell, do not take up a lot of memory, as they are made up of peripheral information like position, voice, gain, pan, etc.  The actual sound data is stored in a sound buffer, and that is loaded only once (in my library a sound is either loaded manually, or loaded automatically if you try to play a sound that has not been loaded yet).

Once upon a time I had considered using a system where sources are recycled, but eventually abandoned the idea.  You can only create around 16- 32 total sources, depending on your sound card, and each source is loaded with a single sound.  So if you ever wanted to have more sound effects than that, you need to be able to actively delete sources.  The problem of "limited sound effects" would be compounded exponentially if you wanted to play multiple instances of each sound effect from different positions -- each instance of each sound uses up one of those total sources.

I suppose one way this idea could be resurrected would be to hold on to sources as long as possible, until one of them had to be deleted to be used for a different sound effect or instance of a sound effect.  That way if you played the same sound a hundred times in a row from different positions, you would not necessarily be creating hundreds of different sources.  I may test this idea out to see if it has tangable performance benefits.

I need to place the sound source, but it doesn't have to move. It's sufficient if it stays where it started IMHO....at least for the sounds that i have in mind. I don't think that i'll add any ambient sounds. However, having the option would be nice.

I finished creating an easy method for doing this:
Code: [Select]
String quickPlay( String filename, boolean toLoop, float x, float y, float z )
It creates a source for the sound "filename" at the specified 3D position, plays the source, and removes the source when it finishes playing (unless it is a looping source).  It automatically loads the sound "filename" if it hasn't been loaded yet.  The sound data for "filename" stays loaded, so you are not reloading the file every time you call the quickPlay method.  Return value is a random String name for the source, which you can use to manipulate the source while it is active, or just ignore it if you have no need to manipulate the source after creating it.  There are multiple versions of the method, which optionally allow you to specify attenuation model (ATTENUATION_NONE for ambient sound), fade distance, or rolloff factor.  I think this makes source creation on the fly quite simple, while still giving you options to do more complex things if required for a particular situation.

Anyway, sorry to get a little off topic on your thread.  Screen shots from your game are looking awesome - keep it up!
Title: Re: Finally...
Post by: EgonOlsen on May 25, 2008, 05:20:42 pm
Sounds fine. I don't consider this to be off topic, because i want to use it for the game... ;D
Title: Re: Finally...
Post by: paulscode on May 25, 2008, 05:34:12 pm
I just now went back to look at code I wrote some time ago when I started on the sound stuff, and I noticed something in OpenAL I seem to have overlooked before:
Code: [Select]
AL10.alSourcei( mySource.get( 0 ), AL10.AL_BUFFER, myBuffer.get(0) );
It immediately jumped out at me, probably because I have been working with OpenAL for so long that it is becomming like a second language to me ;D.  Anyway, this line of code should allow buffers from different sound effects to be swapped in a source without actually deleting the entire source (duh!).  That in mind, I am going to go back and redo the way I handle sources, to ensure the best performance possible.  Thanks for bringing up the question, or I probably wouldn't have noticed this!  :D

--EDIT --
I just ran some tests, and it is a bit faster to use this method than what I was using.  Only requirement seems to be that the source is stopped before using the above line of code.  This is actually going to simplify things for me when I finish SoundSystem and get back to SoundManager, because I can now grab up all the available channels in the beginning, and not have to constantly recheck if channels are available every time a source is changed to a different sound effect.
Title: Re: Finally...
Post by: EgonOlsen on July 17, 2008, 11:25:15 pm
After a short pause (had to play Mass Effect first and replace the Radeon HD2900XT with a shiny new Radeon HD4870), i'm back on the game. In the last two days, i've added the basic bot support. The bots are currently using a kind of civil-servant-AI, i.e. they don't do anything apart from standing around. Adding movement will be the next big thing(tm).
However, that shouldn't be too hard, because they appear to the server (and all other clients) as normal clients, so i don't have to do anything special for the bots on that side.
I first planned to make each bot an indivudual client and make the bot clients share the same resources (they do need access to some geometry data, because they have to do collision stuff on their own) to save some memory, but that was too awkward. Sharing the resources would have required a huge amount of synchronization...not good. So i decided to make one bot client that manages an unlimited number of bots. I had to refactor the server to handle multiple players per client, but that wasn't that hard. I'm quite satisfied with the results so far.
Here's a shot of Bobby Bowden, Johnny Bower and Milton Bradley (i don't know who these guys are/were (expect for Milton) but they have their birthday on the 8th of November, like me...which is why i took those names...) in "action":

(http://www.jpct.net/img/proj/wip/wip9.jpg)
Title: Re: Finally...
Post by: fireside on July 18, 2008, 12:08:58 am
The walls look bump mapped, are they?
Looking good, anyway. 
Title: Re: Finally...
Post by: raft on July 18, 2008, 12:11:15 am
very cute ;D
Title: Re: Finally...
Post by: EgonOlsen on July 23, 2008, 12:11:53 am
Fun with bots:
(http://www.jpct.net/img/proj/wip/wip10.jpg)
These are 50 of them. In a normal game, you'll have 0-5 or something like that. But it has to be able to handle 50 too, so i tried this. The AI is extremely dumb ATM. It uses A* to move and places bombs when blocked...most of the time, the bots blast themselves off.
Title: Re: Finally...
Post by: EgonOlsen on July 30, 2008, 05:57:39 pm
I decided to rewrite the Bot AI from scratch. I had something that worked quite well in the wide open test levels, but when used in a more bomberman like level, it failed miserable. I had to face it: I created idiots...idiots following a complex set of rules, but still idiots... :'(
Title: Re: Finally...
Post by: Melssj5 on July 30, 2008, 06:46:33 pm
like many Bureaucrats and Politicians.
Title: Re: Finally...
Post by: JavaMan on August 02, 2008, 04:26:34 pm
complex rules for politicians==whatever is best for them
Title: Re: Finally...
Post by: EgonOlsen on August 02, 2008, 10:12:52 pm
The bots act much better now. Still not perfect, but i can live with them for the moment. I started to create different tile sets. I'm not an artist...not at all. So bear with me...

Classic set:
(http://www.jpct.net/img/proj/wip/wip_classic.jpg)

Warehouse set:
(http://www.jpct.net/img/proj/wip/wip_warehouse.jpg)

Asia set:
(http://www.jpct.net/img/proj/wip/wip_japan.jpg)

Forest set:
(http://www.jpct.net/img/proj/wip/wip_forest.jpg)
Title: Re: Finally...
Post by: fireside on August 03, 2008, 01:49:17 am
They look great.
Title: Re: Finally...
Post by: fireside on August 03, 2008, 02:38:03 pm
By the way, how does multiplayer work?  Do you need a dedicated server for that?  I don't know anything about it.
Title: Re: Finally...
Post by: EgonOlsen on August 03, 2008, 05:42:12 pm
No, the server runs on the client that hosts the game. You may as well start it as a dedicated one, but that would require to add the possibility to configure the server (map rotation, bots...) from the outside via some configuration file. I'll add that later, but not for now. If the server is running and bots should be used, the server spawns a bot client. It appears like a normal client to the server and to the other clients, except that it handles multiple players (=bots) in one instance, which the normal, interactive clients don't.
Title: Re: Finally...
Post by: fireside on August 04, 2008, 10:57:06 pm
I haven't really played any multiplayer games because of my phone modem.   How does that work then, does one player download the game and then wait for another player to connect to his client server?
Title: Re: Finally...
Post by: EgonOlsen on August 05, 2008, 12:11:16 am
You would need a central server browser for that (i.e. a machine that manages servers, a kind of server server). Because otherwise, no client would know who the server is and where it can be found. Without that, you would have to know the address of the server to connect. Anyway, this isn't my main focus. The game is intended to be played in a LAN. I don't even know if the network code will still work good enough in the internet with all it's lags and packet losses. In a LAN, you can make a broadcast containing the server data and all client in the same subnet should be able to see that server in their server list. We'll see how this all works out. For now, it works fine in my LAN... ;)
Title: Re: Finally...
Post by: raft on August 06, 2008, 09:42:40 pm
i would like to hear about those bots. what are the goals and how did you implement them ? just for curiosity ;)
Title: Re: Finally...
Post by: EgonOlsen on August 06, 2008, 10:39:51 pm
@raft:

Currently, the bots are not very clever. What they basically do, is to wander around in the level by choosing a random target and moving towards this target by using a modifed A* (very similar to what i used in Paradroidz). The target is, as said, either random or, with a certain chance, a collectable item. Walls and bombs act as a blocker for A*, crates don't (but they are bit more expensive than free tiles). If the bot is blocked by a crate on the calculated way, he drops a bomb and chooses a target in the opposite direction to escape the blow. Something similar happens when he runs into another bot (or a human player). When trying to escape a bomb's blow, the crates do act as blockers for A* to avoid a situation where a bot tries to escape one blow by blowing up another crate...that just didn't work very well in most cases.
While the bombs are blockers, the blow itself isn't. It's very expensive to cross it though. Basically, that's all they do right now (there are some minor tweaks and such, but you got the idea...). They don't try to hunt the player and they don't shoot (right now, every player can shoot...i'm not sure if this works well in that kind of game so i might remove or limit it later).
I guess they have to be improved to offer a real challenge, but for now, they act ok. Basically, they are meant as a kind of filler when you don't get enough players together for a decent LAN. They are not supposed to be real opponents. Here's a video that shows them in action (the player in the foreground is me, not a bot): http://www.jpct.net/img/proj/wip/bots.mpeg (http://www.jpct.net/img/proj/wip/bots.mpeg)

As you can see, the blow themselves up from time to time. While this is realistic to a degree, i don't really know why this happens. It shouldn't. Then again, they place a bomb, escape and wait until the bomb explodes before moving on. There is no code that explictly triggers this behaviour...again, i don't know why they are doing this... ;D
Title: Re: Finally...
Post by: raft on August 06, 2008, 11:09:30 pm
nice video. it is always fun to watch -especially self made- bots :)

so this is a continuous process ? bot calculates a path and follows it, then immediately calculates another and follows it and so on.. it places a bomb, calculated a path in opposite direction and calculates a regular path again ? what if it finds no path ?
Title: Re: Finally...
Post by: EgonOlsen on August 06, 2008, 11:22:34 pm
Yes, that describes it pretty well. If it doesn't find a path, it simply doesn't move and tries again in some ticks. In those levels, this usually doesn't happen (except when it tries to escape a bomb where the crates are blockers.). Under normal conditions, there's always a path to take to the target tile.
Title: Re: Finally...
Post by: raft on August 07, 2008, 12:16:19 am
i see. doesnt that explain -at least some of the occurances of- why they blow theirselves and wait in some spot after they placed a bomb ? in that movie,  i saw a bot placed a bomb and stuck in next spot. nowhere to move because of the bomb. for waiting bots, it may the case that it found no path to a certain destination and waiting a few ticks for a new attempt
Title: Re: Finally...
Post by: fireside on August 07, 2008, 12:45:56 am
These pics make my applet look a little bad because I'm using small textures and ambient light to get maximum speed with the software renderer.  There might be a possibility I can do a webstart but I want to do it this way first.  I don't think shooting would be a good idea, but I haven't played the game much.
Title: Re: Finally...
Post by: EgonOlsen on August 07, 2008, 10:17:56 pm
i see. doesnt that explain -at least some of the occurances of- why they blow theirselves and wait in some spot after they placed a bomb ? in that movie,  i saw a bot placed a bomb and stuck in next spot. nowhere to move because of the bomb. for waiting bots, it may the case that it found no path to a certain destination and waiting a few ticks for a new attempt
Yes, something like that...but htey shouldn't move into those dead ends at all. It has something to do with costs. Walking two tiles along a blow into a dead end is cheaper than along three tiles into safety. I've added some code that should prevent this (with a chance that it gets ignored to appear more "human")...we'll see how it works out.
 
Title: Re: Finally...
Post by: EgonOlsen on August 07, 2008, 10:21:27 pm
I don't think shooting would be a good idea, but I haven't played the game much.
I'm not sure either. The problem is, that the model carries a gun and i can't modify it (lack of time + talent) in a way that it doesn't. The gun can be used to blow up bombs ealier, which may be a tactical element. You can also kill other players with it, but it's very hard to do so. So hard, that it doesn't make sense at all. So either i should remove the ability to kill others with it or make it easier. The former doesn't make much sense to the player IMHO while the latter may turn the game into a shooter kind of thing. It's difficult, but it think i'll get a good idea sooner or later.
Title: Re: Finally...
Post by: fireside on August 08, 2008, 02:51:26 pm
The AI sounds like a lot of fun to work on.  It sounds like you're kind of building it into the path finding.  I have no experience at all in it so I wouldn't know, but it seems like it would be easier to make changes if you used a state machine and preference type choices.
Title: Re: Finally...
Post by: EgonOlsen on August 08, 2008, 03:05:46 pm
Not exactly...the path finding handles some special cases for this game (like making crates to blockers on demand) but after all, it's a simple A*. The bots' logic itself is placed in a bot class that uses a target finder class that uses the A*-implementation (but doesn't have to). I did the state machine stuff in my former game to a degree and i had different types of bots (mover, defender, attacker,...). It worked fine but i don't need it for this game. I agree that the bot class looks a bit cluttered ATM, but it's not that bad.
And no, it's not fun... ;D
Title: Re: Finally...
Post by: fireside on August 08, 2008, 06:14:02 pm
I suppose it gets complex really fast.  I can imagine my spaghetti code now.
Title: Re: Finally...
Post by: EgonOlsen on August 08, 2008, 06:23:55 pm
Not really complex, but i tend to break working stuff by adding new rules. Yesterday, i've added a rule that should have prevented the bots from running into the explosions a little more reliable. The problem was, that sometimes it's required to cross a potential explosion tile to run into safety. So you either have to detect that too or remove the additional rule. I decided to do the latter... ;)
Title: Re: Finally...
Post by: EgonOlsen on August 21, 2008, 08:21:39 pm
I've decided what to do with the gun: It's a water pistol now that can be used to defuse the bombs. It always available but needs some time to reload after usage. I'm still working on the look of the water to make it look like water somehow...not that easy...
Title: Re: Finally...
Post by: fireside on August 21, 2008, 09:32:56 pm
Good Idea.
Title: Re: Finally...
Post by: cyberkilla on August 22, 2008, 02:47:03 pm
Tsk! Does no-one know what snorks are? What do they teach in schools nowadays? *mutter, mumble*

Created by the wonderful Finnish authoress Tove Jansson in 1946: http://www.geocities.com/lindashippert/moomin/moominnf.html#extended (http://www.geocities.com/lindashippert/moomin/moominnf.html#extended)

(game looks good BTW :))

Wow, I remember those:) The cartoons were on in the mornings before I went to school, years ago:)
Title: Re: Finally...
Post by: EgonOlsen on September 22, 2008, 12:08:06 am
It's out. Please post further replies in the new thread: http://www.jpct.net/forum2/index.php/topic,1207.0.html (http://www.jpct.net/forum2/index.php/topic,1207.0.html)