[Game] worm

[newdep]

I think its a key-event or buffer update issue.. but not 100% sure..



here is the demo ->

(load "http://www.nodep.nl/downloads/newlisp/sound.lsp">//http://www.nodep.nl/downloads/newlisp/sound.lsp")

(it includes the wav file)



when you start it... press some random keys on the keyboard

and keep you ear on the sound...



Its also happens without pressing the keyboard checked now...





PS: only happens on Linux as it seems now..



Norman.

[Lutz]

Perhaps a platform issue. On OS X this seems to run forever with or without keyboard input. When doing keyboard input the keyboard events are lined up, and the key doesn't display until the sound has finished. When presssing 1 to 9 in a row, they appear one by one after a plop. Sometimes the same number appears more than once, when 2 plops appear in-between serving the keyboard queue.



Lutz

[newdep]

Yes could very well be a platform issue.. But i would expect Java to take

control of this..like tuning speed and threads in its VM.. But then again we have

the GS in between where we have an IO queue.. On windows its also different..odd ;-)



On linux, while NOT pressing keys its not constant a 1 second beep.. its

very random.. like a hickup in between.. then some silence..etc.. but the key-event

is here synchrone..though not inline with the beep..



well I think i have to live with it ;-)





PS: Could it behaps be related to the disk-read of the sound file? and buffering

related to that action?

[Lutz]

In a later release gs:play-sound could be in an extra Java thread, so other events can be served during sound playing.



The choppiness (hickups) you are observing, is Java's carbage collection kicking in and absorbing cycles. For the time beeing the only thing you can do, is to make sounds as short as possible.



The IO queue will always be something, which has to be dealt with. Thats why real-world gaming software is interrupt driven. The moment you hit the button or move the stick, it gets served as a pirority.



Lutz

[newdep]

Aha..yes i thought so... another java thread would be very welcom but

i think the GS should not have too many java threads running, but GS cant get around that..;-)



Is there a more direct way to communicate towards Java? I could emagine

that IPC's or pipe's are much quicker then network events for example... Or perhpas direct API calls or the whole guiserver.lsp in JAVA itself? ;-)



For now the networking speed is fine the only problem is indeed the Sync

of processes and the speed handling when building game-like applications

with GS... widgets do great and small canvas tools too..but i thing the "worm.lsp"

almost is on its limits regarding interaction of events..



Aaa its still a joy ;-)



regards, Norman.