Java-Gaming.org Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (555)
Games in Android Showcase (150)
games submitted by our members
Games in WIP (602)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 6 7 [8] 9 10
 71 
 on: 2015-03-04 15:04:26 
Started by Dogstep - Last post by KevinWorkman
Thank you for all the replies everyone! Could somebody point me the right way to a tutorial on how to make a game such as Pong or Space Invaders with Java? All the ones I've found are basically copy and paste tutorials. I would like to find one that actually explains what the code does instead of just saying "do this to make this work".

You also might consider starting with Processing. Processing is built on top of Java, but makes it much easier to get something visual and interactive up and running, without all the boilerplate Java code. You can easily "ramp up" from Processing and into Java, then eventually on to more advanced topics like libGDX and Android programming.

Shameless self-promotion: I've written tutorials designed for exactly that:

Hour of Code: Learn the basics and create Pong in about an hour.
Basic Concepts: Go into more detail about everything covered in the Hour of Code.
Swing Pong: Write Pong in standard Java.

 72 
 on: 2015-03-04 14:54:23 
Started by ratchet12340 - Last post by princec
There's nothing special about it. It's just designed primarily to be an OS-event-driven UI library for normal UIs, for which its design is perfectly optimal.

FWIW I've got my own UI library I use for making games UIs. It executes in the main loop, and renders in the main loop, and doesn't even use "events" (just a horribly complex load of state machines). As soon as I want to do anything asynchronous, I have to punt it out into another thread and I am only allowed to interact with my own UI in the main thread. It's a solution you'll end up with time and time again - it's best to accept that's the way it works.

At least with static import and lambda Runnables now it's nowhere near as fiddly and ugly as it used to look:
1  
invokeLater(()->{ setText("Finished!"); });


Cas Smiley

 73 
 on: 2015-03-04 14:48:33 
Started by NegativeZero - Last post by princec
Exposition:

There are exactly 3 consumer-level hardware vendors of any note: Intel, Nvidia, and AMD. They are all capable of or already have a unified driver model which is essentially the same set of binaries for most of their modern hardware.

The way I envisage this working is in a very similar way to DirectX: the game ships the driver installer with the game, just like you see whenever you install a DirectX based game (they always install DX first as part of the installation).

Of course we can always hope and pray that customers have this new Vulkan thing pre-installed and all will be well but there is a reason why DX titles ship with the installer.

Cas Smiley

 74 
 on: 2015-03-04 14:45:16 
Started by craftm - Last post by craftm
Hello friends.

I'm confused about a little issue. I'm finishing my game and I found a problem, when I start the Menu Screen/Game Screen I have a delay (only on Android) until everything start to run properly.

E.g: When I switch to the Game Screen I need to start in "pause state", so the player can start the game itself manually when he feels everything is "loaded". My character has a constant move (horizontal), so if I start the game directly, the player can move for some milliseconds before the player start the game itself.

I really think it can happen because I separated the Draw code and Calculate code inside of render(). The draw() is ALWAYS running and the calculate() is running inside a FPS independent movement code, this is great because I have the same movement speed when 10/20/30/60FPS, but in theory when the game/any_screen starts, the calculate() runs normally in the first frame and this is why the game "starts" few milliseconds before my device show me. In the Desktop version this is not perceivable because CPU/GPU/Memory is very fast.

My code is simple and always the same:
- Show()/Create(): stage, batch, viewport, initialize some variables...
- Render(): RunningState(draw, calc), PauseState(draw, calc).

I want to wait everything be loaded before render(), but in theory render() is only called after show()/create(), so my game is working properly, but how can I start the game itself or the calc() only when the device is prepared to run?

Other e.g: In the first screen, a logo appears with fadeIn-fadeOut, when I start the game on my Android device, I usually can see only the fadeOut or at least the end of fadeIn.

 75 
 on: 2015-03-04 14:44:57 
Started by ratchet12340 - Last post by CommanderKeith
The method you're looking for is called push(), but it's on EventQueue itself.  You don't replace the Toolkit queue, you push another on top of it.
Thank you, I'll try that and report back. It certainly looks like the solution I'm after, which is great.

nsigma at least understands the problem and offers some directions to the solution. The run-your-game-loop-on-the-EDT solution is obvious and isn't the solution I'm after which is painting the GUI in my own thread.
And I say this in the friendliest way (eyeballs @Riven Wink ) - What's so damn special about your own thread?  Do you complain that main() doesn't run in your own thread?  Now, I'm not 100% sure this is the way to go, or that AWT wouldn't kick up a fuss about it, but it would be the simplest way - just make sure to manually drain and dispatch the event queue!
1  
2  
3  
4  
5  
6  
7  
public static void main (final String[] args) {
  EventQueue.invokeLater(new Runnable() {
    public void run() {
      actualMain(args);
    }
  }
}

There's nothing special about my main game loop thread. But what's so special about the GUI library? I just don't think that a GUI library needs to bundle a thread with itself and force me to do all event handling, painting and logic on it. I mean, what if the physics, lighting, AI and scripting also insisted on running all their code on their own threads? It'd be a nightmare. I don't see what's so special about a GUI when all it's supposed to do is update and paint like everything else  Huh

Quote
If you're stuck with using another thread, I have doubts, as you do, about active rendering from another thread while the EDT is still processing events - not just on the paint() thing, but also because models aren't thread-safe.  So, custom queue ...
It seems as though Swing model updates are also just events on the EventQueue, so I should be able to intercept them if EventQueue.push() works out.

By the way, I stumbled on this java.net forum thread which was written by the Swing dev's Scott Violet and Dmitri Trembovetski:
https://www.java.net/node/644028
Dmitri says that the context-switching from calling invokeLater is expensive in the last post. So perhaps there's also a performance reason why rendering from a single thread is a better idea.

Thanks for your advice nsigma, much appreciated.

 76 
 on: 2015-03-04 14:36:42 
Started by NegativeZero - Last post by Riven
isn't it 3.5 ? .. wouldn't call intels opengl-driver a real driver.
Wouldn't it be 2.5 then? persecutioncomplex


* Riven heads for the hills.

 77 
 on: 2015-03-04 14:31:17 
Started by ratchet12340 - Last post by KevinWorkman
The "You can." answers seem passive aggressive to the max. Not even one line saying how you would ever do that. Doesnt seem very helpful - all you are doing is saying "you are wrong".

Thats like some would say "I wish there was a way to take water and break it down into hydrogen and oxygen gas" and your answer is "You can." instead of saying "well this can be accomplished via electrolysis which uses an electrolyte, electrodes and current."

Fair enough. I wasn't trying to be passive aggressive, but the onus usually isn't on us to prove every little misunderstanding wrong. When we get people making posts like "teh jav is suck, C++ is faster and you can use it for games" - we usually just tell them that they're wrong and leave them to their own research, right? If they have specific code showing specific benchmarks we can talk about that, but generally we just tell them "you're wrong, here's some links explaining why, now if you have some code, please post it."

And that's exactly what I did here. I'm not saying CK is a novice or a troll, in fact I quite like the dude, but I feel like I'm being scolded for telling somebody they're technically incorrect- on a technical forum.

Can we take another look at the conversation from my perspective?

Post 11: CK: Everything must be done on the event dispatch thread rather than your game loop thread, which is quite irritating.
Post 13: CK: I don't see why painting, logic and event processing should be restricted to the same thread. It seems like it wasn't thought out very well by the Sun swing engineers.
Post 16: Me: Here's a link to an explanation about why the EDT works the way it does.
Post 18: CK: That way Swing components could be used in a 'direct-rendering' game loop thread, rather than the current requirement where everything to do with them must be done on the EDT.
Post 21: Me: You can.
Post 22: CK: I've never heard of anyone doing it, because I presume that it's impossible.
Post 25: Me: You can absolutely do that.
Post 32: CK: Show me how you can make Swing render in your own thread without the event dispatch thread (EDT).
Post 38: Me: You can, and here's some code.
Post 39: Riven: don't gang up on CK

If it were anybody else, we would have required code to support the claims. But instead, the onus is on us to discount what appears to be a simple misunderstanding of Swing's model. That seems backwards. It's like me making a post that says libGDX sucks because you can't render images- and then requiring other people to post code that proves me wrong.

Anyway, I was going to make a longer post explaining each of my "you can" statements with another code example, but basil_ and nsigma have already covered the basics- and I don't want to appear to be ganging up on anybody.

I hope there are no hard feelings, and I apologize if I came off as passive aggressive or condescending. That was not my intention. Chit-Chat Monster, here I come.

 78 
 on: 2015-03-04 14:29:07 
Started by NegativeZero - Last post by basil_
isn't it 3.5 ? .. wouldn't call intels opengl-driver a real driver.

 79 
 on: 2015-03-04 14:18:05 
Started by NegativeZero - Last post by princec
3.

Cas Smiley

 80 
 on: 2015-03-04 14:02:54 
Started by NegativeZero - Last post by childofgod
Fundamental requirement for adoption and success: ability to ship drivers with client code.

Cas Smiley

This is stupid idea. Do you realize how many manufacturers and how many drivers there are?

Pages: 1 ... 6 7 [8] 9 10
 
Pippogeek (8 views)
2015-03-05 14:36:23

Pippogeek (8 views)
2015-03-05 13:56:12

Pippogeek (6 views)
2015-03-05 13:55:41

Pippogeek (10 views)
2015-03-05 13:23:02

Pippogeek (10 views)
2015-03-05 13:15:28

Pippogeek (6 views)
2015-03-05 13:15:04

Pippogeek (11 views)
2015-03-05 13:13:24

Pippogeek (15 views)
2015-03-05 13:11:33

BurntPizza (46 views)
2015-02-27 06:09:35

BurntPizza (34 views)
2015-02-27 05:56:17
How to: JGO Wiki
by Mac70
2015-02-17 20:56:16

2D Dynamic Lighting
by ThePixelPony
2015-01-01 20:25:42

How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21

Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27
java-gaming.org 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‑gaming.org
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!