Java-Gaming.org    
Featured games (78)
games approved by the League of Dukes
Games in Showcase (429)
Games in Android Showcase (89)
games submitted by our members
Games in WIP (466)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 3 4 [5]
  ignore  |  Print  
  New j4k contest anytime soon?  (Read 38961 times)
0 Members and 1 Guest are viewing this topic.
Offline Morre

JGO Knight


Medals: 2
Projects: 10


I'm Dragonene on IRC.


« Reply #120 - Posted 2005-11-29 16:09:14 »

I agree that added inclusion for sound support would be nice, but I also agree with kevglass, I don't think additional downloads should be necessary. Letting the author deal with any errors, and having sounds playable only on machines with the SDK seems like a fair comprominse, if:

1) At least one of the judges has the SDK, and can test sound.
2) Additional points for sounds, or music, are pre-balanced in a good way (and, without knowing the rest of the rules and scoring criteria, I can't think of any examples on how this should be done).

That way, you CAN add sound, and you CAN get points for it. Yes, it will be expensive, and no, not everyone will be able to play sounds - fine. Provide the download link, let the ones who want to experience the sound do it, but don't base points on that - base it upon the sole judge, or the judges, that can play it. If judges without SDK can't, then it should count as not having sound support.

This might be a bad idea, I get those all the time, but it's what came to mind first. Please note that I haven't used MIDI sounds at all, so I could very well be missing part of the point.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #121 - Posted 2005-11-29 16:11:15 »

I believe the intention is that you can package your own midi synthesizer with your app.

But then you could also package the MIDI support as a standard extension, there would be little reason to have the MIDI support in the core.

Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #122 - Posted 2005-11-29 16:33:30 »

Midi support can send its data directly to a hardware midi port, resulting generally in the song/sounds played by the soundcard and not the software synth.

So you should be able to get a sequencer and play a midifile without the soundbank.
Unfortunately the method to get the hardware synth is only in the 1.5 API.

It's been a while since I tested this feature, but I think it's still valid.

Lilian

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #123 - Posted 2005-11-29 16:35:31 »

Ah, got it.

Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #124 - Posted 2005-11-29 20:34:44 »

There's a few errors in MIDI information provided this this thread.  The key points are:

- The MIDI API is part of the core 1.4.2 API, but the soundbank is an optional part of the JRE install.
- Even if a soundbank is not fitted, the API supports loading one across the net. Only it's broken in 1.4.2; Fixed in 1.5.
- The PC version of the JRE falls back to a hardware MIDI port if a soundbank is not available.  Unfortunately this is also partly broken, in that the note timing information is not passed correctly, resulting in the notes being played at the wrong times (sounds like me practicing the piano).
- I believe you need a 3rd party library (Tritonus) to get MIDI on linux (but looks at kapta's post - could be wrong)

So, if you get a channel and use noteOn for sound effects, it will probably work on a PC, even with no soundbank.  I wouldn't suggest attempting music though (unless you like that jangley sound).  I haven't checked whether a soundbank is installed on the Mac, so you may or may not get sound.

Alan Smiley

Time flies like a bird. Fruit flies like a banana.
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 70
Projects: 15


★★★★★


« Reply #125 - Posted 2005-11-30 00:15:51 »

- I believe you need a 3rd party library (Tritonus) to get MIDI on linux (but looks at kapta's post - could be wrong)

don't have that 3rd party app, and midi runs fine with linux on java, must be a software midi thing in java on linux.
Offline Rick

Junior Member


Projects: 1


Java games rock!


« Reply #126 - Posted 2005-11-30 01:38:49 »

I tried playing a note with the MidiChannel.noteOn. It works with the sound bank. But if I change the name of the bank so java can't find it, then no sound is played at all. Unless I am missing something it looks like you need some minimal sound bank to play anything at all.
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #127 - Posted 2005-11-30 07:52:20 »

Quote
don't have that 3rd party app, and midi runs fine with linux on java, must be a software midi thing in java on linux.
I checked, and am indeed wrong  Lips Sealed

I tried playing a note with the MidiChannel.noteOn. It works with the sound bank. But if I change the name of the bank so java can't find it, then no sound is played at all. Unless I am missing something it looks like you need some minimal sound bank to play anything at all.

It works here.  It goes via the windows MIDI Mapper, so perhaps that has been configured to use an external synth.
Have a look here (and the rest of the FAQ for that matter).

The jist of it is that MIDI may or may not work, so you can't rely on it.  My feeling is include it if there's space, but check for exceptions when initialising, and check for a null pointer before using onNote.  Generally using the sampled audio API is a safer bet, but I've been unable to get this less than 500 compressed bytes for even the simplest sound, and more than 800 for something decent.  I'm managing just under 300 compressed bytes with MIDI at the moment.  It's all a bit academic for me at the moment, as I've got two potential entries on the blocks, both of which are having trouble getting into 4k without sound Smiley

Moving away from MIDI for the moment.  Part of the overhead with the sampled API is getting a Clip to play just once.  loop(0) works the first time, but not subsequently.  loop(1) works, but plays the sample twice.  In SharpShooter16k I used something like:
1  
2  
3  
4  
5  
                                if (ready) {
                                    ready = false;
                                    fire.setFramePosition(0);
                                    fire.loop(0);
                                }

Originally 'ready' was  '!fire.isRunning()', but I've managed to optimise that out.  I'd like to get rid of 'setFramePosition(0)', but can't seem to manage it.  Any ideas?.

(I tried loop(1) immediately followed by loop(0), which strangely worked from within the IDE, but not when run by double clicking on the jar. Maybe the IDE was using 1.4.2 & I was getting 1.5.0 when running the jar.  Anyway, that whizzo scheme didn't work)

Alan



Time flies like a bird. Fruit flies like a banana.
Offline Anon666

Junior Member




aka Abuse/AbU5e/TehJumpingJawa


« Reply #128 - Posted 2005-11-30 16:27:53 »

Something worth trying - the code to unpack a pack200 stream isn't that large.

A size reduction may still be possible by embedding the games class file as a pack200 stream, with a little bit of code to unpack the stream, and create a class from it.

I'm still not so sure pack200 is the way to go though - a tool to rearrange the constants pool to improve its compressability will have no code overhead, and should give *some* gains (it is a simplistic approach to the far more complex techniques employed by the pack200 algorithm)
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #129 - Posted 2005-11-30 19:20:38 »

Something worth trying - the code to unpack a pack200 stream isn't that large.

A size reduction may still be possible by embedding the games class file as a pack200 stream, with a little bit of code to unpack the stream, and create a class from it.

I'm still not so sure pack200 is the way to go though - a tool to rearrange the constants pool to improve its compressability will have no code overhead, and should give *some* gains (it is a simplistic approach to the far more complex techniques employed by the pack200 algorithm)

Are you sure? Unpack200.exe is a stonking 124kB Smiley

Time flies like a bird. Fruit flies like a banana.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Anon666

Junior Member




aka Abuse/AbU5e/TehJumpingJawa


« Reply #130 - Posted 2005-11-30 21:27:46 »

Something worth trying - the code to unpack a pack200 stream isn't that large.

A size reduction may still be possible by embedding the games class file as a pack200 stream, with a little bit of code to unpack the stream, and create a class from it.

I'm still not so sure pack200 is the way to go though - a tool to rearrange the constants pool to improve its compressability will have no code overhead, and should give *some* gains (it is a simplistic approach to the far more complex techniques employed by the pack200 algorithm)

Are you sure? Unpack200.exe is a stonking 124kB Smiley

I was thinking something along the lines of :-

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
// btw (not tested in any way, shape or form!)
Class unpack(byte [] pack200data) throws Exception
{
ByteArrayOutputStream  baos;
Pack200.newUnpacker(new ByteArrayInputStream(pack200data), new JarOutputStream(baos = new ByteArrayOutputStream()))
byte [] unpackedData = baos.toByteArray();

final int maxClassSize = SOME_VALUE;
byte [] classData = new byte[maxClassSize];
int classDataLength = new JarInputStream(new ByteArrayInputStream(unpackedData)).read(classData,0,maxClassSize);
return ClassLoader.getSystemClassLoader().defineClass("A", classData, 0, classDataLength);
}


The pack200data would also need to be extracted from a nibble-packed String, as-per jbanes 'SuperPacker' (or whatever it was called Cheesy)

p.s.

On a side note, the pack200 api is abit crap - where is the Unpack200[Input/Output]Stream =/
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #131 - Posted 2005-11-30 21:46:00 »

*cough* 1.4 *cough*

弾幕 ☆ @mahonnaiseblog
Offline Anon666

Junior Member




aka Abuse/AbU5e/TehJumpingJawa


« Reply #132 - Posted 2005-11-30 21:50:15 »

*cough* 1.4 *cough*

whaaaat!

1.5 has been out almost an entire year!
I was looking forward to using all the funky new hidden-away 1.5 api bits.
(not to mention forgetting all the hideous work-arounds necessary because of 1.4 bugs/limitations!!)
Infact, what will have changed since last years competition if we use 1.4???
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #133 - Posted 2005-11-30 21:57:45 »

>Infact, what will have changed since last years competition if we use 1.4???

The bar is higher Wink

弾幕 ☆ @mahonnaiseblog
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #134 - Posted 2005-11-30 23:40:27 »

The pack200data would also need to be extracted from a nibble-packed String, as-per jbanes 'SuperPacker' (or whatever it was called Cheesy)

It's part of the SuperPackME toolkit. (Link to tools is at the bottom. The rest just decribes the SuperPack and SuperPackME formats.) The tools are located in the "inline" directory, and do not require that the data actually be in SuperPackME format. BinaryToHex will "nibblize" the data (yes, I just made that term up) while ClassInliner will place the nibblized data into the class. After that, modify the Decoder.java file to begin your game.

For what you're doing, you'll need to modify the Decoder.java file so that the decoding routine doesn't try to convert the "de-nibblized" data (yes, I made that term up as well)  into images. In fact, you could probably start clean. All you need is a public string with the value "$hexdata".  The inliner will automatically do the rest.

Quote
On a side note, the pack200 api is abit crap - where is the Unpack200[Input/Output]Stream =/

1. Pack200 rearranges the class into another format. There's no stream because the entire class needs to be reconstructed first.
2. Puttng aside the 1.4 requirement, I think you'll find that your solution is simply too convoluted to work. In the past we've had many a programmer attempt to pack source code  into a compressed file, then compile at runtime. As far as I'm aware, all the programmers abandoned their research.  I'm not holding out much hope for your scheme, either.

Part of the problem with your scheme (IMHO) is that it involves recompressing compressed data. This is BAD, BAD, BAD as you rarely gain any savings. More often than not, you can actually cause the data to get larger thanks to the fact that the compression algo will be trying to find a way to store so much unique data. The reality of the situation is that you're better off compressing things once, and optimizing for that.

For example, SuperPackME images compress better than PNGs in a JAR file because they aren't already compressed. They also shift as much of the unique data to a palette, then present highly redudant data for the compressor to work with.

Which brings me to another point. When coding, try to reuse the same instructions as much as possible. The redundancy caused by those instructions makes it easy for the compressor to shrink the file. Similarly, if you use a method once, don't be afraid to use it again. Most of the cost is in referencing the class name, then the method signature. Cost-wise, actual use of a method comes in dead last. This means that it sometimes makes more sense to go ahead and use that Math.random() call instead of rewriting your own psuedo-random generator each time you need it.

Good luck! Smiley

Java Game Console Project
Last Journal Entry: 12/17/04
Offline Anon666

Junior Member




aka Abuse/AbU5e/TehJumpingJawa


« Reply #135 - Posted 2005-12-01 00:07:34 »

I suggested it, as people were claiming the pack200'ed 4k games were being reduced by ~800bytes.

Assuming the overhead of  the following 4....

a) the overhead of a second jar head.
b) marginally worse zip compression on the jar, due to the data being nibble-packed.
c) the code to expand the nibble-packed into a byte[]
d) the code to expand the byte [] into a class

....is less than 800 bytes, there should be a saving.

However, I agree pack200 is almost certainly a waste of time - as I don't think an optimally compressed app. will gain anywhere near 800bytes.

I think a few bytecode optimisation tools will be a much more inteligent application of time, and more likely to give real gains.

hell, may even write it using jasmin =)
Offline tom
« Reply #136 - Posted 2005-12-01 00:51:37 »

I'm still not so sure pack200 is the way to go though - a tool to rearrange the constants pool to improve its compressability will have no code overhead, and should give *some* gains (it is a simplistic approach to the far more complex techniques employed by the pack200 algorithm)

Btw, am I the only one who rearanges variables, functions and code in order to get better compression? It's my favorite part of optemizing for size Grin

Offline nonnus29

Senior Member




Giving Java a second chance after ludumdare fiasco


« Reply #137 - Posted 2005-12-01 01:13:47 »

I'm still not so sure pack200 is the way to go though - a tool to rearrange the constants pool to improve its compressability will have no code overhead, and should give *some* gains (it is a simplistic approach to the far more complex techniques employed by the pack200 algorithm)

Btw, am I the only one who rearanges variables, functions and code in order to get better compression? It's my favorite part of optemizing for size Grin

Probably, because hardly anyone else know how!  So, how do you do that? Huh
Offline kevglass

JGO Kernel


Medals: 85
Projects: 22


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #138 - Posted 2005-12-01 01:16:00 »

Quote
Btw, am I the only one who rearanges variables, functions and code in order to get better compression? It's my favorite part of optemizing for size Grin

Na, I thought everyone was doing that! Its the fun bit that helps me learn about how things work underneath. Although, I generally keep trying stuff and comparing sizes and trying to determine patterns Smiley

Kev

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 70
Projects: 15


★★★★★


« Reply #139 - Posted 2005-12-01 01:58:03 »

Btw, am I the only one who rearanges variables, functions and code in order to get better compression? It's my favorite part of optemizing for size Grin

Probably, because hardly anyone else know how!  So, how do you do that? Huh

yeh that is interesting, how do u, do that?
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #140 - Posted 2005-12-01 02:40:41 »

Btw, am I the only one who rearanges variables, functions and code in order to get better compression? It's my favorite part of optemizing for size Grin

Nope, not at all. I find it simply too much work for a rather meager return.  I know Abuse was big on disassembling and reassembing his code to get those sorts of gains, but I could never quite get into that. I'd much rather develop a technology to do it for me. Wink

However, I do usually run a program like JoGa that not only strips out unnecesary info, but reduces necessary info to as little space as possible.

Java Game Console Project
Last Journal Entry: 12/17/04
Offline tom
« Reply #141 - Posted 2005-12-01 02:49:28 »

Btw, am I the only one who rearanges variables, functions and code in order to get better compression? It's my favorite part of optemizing for size Grin

Probably, because hardly anyone else know how!  So, how do you do that? Huh

yeh that is interesting, how do u, do that?

There is nothing to it. Just change the code so that the class file changes. That in turn can make a difference when the class is zipped. You want to produce a class files with as many repeating patterns as possible. Just randomly changing the code will usually save you a couple of bytes. Intentionaly creating code that compresses better is fairly difficult to get right.

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 70
Projects: 15


★★★★★


« Reply #142 - Posted 2005-12-01 15:55:34 »

However, I do usually run a program like JoGa that not only strips out unnecesary info, but reduces necessary info to as little space as possible.

i've run a few tests and found that Proguard to be much better at saving space that JoGa

Original : 5427 bytes
JoGa: 3906 bytes
ProGuard: 3840 bytes
ProGuard and JoGa: 3839 bytes
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #143 - Posted 2005-12-01 16:11:00 »

i've run a few tests and found that Proguard to be much better at saving space that JoGa

When you get a chance, try running JoGa twice on your code. I know it seems odd, but I've actually saved more space that way. I've never seen it work a third time, though.  Undecided

Java Game Console Project
Last Journal Entry: 12/17/04
Offline Morre

JGO Knight


Medals: 2
Projects: 10


I'm Dragonene on IRC.


« Reply #144 - Posted 2005-12-01 16:50:59 »

I just tried that. Didn't work for me Cheesy

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 70
Projects: 15


★★★★★


« Reply #145 - Posted 2005-12-01 16:56:58 »

When you get a chance, try running JoGa twice on your code. I know it seems odd, but I've actually saved more space that way. I've never seen it work a third time, though.  Undecided

retest results

Original : 5427 bytes
JoGa: 3906 bytes
JoGa*2: 3906 bytes
ProGuard*2: 3847
ProGuard: 3840 bytes
JoGa and then ProGuard: 3839 bytes
ProGuard and then JoGa: 3792 bytes
Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2


Make it work; make it better.


« Reply #146 - Posted 2005-12-01 21:18:17 »

Did you also remove the zip message that ProGuard inserts into the archive?

Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #147 - Posted 2005-12-01 22:37:58 »

I've found an interesting quirk in Proguard.  The optimisation option in Proguard 3.4 shrinks the file more than that of Proguard 3.2 and was great under Java 1.5.  However the extra optimisation hammered my framerate under 1.4.2.  So, I'm still using Proguard 3.2 at the moment as I need the performance.  Also, the latest version of 7zip isn't any better than the version I had last spring w.r.t. standard zip files.

Time flies like a bird. Fruit flies like a banana.
Offline kevglass

JGO Kernel


Medals: 85
Projects: 22


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #148 - Posted 2005-12-02 00:56:11 »

You might want to check kzip out, I find it gives better results than 7zip.

Kev

Pages: 1 ... 3 4 [5]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (81 views)
2014-04-15 18:08:23

BurntPizza (73 views)
2014-04-15 03:46:01

UprightPath (84 views)
2014-04-14 17:39:50

UprightPath (67 views)
2014-04-14 17:35:47

Porlus (84 views)
2014-04-14 15:48:38

tom_mai78101 (107 views)
2014-04-10 04:04:31

BurntPizza (167 views)
2014-04-08 23:06:04

tom_mai78101 (263 views)
2014-04-05 13:34:39

trollwarrior1 (214 views)
2014-04-04 12:06:45

CJLetsGame (223 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!