Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (726)
Games in Android Showcase (216)
games submitted by our members
Games in WIP (796)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Game Development / Game Play & Game Design / Varying Screen Dimensions on: 2007-01-09 04:48:14
I'm curious about how folks like to handle variable screen dimensions in 2D games, particularly as it relates to game play and "fairness". This goes for either changes in the window size or screen resolution, which is effectively the same.

Imagining that a game was designed for a standard 4:3 ratio, the following can be done when the user or game switches to another screen dimension:

(a) Lock the ratio at a fixed value: either keep the world view dimensions by scaling the view down to fit in the screen dimension, or locking the window size or screen resolution to a preferred ratio. The first one will create unused screen space on either the sides or top/bottom of the screen. I imagine this is almost necessary for games where the range of visibility is a critical factor in play.
(b) Use the extra screen space to give more world view. Depending on how the window is shaped, this can give either a vertical or horizontal view advantage to the player.
(c) Truncate the view either vertically or horizontally to match the minimum world dimension to the screen. This creates a player disadvantage for non-standard dimensions.
(d) Others?

What's your preference? What kinds of games are most/least affected by this, and how? Do you let players who have large or wide-screen displays get their money's worth ? Smiley (or folks who are willing to create a narrow wide window at the expense of detail). Do you fill dead space with pretty filler or leave it black?

I think varying ratios are less noticeable in 3D games, especially where changing the FOV is allowed -- the player can trade off field-of-view for detail at will, and a little extra screen space on either side due to a funky resolution doesn't seem to make much difference, though I've never played 3D on a true wide-screen -- maybe I'm totally wrong.

2  Java Game APIs & Engines / Java 2D / JFrame Resize at Fixed Ratio on: 2005-04-07 19:29:32

Does anyone know how to lock a JFrame to resizing at a specific height-width ratio, specifically to maintain some ratio of a child component?

My setup right now: I have a JFrame in windowed mode with a menu bar and a JPanel in the content pane for rendering. (Asteroids clone). I'd like to make the JFrame resizable by the user, but I'd like to allow only sizes that keep the JPanel square.

So far, I can imagine trapping component resize events on the JFrame, doing some math in regards to figuring out how big the JFrame should be to make the JPanel square, and then posting setSize() on the JFrame.

Is there a better way to do it (with a layout manager, or something similar)? Something like trap resize events on the JPanel, set max and min size to that, and then will JFrame resize accordingly (perhaps with a call to pack())? Or is there some other interface which can be used to implement this?


3  Game Development / Performance Tuning / GC minimization importance on: 2005-01-31 00:22:15
How important is it to minimize garbage collection in a realtime game on JDK1.5.0/WinXP ?

I have a relatively simple asteroids clone that I wrote in 1999 on JDK1.2 / Win98 that I'm rewriting for an example web release. Back then I ended up retrofitting it so that it would resuse every object that it could to help cut down on garbage collection pauses (it tripled the time between pauses, which was good enough for me then). When I run it now (original code compiled and run on 1.5) on WinXP 3.0GHz P4, I don't get any gc pauses. (NT back then didn't have any pauses either). Has garbage collection / Java improved that much that I don't need to worry about this anymore? I'm asking now before I write too much more because while retrofitting for object reuse isn't too much of a problem, I wouldn't like to do it. Most of what I'm writing now is doing about %70 object reuse and I'd definitely be happier if I didn't have to worry about it too much.

4  Java Game APIs & Engines / Java 2D / Reusing Graphics on: 2004-12-07 02:25:28


If rendering's being done in full screen mode with a BufferStrategy, does the Graphics have to be retrieved and disposed of every frame -- i.e.,  getDrawGraphics(), render, dispose? Can the same Graphics be stored and reused over and over without disposing if the screen isn't resizeable, etc?

Also, can it be reused if the display is in a normal resizeable window (Frame)? I've done this in a Canvas that wasn't being resized and didn't seem to have any problems, but I'd like to know what's correct in the above situations.

Pages: [1]
Archive (284 views)
2017-04-27 17:45:51

buddyBro (474 views)
2017-04-05 03:38:00

CopyableCougar4 (923 views)
2017-03-24 15:39:42

theagentd (935 views)
2017-03-24 15:32:08

Rule (948 views)
2017-03-19 12:43:22

Rule (916 views)
2017-03-19 12:42:17

Rule (918 views)
2017-03-19 12:36:21

theagentd (965 views)
2017-03-16 05:07:07

theagentd (891 views)
2017-03-15 22:37:06

theagentd (687 views)
2017-03-15 22:32:18
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51 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‑
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!