Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (115)
games submitted by our members
Games in WIP (563)
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 ... 279
1  Game Development / Networking & Multiplayer / Re: Check if UDP message was successfully received? on: 2014-09-22 07:28:54
In the Work in Progress board.
2  Game Development / Performance Tuning / Re: Best way to go about many objects checking array for data? on: 2014-09-22 05:42:38
Yup. Still no trig. You take the vector from one mass to the other, normalize it, and you have your directional vector, which you can multiply with F/m (from: F=m*a) to get the (directional) acceleration.
3  Game Development / Performance Tuning / Re: Best way to go about many objects checking array for data? on: 2014-09-22 05:31:45
FYI: you don't need trig for gravity.

4  Discussions / Miscellaneous Topics / Re: Whays the story behind your name on: 2014-09-21 20:51:36
So, what's the incredulous tale about your nick?
5  Discussions / Miscellaneous Topics / Re: Whays the story behind your name on: 2014-09-21 20:44:14
I once was registered on JGO under a different name. A couple of years later I realized it was a bad one, so I associated myself with the best game ever.
6  Discussions / General Discussions / Re: Welcome back... on: 2014-09-21 17:53:52
I checked the logs, and see lots of errors like these for your domain:
Quote
The recipient <******@sldt-team.net> has exceeded their message rate limit. Try again later.
7  Discussions / General Discussions / Re: Microsoft to buy Mojang for $2 billion? on: 2014-09-19 06:54:19
Quote
What if you *couldn't meet a single person in real life* who hasn't heard something negative about you?
Move to eastern Europe where no one expects you. I have already done this in anticipation.
It takes one tweet for your efforts to be thwarted. You run out of countries surprisingly fast. And I'd know, I'm posting this from a shed in Chile.

Anyway, for me the worst thing about being filthy rich probably wouldn't be dealing with 'the enemy', it'd be figuring out who's a friend. That stuff is hard enough without people trying to piggy back your wealth. I'd probably put it in a 10 year deposit and see who sticks with you for... you, if any.

It's probably the small things in life that are ruined. I certainly hope to never have more than, say, a modest 10 million.
8  Discussions / General Discussions / Re: Microsoft to buy Mojang for $2 billion? on: 2014-09-18 21:19:26
It takes one to recognize you, and then everybody else notices. Then you're surrounded by kiddos that think you owe them something because they once paid $10 - after having just spent $15 at Mc D. If you walk the mall three times a week, and it happens once a month, you're going to feel uncomfortable every time you're there. I'm not saying that what you say isn't correct, it's just not fully thought through Pointing (trollololol)
9  Discussions / General Discussions / Re: Microsoft to buy Mojang for $2 billion? on: 2014-09-18 16:57:38
Enlighten me about Daft Punk. (because this fully a capella rip-off remix is awesome)

<a href="http://www.youtube.com/v/3MteSlpxCpo?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/3MteSlpxCpo?version=3&amp;hl=en_US&amp;start=</a>
10  Discussions / General Discussions / Re: Microsoft to buy Mojang for $2 billion? on: 2014-09-18 15:31:14
The opinions of millions of misinformed strangers trickle through in your personal life, I suspect.
11  Discussions / Miscellaneous Topics / Re: What I did today on: 2014-09-17 12:50:07
Brought back JGO, among other things...
12  Discussions / General Discussions / Re: Asteroid hit the memcache service on: 2014-09-17 12:43:22
Fallback added and tested. Now back to work persecutioncomplex
13  Discussions / General Discussions / Re: Asteroid hit the memcache service on: 2014-09-17 12:10:57
Scripting error fixed! Now on to adding a memcache fallback...
14  Discussions / General Discussions / Re: Asteroid hit the memcache service on: 2014-09-17 12:01:29
Not even for 2bln I'd point java-gaming.org to their servers.


15  Discussions / General Discussions / Asteroid hit the memcache service on: 2014-09-17 11:57:00
The memcache service that keeps JGO reasonably performant, went in limbo about 9 hours ago. Cranky This has been the longest downtime for JGO since the time JGO was hosted on its first VPS, and the hoster decided to install a firewall (behind my back) that went into lockdown mode when iptables was altered in any way, and they didn't offer any support whatsoever in weekends. Those were the days...

It was a 2 minute fix, so the memcache service is up and running again, and things seem to run reasonably well, except for that scripting error in the 'info center' on the homepage. I can't put too much time in it at this very moment, because... work. At least you get to post again!

I'll keep you updated, whenever I can!
16  Discussions / General Discussions / Re: Microsoft to buy Mojang for $2 billion? on: 2014-09-16 15:31:08
He's probably flooded with financial pleas, and he'll be regarded arrogant for not granting them (all). Emo
17  Game Development / Shared Code / Re: [Java 2D] Simple Particle System on: 2014-09-14 19:56:48
Threads in the [shared code] board must contain shared code, not references to it.
18  Games Center / Featured Games / Re: [Slick2d] Retro-Pixel Castles > Building Info! < on: 2014-09-14 19:53:02
Adding roads and rails (especially the curvy kind) with vehicles using them, is enough to be a full project all by itself.

Even the backburner sounds like a dangerous place. Pointing
19  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LibStruct on: 2014-09-10 21:20:13
More chapters will be written after a good night's sleep. Pointing
20  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LibStruct on: 2014-09-10 21:01:15

Chapter 2: why using structs as objects will break in horrible ways at runtime




A bunch of static methods

When LibStruct encounters a struct, like a simple Vec3, it will turn this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
public class Vec3
{
   public float x,y,z;

   public Vec3 add(Vec3 that) {
      ...
   }

   public String toString() {
      return "("+x+", "+y+", "+z+")";
   }
}

into:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
public class Vec3
{
   // note: no fields!

   public static int add(int this, int that) {
      ...
   }

   public static String toString(int this) {
      // HotSpot recognizes this pattern, and turns all
     // these operations into the LEA x86 instruction.
     // it also allows us to address 16GB (!), instead of 4GB of structs.
     float x = Struct.unsafe.getFloat(((this & 0xFFFF_FFFFL)<<2)+0);
      float y = Struct.unsafe.getFloat(((this & 0xFFFF_FFFFL)<<2)+4);
      float z = Struct.unsafe.getFloat(((this & 0xFFFF_FFFFL)<<2)+8);
      return "("+x+", "+y+", "+z+")";
   }
}

In short: your fields won't exist, and all your methods will be static, including methods intended to override other methods, like if functions like hashCode() and toString() are declared in your struct. This is tricky territory, if, and only if, you're going to use your structs as if they are objects.

A simple callsite, looking like this:
1  
2  
3  
4  
Vec3 a = ...
Vec3 b = ...
Vec3 c = a.add(b);
String s = c.toString();

is rewritten into:
1  
2  
3  
4  
int a = ...
int b = ...
int c = Vec3.add(a,b);
String s = Vec3.toString(c);




Unexpected duplicate method signatures

Let's say you have 2 struct types: Point and Triangle, now this innocent looking code:
1  
2  
3  
4  
5  
public class NonStructType
{
   public void dup(Point p) {...}
   public void dup(Triangle t) {...}
}

will be rewritten to:
1  
2  
3  
4  
5  
public class NonStructType
{
   public void dup(int p) {...}
   public void dup(int t) {...}
}
leading to a duplicate method signature at runtime, causing the bytecode verifier to bark. Beware. Make your method names more explicit if the need arises.



The usage of toString and incorrect parameter arguments

As previously explained, struct variables are nothing but integers holding references to memory addresses.

Let's say we have this code:
1  
2  
Vec3 a = ...;
System.out.println(a);

behind the scenes, this bytecode is generated by javac:
1  
2  
3  
ALOAD 0
GETSTATIC java/lang/System.out
INVOKESTATIC java/lang/PrintStream.println(Ljava/lang/Object;)V

(maybe) you can imagine the problem of rewriting that 'a' variable to an int:
1  
2  
3  
ILOAD 0
GETSTATIC java/lang/System.out
INVOKESTATIC java/lang/PrintStream.println(Ljava/lang/Object;)V

we just attempted to push an
int
argument into a parameter defined as java.lang.Object. The bytecode verifier will instantly reject this mockery. So why don't we just rewrite the parameter to accept an int,like so:
1  
2  
3  
ILOAD 0
GETSTATIC java/lang/System.out
INVOKESTATIC java/lang/PrintStream.println(I)V

Well, in this case, PrintStream.println(int) actually exists, but we're just lucky. The vast majority of methods with Object parameters, do not have an overloaded method with an int, and even if so, you'd wonder whether you could just call a totally different method, just because its parameter types fit your need.

Long story short: this is a problem that cannot be solved correctly, because the callsite is actually making a mistake! It is trying to pass a struct to a method that expects an object. The Java Compiler won't complain though, because the compiler doesn't know about LibStruct, and the code is perfectly valid at compile-time (as opposed to rewrite-time).

People (the first users of LibStruct) however, kept making this mistake, so I hacked up LibStruct quite badly, so that in case it detects this problem, it injects code that converts the struct argument (at runtime, an int argument), into a String argument, with a plain description of your struct: "<struct@...address...>"

With this arcane hack, you can finally do what should be forbidden in the first place:
1  
System.out.println(a); // prints: "<struct@394843575>"




Java Collection classes and Generics
The collection classes in the java.util-package only deal with Objects. You can't use them with structs. Structs are not objects, using them as such will only lead to misery. Case closed. Same with generics: Generics won't work for primitives, only for (types of) objects, and structs are not objects.

How would the following code work?
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
interface Producer<T> {
   T produce();
}
class StringProducer implements Producer<String> {
   String produce() {
      return "yarn";
   }
}
class Vec3Producer implements Producer<Vec3> {
   Vec3 produce() {
      return Struct.malloc(Vec3.class);
   }
}

String s = new StringProducer().produce();
Vec3 v = new Vec3Producer().produce();

If at all possible, the last line would be rewritten to:
1  
int v = new Vec3Producer().produce();

which would require support for primitive-generics, and a Producer that had a magically overloaded produce() method that returned an
int
, breaking the contract of Producer. Both problems are not something we should seek to solve, as struct(type)s simply should not be used as object(type)s.


The only reason the following works:
1  
2  
3  
List<Vec3> vecs = new ArrayList<Vec3>();
vecs.add(new Vec3(1,2,3)); // really?
Vec3 vec = vecs.get(0); // kaboom

is due to the [struct-argument to object-parameter] hack, actually adding a String ("<struct@9384753>") to the type-erased ArrayList. Upon calling vecs.get(0), the Java Compiler will have sneaked in a cast-check to Vec3, to add a safety net around type-erasure, and at runtime your code will throw a ClassCastException (String cannot be cast to Vec3):
1  
2  
3  
4  
5  
List vecs = new ArrayList();
vecs.add("<struct@9384753>"); // really?
Vec3 vec = (Vec3)vecs.get(0); // kaboom
// or rather
int vec = (int)vecs.get(0); // doubly kaboom




With that out of the way, just don't. Don't use structs as if they are objects. For these kinds of problems, think of them as really wide primitives, without Java 5's auto-boxing.
21  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LibStruct on: 2014-09-10 20:05:24

Chapter 1: different types of acquiring structs and their (automatic) disposal


There are a few ways to allocate and free structs, roughly following the way C handles structs:



Stack Allocation

First we have stack-allocation, using the
new
keyword:

1  
2  
3  
4  
5  
6  
7  
8  
9  
public void execute() {
   // here, the stack position is saved (let's say it's 53489448)

   Vec3 a = new Vec3(); // struct at position 53489448
  Vec3 b = new Vec3(); // struct at position 53489460
  Vec3 c = new Vec3(); // struct at position 53489472

   // here the stack position is restored to 53489448
}
The stack, is like the C stack: the address it's at, is saved upon method entry, and is restored upon method termination. Once the stack is popped, all structs created within that method are considered freed, and the references pointing to them must not be used. This means that you would* not be able to return a struct that you stack-allocated within a method, because after the method is terminated, the callsite will receive a reference to a struct that is considered 'undefined memory'.

Another misconception is that stack-allocation is that saving and restoring the stack happens on arbitrary scopes. This is not the case: the following loop will grow the stack, until the JVM crashes:
1  
2  
3  
4  
5  
6  
7  
8  
9  
public void kaboom() {
   // here, the stack position is saved (let's say it's 53489448)

   while(true) {
      new Vec3(); // struct at position 53489448 + (n++)*12
  }

   // here the stack position is restored to 53489448
}
Moving the while-loop body into it's own method, would solve the problem, as the stack would be saved and restored each time the method in the loop body is called.

N.B.: Never free() a stack allocated struct: it is conceptually equal to a double-free in C, leading to memory corruption.


How do we make a stack-allocated struct, available to the callsite? We let LibStruct copy it to a stack-allocated struct in the callsite:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
@CopyStruct
public Vec3 add(Vec3 a, Vec3 b) {
   Vec3 sum = new Vec3();
   sum.x = a.x + b.x;
   sum.y = a.y + b.y;
   sum.z = a.z + b.z;
  return sum; // copy into callsite happens here, the 'sum' struct goes out of scope
}

Vec3 a = new Vec3(1,2,3); // stack allocated explicitly
Vec3 b = new Vec3(4,5,6); // stack allocated explicitly
Vec3 c = add(a, b); // 'c' is stack allocated implicitly





Mapping structs on byte-buffers

Let's say we have a region in memory in which we want to place our structs. For games, this typically is a VBO.
1  
2  
ByteBuffer bb = ByteBuffer.allocateDirect(...);
Vec3[] mapped = Struct.map(Vec3.class, bb, stride, offset);

The references to the structs in the Vec3[], point to memory addresses in the byte-buffer. You are free to overwrite these references:
1  
2  
mapped[13] = mapped[15];
mapped[14] = new Vec3(); // stack allocated, beware!
The references to these structs are valid, as long as the memory the ByteBuffer is pointing to, is not garbage collected. Structs to not contain a reference to this byte-buffer, so it's up to you to keep the byte-buffer referenced.

N.B.: Never free() a mapped struct: it is conceptually equal to a double-free in C, leading to memory corruption.



Manually allocated and freed structs

If you wish a bit of convenience, you can let LibStruct manage the allocation and free-ing of structs for you.
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
@TakeStruct
public Vec3 add(Vec3 a, Vec3 b) {
   Vec3 sum = Struct.malloc(Vec3.class);
   sum.x = a.x + b.x;
   sum.y = a.y + b.y;
   sum.z = a.z + b.z;
  return sum; // no copy is made, the reference is passed as is
}

Vec3 a = new Vec3(1,2,3); // stack allocated
Vec3 b = new Vec3(4,5,6); // stack allocated
Vec3 c = add(a, b); // 'c' is manually allocated

Struct.free(c); // and must be freed manually

N.B.: Only free() a malloc()ed struct.



Arrays of structs

With
new Vec3[n]
, you are guaranteed to receive a tightly packed sequence of structs.
With
Struct.map(...)
, you are guaranteed to receive a tightly packed sequence of structs.
With
Struct.malloc(Vec3.class, n)
the structs are not guaranteed to be tightly packed, as the memory manager can run out of space in it's current TLAB (thread local allocation buffer) and continue allocating instances on the next TLAB.
With
Struct.emptyArray(Vec3.class, n)
, you get an array of null references, for you to decide how to fill with references, not with data - writing into these (arr[13].x = 0.0f) will crash the JVM with a memory access violation.
22  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LibStruct on: 2014-09-10 15:18:40
Nice to see you poking around. Pointing

I see you have a metric ton of misconceptions, which I will happily clearify in a few hours Smiley
23  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LibStruct on: 2014-09-09 22:18:40
Spill it! And as long as I don't have to post a wall of text introducing LibStruct to people thinking Objects are just fine, I might even offer some support, patches and new features Smiley
24  Discussions / Miscellaneous Topics / Re: What I did today on: 2014-09-09 21:35:40
You drew: geometry shader → vertex shader → fragment shader,
while it is: vertex shader → geometry shader → fragment shader.
25  Java Game APIs & Engines / OpenGL Development / Re: [LWJGL] Why should we call Display.destroy()? on: 2014-09-09 06:30:23
Just remember how often your game crashes while it's in development. All these times the process terminated without having called
Display.destroy()
. The gfx-driver will clean up after you, no matter what, but that doesn't mean you should give it the finger Smiley
26  Discussions / General Discussions / Re: Aspect Oriented Programming: Has anyone tried it? on: 2014-09-08 23:09:22
I don't see how there is any irony or contradiction there, honestly. Structs don't change flow, they give you control over the memory layout of your data.
27  Games Center / WIP games, tools & toy projects / Re: Kid On Crack 2 on: 2014-09-08 22:43:30
Please show us some of the gameplay.
28  Games Center / WIP games, tools & toy projects / Re: Kid On Crack 2 on: 2014-09-08 22:15:56
Moved from Featured to WIP.
29  Discussions / General Discussions / Re: Aspect Oriented Programming: Has anyone tried it? on: 2014-09-08 20:04:00
Decoupling functionality and stitching it back together with regex/patterns is a great way to ensure job security. I steered clear of this (anti)pattern because it was so obviously nuts. Clicking through code - using your IDE - is invaluable when tracing the flow of your code. AOP scatters your decoupled code around your code base, leaving your IDE and you clueless when debugging. It seems like its finally on the way out though, people are dropping it left and right.

Learn from the mistakes others made, if you don't see the disadvantages right away Smiley
30  Game Development / Newbie & Debugging Questions / Re: Moving player tile-to-tile (A* Pathfinding finally done) on: 2014-09-08 16:03:18
(Near)zero-cost is not required, the effect is already observable if we have a parallel dirt road and paved road. Let's say the edges of the dirt road have cost 1.1 and the paved road has cost 0.9, all other edges (grass) have a cost of 2.0.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
ORIGIN     |
   |       |
   |  <====|====== dirt road
   |       |
   |       |
   |       |  <=== paved road
   |       |
   |       |
   |       |
   |       |
   |       |
   |       |
   |       |
   |       |
   |       |
   |       |
   |       |
   |     TARGET

Dijkstra's yielded path will follow the paved road. (takes a long time to compute)
A*'s yielded path will follow the dirt road. (takes a fraction of the time to compute)


I think we agree, though... Pointing
Pages: [1] 2 3 ... 279
 

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

The first screenshot will be displayed as a thumbnail.

radar3301 (12 views)
2014-09-21 23:33:17

BurntPizza (29 views)
2014-09-21 02:42:18

BurntPizza (19 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (27 views)
2014-09-20 20:14:06

BurntPizza (31 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (102 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!