Show Posts
|
|
Pages: [1] 2
|
|
2
|
Java Game APIs & Engines / Java Sound & OpenAL / Re: audioInputStream with Zip
|
on: 2003-08-30 16:43:42
|
|
Although it should not be a problem to create an AudioInputStream using byte array, you could create one even easier directly using ZipFile.getInputStream. Unless there is a specific reason why you need to use byte[] instread...
ZipFile zf = new ZipFile("test.zip"); Enumeration entries = zf.entries();
ZipEntry ze = (ZipEntry) entries.nextElement(); while(!ze.getName().equals("music.wav")) { ze = (ZipEntry) entries.nextElement(); }
AudioInputStream audioInputStream = AudioSystem.getAudioInputStream(zf.getInputStream(ze));
|
|
|
|
|
4
|
Game Development / Performance Tuning / Re: High Resolution Timer in Java 1.4.2
|
on: 2003-08-11 15:17:04
|
I've seen your 64k demo (varhaiset_signaalit) several months ago and was really impressed. It was the first demo I've seen wich was written in Java and it was able to run in fullscreen (I hadn't known that it's possible before). Without your demo I won't be here. Thank you for bringing me back to this wonderful language
Well now we have released another 64 kB intro at Assembly 2003 called raskasmetallia, which uses the high resolution timer in Java 1.4.2  Feel free to download it from: http://www.pouet.net/prod.php?which=10585Comments, feedback and especially bug reports are all welcome...
|
|
|
|
|
5
|
Java Game APIs & Engines / Java Sound & OpenAL / Re: Playing the same sound many times
|
on: 2003-07-27 10:44:18
|
1
| DataLine.Info info = new DataLine.Info(Clip.class, af, size); |
One potential problem with re-using the DataLines is the code above. DataLine.Info requires that you state the used audio format and buffer size, so if you want to re-use the same line, you have to make sure it supports ALL the needed formats and the buffer size is big enough. Once again, the Java documentation will come to rescue. You can create a DataLine.Info with multiple audio formats: 1
| DataLine.Info(Class lineClass, AudioFormat[] formats, int minBufferSize, int maxBufferSize) |
|
|
|
|
|
6
|
Java Game APIs & Engines / Java Sound & OpenAL / Re: Playing the same sound many times
|
on: 2003-07-26 20:14:03
|
1
| javax.sound.sampled.LineUnavailableException: No Free Voices |
simply means you don't have any more free lines left. Seems that your soundcard supports 64 polyphony (mine only supports 32!). I think your problem is that you never close the lines (sorry about my bad example). Stop method does not release the line, it simply stops the playback. As the Java documentation says: "public void stop() Stops the line. A stopped line should cease I/O activity. If the line is open and running, however, it should retain the resources required to resume activity. A stopped line should retain any audio data in its buffer instead of discarding it, so that upon resumption the I/O can continue where it left off, if possible. So... instead of stop() method, try close()
|
|
|
|
|
7
|
Java Game APIs & Engines / Java Sound & OpenAL / Re: Playing the same sound many times
|
on: 2003-07-26 08:40:33
|
I would suggest that you load your clip to a byte array and then use AudioSystem.getLine to get a new line for each clip. Here is a short example how to play audio.wav 32 times simultaneously (i.e. 32 polyphony): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
| import javax.sound.sampled.*; import java.io.*;
public class MultiClip { public static void main(String[] args) { try { AudioInputStream audioInputStream = AudioSystem.getAudioInputStream(new File("audio.wav")); AudioFormat af = audioInputStream.getFormat(); int size = (int) (af.getFrameSize() * audioInputStream.getFrameLength()); byte[] audio = new byte[size]; DataLine.Info info = new DataLine.Info(Clip.class, af, size); audioInputStream.read(audio, 0, size);
for(int i=0; i < 32; i++) { Clip clip = (Clip) AudioSystem.getLine(info); clip.open(af, audio, 0, size); clip.start(); } } catch(Exception e) { e.printStackTrace(); } } } |
|
|
|
|
|
8
|
Game Development / Performance Tuning / Re: JRE Download Size
|
on: 2003-07-01 08:17:30
|
you much make the assumption that the person you're deploying to have internet connection. Yes, it is true that I assumed that download size only matters if you are actually going to download the JRE. If you are installing it from CD-ROM, who cares if it's 5, 10 or 50 megabytes?
|
|
|
|
|
9
|
Game Development / Performance Tuning / Re: JRE Download Size
|
on: 2003-06-30 21:18:34
|
1.4.2 is now 14.1 MBs ..... So much for cutting down the size .....
The size of J2SE 1.4.2 Windows Offline Installation is 13.5 MBs. However, it includes tons of stuff that is not installed unless you choose a custom installation instead of the typical installation. The typical installation does not include non-European languages (18 MBs when installed) and additional font & media support (6 MB when installed), which are all part of the offline installation package. So you definitely want to use the online installation, if you only want the typical installation...
|
|
|
|
|
12
|
Game Development / Performance Tuning / Re: High Resolution Timer in Java 1.4.2
|
on: 2003-06-08 17:53:45
|
Tricky? Because you need a Java version that supports hires timer (i.e. J2SE 1.4.2 at the moment) to compile it? Why on earth would you have hires fallback timer if you are not using such a compiler?  Besides, your code will not compile with any Java version because "import sun.misc.Perf;" is missing  [edit: sorry, of course your code will compile without the import unless the hires timer is needed]
|
|
|
|
|
14
|
Game Development / Performance Tuning / Re: High Resolution Timer in Java 1.4.2
|
on: 2003-06-07 19:08:01
|
Yep, if you use the hires timer, you definitely need a fallback in case it is not available. But I think it would be nicer if the availability of the hires timer is checked by the Timer class itself, not the caller. For example, the code could be something like this: import sun.misc.Perf;
public class Timer { Perf hiResTimer; long freq; boolean hires = false;
public Timer() { try { hiResTimer = Perf.getPerf(); freq = hiResTimer.highResFrequency(); hires = true; } catch(Throwable t) { } }
public long currentTimeMillis() { if(hires == true) { return hiResTimer.highResCounter() * 1000 / freq; } else { return System.currentTimeMillis(); } } }
Then the caller could use the Timer like this: 1 2
| Timer timer = new Timer(); long time = timer.currentTimeMillis(); |
|
|
|
|
|
15
|
Java Game APIs & Engines / Java 2D / Re: how would you implement this?
|
on: 2003-06-07 16:05:25
|
Here is example code how to do palette manipulation without touching the pixels with Java1.1: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91
| import java.awt.*; import java.awt.image.*;
public class paletteManipulation extends java.applet.Applet implements Runnable { private final static int width = 640; private final static int height = 480; private final static int speed = 2;
Thread tr; public MemoryImageSource mis; private static Image image; Graphics screen; int[] jpgPixels = new int[width*height]; byte[] pixels = new byte[width*height];
public void run() { byte[] R = new byte[256]; byte[] G = new byte[256]; byte[] B = new byte[256];
for(int i = 0; i < 256; i++) { R[i] = (byte) i; G[i] = (byte) i; B[i] = (byte) i; }
try { MediaTracker track = new MediaTracker (this); image = getImage(getDocumentBase(), "test.jpg"); track.addImage(image,666); track.waitForAll(); PixelGrabber ap = new PixelGrabber (image, 0, 0, width, height, jpgPixels, 0, width); while (ap.grabPixels() && ((ap.status() & ImageObserver.ALLBITS) == 0)) { } } catch (Exception e) { e.printStackTrace (); } for(int i = 0; i < width*height; i++) { pixels[i] = (byte) (jpgPixels[i] & 0xff); }
screen = getGraphics(); mis = new MemoryImageSource (width, height, new IndexColorModel(8, 256, R, G, B), pixels, 0, width, null); mis.setAnimated(true); mis.setFullBufferUpdates(true); image = createImage(mis);
boolean reset = false; while(true) { if((R[0] & 0xff) == 0xff) { reset = true; } else { reset = false; }
for(int i = 0; i < 256; i++) { int color = (R[i] & 0xff); if(reset == true) { color = i; } else { color += speed; } if(color > 255) { color = 255; } R[i] = (byte) (color & 0xff); G[i] = (byte) (color & 0xff); B[i] = (byte) (color & 0xff); } mis.newPixels(pixels, new IndexColorModel(8, 256, R, G, B), 0, width); screen.drawImage(image, 0, 0, null); } }
public void start() { if (tr == null) { tr = new Thread(this); tr.start(); } }
public void stop() { if (tr != null) { tr.stop(); tr = null; } } } |
The code loads a grayscale jpg picture and then fades the palette until the picture is all white and then resets the palette and starts from the beginning. Basically you can do exactly the same "effect" as in the video with code similar to this one. If you are working with large palettes (such as 24bit palette), realtime manipulation of the palette might be too slow. In this case, you can simply precalculate couple of palettes, such as "night palette" and "day palette" and then switch the palette very fast when needed without touching the pixels. Of course if you need a nice fading effect, you would need to precalculate a lot of palettes...
|
|
|
|
|
20
|
Discussions / General Discussions / Re: Sun plans to unveil new Java logo next week
|
on: 2003-06-06 18:15:19
|
Does this mean I have to replace my new Java T-Shirt? Drats. Foiled again. NO! This means that now your Java T-shirt has cult status and you should wear it forever. Just like some guys still have "Metallica World Tour 1983" T-shirts on and it makes you wonder "that guy hasn't changed his shirt for 20 years?!"
|
|
|
|
|
24
|
Java Game APIs & Engines / Java 2D / Re: Bits manipulation expert, please join :)
|
on: 2003-06-02 14:51:22
|
You don't need bit manipulation to have binary file with bytes. Here is an example with your data structure: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
| import java.io.*;
public class Binary { public static void main(String[] args) { try { DataOutputStream out = new DataOutputStream(new FileOutputStream("binary.dat")); int brepeat = 255; int bmove = 1; byte bx = 1; byte by = -1;
out.writeByte(brepeat); out.writeByte(bmove); out.writeByte(bx); out.writeByte(by);
DataInputStream in = new DataInputStream(new FileInputStream("binary.dat")); System.out.println("brepeat: "+(in.readByte() & 0xff)); System.out.println("bmove: "+(in.readByte() & 0xff)); System.out.println("bx: "+in.readByte()); System.out.println("by: "+in.readByte()); } catch(Exception e) { e.printStackTrace (); } } } |
|
|
|
|
|
25
|
Java Game APIs & Engines / Java Sound & OpenAL / Re: Midi playback is fine using the JDK but not in
|
on: 2003-06-01 08:06:15
|
Midi playback in Java uses software synthesis, which requires a soundbank. The soundbank is included in Java SDK, and in your case it is located in c:\j2sdk1.4.0\jre\lib\audio\soundbank.gm However, to cut down the size of Windows version of JRE, Sun decided not to include the soundbank in Windows JRE (although it is included in Linux and Solaris version). Without a soundbank, JRE cannot perform software synthesis and JRE performs hardware synthesis using your sound card. In hardware synthesis, the sounds are different when using different sound cards and the timing can be poor. So the only solution to your problem is that the people who only have the JRE version have to install a soundbank. Soundbanks can be downloaded from here: http://java.sun.com/products/java-media/sound/soundbanks.html
|
|
|
|
|
26
|
Game Development / Performance Tuning / Re: Micro benchmarks
|
on: 2003-05-24 13:17:26
|
Isn't it normal that floating point is better for division/multiplation and integer is better for addition/negation? I thought it was common knowledge  Read the earlier posts. It depends. For example, I just said on my earlier post that "floating point multiplication is SLOWER than integer multiplication".
|
|
|
|
|
27
|
Game Development / Performance Tuning / Re: Micro benchmarks
|
on: 2003-05-24 11:04:49
|
I did some microbenchmarking too (with J2SE 1.4.2 + WinXP) and I found out that floating point division was working faster than integer division. However, floating point multiplication was working slower than integer multiplication. By the way, you can find an interesting table comparing the relative performance of common operations on PIII-733 using C++ here (appendix B): http://www.tantalon.com/pete/cppopt/appendix.htmIt states that "In fact, floating-point division is as fast or faster than integer division". So this is not a Java only "feature". Somebody should do a table like that for Java and post it here  .
|
|
|
|
|
29
|
Game Development / Performance Tuning / Re: Performance Myths
|
on: 2003-05-18 20:33:27
|
The article says these 3 things are legends: 1. Synchronization is really slow 2. Declaring classes or methods final makes them faster 3. Immutable objects are bad for performance Yet, it doesn't show any measurements showing that they really are legends. There is a lot of discussion about this article on Slashdot: http://developers.slashdot.org/developers/03/05/17/175255.shtml?tid=126&tid=156&tid=108For example "jdennett" tells that these 3 things were the main performance problems in his project (using J2SE 1.3): 1. Synchronization 2. Object creation 3. Immutable objects He also says: "Funny that the article "debunks" these myths without figures, when our thorough measurements showed that the problems are real, and in our case would have killed our chances of meeting performance targets had we not found them and dealt with them." I haven't done any measurements related to these things myself, so I'm not saying what is right and what is wrong. I am just saying that I only trust performance measurements (well not even all of them), not words 
|
|
|
|
|
30
|
Game Development / Performance Tuning / Re: High Resolution Timer in Java 1.4.2
|
on: 2003-05-17 18:00:36
|
oNyx, thanks for your nice feedback. We are going to release even better Java stuff this year, so stay tuned  Themroc, yes it could vanish any time. But Florian Bomers (the guy responsible for Java Sound at Sun) is going to use it in Tritonus' Java sequencer, so I guess at least he is not expecting it to vanish soon. I guess they could not make it an "official" timer class in J2SE 1.4.2, because it would have been a new feature, but I hope it will be an official class in J2SE 1.5. Orangy Tang, our demo (actually a 64 kB intro) was released almost a year ago, and we made it using J2SE 1.4.0 beta. So although it was not made to demonstrate fullscreen API, it definitely was made with the first possible Java SDK that had fullscreen API support  . And to my great surprise, it actually works BETTER with 1.4.0 than 1.4.1 or 1.4.2. About the timers; my guess is that both the Windows implementation of the "new" timer and J3D timer (and several native timers floating in the web) use QueryPerformanceCounter and QueryPerformanceFrequency functions. Smoke, you can actually get the resolution of the timer with hiResTimer.highResFrequency() method  . Resolution on my WinXP set up is 3579545 ticks/sec, which means a resolution of 1/3579545 = 0.000000279365114840015 s. Those of you who wonder what is varhaiset signaalit, you can download it from here: http://www.pouet.net/prod.php?which=7145
|
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|