Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (524)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (592)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3
  ignore  |  Print  
  JDK 1.5.0-beta2 is now available  (Read 10300 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #30 - Posted 2004-06-01 18:25:02 »

The reason some games run fast and some slow on your machine is probably some fecked up Linux twit-mode X configuration foolishness. There's about 4MB of textures *total* used in Hallucinogenesis yet it's not getting hardware accelerated. I find this difficult to believe Wink

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #31 - Posted 2004-06-01 22:22:55 »

Quote
The reason some games run fast and some slow on your machine is probably some fecked up Linux twit-mode X configuration foolishness. There's about 4MB of textures *total* used in Hallucinogenesis yet it's not getting hardware accelerated. I find this difficult to believe Wink


There's very very very little in the way of user config on this machine - just enough to force the stupid stupid stupid nvidia driver that yes the 1400x1050 LCD can display more than 800x600 without blowing up (it probes the LCD and decides it's not safe to go that high, so you have to disable the autoprobing. Sigh).

Given the crapness of nv drivers (all platforms) and their tendency to add regression bugs every other release (I've spent too many years with Detonator drivers, always saving backups of the last 3 versions because you so often need to downgrade to keep your games working Sad) I would currently guess it's driver bugs.

But the 16Mb is unusual for a GF2, and we know it does small java things (e.g. demos) with acceleration, so I just thought "maybe...".

(EDIT: for "know" in above para read "think". If you can point me to a simple demo that I shouldn't be able to do without hw acceleration, I could verify)

malloc will be first against the wall when the revolution comes...
Offline Olof Hanell

Senior Newbie




Smooth scrolling rocks.


« Reply #32 - Posted 2004-06-02 06:59:32 »

One thing I've noted is that the new version(probably since 1.5.0 beta1?) uses XP-LookAndFell. Okay, that's nice, but, I'm using windows-classic-theme just to get rid of that plastic(in my opinion) look, but, my swing GUIs uses some standard winXP-theme-style.

(I do not use any UIManager.setLook...) It may be that?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline javazoid

Junior Devvie




Where's Flender?


« Reply #33 - Posted 2004-06-02 07:11:48 »

Chris,
I did some tests by modifying the good old balls.jar source code by introducing an affinettransform that rotates the gfx context.

(using a Radeon 7000 agp 32Mb with "working"drivers (6.14.10.6396))

1. transforms are hw accelerated. That makes the fps jump very high (up to 100x comparing to "standard" java2d) !

2. bilinear interpolation does not work. Everything seems to be non interpolated.

3. the graphics output looks like being 16bit instead of 32 bit (i use a red shaded translucent ball for the test). This happens with managed images. Volatile images seem to be correct.

4. I can only use resolutions up to 640x480. I only get a black screen with higher resolutions.

I hope this helps.
I understand that the points 2,3,4 may be only driver/board problems, that's why I think that some "Sun-made" testcode could be of great help in order to test the ogl pipeline both for performance and compliance.

Cheers,

Mik



Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #34 - Posted 2004-06-02 07:36:29 »

Chris - please have a word with the desktop team and get them to turn on font antialiasing for font rendering by default. Java applications just look seriously unprofessional these days because of the blocky fonts.

Webstart is still looking totally, utterly, atrociously ugly. Take the programmers out and hang them by the toenails until they're sorry, and then hire someone who knows about UIs to design it.

I advise losing the XP L&F for Webstart too and going for something a little more "dynamic" (eg. skinned). Make it flashy. Make it special. Make it neat. Make it antialiased. Make it feel like a Mac GUI. Make it feel like a really slick bit of Sony hardware. Don't make it feel like a rush job written by someone who doesn't care.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #35 - Posted 2004-06-02 07:51:35 »

Doew webstart still pop up that horrible "Desktop intergration" dialog? It would be so nice if you could disable that via a tag in the webstart script.

I wouldn't mind too much but:
1. It has an annoying tendancy to pop up behind every other window, making lots of test subjects think your app has crashed.
2. It doesn't even work whenever I've tried it. Shocked

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #36 - Posted 2004-06-02 08:40:02 »

That feature really does need fixing too. I hope Chris can get some feedback from us under the right noses (I've given up on bug parade after the structs fiasco)

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #37 - Posted 2004-06-02 10:25:44 »

Oh dear. beta 2 has a nasty change (bug?) under linux: MouseListener Sad.

Where it used to:
- btn pressed = mousePressed
- mouse moved = mouseDragged
- btn released = mouseReleased
- mouse moved = mouseMoved
- btn pressed = mousePressed
- btn released = mouseReleased
-        + mouseClicked

it now:
- mousePressed
- mouseDragged
- mouseReleased
- *** mouseClicked ***
- ...

So every GUI with 1.5 beta 2 is "broken" - you can't even drag the windows used by the Sun tutorials without them alternately max/restoring on every drag (they seem to read a drag + "this new phantom click" == double-click) and all my Swing GUIs that e.g. use clicked for selection and dragged for behaviour are alternately deselecting/reselecting on every drag Sad. Makes them unusable.

Is this how it is on windows already? It's been so long since I used one of my own swing guis in windows I can't remember Wink...

(i.e. this could be like the linux broken keylistener behaviour - something that's just been broken on linux so long I've become used to it, and now it's been fixed Smiley)

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #38 - Posted 2004-06-02 11:28:46 »

MouseListener seems to work on Windows. I can drag windows around without them doing weird things at least.

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #39 - Posted 2004-06-02 11:29:40 »

Has anyone else noticed that beta 2 will crash the VM on Windows if you use JFileChoosers and have broken shortcuts on your desktop?

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

Junior Devvie




Java games rock!


« Reply #40 - Posted 2004-06-02 11:34:11 »

Quote
Has anyone else noticed that beta 2 will crash the VM on Windows if you use JFileChoosers and have broken shortcuts on your desktop?


I did. It doesn't crash, it complaints about a million times about it. I even had same expirience with some app's withouth opening JFileChooser (?!). On the side note, I'm unable to open anything with WebStart....something wiht io exception and stream closed.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #41 - Posted 2004-06-02 11:37:44 »

Interesting, WebStart works for me.

With broken shortcuts, I get a VM crash after going through all the "Prblem with shortcut" dialogs..  Win32ShellFolder... something or other kills things.  Also related to the Finalizer thread and the initialization of a JFileChooser (that never has to be actually shown).

Offline selendic

Junior Devvie




Java games rock!


« Reply #42 - Posted 2004-06-02 11:40:25 »

Quote
Interesting, WebStart works for me.

With broken shortcuts, I get a VM crash after going through all the "Prblem with shortcut" dialogs..  Win32ShellFolder... something or other kills things.  Also related to the Finalizer thread and the initialization of a JFileChooser (that never has to be actually shown).


Could you please try some of JGoodies (jgoodies.com) demos? I'm able to run some but not all with WS.
Offline deepFlame

Senior Newbie




Java games rock!


« Reply #43 - Posted 2004-06-03 06:42:12 »

WebStart doesn't work for me either.
Often it stops installing with the "Stream Closed"-Exception. Some links work, some sometimes (ofter a few clicks) and some never. Really strange.
The JGoodies demo dosn't work for example.

Thought beta 2 got even better  :-/
Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #44 - Posted 2004-06-03 06:45:42 »

Quote


Could you please try some of JGoodies (jgoodies.com) demos? I'm able to run some but not all with WS.


I can run all of them, but not always on the inital attempt. Sometimes I have to try several times.

I have to use a proxy here that I could not tunnel with WS1.4.2. So WS1.5 is a big progress concerning that.

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

JGO Coder


Medals: 2


pixels! :x


« Reply #45 - Posted 2004-06-03 07:02:10 »

>1. It has an annoying tendancy to pop up behind every
>other window, making lots of test subjects think your app
>has crashed.

It's like that since... uhm... ever?

That dialog(*) is modal and it seems that it has null as parent. Therefore no notification if webstart gets the focus, no getting visible... but still it eats the focus.

(* that's also true for the other one... what were they thinking?)

弾幕 ☆ @mahonnaiseblog
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #46 - Posted 2004-06-03 07:17:16 »

This is a generic Java AWT problem too. Dialog windows can be placed behind their parent windows, and hence unclickable on. It's been like that for nearly a decade. Unbelievable.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #47 - Posted 2004-06-03 08:08:41 »

Quote
Is this how it is on windows already? It's been so long since I used one of my own swing guis in windows I can't remember Wink...

Nope, on windows you only get a clicked event if you press and release without moving the mouse, so the sequence of events you've got there appears to be broken. Shocked

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #48 - Posted 2004-06-03 16:23:58 »

The JFileDialog problem is a known bug (5049016, 5056514), will be fixed by fcs.

I've sent your feedback on other stuff to appropriate people..
Offline campbell

Junior Devvie




Java games rock!


« Reply #49 - Posted 2004-06-03 16:43:45 »

Quote


I believe you, but...where's it all going? It's only 1.5 million pixels, which is presumably no more than 6 MB. Is it something like: 6MB for current screen, 6MB for grahics driver double-buffer ...leaving a paltry 4Mb for apps like Java?

And does this mean it should suddenly get very much faster if I resize the window down to, say, 640x480?


I'm not exactly sure about the internals of Nvidia's drivers, but depending on the pixel format used, they may allocate more than just 4 bytes per pixel.  For pbuffers, you'll have 4 bytes per pixel for the front color buffer, (possibly) 4 bytes per pixel for the back color buffer (yes, we shouldn't be using double buffered pbuffers, but in some cases we can't get around it), and another 1 byte per pixel for the stencil buffer.  So now you're talking about 12MB or more just for a pbuffer of that size.  I'll try to run some OGL tests on a low-VRAM config similar to yours to see if I can find ways to reduce the amount of VRAM used by pbuffers.

And yes, I would hope that if you reduced the size of your Swing window, everything would fit into VRAM and performance should improve; well, at least it won't be painting a scanline at a time Smiley

Thanks,
Chris
Offline campbell

Junior Devvie




Java games rock!


« Reply #50 - Posted 2004-06-03 16:48:33 »

Quote
Chris,
I did some tests by modifying the good old balls.jar source code by introducing an affinettransform that rotates the gfx context.

(using a Radeon 7000 agp 32Mb with "working"drivers (6.14.10.6396))

1. transforms are hw accelerated. That makes the fps jump very high (up to 100x comparing to "standard" java2d) !

2. bilinear interpolation does not work. Everything seems to be non interpolated.

3. the graphics output looks like being 16bit instead of 32 bit (i use a red shaded translucent ball for the test). This happens with managed images. Volatile images seem to be correct.

4. I can only use resolutions up to 640x480. I only get a black screen with higher resolutions.

I hope this helps.
I understand that the points 2,3,4 may be only driver/board problems, that's why I think that some "Sun-made" testcode could be of great help in order to test the ogl pipeline both for performance and compliance.


Hi Mik,

Thanks for the testing results... Could you send me your modified source code, and your rebuilt balls.jar?  We have a similarly modified version of that demo in-house that we use for testing all the time, and I haven't noticed those issues that you've reported (but I haven't done much testing on a Radeon 7000 either).

Thanks,
Chris
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #51 - Posted 2004-06-03 16:53:18 »

Quote

And yes, I would hope that if you reduced the size of your Swing window, everything would fit into VRAM and performance should improve; well, at least it won't be painting a scanline at a time Smiley

Thanks,
Chris


Having a little time and patience to spare, I tried again and waited for the slow updates long enough to do some experimentation.

It *seems* as though either:
- this is not a "not enough RAM" problem or:
- it is using a truly terrifying amount of RAM (i.e. there's some serious bug somewhere)

I say this because with caching situations you expect performance to go:
- terrible -> very slight improvement -> sudden huge improvement - > very good

But I found that the performance was directly varying with window size, all the way down to 458x320 (window manager's reported window size; actual java painted area probably 10-20 pixels narrower/shorter). Beyond that there's so little visible it's hard to tell,  but I went all the way to 205x168 and was still getting window updates at a pitiful 8 FPS or so. Just slightly faster than I can reliably count them manually, but slow enough you can still see the window redrawing. And this is a TINY surface area (just 32,000 pixels or so Sad).

So. Maybe it's not a RAM problem.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #52 - Posted 2004-06-03 17:00:42 »

EDIT: all the below is using JDK 1.4.2_04 - this is a problem with OpenGL acceleration both in JOGL and LWJGL on 1.4. Just to make it clear Smiley

...but I have a similar problem with some OpenGL Java games that *did* get much better with resizing. I went from 0.25 FPS to 63 FPS fby resizing just a 100 pixels or so - although I'm not yet sure if it's the "fewer pixels" causing this or just the act of "switching from MAXIMIZED state to RESTORED state"

look at my post here for info:

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=Announcements;action=display;num=1086016376;start=30#35

This is a JOGL game.

Although, as mentiuoned in that post:
- on the menu screen of the game, with VERY little being rendered, every pixel reduction increases performance (just like with vanilla swing using sun.java2d.opengl=true, as described in previous post)
- in the *game* itself resizing has almost no effect - I either have around 60 FPS or (if I maximize) all performance vanishes and it's sub-1 FPS again.

So, in that game, I'm seeing BOTH behaviour consistent with mem problems AND non-consistent (going by my layman's expectations).

So, perhaps my above comments suggesting this isn't a mem problem are a sensible-but-incorrect guess, and in fact there's just some kind of special case (for swing and for this game's menu) where it behaves strangely.

PS: if you have any test apps you want me to run, I'd be glad to - I'd really like to track down the problem...I'd just like to understand what's going on, even if the only possible solution is "never buy an nvidia laptop again" or similar Wink Tongue

malloc will be first against the wall when the revolution comes...
Offline campbell

Junior Devvie




Java games rock!


« Reply #53 - Posted 2004-06-03 17:06:40 »

Quote
Chris - please have a word with the desktop team and get them to turn on font antialiasing for font rendering by default. Java applications just look seriously unprofessional these days because of the blocky fonts.


Hi Cas,

In beta2, text is now antialiased by default for the GTK L&F if AA text is enabled on the desktop (see 5030990).  We will likely do the same for the Windows L&F in a future release, but probably not for Tiger.

I imagine you're mostly concerned with Windows (correct me if I'm wrong).  Are you referring to the fonts used for the WinXP L&F or for Metal/Ocean?  Are you comparing to the way fonts are rendered in native applications?  When you say "blocky fonts", are you referring to the bold fonts used by the Metal L&F?  (In beta2, you can make Metal's default font plain instead of bold.  I can't remember exactly the property used, but you can see how they did it in SwingSet2...)

Trust me when I say we work very hard to make text rendering quality a priority.  We have more improvements on the way to improve quality of text on LCD screens, and to use AA text whenever appropriate (as mentioned above), and so on.  Native L&F fidelity is a must if Java apps are to blend in seamlessly with the desktop environment...

Your other comments regarding WebStart have been forward to the appropriate folks.  (No toenails were harmed, nor other violent actions pursued...)

Thanks,
Chris
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #54 - Posted 2004-06-03 20:10:49 »

Quote
In beta2, text is now antialiased by default for the GTK L&F if AA text is enabled on the desktop (see 5030990).  

Hmm, that doesn't really seem like a good idea from a quality point of view. I don't know what others think but the built-in windows text antialiasing is pretty bad quality IMHO, it tends to just blur text and give a generally worse output. The result being that I don't know many people who choose to actually use it.

Java text on the other hand looks so much better with AA, especially with the default bold text. It seems like you'd end up with only a minority of people actually seeing the text quality improve when really you want everyone to be using it. Perhaps an option in the Java control panel would be a better idea (and let it default to on).

It seems silly to spend so much time getting good, high quality font rendering and then not show it to the user by default.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #55 - Posted 2004-06-03 21:14:23 »

You must antialias the fonts on the Windows L&Fs if the user has specified AA fonts for their desktop or the experience is extremely jarring.

Cas Smiley

Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #56 - Posted 2004-06-03 21:56:08 »

Quote
You must antialias the fonts on the Windows L&Fs if the user has specified AA fonts for their desktop or the experience is extremely jarring.


Even at the expense of performance?
Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #57 - Posted 2004-06-03 22:26:46 »

The problem with mouse events is described in this bugreport:
 5039416: REGRESSION: Extra mouse click dispatched after press-drag-release sequence

The workaround is to use Motif toolkit:
-Dawt.toolkit=sun.awt.motif.MToolkit

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #58 - Posted 2004-06-03 22:39:03 »

Quote
The problem with mouse events is described in this bugreport:
 5039416: REGRESSION: Extra mouse click dispatched after press-drag-release sequence

The workaround is to use Motif toolkit:
-Dawt.toolkit=sun.awt.motif.MToolkit



Thanks. I guessed someone else would have got there first with the bugreport Smiley

malloc will be first against the wall when the revolution comes...
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #59 - Posted 2004-06-04 07:43:20 »

Yes, even at the expense of performance. If the user has already decided to antialias their Windows fonts then it's not for Java to decide not do antialias them too on the basis of performance.

Besides, we really are talking about a tiny performance hit if you profile a typical Java client application.

Cas Smiley

Pages: 1 [2] 3
  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.

toopeicgaming1999 (65 views)
2014-11-26 15:22:04

toopeicgaming1999 (58 views)
2014-11-26 15:20:36

toopeicgaming1999 (11 views)
2014-11-26 15:20:08

SHC (24 views)
2014-11-25 12:00:59

SHC (24 views)
2014-11-25 11:53:45

Norakomi (28 views)
2014-11-25 11:26:43

Gibbo3771 (24 views)
2014-11-24 19:59:16

trollwarrior1 (37 views)
2014-11-22 12:13:56

xFryIx (76 views)
2014-11-13 12:34:49

digdugdiggy (53 views)
2014-11-12 21:11:50
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!