Simple game framework?

Java 2D
#1

Hello all,

I would love to see an article/discussion on java-gaming.org about constructing a simple, practical 2D game framework.

Target games would be things like Space Invaders, Breakout, PacMan, card games, etc. (scrolling is not a priority). After all these years, this is a topic that surely must have been resolved into a ‘best case’ answer!

Specifically, I would like the framework to:

  • Handle the main ‘move/test/redraw’ loop
  • Have a base ‘applet’ (or whatever) class and a base ‘actor’ (or whatever) class, whereby actors have abstract methods like ‘move’ and ‘paint’, and the applet takes care of moving and painting them each frame
  • How to keep the frame rate smooth
  • Discussion over the impact of using Collections vs. arrays of primitive types
  • Discussion over different techniques for ‘only redrawing what has changed’
  • Can you use VolatileImage effectively with applets and one-bit transparency? What about if you mix in some alpha transparency too - do you have to forgo VolatileImage completely? What is the fastest BufferedImage image type?
  • Other optimizations

I have constructed such a framework myself, and my main performance bottleneck seems to be because I try to construct an ‘optimal’ clipping shape (consisting only of the rectangles of actors that have moved) and the java ‘Area’ (specifically, sun.awt.geom.AreaOp.AddOp) class seems pretty slow (however, it’s a good deal faster than doing multiple rectangular copyAreas).

I would gladly submit the source for my framework, but would prefer not to slant the opening discussion :slight_smile:

#2

Heh - the old board actually have discussions for all of the above questions - though they are spread across several topics…

I think that there are a lot of ways to do a 2d kit, but that it would be a good idea to do it… something like the LWJGL (http://java-game-lib.sourceforge.net) which was also done by members of this board.

LWJGL is for 3D (specifically OpenGL) though.

Creating a small 2D library which have the common classes and examples of typical stuff that is done in 2D (ie. scrolling, tiling, isometric and so forth) would not be a huge task, and especially since seem to have done some of it already… but recruiting more people for the effort would probably be a good idea!

#3

tsk! Brian! You should know better :slight_smile:

The LWJGL is 2D and 3D (and sound and input and maths).

The SPGL I’ve just plonked up on sourceforge has a neato sprite library in it which takes most of the thinking out of it.

I was toying with writing a series of proper articles but alas I have no money and need to spend nearly all my time working to keep the roof over my head :frowning: All my spare time goes into the Game.

Cas :slight_smile:

#4

;D

I know that LWJGL is capable of 2d graphics and sound - but without SPGL (http://www.sf.net/projects/spgl/) 2d graphics is a bit of work - while the java.awt.Image is a bit easier… (but you’ll soon learn why awt/swing sucks for games…)

But I am really looking forward to a complete 2d/3d game (smallish or not) using LWJGL - and SPGL if needed… - I haven’t got the time, nor the experience with 3d yet :-/

So get working Cas! :wink:

ps. Damn - smileys everywhere…

#5

[quote]But I am really looking forward to a complete 2d/3d game (smallish or not) using LWJGL
[/quote]
heh, workin’ on it ;D I’m trying to figure out if i’ll be able to enter the 48hour comp over here: http://ludumdare.com/ with it as well…

#6

Ohh that would cool!!!

and I noticed that lwjgl is an authorized library! - how cool is that!!

mental note: must get beta ready

#7

Hi,

just got the source for spgl from sourceforge, and its giving me an error in GLTexture about gl.colorTable ???

After a little digging around in the LWJGL source it looks like it isnt in the library at all.

Or am I missing something here?

#8

Haha! Yes, you’ve been tricked by me. I just checked it in against the current LWJGL in CVS, which has the colortable functions added. Grab the latest org.lwjgl.opengl.CoreGL.java from Sourceforge.

So we’re authorised eh? Lovely.

Cas :slight_smile:

#9

Could I humbly request this thread return to the topic of discussion? :slight_smile:

As has been resolved, LWJGL is not really that suitable for lightweight, purely 2d graphics and sound, at least not without SPGL, and either way not really for small, downloadable applets.

Any framework that satisfies the general need is going to have to be pretty small, and run inside a browser (i.e. not full screen). To reiterate, it would need to:

  • Handle the main ‘move/test/redraw’ loop
  • Have a base ‘applet’ (or whatever) class and a base ‘actor’ (or whatever) class, whereby actors have abstract methods like ‘move’ and ‘paint’, and the applet takes care of moving and painting them each frame
  • How to keep the frame rate smooth
  • Discussion over the impact of using Collections vs. arrays of primitive types
  • Discussion over different techniques for ‘only redrawing what has changed’
  • Can you use VolatileImage effectively with applets and one-bit transparency? What about if you mix in some alpha transparency too - do you have to forgo VolatileImage completely? What is the fastest BufferedImage image type?
  • Other optimizations

I have recently had a good deal of success with my own framework by going around the Area class altogether. I have found I can get significant improvements by manually creating a GeneralPath (of multiple rectangles) and assigning that as a clipping shape.

I think a framework or an article bringing together the collective knowledge of people on these boards would be invaluable, and achievable given how mature this topic should be.

As a starting point: what framerate is realistic for a PacMan-like, browser-based applet?

#10

Heh - I have all of that code actually - part of my old company’s game library. Unfortunately I cannot releases it…
However I can point you to some stuff:
(Note, this is just something that weed agreed on - not nescesarrily “correct”…)

" * Have a base ‘applet’ (or whatever) class"
If you start generalizing around an applet, you have limit you games to be applets. Create the game around some other class, which has the initialize, start, stop and destroy events.

“base ‘actor’ (or whatever) class, whereby actors have abstract methods like ‘move’ and ‘paint’”
If you wan’t to make et really abstract, think about moving the “paint stuff” out of the actor. This was discussed much, but it basically came down to - having an actor without a sprite (and instead a “renderable” interface (which the sprite implemented)) a server is able to use actors in it’s game logic, without having any references to AWT.

" and the applet takes care of moving and painting them each frame "
Again - don’t generalize around an applet

"How to keep the frame rate smooth "
You can’t - pure and simple. Since Java hasn’t got a high performance timer, it is impossible to get a smoooth framerate. Search the old board for solutione (and perhaps paste them here for reference)

"Discussion over the impact of using Collections vs. arrays of primitive types "
Use them all you want, but beware performance implications (object creation, memory usage)

"Discussion over different techniques for ‘only redrawing what has changed’ "
Dirty rectangles deserves its own thread…

I fear that trying to keep all the information in this thread will be difficult - perhaps create a small webpage?..

/matzon

#11

Create the game around some other class, which has the
initialize, start, stop and destroy events.

While it’s true to say that designing around an applet limits you to applet-based games, it’s ALSO true to say that the more generic you go (with software in general) the higher the learning curve (to tailor it back down again to your specific needs) and the fewer the opportunities for performance improvements.

For example, as I stated when I started this thread, I’m only interested in the (large) class of games that fall into the ‘applet-based, not everything on the screen moves’ category (such as PacMan, Space Invaders, etc.). I think these are achievable in Java.

I’m not, for example, interested in scrolling games because:

a) you can’t do any ‘dirty rectangle’ stuff then
b) you could easily argue that Java doesn’t have all the necessary mechanisms for ‘real’ scrolling anyway

Search the old board for solutione (and perhaps paste them
here for reference)

There was a newbie PacMan game that got a lot of kudos on the old board, but its code has long since disappeared. Regardless, I expect better versions have now been created with, say, triple buffering?

I fear that trying to keep all the information in this thread will
be difficult - perhaps create a small webpage?..

With respect, I think the java-gaming.org forum is EXACTLY the place for this discussion. It’d be great if the site owner’s could see fit to produce a ‘definitive’ (if such a thing is possible, and I would think it is for the category of games I have described) article, but until then this thread would hopefully be the best place.

#12

Nah, Pacman is still around and I’m just molling over how to continue with it. I think I’m going to end up re-doing it again. Anyway, the source still remains at http://www.mindspring.com/~bishopmw/pacman

The .ZIP file is the (documented) source code.
The .JAR and the .CFG files are the playable game.

Michael Bishop

#13

That is indeed a very smooth running game! Allow me to add my kudos to the pile :slight_smile:

There seems to be some cleverness with a ‘high resolution timer’ class: could I trouble you with a couple of questions about it?

  1. What is its history? Who was the author (someone’s name is quoted)?
  2. Why, in the PacMan game itself, do you worry about timing frames and ‘ticks’? What are the ticks used for?

Many thanks.

#14

  1. The history of that particular Pacman application is that it was simply my attempt at learning Java Game Programming. I’m the author, although the input from this community has been tremendous. In the archives, there are an excessive number of posts. If you’re asking about the author of the class that handles timing, that would be “thelorax”, another user on this board.

  2. Frames and ticks are supposed to be one and the same but it doesn’t always happen. I’ll explain.

  • Frames are the number of frames the application has actually drawn.

  • Ticks are the number of frames the application is supposed to have drawn. When it’s time to draw a frame. the timer class “ticks” and increments its tick count. The application waits for the next tick to maintain the given frame rate.

  • When the application is ready to draw the next frame, it examines the frame count versus the tick count. Due to garbage collection or otherwise, sometimes a frame or two is skipped. To compensate for that, I’ll do the logic loop until it’s caught up again.

Take a good look at the run() method in the GameBoard class. It does something like this:

  • Run the game logic (tickCount - frameCount) times.
  • Draw the offscreen buffer.
  • Wait for the next tick.
  • Draw the screen.

Michael Bishop

#15

Great!

Thanks purely to the input from these boards, I have implemented hi(gher)-res timers, triple buffering and hardware acceleration into my applet.

However, I’m concerned that this opens the door for all sorts of compatibility problems, so would appreciate it if anybody out there could stop by my site and see if the applet works (no full-screen, no Java Web Start, no hassle!)…

http://www.juliannegiffin.com

(click on the ‘House of Cards’ link)

I’d rather not post this on the ‘look at my Java game’ forum because I’m looking for feedback from people that understand what effect timers, triple buffering and accelerated images have :slight_smile: