Greying

Java 2D
#1

Its been a while, but I’m looking at some doing some 2D stuff again. Could someone try this out:

http://www.cokeandcode.com/commander/commander.jnlp

The panel at the top is an accelerated rendering surface. Cursor keys will move the elements around. The FPS is attempted to be fixed to 50.

  • Do you get 50 FPS? (on what hardware)
  • When the bits and pieces move do you get a greying of the white box?
  • Does it run on your platform?

Can anyone explain to me whats causing the greying out of the white box as it moves around?

Cheers in advance for any help,

Kev

#2

Dead on 50Hz, scary 100% CPU and at 90% kernel time (!), P4m2GHz, Nvidia GF4 mobile thing, JRE1.5.0beta1
Didn’t see any greying but it might be coz the TFT screen doesn’t show it up.

Cas :slight_smile:

#3

50 FPS on the dot. Geforce 3, P4 2.4 Win 2k.

I did not see any greying of the box, it stayed white for me.

#4

Greying is only visible when moving the block around with the cursors.

Yeah, the 100% CPU is the sleep routine I think (gagetimer). If anything else should attempt to get some processor time it’ll yield() to it… at least, thats the theory.

I’m running on a lapper to, greying is fairly evident.

Cheers for trying it Cas,

Kev

#5

Just tried it on a desktop box and the greying isn’t present, unfortunately I seem to have rather alot of “tearing” as the box moves around.

Any idea whats causing this?

Kev

#6

If you’re getting tearing, I’m guessing it’s not double buffered?

Worked fine for me, 50fps exactly. Win98SE, 700MHz Athlon, GeForce4 MX 420. Although it hard-crashed my machine on exit, for which I’m willing to blame Firebird’s connection to the WebStart process. ;D

Oh, and the cursor keys move the box in the wrong direction!

#7

See, thats what confused me… it uses a BufferStrategy which I figured was handling that for me. But still with the tearing… maybe I need to go read the wiki or something, huh?

:slight_smile: Only if you think of it as moving the box, its a map, so your moving your viewpoint.

Kev

#8

[quote]See, thats what confused me… it uses a BufferStrategy which I figured was handling that for me. But still with the tearing… maybe I need to go read the wiki or something, huh?
[/quote]
BufferStragegy handles the double/triple/whatever buffers for you, and their swapping to the screen, but it does not always swap at the end of a monitors vertical trace.

IIRC, proper v-sync’ed buffer swapping only happens on windows, in fullscreen mode. Else you get tearing :frowning:

#9

Tearing is a result of not vsyncing on the monitor refresh.

As you are not running fullscreen, you can’t vsync anyway, so don’t worry about it.

  • Do you get 50 FPS? (on what hardware)

the fps counter says 50… that doesn’t mean thats how fast its running ofcourse :wink:

1.33gig Athlon GF2gts

  • When the bits and pieces move do you get a greying of the white box?

no

  • Does it run on your platform?

yeah, WinXP Java 1.5.0beta1

#10

Mac OS X 10.3.2 JRE 1.4.2_03 powerbook G4 1GHz ATI Radeon 9000

Max 25fps low of 16fps :frowning:

no greying.

I sure wish the OS X guys would get accelerated images going…

#11

So then, this is annoying. I want to write a very simple (at least visually) game. RTS style with those little circles representing players and the white bits being walls.

However, if I can even get the map scrolling around without fsking people’s eyes up what hope is there? I was hoping aim the game at low end machines (the type offices are full of - onboard Intel graphics). Was hoping to stay windowed aswell (makes it easy to pretend your working :))

Any ideas folks?

Kev

#12

Tearing is only realy visible when you have high contrast areas (such as white on black in your test app.)
It won’t be a problem in a proper game.

#13

Thats the thing, it was gonna be somewhat a diagramatic representation of the world. So blocks of white on black (or green on black) are fairly likely…

Kev

#14

hmm, well if you have an accurate timer (that doesn’t drift), u could hack together a user feedback calibration system.

Where by, you continually blit a sequence of differently colored rectangles to the screen, and ask for the user to press +/- until the tearing stops.
(you use the +/- adjustment to alter your timing offset)

It is abit of a hack, but, if your careful and your timer is good enough, there is no reason why you can’t artificially keep yourself in sync with the vblank signal :open_mouth:

Or, alternatively, you could write some native code that tied itself to the vblank signal. Got no idea how you would go about doing that… but im (fairly) sure it isn’t impossible.

#15
  • Do you get 50 FPS? (on what hardware)

Rock solid 50fps. K7 500/128mb/gf2mx/1.4.2_03

It would even run on something like a K6-2 300/128mb/banshee with 50fps :slight_smile:

  • When the bits and pieces move do you get a greying of the white box?

No. You use a TFT display don’t you?

You have rise/fall latencies. That’s the time a pixel needs to turn completly white (from black) and vice versa. If it’s moving you have pixels wich turns white and pixels wich turns black (but no real black/white), therefore it appears to be gray.

Usually the effect isn’t that visible because the contrast isn’t that high (eg instead of a 0-100% rise you have something like 45-60%).

  • Does it run on your platform?

Apparently :slight_smile:

#16

[quote]Its been a while, but I’m looking at some doing some 2D stuff again. Could someone try this out:

http://www.cokeandcode.com/commander/commander.jnlp
[/quote]
It won’t run at all on linux. Webstart complains that your JAR is unsigned and is attempting to get full access. It only gives me the options of “Abort” and “Details”.

Because JWS sucks almightily, it doesn’t support copy/paste in the details box so I can’t copy paste the exact details and/or exception.

I’ve never had this problem before, and I’ve not updated my java for many months (1.4.2)

#17

Shame… and it works so well on Windows :slight_smile:

LWJGL! LWJGL! LWJGL! That’s why we created it. Solve those performance blues. Get that smoov and slick feel. Grease that weasel.

Cas :slight_smile:

#18

There you go:

And it’s on WinXP. I wish JWS asked me if I want to run the app instead of just showing that error dialog.

#19

Sorry about that guys, I must have forgotten to sign as I uploaded the new version. Resigned, reuploaded.

LWJGL - doesn’t this mean I automagically using GL tho? With onboard graphics card (old machines) that’d mean I get software GL wouldn’t it? Is that going to be faster than DX in this case? Oh, and does LWJGL have any problems using super early versions of GL? Not ruled the idea out, just need to check.

Kev

#20

Actually we don’t allow software GL rendering - the whole point is that you’re guaranteed hardware acceleration. So maybe not a great solution in that respect but you will get cracking performance on 65% of Windows machines and 95% of Macs and any Linux machines whose users have patience and skill.

Early GL is fine. AF runs entirely on 1.1 and has even been seen running on a Voodoo 3 and a G200. The problem is always the drivers rather than anything else.

Cas :slight_smile: