Show Posts
|
|
Pages: [1]
|
|
2
|
Game Development / Shared Code / Simple Full screen/Windowed Framework
|
on: 2002-11-08 19:40:57
|
For my fellow noobs: this code shows how to implement a basic game loop. It puts the display into full screen exclusive mode or, if that's not available, a window of a fixed size, then loops until the "game" is over, then exits. It should compile and run as-is (it does for me on my Windows boxen). It uses double buffering, so animation is smooth and flicker-free. For those who know oh so much more than I do (most of you I imagine): is this code correct? Am I missing anything? This is what I came up with after many hours of looking at many different examples. I was trying to boil them all down to the barest essentials. I didn't really understand Jeff's code until I got mine working, then his made sense to me. I figured other newbies like myself might like something simpler with more comments... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174
| import java.awt.*; import java.awt.image.BufferStrategy;
public class Test { public static void main( String[] args ) { Test test = new Test( true ); System.exit( 0 ); }
private static DisplayMode[] PreferredModes = new DisplayMode[] { new DisplayMode( 800, 600, 32, 0 ), new DisplayMode( 800, 600, 16, 0 ), new DisplayMode( 800, 600, 8, 0 ) };
private DisplayMode bestmode( GraphicsDevice gd ) { DisplayMode[] modes = gd.getDisplayModes();
for( int j = 0; j < PreferredModes.length; j++ ) { for( int i = 0; i < modes.length; i++ ) { if( modes[i].getWidth() == PreferredModes[j].getWidth() && modes[i].getHeight() == PreferredModes[j].getHeight() && modes[i].getBitDepth() == PreferredModes[j].getBitDepth() ) return PreferredModes[j]; } }
return null; }
Frame mainFrame; BufferStrategy bufferStrategy;
int ScreenWidth; int ScreenHeight;
boolean Running = true;
public Test( boolean fs ) { GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); GraphicsDevice gd = ge.getDefaultScreenDevice(); GraphicsConfiguration gc = gd.getDefaultConfiguration(); DisplayMode dm = bestmode( gd );
if( dm == null || gd.isFullScreenSupported() == false ) fs = false;
mainFrame = new Frame( gc ); mainFrame.setLayout( null ); mainFrame.setIgnoreRepaint( true );
if( fs ) { mainFrame.setUndecorated( true ); gd.setFullScreenWindow( mainFrame ); gd.setDisplayMode( dm ); ScreenWidth = dm.getWidth(); ScreenHeight = dm.getHeight(); }
else { ScreenWidth = 800; ScreenHeight = 600; mainFrame.setSize( new Dimension( ScreenWidth, ScreenHeight ) ); mainFrame.show(); }
mainFrame.createBufferStrategy( 2 ); bufferStrategy = mainFrame.getBufferStrategy();
while( Running ) { render();
try { Thread.sleep( 30 ); } catch( InterruptedException e ) {} } }
int i = 0;
private void render() { if( !bufferStrategy.contentsLost() ) { Graphics g = bufferStrategy.getDrawGraphics();
g.setColor( Color.white ); g.fillRect( 0, 0, ScreenWidth, ScreenHeight );
g.setColor( Color.black ); g.drawString( "Hello World!", i, i );
i++; if( i > 400 ) Running = false;
bufferStrategy.show(); g.dispose(); } } } |
|
|
|
|
|
3
|
Games Center / Archived Projects / Re: Critique my game...
|
on: 2002-11-08 19:16:10
|
I said that the ball could theoretically move such that it hits 3 bricks, when dx, dy have been added to x, y.
Ah, sorry, misunderstood you. In my code I move the X first, check for a collision, then move the Y and check for a coliision again. I *think* this eliminates the problem you describe (ie: it can't skip over a brick by going over a corner of it). As long as the ball can never move more than 16 pixels in X or Y then it should always collide properly with the bricks. I think. Btw: Looove the background - reminds me of my graphics :/ - WHY can't programmers do graphics - it is mindbogglingly weird ... <shrug> your guess is as good as mine...  For those who are still following this game, I've uploaded an update. Better splash screen, vertical mouse indicators on the left and right sides of the screen, less cheesy background image, slightly dfferent sprites for the powerups, a few bug fixes. Just a few more levels to add and I'll stick a fork in it.
|
|
|
|
|
4
|
Games Center / Archived Projects / Re: Critique my game...
|
on: 2002-11-06 19:24:24
|
well that's not complete: At any givent moment, the ball is able to hit 3 bricks. I was just playing the game again and thinking about what you wrote... how do you figure that the ball can ever be in a position to hit 3 bricks? The ball is round, the "corner" between two diagonal bricks is square... a ball can only ever make contact with two bricks simultaneously, and my game deals with that just fine. It's not physically possible for the ball to hit the "corner" brick, and it's not possible (or shouldn't be) in my game either. Perhaps I misunderstand what you are trying to say? If the ball is moving faster than 2.0 px/frame then the ball can hit multiple bricks in one frame. In a corner case the ball could first hit a brick to the left (which causes x *= -1) and in the next px movement hit a brick above it. You would therefore potentially need to map the movement of the ball, especially if the ball can somehow move faster than brickheight/width + ball height/width. In which case the ball could move over a brick. Yes, if the ball was moving more than 15 pixels at a time (which my game does not allow) it could skip over bricks, but other than that I don't think I follow you. Just for kicks I made the ball move 12 pixels at a time and lowered the frame rate to twice a second. I couldn't see a single instance where the ball/brick collision did not work as one would expect. When I bumped it up to 20 pixels it occasionally skipped a brick and took out the one on the other side of it, but that's not really an issue since the game doesn't allow balls to travel that fast normally.
|
|
|
|
|
5
|
Games Center / Archived Projects / Re: Critique my game...
|
on: 2002-11-06 18:41:27
|
|
You are over-complicating things. This is just a breakout game, not a physics demo afterall :-) I dare say the collision works as well or better than any other breakout game I've tried lately (and I've tried dozens of them).
|
|
|
|
|
6
|
Games Center / Archived Projects / Re: Critique my game...
|
on: 2002-11-06 15:05:48
|
Yes ! The normal Applet-tag version works fine  Nice game !!! How did you solve the collision detection (i mean how did you solve to find out from which side exactly the ball hits the brick ?) Each ball has an X, Y, DX, and DY value (all floats). To move a ball I: First add DX to X. Check to see if the new X/old Y falls within a brick, which is as simple as dividing X by 32 (the width of the bricks) and Y by 16 (the height of the bricks) to get indexes into my 2D array of bricks. If the brick at that location has any hits left, then there is a brick present, so I reverse the sign of DX and add it to X again immediately. Because I've only moved it horizontally at this point, I know it had to have hit the left or right side of a brick, and I can use the sign of DX to tell which side. Then I do the same thing for Y and DY, which tells me if it hit anything from the top or bottom. Knowing which side got hit is important in my game since bricks can have optional armour plating on one or more sides, which means you can only break them if you hit them from a particular side (should make for some interesting levels later on).
|
|
|
|
|
7
|
Games Center / Archived Projects / Re: Critique my game...
|
on: 2002-11-05 20:22:56
|
I initially thought you didn't have a FPS limiter. I do, but I suppose it could be buggy. It seems to work fine for me on my two machines, but they are about equal and they both run Windows. I don't know about the robot technique. My first thought was a tick mark that moved up/down one side following the position of the mouse. The robot class doesn't seem to work in applets anyway :-( The tick mark idea might work, I'll give that a shot. Thanks.
|
|
|
|
|
9
|
Games Center / Archived Projects / Re: Critique my game...
|
on: 2002-11-05 17:20:13
|
I tried to play, but he told me i have to download the JRE1.4.1, which i have already, and a don't like to download tons of data i already have, because i'm with 56k....  Is this part of your code, or is it my probably wrong configuration ? If anyone can help me,.... PLEASE !  mbw :-/ This is nothing to do with the applet itself, but it could be something in my plugin code in the HTML (I'm a complete Java newbie and copied the HTML plugin code from someone else's example). There is an ordinary APPLET version here: http://christian.net/games/jericho/Gamelet.htmTry that one and see what happens...
|
|
|
|
|
10
|
Games Center / Archived Projects / Re: Critique my game...
|
on: 2002-11-05 17:17:10
|
It was too fast, IMO, on my windows box. Can you elaborate? It has frame-rate limiting in it, so it shouldn't run any faster on your system than on mine or anyone else's. If anything it might get a slower frame rate on a slow machine. Or do you mean the balls start out too fast to be playable? (the balls will speed up over time as well). I'd like some vertical indicator about where the mouse is. When the mouse is moved outside the applet the paddle stops tracking the mouse. This is frustrating when I move the mouse a little to low and cannot get to the otherside of the screen in time. This is a problem with Java applets in general, as far as I can see. Once the mouse leaves the panel events are no longer sent to the applet. I eliminated the mouse cursor because other testers found it annoying and it left "mouse droppings" on a couple of platforms with buggy mouse drivers. So I'm thinking of using a "robot" to force the mouse's Y position to remain constant as long as the mouse is within the panel. This should help somewhat (if it works). As for horizontal movement, I could also use the robot technique to move the mouse pointer back if it gets too close to the edges. The only time the mouse should then leave the panel is if you move it quickly and move it far. Any thoughts on whether this would work?
|
|
|
|
|
11
|
Games Center / Archived Projects / Re: Critique my game...
|
on: 2002-11-05 17:00:15
|
It seems to happen that a games starts w/o a ball on the paddle?
Yes, that's a bug. It happens if you hit the mouse/keyboard too soon. If you wait until the title page appears (after the loading screen) it's ok.
|
|
|
|
|
12
|
Games Center / Archived Projects / Re: Critique my game...
|
on: 2002-11-05 16:59:07
|
Love the sound FX, what a riot! I would like more control in the direction of the "ball" via the hit location on the "paddle" though. Nice and smooth and fun. Thanks. I'll modify the paddle/ball collision code a bit.
|
|
|
|
|
13
|
Games Center / Archived Projects / Critique my game...
|
on: 2002-11-05 00:59:15
|
I am creating a series of web games for a web site and I decided I'd rather learn Java then Flash (for now anyway). My first attempt at writing anything (other than HelloWorld) is a break-out game (original, I know). It's not finished (mainly I'm just waiting on some artwork and some new level designs), but it's playable. I think it's turning out ok. What do you think? http://christian.net/games/jerichoJavaNoob PS: "programmer art" - you've been warned.
|
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|