Frustrated by full screen at 800 x 600

[Mich Robinson]

I write old style arcade games as a hobby but I'd like to try selling them on steam (you have to dream). I like to use low resolutions (800x600) because this matches the styles of the games. At the moment I use basic java for everything but I find it isn't very reliable when it comes to producing a full screen application and that's my big issue. I use the standard full screen stuff but on my own PC I need to set the run time flag nodraw=true else I just get a black screen while it runs fine on my son's PC. On my moderately widescreen laptop it just runs in a small window. I thought Java would be naturally suited to this but ...

I wondered about JavaFX but obviously I'd have the issue of learning a new library (I'm a bit slow witted when it comes to other peoples code). All I need is the ability to draw an image and write text, certainly nothing special. Does anyone else have this issue and did they find a solution? Any suggestions or simple examples?

[Piet Souris]

I have no experience with code using the full screen (always runs them in a window), but did you have a look at the Oracle tutorial:
tutorial
Another simple(but possibly too slow) method is to use a Frame, size full size of the screen, but with a user coordinate system (0,0) - (800, 600).

[Mich Robinson]

That's pretty much where I got the original code for doing full screen.

[Matt Wong]

depending on the graphics framework you use you have to make sure to run code that modifies the output is only run in the correct thread

if you're using swing for example you have to make sure all gui code runs in the EDT - otherwise you may encounter unpredictable behaviour

[Tim Holloway]

Matt Wong wrote:make sure all gui code runs in the EDT

EDT == Event Dispatch Thread.

In Java's GUI subsystems, you don't draw directly to the screen. You set up a "drawing program" that is then executed independently by a separate rendering thread. Roughly speaking, since the actual drawing these days is likely to be done via a GPU running dozens of hundreds of parallel threads.

The reason for this disconnect is that it makes it possible for graphics to render more smoothly and likewise the user interface (which is handled by the EDT). If you click a mouse button and that is supposed to make a square pop up in the game window, the EDT thread dispatches the mouse event to your click handler code which obtains whatever data it requires (presumably the mouse co-ordinates so you can draw a square there). The handler then adds a "draw a square" command to the graphics program, and invalidates the section of the display where the square will be drawn so that the rendering thread will then do the actual drawing. By setting a "clipping area" (usually one or more rectangles) you can save the overhead and flicker of re-drawing the unchanged parts of the display. This is also how the system handles overlapping windows and other stacked artefacts, where you don't need to draw something if something else is sitting on top of it.

Although everyone knows that real games run at 320x200 pixels!