Actually, thinking about this - you could reduce average wait time (if that is significant) by introducing a third instance which does nothing but relay messages.
(You could pilot this using a file or two, to represent the middle layer, but that could introduce occasional errors with partially written files. It may also have performance problems because files what to be written elsewhere. But it might be that these issues are too minor to be worth worrying about.) Thanks, -- Raul On Fri, Aug 29, 2014 at 7:49 PM, Raul Miller <[email protected]> wrote: > What I think you want to do here is run two instances of J. > > One instance for your "ticks" and the other for your "frames". > > Sockets would be a way for these instances to communicate. Loosely > speaking: one of the instances would be a "web browser" and the other > would be a "web server" (but the complexities of the various http > protocol issues would be total overkill for something like this). > > Note also that you'll have to do a certain amount of experimenting. If > you try to do "too much" you'll start spilling more time than you can > comfortably deal with. So you'll want to get something working and as > you progress through your game development you will have to adjust > both your game play and your code to live with what your current > system seems able to deal with. It'll be good to have a rough idea of > where you want to head but ... a lot will change. This will be > frustrating, at times. > > Anyways... > > That's the overview. > > Also keep in mind that there are generally multiple ways of > accomplishing each aspect of your project. > > For example: the whole point of this "dual J" design is so that the > two different aspects of the system can become out of sync with each > other. That's a complication and a questionable one. On the other > hand, this will also let you take advantage of two cpus, and that can > be a good thing. > > But how do you let your two J programs run out of sync with each other > without getting lost? > > Basically, one of them is going to have to wait some of the time or be > ignored some of the time. > > In other words the client makes a request to the server and waits for > the server to get around to responding. The server tries to make > handling requests quick and simple. In your proposed outline, this > makes the "tick" system the server - and ticks will need to be fast > enough to keep your frame server from lagging too much (but slow > enough to be meaningful). > > (There's other ways of doing this, but that's the simplest, given what > you've described.) > > I'd also point you at J's socket labs, to get started. Note that this > puts you at the level of sending text messages - very simple > mechanism. Simple is good, though. > > Would that be enough to get you started? > > Of course another approach would be to just keep frames and ticks in > sync. That's much simpler. > > Simple is good. > > Thanks, > > -- > Raul > > > On Fri, Aug 29, 2014 at 7:23 PM, Neill Robson <[email protected]> > wrote: >> Hello to all on the forum! If any you happen to know Mr. (Henry) Rich, I'm >> one of his students. >> >> The most direct way to create a constantly updating screen in J is to run >> the relevant gl2 commands in a sys_timer verb, set to repeat at a certain >> interval by the window driver. However, for a video game with any more than >> rudimentary complexity, one would wish to separate "frames" (drawing the >> image to the screen) from "ticks" (computing the game logic). Preferably, >> ticks would happen at a constant rate per second, and then the remaining >> computation time would be spent rendering frames. In Java, that would be >> implemented somehow similar to this: >> >> long lastTime = System.nanoTime(); >> double nsPerTick = 1000000000D / 60D; >> double delta = 0; >> while (running) { >> long now = System.nanoTime(); >> // Determine how long it has been since the last tick >> delta += (now - lastTime) / nsPerTick; >> lastTime = now; >> >> // If more than 1/60th of a second has passed, tick for each >> 60th. >> while (delta >= 1) { >> ticks++; >> tick(); >> delta -= 1; >> } >> >> render(); >> } >> >> Of course, J is *much* different than Java in many respects. "While" loops >> are frowned upon in this situation, because functional languages get hung >> up in the while loop until it is "finished;" however, for video games this >> "hanging up" seems to be exactly what is needed (without the side effects >> of freezing the terminal, of course). >> >> I have been directed towards sockets for this sort of situation in the >> past, but I've never progressed far enough down that route to understand >> the gritty details of how to implement such a system. >> >> Would someone on the forum be able to guide me towards a solution? To >> restate the problem, I'm looking for the functional (J) equivalent of a >> "while" loop that repeats one function at a fixed rate and runs the other >> as frequently as the host machine safely allows. >> >> Thank you for your assistance, and apologies for the protracted & ugly Java >> example! >> >> -- >> -Neill >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
