CottAGE goes LWJGL/JWS

[princec]

Galaga - "illegal request to write non-integral number of frames" Apparently some kind of JMF error...?

Cas

[erikd]

I'm not even sure what that message means.  
Maybe I should just render sound using openAL.

[princec]

YES That's the whole point of the LWJGL after all

Cas

Games published by our own members! Check 'em out!

[BorgKnight]

"illegal request to write non-integral number of frames" means JavaSound's streaming has been sent a chunk of sound that's not a full frame (as in the number of bytes in a sample). Ex.: you're using 16-bit sound samples and you've only sent 1 (not 2 or multiples of 2) byte to the JavaSound line. That'll cause the message.

HTH,
BK

[blahblahblahh]

I expect problems on linux since I rely on being able to select 60Hz modes in order to use VSync. It might still work but probably not smooth or at the wrong speed.

No just crashes. It attempted to change screen mode ( I saw my screen res appear briefly in the JWS window log message, then screen flicked to black, then almost straight away it crashed.

Still desperately waiting for the day that LWJGL has a default screen-mode-selection routine that is easy and works AND which all developers use instead of each rolling their own and it not working half the time...

[erikd]

Thanks for the explanation.
Looks like a bogus message in this case though, since my code cannot cause that.
I'm doing this:

line.write(sc.getByteStream(), 0, WRITE_BUF_SIZE * 2);

and WRITE_BUF_SIZE is an int...

Converting to openAL now :-/

[erikd]

No just crashes.

Oh, bummer . Does Cosmic Trip also crash on your machine? (I'm using the same display selection code, so maybe the display selection is not the problem).
Do you have a webstart log?

[princec]

Y'all should take a look in CVS for the lwjgl util Display class which has a very comprehensive screen mode selector class in it.

And of course there's the new LWJGL Display code, which is now as simple as Display.create() Gets you a fullscreen window in the user's normal desktop resolution and colour depth.

Cas

[erikd]

Okay, I'll take a look even though I'm not at all convinced my own display selection code is at fault here (after all, blah's display mode did change briefly)

[princec]

blah's computer is frequently fux0red I think he must have drowned one of his great ancestors in a cup of tea or something.

Cas

Games published by our own members! Check 'em out!

[blahblahblahh]

Okay, I'll take a look even though I'm not at all convinced my own display selection code is at fault here (after all, blah's display mode did change briefly)

...yup, which is why I mentioned it. It seemed unusual . when I get some game-playing time next I'll go try Cosmic Trip again etc and get back to you...

[blahblahblahh]

blah's computer is frequently fux0red I think he must have drowned one of his great ancestors in a cup of tea or something.

Cas

Yeah, but it's not *that* bad. e.g. Kev managed to correct the timing problem all his code was getting on my machine (was it the Toolkit.sync() or something), and sub-1-fps hw-accelerated OGL seems consistently to be related to number of pixels being rendered.

So it's all settled down to predictable patterns...

[erikd]

I updated the rendering a bit so that the emulated display is stretched to the size of your monitor (arcades with a rotated monitor will be stretched as large as possible while retaining 3:4 aspect ratio, so they will appear a bit smaller).

There's one thing I notice though, when the emulated display is as large as the texture that it's rendered to, the sides will 'leak' to the opposite sides. See for example in Black Tiger, where pixels from the far left side will show at the far right side and vice versa.
Any trick how that should be prevented without creating larger textures?

EDIT: Never mind, found it.

[erikd]

Could a Mac owner please try to start it manually? I'm wondering if the input will work when not using jws.

Download the following:
http://www.movegaga.nl/80s/JEmu2.jar
http://www.movegaga.nl/80s/lwjgl.jar
http://www.movegaga.nl/80s/solomon.jar
http://www.movegaga.nl/80s/lwjgl_mac.jar

Extract lwjgl_mac.jar.

Start it by doing something like:

1	java -cp JEmu2.jar:lwjgl.jar:solomon.jar -Djemu.driver=solomon net.movegaga.jemu2.JEmu2

Maybe the ':' in the classpath above needs to be a ';' but I think I got it right.

Erik

[swpalmer]

Mac OS X 10.3.4 JRE 1.4.2_04

Scotts-Laptop:~/Desktop/erikd scottpalmer$ java -cp JEmu2.jar:lwjgl.jar:solomon.jar -Djemu.driver=solomon net.movegaga.jemu2.JEmu2
Trying to select driver 'solomon'...Ok!
cpus :2
sndchips :1
loadFromWeb(null,false);
jar:file:/Users/scottpalmer/Desktop/erikd/solomon.jar!/solomon.zip
e4d421ff(slmn_06.bin),e4d421ff
Loading slmn_06.bin(e4d421ff)...Ok!
8310c2a1(slmn_10.bin),e4d421ff
8310c2a1(slmn_10.bin),d52d7e38
8310c2a1(slmn_10.bin),0
8310c2a1(slmn_10.bin),b924d162
8310c2a1(slmn_10.bin),fa6e562e
8310c2a1(slmn_10.bin),aa26dfcb
8310c2a1(slmn_10.bin),6f94d2af
8310c2a1(slmn_10.bin),8310c2a1
Loading slmn_10.bin(8310c2a1)...Ok!
fa6e562e(slmn_01.bin),e4d421ff
fa6e562e(slmn_01.bin),d52d7e38
fa6e562e(slmn_01.bin),0
fa6e562e(slmn_01.bin),b924d162
fa6e562e(slmn_01.bin),fa6e562e
Loading slmn_01.bin(fa6e562e)...Ok!
d52d7e38(slmn_07.bin),e4d421ff
d52d7e38(slmn_07.bin),d52d7e38
Loading slmn_07.bin(d52d7e38)...Ok!
6f94d2af(slmn_11.bin),e4d421ff
6f94d2af(slmn_11.bin),d52d7e38
6f94d2af(slmn_11.bin),0
6f94d2af(slmn_11.bin),b924d162
6f94d2af(slmn_11.bin),fa6e562e
6f94d2af(slmn_11.bin),aa26dfcb
6f94d2af(slmn_11.bin),6f94d2af
Loading slmn_11.bin(6f94d2af)...Ok!
236106b4(slmn_03.bin),e4d421ff
236106b4(slmn_03.bin),d52d7e38
236106b4(slmn_03.bin),0
236106b4(slmn_03.bin),b924d162
236106b4(slmn_03.bin),fa6e562e
236106b4(slmn_03.bin),aa26dfcb
236106b4(slmn_03.bin),6f94d2af
236106b4(slmn_03.bin),8310c2a1
236106b4(slmn_03.bin),ab7e6c42
236106b4(slmn_03.bin),80fa2be3
236106b4(slmn_03.bin),236106b4
Loading slmn_03.bin(236106b4)...Ok!
aa26dfcb(slmn_12.bin),e4d421ff
aa26dfcb(slmn_12.bin),d52d7e38
aa26dfcb(slmn_12.bin),0
aa26dfcb(slmn_12.bin),b924d162
aa26dfcb(slmn_12.bin),fa6e562e
aa26dfcb(slmn_12.bin),aa26dfcb
Loading slmn_12.bin(aa26dfcb)...Ok!
80fa2be3(slmn_02.bin),e4d421ff
80fa2be3(slmn_02.bin),d52d7e38
80fa2be3(slmn_02.bin),0
80fa2be3(slmn_02.bin),b924d162
80fa2be3(slmn_02.bin),fa6e562e
80fa2be3(slmn_02.bin),aa26dfcb
80fa2be3(slmn_02.bin),6f94d2af
80fa2be3(slmn_02.bin),8310c2a1
80fa2be3(slmn_02.bin),ab7e6c42
80fa2be3(slmn_02.bin),80fa2be3
Loading slmn_02.bin(80fa2be3)...Ok!
88fe5d9(slmn_04.bin),e4d421ff
88fe5d9(slmn_04.bin),d52d7e38
88fe5d9(slmn_04.bin),0
88fe5d9(slmn_04.bin),b924d162
88fe5d9(slmn_04.bin),fa6e562e
88fe5d9(slmn_04.bin),aa26dfcb
88fe5d9(slmn_04.bin),6f94d2af
88fe5d9(slmn_04.bin),8310c2a1
88fe5d9(slmn_04.bin),ab7e6c42
88fe5d9(slmn_04.bin),80fa2be3
88fe5d9(slmn_04.bin),236106b4
88fe5d9(slmn_04.bin),88fe5d9
Loading slmn_04.bin(88fe5d9)...Ok!
b924d162(slmn_08.bin),e4d421ff
b924d162(slmn_08.bin),d52d7e38
b924d162(slmn_08.bin),0
b924d162(slmn_08.bin),b924d162
Loading slmn_08.bin(b924d162)...Ok!
ab7e6c42(slmn_09.bin),e4d421ff
ab7e6c42(slmn_09.bin),d52d7e38
ab7e6c42(slmn_09.bin),0
ab7e6c42(slmn_09.bin),b924d162
ab7e6c42(slmn_09.bin),fa6e562e
ab7e6c42(slmn_09.bin),aa26dfcb
ab7e6c42(slmn_09.bin),6f94d2af
ab7e6c42(slmn_09.bin),8310c2a1
ab7e6c42(slmn_09.bin),ab7e6c42
Loading slmn_09.bin(ab7e6c42)...Ok!
8366232a(slmn_05.bin),e4d421ff
8366232a(slmn_05.bin),d52d7e38
8366232a(slmn_05.bin),0
8366232a(slmn_05.bin),b924d162
8366232a(slmn_05.bin),fa6e562e
8366232a(slmn_05.bin),aa26dfcb
8366232a(slmn_05.bin),6f94d2af
8366232a(slmn_05.bin),8310c2a1
8366232a(slmn_05.bin),ab7e6c42
8366232a(slmn_05.bin),80fa2be3
8366232a(slmn_05.bin),236106b4
8366232a(slmn_05.bin),88fe5d9
8366232a(slmn_05.bin),8366232a
Loading slmn_05.bin(8366232a)...Ok!
21b5993b(solomon.txt),e4d421ff
21b5993b(solomon.txt),d52d7e38
21b5993b(solomon.txt),0
21b5993b(solomon.txt),b924d162
21b5993b(solomon.txt),fa6e562e
21b5993b(solomon.txt),aa26dfcb
21b5993b(solomon.txt),6f94d2af
21b5993b(solomon.txt),8310c2a1
21b5993b(solomon.txt),ab7e6c42
21b5993b(solomon.txt),80fa2be3
21b5993b(solomon.txt),236106b4
21b5993b(solomon.txt),88fe5d9
21b5993b(solomon.txt),8366232a
Starting...
Solomon's Key (Japan)
1986 - Tecmo
Sound initializing...
javax.sound support detected.
SoundChip emulators found:1
Sound initialized successfully.
SoundChip jef.sound.chip.AY8910@8f5824 initialized.
AY8910_init 0
AY8910_init 1
AY8910_init 2

and then it appears to lock up

[erikd]

Crap  

Did you get the 'Starting JEmu' nag screen?
It seems like it hangs there. I removed it for now and added some logging (and removed some other logging).
Could you download JEmu2.jar again and give it another shot?

Thanks!
Erik

[swpalmer]

Didn't get any UI at all.  The process didn't even respond to a "normal" quit... had to kill -9.

Trying new version....

better... :

Machine initialized successfully.
256
256
Screen dimensions 256x224
Texture dimensions 256x256
Maybe selecting mode 800 x 600 x 16 @0Hz
VSync:false
Throttle:true
Setting display mode 800 x 600 x 16 @0Hz...
OK. Creating window...
OK. Setting up keyboard + buffer...
OK. Setting up mouse and setting native cursor to null...
java.lang.Exception: Problem initialising GL
       at net.movegaga.jemu2.FrameWork.createGLWindow(FrameWork.java:231)
       at net.movegaga.jemu2.FrameWork.init(FrameWork.java:70)
       at net.movegaga.jemu2.JEmu2.main(JEmu2.java:33)
Caused by: java.lang.IllegalStateException: Mouse doesn't support native cursors
       at org.lwjgl.input.Mouse.setNativeCursor(Unknown Source)
       at net.movegaga.jemu2.FrameWork.createGLWindow(FrameWork.java:192)
       ... 2 more

This time I saw the display switch then the exception killed it.

[erikd]

Oh, that was a stupid bug .
Should be fixed now (new version is online).

[erikd]

Galaga - "illegal request to write non-integral number of frames" Apparently some kind of JMF error...?

This is definitely an 1.5 bug in JavaSound  

Getting this myself:

Exception in thread "main" java.lang.IllegalArgumentException: illegal request t
o write non-integral number of frames (1470 bytes, frameSize = 4 bytes)

while I did set the frame size to 2:

       AudioFormat format = new AudioFormat(AudioFormat.Encoding.PCM_SIGNED,
               samfreq,
               16,
               1,
               2,
               samfreq,
               true);

Grumble, grumble  

EDIT: Oh, and while I was trying to find a workaround I got to have the pleasure of finding out what Cas meant by the sound of pigs being slaughtered by chainsaws. Damn, that sounds nasty!  

[swpalmer]

Oh, that was a stupid bug .
Should be fixed now (new version is online).

Works fine now on the Mac.  Only complaint is the garbled desktop when I exit (everything on the desktop needs to be forced to repaint otherwise it is complete junk) - but that is a LWJGL bug.

[Matzon]

but that is a LWJGL bug.

Heh, I am tempted to say that it is an OS bug - but fixed it will be

[erikd]

Great, thanks for testing  

I also uploaded a new version which should fix the sound problem on 1.5 which caused a crash.

For those interested, it seems behaviour of SourceDataLine.open() is different on 1.5.
I changed it to use SourceDataLine.open(AudioFormat), and now it works. Seems like a strange design of the api to me, since you have to pass the AudioFormat to construct the SourceDataLine, passing the AudioFormat again while opening the line seems redundant to me.

[erikd]

FYI, I uploaded a web page at http://www.movegaga.nl/80s
Could someone with java (1.)5.0 please confirm that sound is really working now?

[princec]

Works lovely here Ms. Pacman brings back memories.

Cas

[erikd]

Ms. Pacman brings back memories.

Yes it does, doesn't it?  
I still think it's one of the greatest games ever, together with galaga. I still play them regularly...

[erikd]

I added online high score saving (currently only Ms.Pac Man).
Check out http://www.movegaga.nl/80s  

[princec]

Please stick a Defender rom up there.

I just can't get over how cool CottAGE is. It's like, having an arcade machine in a hyperlink. So much less hassle than MAME.

Beware copyright daemons coming to haunt you. Better not get too much publicity eh?

Cas

[erikd]

Please stick a Defender rom up there.

Yeah, defender is soo cool (esp. the explosions )
Unfortunately, CottAGE doesn't support defender yet.
I'll see if I can create a driver for it. If it uses a Z80 or 6809 CPU, it shouldn't be too difficult...

Beware copyright daemons coming to haunt you. Better not get too much publicity eh?

Yeah, I guess that could happen. OTOH, when the CottAGE emulator was still online, we were getting like 3000-4000 unique hits a day but we didn't get any trouble or anything...
I guess that's because most companies that created those games don't exist anymore...

BTW. The predecessor of CottAGE, JEmu, recently started to attract visitors too. I almost forgot about the thing being online, but now it's getting like >2500 visitors a day.
I put a link up there to JEmu2 to attract some visitors there. JEmu2 is the successor of CottAGE and the emulator this thread's about (confused yet? )
Maybe I should get naughty and add some banners up there

[rreyelts]

Hey Eric,

I was wondering if you'd still like some help trying to speed up Jef/Cottage. I don't really have a lot of free time, but I thought it would be fun to give a go at adding dynamic recompilation to your emulator.

I downloaded what was available at the Cottage website (Cottage 0.11), and had a look through the sources. Right now, it looks like the easiest thing to do would be to add dynamic recompilation for a particular cpu (6809 looks the easiest), rather than attempting something more generic.

I think the basic idea would be to try to aggregate several non-branching instructions together. Once you've got that, you could then generate Java bytecode for those instructions. You'd replace the first instruction or two in the list with a special opcode that you'd interpret as a jump to the newly generated bytecode.

This approach might have some problems for roms that are self-rewriting.

So what do you think?

God bless,
-Toby Reyelts

[erikd]

Yes, that would be *really* interesting although I wouldn't know where to start
I did have a look at a site which explains how to do static binary translation (so the original machine code is translated to java, and removing dead flags and such), and that seems to me the way to speed up CPU emulation the most, but I'm not sure (not knowing much about dynamic recompilation if anything)...
When I look at the profiler output, CPU emulation is quite expensive (although it's only ~5-15% on my PC, but that's a quite fast PC), but video emulation is even more expensive in many games... I guess because of lots of array access.
When I would know how to do 'dynarec' or static binary translation, I could have a go at emulating an 68000.

So yes, I'm interested