Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (578)
games submitted by our members
Games in WIP (498)
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] 2 3 ... 106
1  Java Game APIs & Engines / OpenGL Development / Re: FloatBuffer and Batching on: 2014-04-07 15:16:08
The Hotspot VM is supposed to intrinsify the put() call such that it should be identical in performance to the float[] access... maybe this isn't happening for some reason?

Cas Smiley

Last time I did this it was indeed roughly identical... on desktop VMs. The android vm was much, much slower and combining everything into a big float[] was way faster. Probably why libgdx is doing it this way too.
2  Game Development / Game Mechanics / Gameplay movement: physics engine vs. hand crafted on: 2014-02-26 01:50:33
I'm currently prototyping a 2d spaceship flying/combat game (think Asteroids meets Elite) and I'm looking at various ways to control the ship and how the movement works out. At the moment I've got a simple mock up using Box2d, a single dynamic body for the ship and thrusters that work by applying forces to the body. This works, but feels pretty crap.

Obviously I'm going to tweak this a bit right now, but it leaves me with the same lingering question I had at the beginning - is it ever a good idea to use a physics engine for the central gameplay movement / control which the player will interact with? Often physics-based games feel either laggy or floaty (eg. compare Little Big Planet with Mario Galaxy). But it does mean you get much more emergent behaviour (like proper torque when objects collide, and player's physics triggering physics reactions in the environment). And using a physics engine tends to get you more behaviour 'for free' which is often a big win when it's just a one person project. But it's very hard to get that proper responsive 'arcade' feel with a physics engine.

What are everyone else's thoughts? Do you prefer to go one way or another or does it depend what you're implementing and how it should feel? Have you ever got better results using (say) Box2d over implementing it yourself, and did it feel good to control?
3  Game Development / Performance Tuning / Re: Android - fastest way to fill a [Byte|Float|Int]Buffer on: 2014-02-04 09:04:10
Hmm, that is another possibility I've not thought of before. This is plugged direct into my macbook - i wonder if there's somewhere that will tell me what speed it's running at.

I don't have a spare cable to hand right now, but I'll certainly give that a try when I can. Thanks.
4  Game Development / Performance Tuning / Re: Android - fastest way to fill a [Byte|Float|Int]Buffer on: 2014-02-04 00:27:43
Just the usual debug via Eclipse and usb debugging. No funny settings on the developer options as far as I can tell.
5  Game Development / Performance Tuning / Re: Android - fastest way to fill a [Byte|Float|Int]Buffer on: 2014-02-03 22:31:05
Gnn. Just found out that when run normally on the phone (an S4) it runs at 60fps. Only when running with Eclipse attached is it super slow.

That's particularly annoying since I had a very similar issue with my previous phone (an S2) and a different dev environment setup over a year ago and never found the root cause of it.
6  Game Development / Performance Tuning / Re: Android - fastest way to fill a [Byte|Float|Int]Buffer on: 2014-02-03 17:53:18
Yeah. I'm using a Bubblemark setup for benchmarking, so all the sprites are moving all the time.
7  Game Development / Performance Tuning / Re: Android - fastest way to fill a [Byte|Float|Int]Buffer on: 2014-02-03 05:40:38
Hmm. That's annoying. Because right now I've got 20 sprite objects, and simply generating their vertices and packing them into a ByteBuffer is running at 18fps. The same code happily runs 8k sprites at 60fps on my several years old MacBook Pro.

Surely Android isn't this bad? I must be doing something wrong somewhere...
8  Game Development / Performance Tuning / Android - fastest way to fill a [Byte|Float|Int]Buffer on: 2014-02-01 18:19:29
I've been porting some code from desktop to Android and suddenly found my loading times were up to a couple of minutes. Turns out this was due to filling a ByteBuffer with initial pixels for a new texture.

Looping over all the pixels and doing relative ByteBuffer.put(byte) calls was taking ~10. But creating a temporary array, looping over that and then doing a single bulk ByteBuffer.put(byte[]) takes about 500ms. Filling the array with Arrays.fill() is about 200ms.

Have other people seen the same performance behaviour or is this a quirk of my device (S3)? What's the fastest way to fill a byte buffer with unique values?
9  Discussions / General Discussions / Re: Other Operating Systems on: 2013-10-09 00:20:06
Linux even runs on playstation.

OtherOS was removed from the PS3 in 2010.
10  Discussions / Miscellaneous Topics / Re: What would you like to see in Java? on: 2013-10-08 22:49:26
The syntax would just be a function name? How that looks horrible to you, I don't know.

cout(string);
coutf(string, ...);

Then again, I would just name them print/printf. Either way. That's just as clean as any method.
And what can those operators do that you can't do in a function?

Either way. It's preference. I'd prefer a function. You'd prefer the operators. This thread is about what we would like. (Though, in Java, but that's beside the point).

That's not (in C++ land) equivalent functionality. The use of an operator allows for the conversion to string to be overridden per-type in a non-member function and in a way that decouples it from both the stream code and the type that's being output.

Java gets around this by saying "everything is an Object, and all objects have toString()". Even then it's not functionally equivalent since it tightly links the formatting of an object to the type's definition (which is not always desirable). And only works because the language has an implicit understanding of how + works for strings and how that is mapped into a toString() call. ie. it's a single specific case hardcoded into the language, whereas the C++ streams system is constructed entirely with language features available to any developer.
11  Discussions / Miscellaneous Topics / Re: What would you like to see in Java? on: 2013-10-08 21:45:19
C++ could have just as easily accomplished what "<<" and ">>" do with simple function names.

Not without either horrible resulting syntax, or a reduction in functionality.
12  Discussions / Miscellaneous Topics / Re: What would you like to see in Java? on: 2013-10-08 21:37:59
Do people actually like "<<" and ">>" in C++? I thought that was the dumbest thing. C was doing just fine with printf/scanf and the variants.

No, it wasn't. printf and the like are fundamentally type-unsafe and not extendable. You can scribble all over memory by accidentally mis-matching your format code and the actual type you pass it. And you're limited to the built-in type formatting that the functions support.

C++ streams and the insertion (<<) operator is *always* type safe, and you can override the insertion operator per-type to provide custom formatters (much like Java does with toString(), but more generically). The only disadvantage is the different syntax, and once you've used it for a while both become equally natural.
13  Game Development / Newbie & Debugging Questions / Re: How to implement game objects? on: 2013-09-23 14:14:35
Of course, with XML you can skip the editor and write it in XML at first.  When you write an editor you can check what the editor's doing easily.  Every other programmer in the universe will tell you to use XML.  And you need to do what works for your.

There's a whole range of possibilities between binary and xml. Json and yaml are the obvious alternatives, both considerably less verbose. And if you go binary too soon you make your data harder to work with and change.

See also The Power Of Plain Text
14  Discussions / General Discussions / Re: Do you customize your IDE (Eclipse?) on: 2013-09-16 18:34:05
I don't quite customize Eclipse since it always resets the settings every time I create a new workspace (unless there's a way to keep the settings as I've set them)

File->Export->Settings in the original workspace, then File->Import->Settings in the new workspace?

Alternatively, you can kind-of do the same thing with 'working sets', which is basically a set of projects that you can open/close as a group.

I don't tend to customise my programming tools a huge amount (Eclipse, Visual Studio, etc.), I find it really helpful to stick as close to the 'factory settings as possible. Firstly you tend to find less bugs since you hit less edge cases, and secondly it's much easier to switch to working on other people's machines, or for other people to work on yours. I count that as a huge win when working in a team.

About the only thing I do in Eclipse is crank up the compliance/compiler checking to near max.
15  Discussions / Miscellaneous Topics / Re: RAM size on consoles: How did they make those old awesome games? on: 2013-09-16 10:46:09
Much of what I coded for the ps2 was an octree based renderer for an f1 racing game in a now defunc outfit so not much knowledge there.

SCEE Liverpool?
16  Game Development / Newbie & Debugging Questions / Re: this. - code consistency and readability on: 2013-09-15 19:59:09
Consider the following Class of a program:

If you always declare your input args to a function as final (which IMHO everyone should do, at least for primitive types) then you'll get an error if you accidentally forget the 'this.' in the assignment.

For simple setXxx() methods it's often the style to have the arg name identical to the member name. That's helpful because you're hinting at the reader that it's supposed to be a straightforward 'set' with no translation, adjustment or other monkey business.

I generally only use 'this.' at times when I want to emphasise that the code is changing the object's state. Particularly when you've got a bunch of calculation on local values, then you set the result as a member.

Your functions should (usually) be small enough that you don't need m_ or 'this.' to make them readable. And if you use 'this.' everywhere then you loose the ability to make people sit up and notice when one actually appears.
17  Discussions / Miscellaneous Topics / Re: RAM size on consoles: How did they make those old awesome games? on: 2013-09-15 19:47:51
You should totally read this book:

http://mitpress.mit.edu/books/racing-beam

It goes into loads of gritty details of how games managed to squeeze out playable games on a tiny, tiny system. And it's super readable too.

Also remember that a lot of older hardware (particularly 8-bit and 16-bit consoles) had chips designed to throw around game-like graphics. Tile maps and sprites were basically built-in, which saves a lot of memory and code size.
18  Game Development / Newbie & Debugging Questions / Re: UDP and TCP on: 2013-09-09 19:31:26
There's basically three ways to approach it:

1. Use tcp everywhere and just put up with the (potential) extra latency added.
2. Use udp everywhere and write your own transmission protocol to guarantee delivery when required.
3. Use both at the same time.

I've previously done all three, and they all basically work. Option 3 is nicer if you want to avoid writing a reliability layer over udp, but can make the initial connecting and handshaking more of a pain since you've got two connections to manage instead of one. What you've described is completely valid if that's the way you want to go.

If you're only concerned with minimising latency, then 2 can be good as you can theoretically get a faster reliable protocol than TCP if you bend some of the rules TCP adheres to.

However if this is your first multiplayer game, or if you're just trying out some ideas, totally go for 1. You can focus on your mechanics and gameplay *much* quicker, and you probably won't notice the difference in latency unless you've got players in different countries or across mobile networks. I'm doing 1 right now to prove some gameplay and latency is completely not an issue.

Also, consider Kryonet: https://code.google.com/p/kryonet/
19  Game Development / Newbie & Debugging Questions / Re: Extending the Color class on: 2013-09-08 02:15:47
It depends on how you're calling it, but I suspect you're trying to override a static method, which won't work.

Don't bother with a custom subtype of Color - that's bad OOP. Instead just move your static blend() function into a utility class somewhere, then call it.
20  Java Game APIs & Engines / OpenGL Development / Re: 2D Translucent Sprites in 3d (2.5D) on: 2013-09-04 11:01:57
If you want hard-edged sprites like those, keep depth test enabled, disable alpha blend and enable alpha test. Then they'll be sorted properly with the rest of your opaque geometry.

You may also want to set an alpha test reference value.
21  Java Game APIs & Engines / OpenGL Development / Re: Cube is rendering faces out of order! on: 2013-09-02 11:11:52
Make sure you're requesting a depth buffer when you create your display, otherwise GL_DEPTH_TEST won't have anything to work against.
22  Discussions / General Discussions / Re: Eclipse Kepler automatic semicolon on: 2013-08-31 20:25:34
Preferences -> Java->Editor->Typing

Checkbox 'Automatically insert at correct position: semicolons' ?
23  Java Game APIs & Engines / Engines, Libraries and Tools / Re: libgdx: Terrible performance with very few draw calls on: 2013-08-31 19:08:05
ah that would explain it. I only use logcat.

I'm not sure that's true; DDMS seems to be a required part of the debugger backend - you're using it even if you're not using the DDMS perspective in eclipse.

I'm not entirely convinced I've got all the problems out though - I'm still seeing very spiking framerate behaviour even without DDMS. I don't know if this is standard for android and getting a smooth 60fps is impossible?
24  Java Game APIs & Engines / Engines, Libraries and Tools / Re: libgdx: Terrible performance with very few draw calls on: 2013-08-31 16:57:36
Aha! Looks like the code is fine - it's actually the debugger (more specifically, DDMS) that's causing the drop. Running the app from the device gets 60fps, but if I then get DDMS to connect to that process the framerate drops to 20ms. Shutting down eclipse (and thus DDMS) makes the performance shoot back up to 60fps.

It looks like this old (and still open) bug from 2011: https://code.google.com/p/android/issues/detail?id=21190
25  Java Game APIs & Engines / Engines, Libraries and Tools / Re: libgdx: Terrible performance with very few draw calls on: 2013-08-30 12:22:35
It does feel like there's something else going on I'm missing. Next step is to strip back the code to the bare minimum and see how performance changes (if at all).
26  Java Game APIs & Engines / Engines, Libraries and Tools / Re: libgdx: Terrible performance with very few draw calls on: 2013-08-30 00:42:31
Hmm. Packing the couple of textures and font at runtime means I've now got my 40-odd sprites and text being drawn in one batch, so that's good - however in-game with a small tile map I'm still only seeing 20-25fps (which is an improvement, but far from 60fps). And DDMS says I'm still taking 20ms for 'Process' per frame.

Needs more probing...
27  Java Game APIs & Engines / Engines, Libraries and Tools / Re: libgdx: Terrible performance with very few draw calls on: 2013-08-29 09:36:33
From some more poking I'm getting 40 batches per frame, which doesn't sound like a lot but could be part of the problem.

I'm doing something like this:
1  
2  
3  
4  
5  
6  
7  
8  
class TextButton extends Actor
{
  public void draw(SpriteBatch batch)
  {
     patch.draw(batch);
     text.draw(batch);
  }
}

This seems to be causing a draw batch for every button since the nine patch and text use different textures. Is there a way to layer these at runtime via sprite batch (so all text is drawn over the top), or do I need to start merging the textures into an atlas somehow?

Also I can't see how I'd avoid having two batches if I want to draw the fps text separately. Stage doesn't expose the sprite batch. I guess I could add an Actor for the fps but that seems like a sledgehammer to crack a nut.
28  Java Game APIs & Engines / Engines, Libraries and Tools / libgdx: Terrible performance with very few draw calls on: 2013-08-29 00:37:02
I got a bit of a shock today when I tried the game I've been working on with a proper device and found that my tiny game is running at about 20fps. Sad

In-game, at the moment I've got 16 tiles, one sprite, 6 patches and 6 bitmap font draw calls. On an S4 I'd hope that'd be capable of hitting 60fps without breaking a sweat.

Simplifying it, my hacked main menu now just has 20 tiny buttons on it, which is each a single call to BitmapFont.draw and NinePatch.draw. This gets ~15fps.

I have a single libgdx Stage.draw() set to the full screen res, and a second SpriteBatch that's just used to draw the fps text. The app is set to use GL2.0, but it doesn't make a different to the fps either way. Just drawing the fps display gets me a solid 60fps.

Textures are only being loaded at startup. Fillrate doesn't seem to be an issue since it occurs no matter how small I make the buttons.

DDMS's frame time measurement says it's taking 68ms to 'Process', whatever that covers, with 'Draw' at 9ms and 'Execute' at 0.7ms.

I'm fairly sure I must be doing something stupid here since I'm new to libgdx. Anyone have any pointers? Thanks.
29  Game Development / Networking & Multiplayer / Re: Android / libGDX: High ping times in simple TCP connection on: 2013-08-11 13:02:23
If you don't mind me asking, why would you need such real-time networking anyway?

For a real-time multiplayer game, of course.

Obviously I need client prediction and latency hiding and all that jazz, but when my baseline, best possible conditions ping turns up at 300ms then that's really worrying.

I may knock up a udp test and see how the latency compares (annoyingly libGDX doesn't support UDP from what I can tell. Sad ).
30  Game Development / Networking & Multiplayer / Re: Android / libGDX: High ping times in simple TCP connection on: 2013-08-11 01:34:23
I wouldn't expect smartphones/tablets to be capable of any kind of real time networking without WiFi and even then expect an average 500ms.
This is a local lan via wifi - I'm not sure why you'd expect such bad ping times? Mobile phones are pretty much full computers now, just with a locked down OS. With a wifi laptop on the same lan I can ping google and get ~20ms response times, and that includes going over the internet to google's server and back.

Poking around in the options there's 'power savings' settings which seem to affect the wifi, but with everything off the ping time remains unchanged.
Pages: [1] 2 3 ... 106
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (27 views)
2014-04-15 18:08:23

BurntPizza (22 views)
2014-04-15 03:46:01

UprightPath (38 views)
2014-04-14 17:39:50

UprightPath (20 views)
2014-04-14 17:35:47

Porlus (36 views)
2014-04-14 15:48:38

tom_mai78101 (61 views)
2014-04-10 04:04:31

BurntPizza (119 views)
2014-04-08 23:06:04

tom_mai78101 (219 views)
2014-04-05 13:34:39

trollwarrior1 (186 views)
2014-04-04 12:06:45

CJLetsGame (193 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
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!