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 ... 8 9 [10]
 91 
 on: 2015-03-04 05:54:51 
Started by BurntPizza - Last post by Slyth2727
Ingame script editing, fully dynamic and reloads the map as soon as you hit the button. I've been up till about 3 every night this week trying to finish this game. It's due Saturday. Wish me luck in nationals.
Edit: I now fully understand the saying "a programmer is simply a machine that turns pizza and caffeine into code". gfdgm,hsdfhhhhh


 92 
 on: 2015-03-04 05:51:28 
Started by NegativeZero - Last post by Slyth2727
This is exciting. A low level API working on multiple platforms will be incredible. That's all I have to say.

 93 
 on: 2015-03-04 04:49:19 
Started by NegativeZero - Last post by HeroesGraveDev
I just hope that AMD/Nvidia release their Linux/Mac drivers at the same time as everything else. It would be a bit embarassing if the next generation of cross-platform graphics only worked on Windows.

Lower-level will be a good thing. Current OpenGL requires lots of boilerplate to work around awkward API decisions. Having the control available to let third parties sort out the API will be a great step forward (and allow those who are interested to better understand how graphics cards work).

Precompiled shaders will definitely be an awesome addition. The more errors that can be detected at compile-time the better.

Also, is there any word on what range of existing graphics cards will support this?

(Sorry about the layout of this post. My thoughts are a little bit all over the place)

 94 
 on: 2015-03-04 04:34:06 
Started by KevinWorkman - Last post by HeroesGraveDev
You really do not get it, do you?

What you're doing is creating rumours and spreading lies to try and devalue someone else's work and make yourself feel better about your lack of success. Some of the people who have been members on this forum for a while even know the guy who you're doing this to, and you're expecting them to help you in spreading these lies? You're even going as far as to complain about people pointing out this nastiness and labelling them as trolls. This guy you're attacking just wanted to make a fun game, and through a combination of luck and hard work ended up rather rich and famous (which he doesn't seem to be that happy with). Just because he's super-rich and famous doesn't excuse this kind of behaviour.

It's absolutely pathetic.

You want my constructive feedback?
Delete all your posts in this thread.

 95 
 on: 2015-03-04 03:50:42 
Started by Dogstep - Last post by Dogstep
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".

 96 
 on: 2015-03-04 03:40:44 
Started by ratchet12340 - Last post by CommanderKeith
And here's a really dumb program that follows the bullet points at the bottom of that link to perform active rendering in Swing, off the EDT:
1  
2  
3  
4  
5  
6  
               Graphics g = myPanel.getGraphics();
               g.setColor(Color.WHITE);
               g.fillRect(0, 0, myPanel.getWidth(), myPanel.getHeight());
               g.setColor(Color.BLACK);
               g.drawRect((int)ballX, (int)ballY, 100, 100);
               g.dispose();

I don't think that you understand the problem, which is to paint Swing components inside the game loop, not rendering inside an empty JPanel. There should be a swingComponent.paint(g) in there.

When you switch to active rendering you're in control of paint() not the EDT.
setIgnoreRepaint only stops the operating system (OS) events from calling paint, not internal changes to the menu. See the java docs:
Quote
Sets whether or not paint messages received from the operating system should be ignored. This does not affect paint events generated in software by the AWT, unless they are an immediate response to an OS-level paint message.
This is useful, for example, if running under full-screen mode and better performance is desired, or if page-flipping is used as the buffer strategy.
So for example, if the game logic calls setText(String) on an in-game GUI JLabel, then inside the JLabel.setText method repaint is called, which posts an even to the EventQueue, which will occur on the EDT even though setText was called from the game loop thread, conflicting with the painting of that button in my game loop thread.
Stopping this is difficult, as basil said it requires 'interception' of the event on the EDT which is not easy. I thought it was impossible since no-one has shown how it is done without reflection hacks, but I'm open to being proved wrong. nsigma is the only person who has offered reasonable advice, and even then I wonder if it's possible.

You can do all that already!  To paint, you could use active rendering, or if you're running your game loop in the EDT you could control the default Swing paint mechanism.  For the other two, use Toolkit.getSystemEventQueue() to get access to the queue.  If you're running your game loop in the EDT, just pull events and dispatch (see component.dispatchEvent()).  Otherwise, push your own EventQueue implementation on top of the existing and override EventQueue.dispatchEvent() to filter / pass to your game thread.  The latter might have an issue if anything was using EventQueue.isDispatchThread() though.

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.
How do you push your own EventQueue? I note that there is Toolkit.getEventQueue but no Toolkit.setEventQueue()?
I would like to see your EDT-event interception idea work. As I said, no-one has demonstrated this being done that I have ever found.

Nuff of this. We all have our ill-informed moments. No need to 'gang up' on our beloved Keith. I'm sure lots of people found new information in this thread about the inner workings of Swing - we should focus on sharing such information instead of telling eachother how ill-informed we are, over and over and over. We don't need N similar corrections from N people quoting the same statement. It gets old rather quickly.
Thanks, it's nice to be beloved! I'll be the first person to admit that I'm wrong, but so far it seems that people either don't understand the problem or dismiss it as not being a problem.

I would like to treat the GUI like everything else in a game: with an update and a paint method. I thought that is what we would all want Huh

Quote
Like I've said several times now, this is not just a Swing thing. Almost every GUI library (including OpenGL, Android, JavaFX, libGDX, and JMonkeyEngine) uses this model. I promise that the people behind these libraries have put more thought into it than you or I.
If every GUI library has an EDT like Swing, I'm surprised. I think it's a design deficiency because it's inflexible. According to the principal of loose-coupling, Swing's event system, painting and logic should be separable, but clearly they aren't.

Quote
Edit: And like Cas says, none of this really matters. If you really think you need to go through all of this rigmarole with active rendering and threading in Swing: you're either wrong, or you should be using a different library that handles it for you.
On the whole I like the swing libary and it's what I know. If I could re-use it in my games I would. But the way it enforces everything to be done on the EDT is quite irritating. I will try libgdx's scene2d.ui, nifty or TWL for my next projects.

That tutorial guide gives no working examples, and even worse, it seems to indicate that active-rendering swing components from a non-EDT game loop thread in a thread safe way is impossible, since it says:
Quote
Don't put drawing code in the paint routine. You may never know when that routine may get called! Instead, use another method name, such as render(Graphics g), which can be called from the paint method when operating in windowed mode, or alternately called with its own graphics from the rendering loop.
It seems to indicate that a swing component's paint method can be called at any time from the EDT (with or without setIgnoreRepaint) and therefore you can't truly paint swing components in your own game loop thread.

By the way, it's great to be part of a forum where we can debate interesting topics like this.

 97 
 on: 2015-03-04 03:12:22 
Started by Herbherth - Last post by Ecumene
I love the art, this is a really cool idea, and probably helps brain power too! Nice work. Smiley

I'm not a programmer or musician or designer but somehow I managed to do everything in this game (That's why it's not GREAT, but I think it's not bad too [at least I hope so...  Lips Sealed])

"Our character is what we do when we think no one is looking"

I used LibGdx to do the game.

If you like it, please rate and share with friends Wink

Nice work, keep at it!

 98 
 on: 2015-03-04 03:05:38 
Started by Fairy Tailz - Last post by Husk
This function works on floats in the range [0.0F, 1.0F] only. This of course represents a percentage.

Like with anything else, you can get a percentage by dividing N by it's limit. The maximum of an RGB integer component is 255.

So you can perform 135/255 to arrive at 0.5294117647058824. Truncate that as needed. Smiley

Edit: Don't forget about integer division! 135/255 equals 0. One of the numbers must be a float when you divide.

 99 
 on: 2015-03-04 03:05:19 
Started by Fairy Tailz - Last post by SHC
Dividing the integer by 255f will make it into a float.

 100 
 on: 2015-03-04 03:04:33 
Started by Fairy Tailz - Last post by Ecumene
OpenGL uses floats for it's colors, because their easier to do math on. So 1.0 would be full, 0.0 would be empty, and .5 would be half full (or half empty persecutioncomplex )

RGB 256 in floats:
color/255
Example:
135/255 = 0.5294117647

RGB floats in 255:
color*255
Example:
0.5 * 255 = 127.5


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

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

Pippogeek (4 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!