Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (843)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / Java 2D / Re: Exiting the JVM and FSEM on: 2004-04-12 12:31:15

I ran your code and it worked ok for me. I switched to FS (monitor click & flash), switched back to windowed (monitor click & flash), then exited (nothing, clean exit).

Only thing I noticed is that your frame is still decorated in FS. There are other problems, as you mentioned, but for isolating your issue, I couldn't reproduce it.
2  Java Game APIs & Engines / Java 2D / Re: Preloading Graphics on: 2004-04-11 23:21:13
Your answers seem to suggest that there is no fast way to load media in Java.

I didn't make any claims that Java loads media faster or slower than any other application loading a large amount of data from files.

Perhaps I am expecting too much of Java to have 10-20 monsters flying around the screen, flashing lights, blaring sounds, and 30 or so bullets flying at a speedy player-controlled ship?

Depends how big those monsters are and what your minimum system requirements are, but I don't think you are asking too much at all.

My question is then, are there fastER ways to load than others?

I think the general process you described sounds fine: determine what you need, load it into memory. Once it's in memory, that doesn't mean you can draw it all to the screen at once, of course.

In my opinion, load time and memory are both less valuable than render time. If you spend a few seconds loading hundreds of files, rotating dozens of images, drawing text to buffered images, and other precalculated graphics operations--as long as all of that effort goes to save you render time when the game is in action and you have to draw the screen in about 0.03 seconds, it was worth it.
3  Game Development / Newbie & Debugging Questions / Re: a little help with my first game on: 2004-04-10 17:00:56

well i was going to use it but it didn't install properly so im just going to use notpad for now.

I am a big fan of Eclipse. Great for java, but useful for other stuff too. Gives you warnings, errors, debugger, code browser, etc. You'll torture yourself using notepad and a dos prompt.
4  Java Game APIs & Engines / Java 2D / Re: Preloading Graphics on: 2004-04-09 15:19:19
Conceptually, preloading is is strategy for any media-intense presentation. Years ago, I developed multimedia CD-Roms when a 4x CD-Rom was fast. The techniques are universal:  if you do anything that takes time, you either let the user know it's happening by telling them with some sort of "Loading..." message or progress bar, or you try to sneak it in when they won't notice, a little bit at a time while the program has idle time.

My opinion is that it's simplest to have logical breaks in your game/presentation when you want this to occur. Even AAA games have pauses in between levels to dump the stuff that isn't needed anymore and load the new level/monster/audio/etc. So in your scroller game, maybe you set up key breaks when the character reaches a flag or special spot. Play a little temporary animation, music loop for a few seconds, or do something else to entertain the player (or just a progress bar for simplicity) and load in your next set of data.

Even if you can preload the entire game into RAM at the start, will you always want to do that? Is it likely that the player will reach the 500th monster without a single pause? So preloading hundreds of MB of stuff at the start, even if possible, might be unnecessary. Maybe you do your dumping/loading every time the player dies. If you know that he's already gotten past Monsters A and B, you could dump those out and load two new ones when the player dies and you get a few seconds of pause. As long as you keep ahead of the player based on predictions of what is coming next, you can keep a workable buffer of "stuff." If the player does catch up and you need to pause, design breaks in the game like I mentioned above. Some sort of mid-level song & dance to give you a chance to clean up and get ready the next wave. If you really can't predict what the player will encounter (in a giant game level, for example, where the player could go anywhere and the monsters are not confined to regions) and you don't want a pause, you might need to preload everything that is possible for the player to get to.
5  Java Game APIs & Engines / Java 2D / Re: FSEM slower than windowed? on: 2004-04-08 16:57:40
I'm experiencing the same problem, but I don't understand the reasoning of why it occurs. When I draw a bunch of images with alpha, fullscreen gets half the framerate that windowed mode gets. If something is not accelerated in fullscreen mode, why would it be accelerated in windowed?
6  Java Game APIs & Engines / Java 2D / Re: fullscreen doublebuffering and swing on: 2004-04-07 22:45:36
As a follow up, I've tried this with JButtons and JLists and it does work, if...

I've found I need to extend the button and list classes and override the paint method in each of them because, although setIgnoreRepaint does cause them to not be drawn unless I call paint explicitly, they are still painted by an AWT Thread when you click on them to change their state. This causes artifacts. Overriding paint so it does nothing, then adding my own custom paint method that calls the superclass paint appears to fix it.

Geesh. I just think this seems wrong. So there are now still some calls being made to paint() that are doing nothing, thanks to my meddling. Seems like a waste. Is there a way to totally disable any painting so it's only drawn when I say so? Am I hacking up a big mess or what?
7  Java Game APIs & Engines / Java 2D / fullscreen doublebuffering and swing on: 2004-04-07 14:37:41
I am wondering about the best way to do a fullscreen doublebuffered application that also uses Swing components. In other words, I want to actively manage drawing, but also have the luxury of not writing my own UI code for buttons, listboxes, etc.

The way I've done it so far is to create a Frame with a page flipping buffer strategy, to use setIgnoreRepaint on the frame, add components to it, then explicitly render those components in my render loop along with all my other sprites. I transform the graphics context to the appropriate locations for each component and call paint on the component using my buffer strategy's graphics context.

It seems to work, but I have doubts. I've only tried it using JButtons and haven't bothered yet with other component types.

Is this a bad idea? Am I spawning new threads by creating and adding these components to my Frame that could come back to haunt me? Is there a better way?

I tried setting up a standard fullscreen Swing application and adding a Canvas to my Frame as one of the components (along with buttons, etc). Then I tried creating a bufferstrategy on just the canvas. This works in windowed mode, but in fullscreen only the Swing components show up. The canvas is blank white and won't draw anything. I can create a single buffer strategy on the canvas and it works, but of course that looks horrible.
8  Games Center / Java Technology Game Development Contest - 2004 / Re: Competition J2ME vs. J2SE on: 2004-04-03 22:48:27
The judges will certainly take into consideration platform as they judge. A J2ME game won't look as visually rich as a J2SE game, but nobody expects it to. If I were a betting man, I'd put my money on at least one J2ME game winning one of the prizes--especially those Tapwave PDAs. To win the grand prize, it'd probably have to be a pretty good game, but I'm someone who believes a good game comes from a great idea, not lush graphics. That being said, I think Sun probably wants to see developers using Java for "real" games not just mobile toys so they can say, "See! Take Java seriously." (Which I do, anway, but mainstream developers probably don't. Yet.)

And I think Gamespy could potentially be useful to a J2ME game, if it's played on a mobile phone or PDA with wireless Internet. (My second bet would be that the grand prize winning game is a multiplayer game that could benefit from Gamespy.)
9  Games Center / Java Technology Game Development Contest - 2004 / Re: The GameSpy SDK on: 2004-04-03 20:58:08

Can you give a more detailed analysis without breaching confidentiality? I'm sure it would be interesting to know the strengths and weaknesses of the grand prize *before* trying to win it Smiley.

We really just wanted it for matchmaking in-game. So, you click a button to play online multiplayer and get a big list of everybody playing right now, which games are open, what game level is being played, etc. To that end it worked perfectly and easily. We didn't care about other stuff, but--at least according to our contract, I was told--we had to allow players to join the game from the Gamespy Arcade lobby where they might already have a Gamespy login identity and do whatever it is Gamespy's community does. I really don't know: Read game reviews, I guess, and look at all of Gamespy's advertisements or something? It just seemed pointless to me. Maybe there's something to gain from getting your game in Gamespy's list, getting promotion that it might not otherwise, but I think our game was so small that it would never get the same attention as the AAA titles. So for us, the matchmaking service was it, and I think that could be built fairly easily--especially with Java.

Anyone else know of other benefits of Gamespy?
10  Games Center / Java Technology Game Development Contest - 2004 / Re: The GameSpy SDK on: 2004-04-03 14:48:37
I worked on a commercial game that used Gamespy's online matchmaking service about a year ago. I must say, I think the service is WAY overpriced and overrated. We were forced to include the GameSpy Arcade installer with our game and to allow players to get into the game through a browser (in addition to the in-game system). I'm pretty sure we didn't pay $45k then, but maybe GameSpy has "platinum" features now that we didn't use.

If your game is expected to sell enough copies (hundreds of thousands) and have enough simultaneous multiplayer users that you don't want the risk of running your own servers, then yes, Gamespy is a very good choice.

In developing an independent game, which could have only a small number of players for the first months or years, I think I would opt to spend a few thousand on a nice dedicated server, use J2EE to build my own matchmaking system, and just watch the numbers of players and scale up the server when and if appropriate.

Just an opinion, and as I mentioned, Gamespy may have some new added value that I'm unfamiliar with. I just think they are mainly interested in getting your customers into their community and charging you big money for the "honor" of being associated with them.

All that to say, if I enter the contest, it would be for publicity. The SDK isn't a big draw for me, and the workstation is nice but a small prize.
Pages: [1]
EgonOlsen (37 views)
2018-06-10 19:43:48

EgonOlsen (20 views)
2018-06-10 19:43:44

EgonOlsen (39 views)
2018-06-10 19:43:20

DesertCoockie (186 views)
2018-05-13 18:23:11

nelsongames (122 views)
2018-04-24 18:15:36

nelsongames (121 views)
2018-04-24 18:14:32

ivj94 (861 views)
2018-03-24 14:47:39

ivj94 (122 views)
2018-03-24 14:46:31

ivj94 (758 views)
2018-03-24 14:43:53

Solater (139 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!