Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (575)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Why is _tick exposed to Java?  (Read 1679 times)
0 Members and 1 Guest are viewing this topic.
Offline gregorypierce

Senior Duke




I come upon thee like the blue screen of death....


« Posted 2003-05-20 02:39:29 »

While working on the port. Mr. Palmer and I ran across Java_org.lwjgl_Window_tick(). Why is this exposed to a Java program? I can't imagine why such a platform specific function would be exposed to a Java program. There isn't anything a Java programmer can do with it except forget to call it and end up with a queue full of windowing messages. Why isn't this encapsulated within the LWJGL framework? (like in swap or something).

Next up, shouldn't this only show up in programs that run in windowed mode? If an application requests to only ever run in fullscreen - shouldn't this function just go away altogether?


http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #1 - Posted 2003-05-20 03:14:04 »

Well generally, I thinkg Cas would like to take this one Wink

The problem is that there are no methods that are guarenteed to be called at any one time, there was therefore no other place to stick it. At least thats what I remember from the discussion.

Quote
Next up, shouldn't this only show up in programs that run in windowed mode? If an application requests to only ever run in fullscreen
Theoretically, yes - however that too would also just introduce the posibility of bugs. Better to always just call tick()

Quote
Next up, shouldn't this only show up in programs that run in windowed mode? If an application requests to only ever run in fullscreen
If it is possible, I would love for it to go away...

Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2003-05-20 10:35:07 »

There are just Some Things That Need To Be Done to make the library work, cross-platformwise. Very much like you need to call paint() to get the display to swap buffers, you need to call tick() to take care of stuff. What the stuff actually is isn't defined, except that it must be called every game tick and it's therefore a great place for the aspiring LWJGL porter to process the underlying OS message loop.

We did have tick() hidden away in paint() at one point but this breaks in certain situations or wastes CPU cycles on those systems that prefer to share them. You don't paint(), for example, when you are in isMinimized() state.

The proper way to do a main loop is this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
while (!finished) {

      gl.tick();

      if (gl.isMinimized()) {
            if (gl.isDirty())
                  gl.paint();
            Thread.sleep(200);
            continue;
      } else if (gl.isCloseRequested()) {
            finished = true;
      }

      // Poll devices, read buffers, tick, render

      // Paint the display and take care of all the
      // OS windowing functions
      gl.paint();

      // Cap frame rate

}


It's so proper we nearly had a go at encapsulating it in the library but something felt wrong so we scrapped it.

Cas Smiley

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

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #3 - Posted 2003-05-20 11:22:04 »

Why not put this loop in the library as a convenience method that calls through an interface to activate the game logic every 'tick'?   It could still be optional to actually use this loop or roll your own... but having it would help in most cases.

Is there any way that you could FORCE apps to fail that don't call tick, so as to make it harder to forget?

Offline gregorypierce

Senior Duke




I come upon thee like the blue screen of death....


« Reply #4 - Posted 2003-05-21 00:13:39 »

The problem is that its just really bad practice to HAVE to do something all the time and then give you a function call to make sure its done. If it needs to be done all the time, there is no reason at all to expose it to the library. There are no user servicable parts inside so all it really done is add a breaking point IMHO.

Tick should be buried deep deep in the bowels of LWJGL because it really serves no purpose to the application developer. Its akin to having AWT or Swing require the developer to call something when their GUI is up. If its mandatory and the user can't do anything with it - they need not know of its existence.

Since this is at the entry point in the rendering loop I remain unclear as to why it could not be encapsulated like many of the calls that the input or audio system encapsulates. Under what conditions does it break?

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #5 - Posted 2003-05-21 04:02:22 »

Quote
Is there any way that you could FORCE apps to fail that don't call tick, so as to make it harder to forget?
Yes, we could have some flag which is set upon paint - and if it is still set on the next paint (or 5 paints) we could throw an exception.

Quote
The problem is that its just really bad practice to HAVE to do something all the time and then give you a function call to make sure its done.
Agreed. However you don't HAVE to call it (at least in theory) - granted windowed mode would be completely f*cked.

In theory I dislike having to call a method, just because the subsystem requires it - but we all have to do that in some way with most api's - take the win32 api, *all* apps have to have the following (in one way or another):
1  
2  
3  
4  
5  
6  
7  
8  
9  
      // Main message loop:
      while (GetMessage(&msg, NULL, 0, 0))
      {
            if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
            {
                  TranslateMessage(&msg);
                  DispatchMessage(&msg);
            }
      }
I don't like that I need to do that - but such is life.

Since there are no methods that are guarenteed to be called at any time (except tick(), which we have defined as being a must call method), the only other way to implement it, is by spawning a thread to do this - which is just as evil.

So we're left with the following solutions:
1 -  mandetory tick() = allows the developer to control when the subsystem should be run.

2 - no tick - the developer does zilch, but has no control over when the subsystem is run.

Of the two, I think the former is the least evil.
That said, I am very open for suggestions...

Offline gregorypierce

Senior Duke




I come upon thee like the blue screen of death....


« Reply #6 - Posted 2003-05-21 15:52:39 »

Personally I'm for number 2.

Giving the developer control over when the wndproc or other event pump is called is a tragic mistake because at the Java layer it doesn't matter. Outside of calling it at the point of paint() what more control would you want to have over it? Paint() is something that it makes perfect sense for the developer to have control over becuase when you process messages makes sense. It doesn't however bring anything to the table to have the developer controlling when tick() is called (not to mention that the name is overloaded for rendering in most cases - processNativeEvents() would make more sense). Maybe I'm alone on that one, but tick crosses a system boundary for no discernable reason.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Pages: [1]
  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.

Longarmx (35 views)
2014-10-17 03:59:02

Norakomi (26 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (26 views)
2014-10-15 16:18:58

TehJavaDev (50 views)
2014-10-14 00:39:48

TehJavaDev (52 views)
2014-10-14 00:35:47

TehJavaDev (40 views)
2014-10-14 00:32:37

BurntPizza (63 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (76 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!