Pipe Extreme

[timfoden]

@ulfjack

I’ve switched my own game to use JComponent (inherit JComponent).
JComponent already gives you double-buffering, so you don’t need to implement it yourself.
Dunno if it works for fast games (my aichess4k is round-based).

You don’t have to implement it yourself on Frame either… well you don’t need to get a back buffer, and then copy it.

I guess your comment about real time is relevant. In a real-time game you want to take control of when screen updates happen, rather than invalidating then waiting for the system to ask you to draw.

The main loop in PE looks something like this:

class G extends Frame
{
public static void main(String args[])
{
G game = new G();
game.createBufferStrategy(2);
BufferStrategy bs = game.getBufferStrategy();

	// setup some stuff.

	for( ; ; )
	{
		// move some stuff.

		if( catching-up )
			continue;

		Graphics2D	g2 = (Graphics2D)bs.getDrawGraphics();

		// draw some stuff.

		g2.dispose();

		while( !time-to-display )
			sleep-some();

		bs.show();
	}
}

}

Cheers, Tim.

[timfoden]

@ulfjack

However, let me suggest you do the levels in a different order. First the really easy, short ones, and later the longer and more difficult ones.

The later ones are only short (and easy) because I haven’t yet made them up… but point taken.

[woogley]

how are you storing the levels by the way? is it like one chunk of map data for each level? if so… you might can save some space by paritioning the levels by “features.” for example… each level has specific features… the red ring, the loop, etc.

let’s say the red ring is feature #1, the loop is #2, and ordinary greenspace is #3.

then, map data could be stored like:

int level1[] = new int[] {3,3,3,1,3,3,1,2};

and you’d load it like…

for (int j = 0;j < level1.length;j++) {
	switch (level1[j]) {
		case 1: genRedRing(); break;
		case 2: genLoop(); break;
		case 3: genSpace(); break;
		default: break;
	}
}

so what I’m trying to say is… procedural (or hey, even random) level generation. something tells me you’re doing something similiar… because, i mean, these levels are kind of long just a thought though

[timfoden]

@woogley

how are you storing the levels by the way? is it like one chunk of map data for each level?

Nope.

@woogley

int level1[] = new int[] {3,3,3,1,3,3,1,2};

It’s pretty much like this… but using an array in this way is horribly expensive in byte use. Try it and see. Each entry takes 6 bytes! It took me ages to figure out why. (hint: the compiler actually writes the bytecode to stuff the value into each individual array entry… yuk!)

So it’s more like:

level[x] = new String("\03\03\03\01\03\03\01\02");

So it’s block procedural, with some random elements.

Cheers, Tim.

[nva225]

Ooo I’m liking the level changes. I could actually get through level one after a few tries.

Much more fun now. Also I really like the loopy thing on level 2.

[ulfjack]

@timfoden

You don’t have to implement it yourself on Frame either… well you don’t need to get a back buffer, and then copy it.

I guess your comment about real time is relevant. In a real-time game you want to take control of when screen updates happen, rather than invalidating then waiting for the system to ask you to draw.

That’s what I mean. However, if you do invalidate and wait for the system, that can save quite a bit of space. You are referencing BufferStrategy as well as createBufferStrategy and getBufferStrategy. That means three strings containing exactly that are part of your classes constant pool. If you just call repaint instead, that can save quite a bit.

And you know that you should do:

level[x] = "\03\03\03\01\03\03\01\02";

don’t you?

Oh, and I really like the short levels. I’d rather put them at the beginning.

[timfoden]

@ulfjack

That’s what I mean. However, if you do invalidate and wait for the system, that can save quite a bit of space. You are referencing BufferStrategy as well as createBufferStrategy and getBufferStrategy. That means three strings containing exactly that are part of your classes constant pool. If you just call repaint instead, that can save quite a bit.

But then you instead have another class: JComponent, plus a reference to JComponent.repaint(), plus you have to override paintComponent(), and, most significantly, all the variables that are required in order to paint need to be class members rather than local vars.

Here’s my “minimal game” program. I wrote it to try various idea out about how to make the smallest possible game loop that has all the support I wanted. If you can make a version which has all the same functionality, and can have the drawing separate to the game loop, then I’d be glad to use it (in fact this is an older version, I’ve got a slightly smaller one now but I don’t have the source with me.)

import java.awt.AWTEvent;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.Frame;
import java.awt.Graphics2D;
import java.awt.Insets;
import java.awt.event.KeyEvent;
import java.awt.event.WindowEvent;
import java.awt.image.BufferStrategy;

class G extends Frame
{
	public static void main( String args[] )
	{
		G	game = new G();

		game.setTitle( "Minimal Game" );
		game.setVisible( true );//show();
//		Insets	insets = game.getInsets();
//		game.setSize( new Dimension(640 + insets.left + insets.right,
//									480 + insets.top  + insets.bottom) );
		game.setSize( new Dimension(640, 480) );
		game.setLocationRelativeTo( null );
		game.createBufferStrategy(2);
		game.enableEvents( -1 );	// enable all events
/*
		{
			System.out.println( "insets " + game.getInsets() );
			System.out.println( "getSize " + game.getSize() );
			System.out.println( "getBounds " + game.getBounds() );
		}
*/
		BufferStrategy	bs = game.getBufferStrategy();

		int		count = 0;
		for(;;)
		{
			Graphics2D	g2 = (Graphics2D)bs.getDrawGraphics();

			Dimension	d = game.getSize();
//			g2.translate( insets.left, insets.top );
//			d.width  -= insets.left + insets.right;
//			d.height -= insets.top  + insets.bottom;
	
			g2.setColor(Color.black);
			g2.fillRect(0, 0, d.width, d.height);
	
			g2.setColor( Color.green );

			int	x = (count % 100) * d.width  / 100;
			int	y = (count % 100) * d.height / 100;
			g2.drawLine( x, 0, d.width - x, d.height );
			g2.drawLine( 0, d.height - y, d.width, y );
			g2.drawLine( 0, 0, d.width, d.height );
	
			g2.setColor( Color.cyan );
			g2.drawString( "MINIMAL GAME", d.width / 2 - 50, d.height / 2 );

			try { Thread.sleep( 10 ); } catch( Exception e ) {}

			bs.show();

			g2.dispose();

			count++;
		}
	}

	public void processEvent( AWTEvent e )
	{
		switch( e.getID() )
		{
			case WindowEvent.WINDOW_CLOSING:
			{
				System.exit( 0 );
			}

			case KeyEvent.KEY_PRESSED:
			{
				int	code = ((KeyEvent)e).getKeyCode();
				m_keysDown

= true;
if( code == KeyEvent.VK_ESCAPE )
System.exit( 0 );
break;
}

		case KeyEvent.KEY_RELEASED:
		{
			int	code = ((KeyEvent)e).getKeyCode();
			m_keysDown

 = false;
			}
		}
	}

	private boolean[]	m_keysDown = new boolean[256];
}

@ulfjack

And you know that you should do:

level[x] = "\03\03\03\01\03\03\01\02";

don’t you?

Yes… slip of the typing fingers.

@ulfjack

Oh, and I really like the short levels. I’d rather put them at the beginning.

[woogley]

@timfoden

the compiler actually writes the bytecode to stuff the value into each individual array entry… yuk!

well yes, just an example

you should release your source code. I bet you almost anything I can throw it back to you with smaller bytecode… ask anyone here (appel, kevglass, etc), I’ve been doing this waaaay too long. and there are others here who are even more insane than me!

[timfoden]

@woogley

you should release your source code. I bet you almost anything I can throw it back to you with smaller bytecode… ask anyone here (appel, kevglass, etc), I’ve been doing this waaaay too long. and there are others here who are even more insane than me!

Well I may do later. I don’t have the source here with me at work ATM anyway.

I’ve not completely run out of space yet, but I’m always mindful of the way that adding extra stuff uses it up.

It goes like this… I add some code… now the progs to big… so I go through it and try to remove some code without losing functionality … prog is now smaller … goto loop. I’ve still got some ideas for things I can chop out (for example, I’ve got 3-d vectors in there… it may be possible to get away with 2-d ones in many cases. The code is still fairly 3-d generalised… the ball could go ahead down the pipe and still be rendered ok… this could probably be simpified a little, etc.).

I currently push the code through proguard and joga, and then bjwflate it. I’ve experimented with the internal pack200 stuff, and that’d save some space too, but at the moment I don’t need it, so it’s not in there (BTW I got the header class for decompressing the pack200 down to 1045 bytes – although I haven’t tested that it actually works! )

Cheers, Tim.

[woogley]

ah, so you’re not out of space yet

well if you’re desperate, you know what to do! there’s people on these forums that know 4K secrets that I could ever imagine… it’s scary. (and handy)

looking forward to your updates!

[timfoden]

@woogley

looking forward to your updates!

Thanks. You’ll have to wait until monday though, as I currently don’t have internet access from my lodgings. Cheers, Tim.

[timfoden]

@woogley

also, increase the speed! (speed-up squares even?)

Well, I’ve uploaded a version (v0.92) where you can go faster while you hold down the shift key. There are also some level updates (e.g. 3rd level complete now).

Cheers, Tim.

[Malohkan]

This game runs great on my Mac. I really liked the game. I got almost through Level 3 on my first try. I think it’s a lot of fun! It might be my #1 pick so far.

[timfoden]

@Malohkan

This game runs great on my Mac.

Thats nice to know. Do you have the same problems as in the picture someone else posted?

1. The score/lives etc at the top of the screen are obscured by the “Java…” banner.
2. There are random black dots on the edges between tiles.

@Malohkan

I really liked the game. I got almost through Level 3 on my first try. I think it’s a lot of fun! It might be my #1 pick so far.

Thanks. I may be persuaded to add a sixth level at some point (still got a bit of space), if people manage to complete level 5 and want some more. I’ve got a couple of ideas for the layout.

Cheers, Tim.