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  
  does Java combine screen paints?  (Read 2333 times)
0 Members and 1 Guest are viewing this topic.
Offline disintegration

Junior Newbie




Java games rock!


« Posted 2003-01-02 19:01:47 »

do requests for screen painting pile up or does Java know to combine them all into one?

thanks,
dan.
Online princec

JGO Kernel


Medals: 403
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2003-01-02 20:26:52 »

Yes, it combines them up (in Swing, at least - not sure about AWT).

No, it does them asynchronously and whenever it feels like it.

Yes, this means the GUI tends to feel sluggish, and responds in an unpredictable fashion - you can't ensure that a bunch of stuff appears in a single repaint as this occurs in a thread you have no control over.

No, you don't want to use this for games, because it will look awful.

What you really want is active rendering, where you draw everything explicitly, when you want to draw it.

Cas Smiley

Offline disintegration

Junior Newbie




Java games rock!


« Reply #2 - Posted 2003-01-02 23:45:47 »

after reading about volatile images and such, i was under the impression that active rendering is only for full screen exclusive mode.  what i'm working on cannot be full screen, must be windowed.

so, am i wrong?  if so, pointing me in the right direction would be much appreciated.. i.e. a primer, tutorial, etc.  

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

JGO Knight


Medals: 13


falling into the abyss of reality


« Reply #3 - Posted 2003-01-03 00:36:17 »

you've got 2 ways to activly render onto a Component.

1)
1  
component.getGraphics();


which returns you a Graphics context for drawing direct onto the Component. (you'll have to implement double buffering yourself)


OR

2)
1  
2  
3  
4  
5  
6  
component.createBufferStrategy(numOfBuffers);
// ^^ this creates an optimal buffer strategy
// for bliting onto the Component, and uses the
// number of buffers specified (2 will usually suffice)

BufferStrategy strategy = component.getBufferStrategy();


and then in your render loop, you want something like...

1  
2  
3  
4  
5  
6  
Graphics g = strategy.getDrawGraphics();

// misc render operations

g.dispose();
strategy.show();


incidentally, the process of
Quote
combining them up
is coalescing Wink. and can be controlled by overriding the method in Component :-

1  
protected  AWTEvent coalesceEvents(AWTEvent existingEvent, AWTEvent newEvent)


though its still crap for games even when paint event coalescing has been disabled.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #4 - Posted 2003-01-03 07:12:59 »

Depending on the game, I think Swing is very well suited t odo it, just because it HAS smart mechanims to perform minimal repaints. And there no reason why it should be ugly, bc. it can look whatever you want to look.

But it is for sure not suitable for 50 repaints a second. I tried it and it just didn't work out. But if you have very high resolution, multiple layers, much to clip,..... I cannot see any reason not to use Swings redraw mechanisms. Take a look at JScrollpane than e.g. - which gives you minimal repaint areas on scrolling.


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Abuse

JGO Knight


Medals: 13


falling into the abyss of reality


« Reply #5 - Posted 2003-01-04 01:58:08 »

Quote
Depending on the game, I think Swing is very well suited t odo it, just because it HAS smart mechanims to perform minimal repaints. And there no reason why it should be ugly, bc. it can look whatever you want to look.

But it is for sure not suitable for 50 repaints a second. I tried it and it just didn't work out. But if you have very high resolution, multiple layers, much to clip,..... I cannot see any reason not to use Swings redraw mechanisms. Take a look at JScrollpane than e.g. - which gives you minimal repaint areas on scrolling.



Swing in a game  Huh

I can draw only 1 conclusion.... you are mad Grin

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline pepe

Junior Duke




Nothing unreal exists


« Reply #6 - Posted 2003-01-04 02:18:49 »

Quote

Swing in a game  Huh
I can draw only 1 conclusion.... you are mad Grin

I think we'll (we've) all heard this:
"A game in java Huh
I can draw only 1 conclusion.... you are mad Grin"

Madness depends on the eye of the one that judges. If the mechanism used does the task, why not?
So, as we are mad anyway, going deeper into madness only matters if we don't succeed.  Grin

Home page: http://frederic.barachant.com
------------------------------------------------------
GoSub: java2D gamechmark http://frederic.barachant.com/GoSub/GoSub.jnlp
Offline SpongeBob

Junior Duke




Who lives in a pinnapple under the sea


« Reply #7 - Posted 2003-01-04 02:22:28 »

Quote
Swing in a game


Swings is not all that bad if your not making a twitch game (something that needs high FPS).  

Talking on this subject though, has anyone ever used SWT to create a game or graphical animation?  Does SWT render components and events in a seperate thread like the AWT?  If I remember right, I seen some code doing event polling manually....
Offline sma

Junior Duke





« Reply #8 - Posted 2003-01-10 08:15:10 »

Quote

Does SWT render components and events in a seperate thread like the AWT?  If I remember right, I seen some code doing event polling manually....


You're right. SWT doesn't use a separate thread but uses a dispatch loop that normally is installed in the application's main thread. As the main thread is idle in most AWT applications, SWT is slightly more efficient here.  Like AWT, SWT can only manipulate components in that thread. Unlike AWT, SWT will throw errors if you try to do this from a different thread.  This helps catching programming errors.

Rendering is done based on OS callbacks. I can only talk about Windows here. Windows itself has a very efficient way to combine damage rectangles and builds up a damage region (a set of damage rectangles) which is then used to clip the drawings. This all happens outside of Java and directly in the ON_PAINT callback when Windows is in a state for fast damage repair.  And custom paint methods are called just once.

With AWT on the other hand, repaint requests are taken from the OS and queued for the AWT event thread. Windows is told that everthing is done and (I'm not sure here) Windows will do its default background painting.  Some time later, AWT will combine damage rectangles to a larger damage rectangle, if possible, but has no concept of a damage region which would be more efficient. Instead, it will call all paint methods multiple times for different rectangles which is obviously slower. AWT will explicitely setup a Graphics object somehow connected to a Windows GC and finally the damaged parts of the screen are repainted.  This is one reason that AWT and Swing often feel a little bit more sluggish.

Regarding animations, SWT uses DIBs and the GDI bitmap functions but no directX stuff.  Therefore, Swing might be faster.

I'm currently creating a tiny freecell-game with SWT and I'm quite satisfied with the drawing speed, it's okay even without double buffering and it feels a bit faster than AWT. I haven't tried.  

However, I'm only blitting static images. SWT has no concept of image producers or image sources. If you want to create your image by hand, you'd setup an ImageData object which is then converted into a real Image object which can then drawn on a Canvas object.  I don't know how fast this is compared to AWT.

Stefan

.: Truth Until Paradox!
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 (25 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 (50 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 (75 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!