Distributing a library

Shared Code
#1

While working on my recent game projects, I’ve realized that I have been developing a GUI/game library that is fairly simple but works very well for 2D projects (I think much better than Java’s built-in GUI). I have developed or am developing Tetris, a hexagonal board game, and a simple RTS all based off of it and could easily see a zelda-type game or many other things. So I was thinking that after I get complete more of it, it might be a good idea to review it with some people here and then release it.

What do you all think?

#2

Reviewing is always good.

Don’t expect anybody to actually use your engine though.

Don’t spend too much time aiming for perfection, just get your
stuff done, and your engine will evolve into perfection (or not…)

#3

Sounds cool, how about some screenshots of what the GUI looks like and what widgets you’ve already got?

Is it rendered using java2D?

#4

Oh, I have no aspirations of changing the Java community, lol. Mostly, its just a chance of trying to make something for the public instead of by myself, and to get some feedback on what I’m doing. However, I do genuinely feel that this would be a good library for some one to start writing games with.

So, the central class of my library is Game, it handles the JFrame and canvas (which I suppose means this is based on Java2D), and is where the main loop is run. Each loop, Game updates and draws the current screen (a Holder defined by the programmer) which starts a chain reaction down components.

The above is the MainMenu screen of my project*, Game sends the update() and draw() commands to MainMenu which in turns sends them to the inner Holder (w/ buttons) which in turns sends them to the Buttons. This way, people can plug in new screens (thus games) without having to alter Game, and most things are accomplished just by overriding update(). Game uses a similar method to cascade MouseEvents to the components to which the events apply, which is how the Buttons alter their state.

Each Holder can hold any number of other GUI elements, including other holders, as in the following. Three holders (status, and console, and world) are added to the screen, which contain other components. The first two are just typical holders, but World is a special holder to work with Entities (which are still derived from the same parent as other components), for those games that use entities. A zIndex of objects used by the Holders allows drawing order to be changed, so for example a unit can go under and over a bridge, its also useful in simple GUI like placing the console over the world.

Another benefit is the easy alteration of game time, for opening menus, dialog, etc. To pause the game, I just have to shift a quickly defined activeObject from the screen itself to the menu (etc.).

That’s pretty much the basis of it. I mean, I can throw together new screens in a few minutes, and theres already plenty of objects to build interfaces for various game designs. Would this be a useful library?

Update:

Got Tetris back up, same design. A main Holder contains several Holders and uses update(), this also uses the Grid class, which will be good for board games (probably as a subclass)

Now that I think about it I could probably make it so that I can move between games within a single session by just defining a new Screen.

P.S. I know this sounds horrible, but what are widgets?

#5

Looks good, I loved warcraft 2 and you’ve emulated their menus really well.

What you’ve got would probably would be a good thing for people starting out, but most people here probably already have their own game-loop and rendering setup which they re-use.

A widget is like a text-field, a button, a scroll bar, etc. They’re pretty hard to make on your own, and while Swing has lots of widgets they are notoriously hard to integrate into an actively-rendered game because they have to be rendered on the event dispatch thread instead of your own game thread. No-one has made any re-usable easy-to-use non-swing widgets that can be rendered using java2D, to my knowledge. For openGL there are a couple of options though, like FenGUI.

#6

That’s exactly how I’m thinking about the situation. I would been able to use this set-up as a black-box long before I knew how to work with Canvas to do custom drawing, which was a HUGE breakthrough for what I could do and thus what I could learn. I have a roommate who just started in programming classes, for example, and I’m probably going to show him this as soon as he asks me about graphics drawing; he’d have to learn Java first though (he’s learning in C right now, and thinking about going to C++ next).

Now that I know what a widget is, you can pretty much see all the ones I have so far. Every widget (from primitive data wrappers to holders to entities) is derived from the DrawableObject class and, as I said, making new ones can usually be done by changing draw(), update(), and possibly event handlers.

There’s quite a bit more to add and change, since I’m developing this library simultaneously with other programs, but its improving all the time.

#7

Looks pretty good, but can you get solid performance with Java2D?

#8

It is a bit limited in how much you can put into it at once. The RTS up there starts to have fps issues with about 250-300 entities in it. I’m sure there are ways to improve that, but I also know it will only go so far. However, I can still think of tons of games that would never come close this maximum (and there could probably be a greater number of simpler entities), so I believe it still would be useful, esp. to a novice programmer.

Oh, while I’m at it, one definite way I can think of to increase speed is to stop rendering off-screen entities and components. I’d rather not have to check bounding on each entity/component because it would probably make the benefit useless, so would using the Graphics built in clipping be a good idea (I would have to be able to change the clip, say for World, draw, and change it back for further drawing)?

#9

You can just give them a radius and just see if that radius is within the screen.

The length of the radius = sqrt((width/2)^2 + (height/2)^2).

That will keep you from needing to do any sort of complicated geometry involving the rotation of each object, and will work well enough to improve performance.

That fps you’re getting is still pretty good. I just made a stress test on a relatively small screen with 100 entities flying around, and I only got 40 fps. When I increased the size of the window, I was getting 11 (because it uses an AffineTransform to scale everything up).

This could be because I’m not sure my BufferedImages were optimized… what sort of things do you do for image optimization, and how are you rotating them? Graphics2D.rotate()?

#10

Ouch,
Because those entities currently don’t have an animation loop, they look and move fine with that many, but I just found that the fps goes from 90-25 with 50 entities. A different program I made using Java2D (but not this library) didn’t have problems w/ animation, but I don’t think I ever exceeded 30 or so. In lieu of this revelation, I’m going to see about changing my library over to openGL, although it might already have everything I’m doing.

Another question, I’m currently handling mouse events by catching them with the canvas and the ‘cascading’ it down through the various components by passing it to their mouse event methods. Would it be better to go through the components and just generate a list of what is under the mouse (of only components to which it applies) and then handle it centrally by calling those components handleEvent() (or w/e I call it)?

#11

Nah, I’d keep sending the event down, or at least some coordinates if that’s all you need. I mean basically you’re either pulling data or pushing it, as in one thing is taking it from other places or one thing is giving it out to other places.

I doesn’t really seem logical to have your mouse event listener holding references to everything that’s going to need data in order to see what got clicked (a pull). Instead sending the click information down so that everything can decide on its own what to do is a smart choice (a push).

Also, check out my recent question about Java2D optimization, you may want to check it out.
http://www.java-gaming.org/index.php/topic,19369.0.html

#12

Using the latest JVM, the hardware accelleration seems to be on my default. It makes a huge difference.

#13

O.K.

So I looked up some stuff about using hardware acceleration for images and am using the following code:

	public Sprite getSprite(String ref) 

        {

           if (sprites.get(ref) != null) 

              return (Sprite) sprites.get(ref);


           BufferedImage sourceImage = null;	

           try {

             sourceImage = ImageIO.read(new File(ref));

           } catch (IOException e) {fail("f**k, my picture:"+ref);}

		

           GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();
           ImageCapabilities ic = new ImageCapabilities(true);
           VolatileImage image = gc.createCompatibleVolatileImage(sourceImage.getWidth(),sourceImage.getHeight(),Transparency.OPAQUE);
           try{
              image = gc.createCompatibleVolatileImage(sourceImage.getWidth(),sourceImage.getHeight(),ic,Transparency.OPAQUE);
           }catch (java.awt.AWTException e){System.out.println("Unable to create Volatile Image");}

       
           image.validate(gc);
           Graphics2D g = (Graphics2D)image.getGraphics();

           g.drawImage(sourceImage,0,0,null);

		

           Sprite sprite = new Sprite(image);

           sprites.put(ref,sprite);

		

           return sprite;

        }

Which successfully accelerates the images. However, according to Sun images that use BITMASK transparency will not be accelerated. Is there any way to get around this caveat?

I’m also planning on putting all my source out to be ripped apart in about a week. I’ve sort of been in a programming slump lately, but got better upon spending a night of coding and customizing Ubuntu

P.S. Let’s see you try to do this with windows

I got a console that hides and reveals with the stroke of a key and, even better, wobbly windows!