Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (753)
Games in Android Showcase (228)
games submitted by our members
Games in WIP (842)
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
1  Game Development / Newbie & Debugging Questions / Re: JMonkeyEngine on: 2017-03-18 19:46:48
I hated Unity for years, especially when I wasnt skilled at it.
Lots of programmers get stubborn, especially when they are young and make their own engines. Not that there is no value to having made one yourself, for understanding sake.

Years ago i did go deep into jMonkeyEngine, with a bit different attitude than others. I took the sources and refactored it heavily, specifically for tasks that i needed, threw away stuff i didn't need and added stuff that was missing.

What i couldn't implement myself was shadow mapping. It was just too much effort to get it right. Then i thought about how i would spend all my time implementing new graphics algorithms to no end.

After some time i tried Unity. Its very frustrating to depend on the editor even for the smallest things. I know there has to be a way to do something, but in Unity its some checkbox hidden somewhere. Then if i want to change some default behaviors i have to completely re-implement stuff, or to add some very hacky solutions on top of the engine.

When i worked with jMonkey, i read solutions and whitepapers from the net, read the GPU gems and implemented my own shader stuff. Working with Unity devolves into reading and searching its forums. Then comes the frustration, when the best solution that you find is some hacked trash, that you know for certain will lead to bugs or slow game or glitches. Or you will have to manually tweak objects in the editor, otherwise it won't work the way you need it. But you can't really dismiss the engine, since either you write your own complete solution or you nerf your game and leave that problematic feature out.

Its completely possible to do the second, to adapt features until it becomes manageable. Good game designers do that. But i get very frustrated, since i know that it would be easy to add that feature given access to source code of the engine. But if i have access to the source code, then why would i use it as it is, or use the editor at all, when i can just refactor the source?

The paid solutions you can get for Unity is another story. There are some well-advertised networking servers for Unity. There is one in Java, fine. Well it works on top of I can (i already did) make my own networking server with They repackaged into a product, added various client libraries, advertising and support.

In the end i come back to Java and jMonkey and open source. jMonkey got lots of new features in meantime and Java itself got new features and new libraries. Github and the BSD licence is a wonderful thing.
2  Discussions / General Discussions / Re: Migration to more modern forum? on: 2013-06-03 11:10:31
I actually liked the older one more (which i can only vaguely remember now). Can we go back to that?
3  Game Development / Newbie & Debugging Questions / Re: C++ to Java and unsigned int64? on: 2013-03-13 18:30:48
This won't work in java as there is no unsigned 64 bit integer. Using a regular signed long would usually work fine but you are doing addition and using all 64 bits which includes the sign bit. You could use java BigInteger but it will be slow and I suspect this is purely a performance hack so I suggest you just replace it with whatever you are actually trying to do.

Java just wraps over int's and long's, so it is irrelevant. Bitwise it is irrelevant if its signed or unsigned, the addition works the same way (the CPU doesn't care if you consider a value as signed or unsigned). The only time when attention must be paid when porting code that deals with unsigned types is the right-shift operator ">>". If the original code works with unsigned types, then the unsigned-shift ">>>" must be used. The ">>" preserves the sign (the top bit), while the unsigned shift ">>>" shifts in a 0 to the topmost bit. But addition and subtraction works the same.
4  Game Development / Performance Tuning / Re: Java Brute Forcing Algorithm Optimization. on: 2013-03-07 21:44:24
I really don't understand what your goal is with this, but i have some tips. If you really mean the "Brute" in the "Brute force", then stop using the StringBuffer, and switch to raw byte[]-s instead. Also stop creating a "new" object in the middle of the loop. You could also unroll those loops to a single loop, and increase the indices in the byte[] yourself.

Ahh never mind, this makes no sense. You are probably just trying to make some benchmark that is heavy on loops and memory.
5  Game Development / Shared Code / Re: Java Continuations and GreenThreads on: 2013-03-01 17:18:47
while(true) {
   virtualProcessor.tick(); // instruct unit movement, wait for arrival

   gameLogic.tick(); // actually move the units around


Yeah that is indeed simpler, but the path generation tends to be quite expensive. So some kind of scheduler is needed to make sure, that it doesn't happen that in a single iteration a bunch of bots request a new path at the same time, because that would be noticeable. So path generation is a good candidate to move out to a second thread. If its on a separate thread, then that thread can generate paths non-stop. And since path generation is tied to what the bot would actually do, the whole scripting is simpler and no "path generation queue" is necessary, if all is done with green threads. The bots will wait for their path until their turn comes to get it generated. I'm assuming that all this is running on a multicore CPU. With a single core, all should run on a single thread, like you described.
6  Game Development / Shared Code / Re: Java Continuations and GreenThreads on: 2013-03-01 16:28:19
Ticked based approaches are the opposite of the what green threads are meant to provide.

Having two "services" for each entity is what i prefer. One "high level script" (or "behavior script") with continuations, that gives orders like this:


Then a second, tick based loop, which handles the per-frame updates to position, direction, path following etc. This second service can run in a separate native thread, as you are suggesting, without using green threads. Then the two threads exchange messages. The path generation can be done on the script thread because that thread is not time sensitive, and generating a path is a one-time big time expense, while path-following is not. If some script event is delayed, thats not a problem. The bot might just stand a couple of more milliseconds where its path ended before continuing with its next action, but that is not game-breaking. But statistically, bots will be always following a path, and will rarely require attention from the script thread. Attacking the player, however, must be done on the tick thread, because the bot must react to player right away. What the script thread can do, is to set the bots reaction to player. Something like: "attack on sight", "neutral", "friendly", "ignore", "stop the path if attacked" etc. Then the condition checking and actual attacking is done by the per-frame thread. If the script wants the attack to end, it has to change the reaction type.
7  Game Development / Newbie & Debugging Questions / Re: Terrain heightmap generation, can this method be easily replicated? on: 2013-02-21 16:14:57
There are lots of ways to combine the noise, even different types. The libraries i mentioned let you combine noise functions like a pipeline. But the basic way to produce a Perlin noise heightmap is to combine multiple octaves of it. The first octave determines the biggest terrain features, like hills. The 8'th (or so) octave has much higher frequency but lower amplitude, and determines much finer details. You use multiplication to get the octaves.

 noise(x,y)/2 : half the amplitude,
 noise(x*2, y*2) : double the frequency

Then you sum up the octaves. But the libraries i mentioned already generate you Perlin noise with multiple octaves, its a parameter they take. The noise is not repeating, you control where you sample the noise with the coordinates. If you specifically want repeating heightmaps (like seamless textures), then there are also techniques for that too. Again the libraries i mentioned contain examples how to do it.
8  Game Development / Newbie & Debugging Questions / Re: Terrain heightmap generation, can this method be easily replicated? on: 2013-02-21 15:48:53
Its not hard to adapt a noise library yourself. There are couple of ports/rewrites of it under different names: libnoise, noisepp, libnoiseforjava. I've taken these, and made my own small library for myself. Then i can generate terrains by combining Perlin noise functions. Then i do a bit of erosion simulation on top of that, and calculate the texturing based on height, slope and erosion amount.

tl;dr: Te key is: Perlin noise
9  Game Development / Shared Code / Re: Java Continuations and GreenThreads on: 2013-02-20 18:42:21
I really like this, and i intend to use it too. I remember some years ago i was working on AI bots, and i had to write my own scheduler for them. It would have been much better if i could write code which doesn't have to go trough the complete bot logic at each iteration.

What about using this for handling players too? Put a certain number of players onto a single native thread and make a VirtualThread for each of the players. I'm evaluating Netty.IO for networking right now, and seems to me that it handles incoming UDP differently than TCP. TCP connection can be delegated out to threads, so each native thread can handle certain number of connections. But UDP packets sent to a single listening port just get delivered to a single thread/channel/pipeline, no matter from where they came. So its the UDP handlers task to sort them out. What if players first got to connect to a specific UDP port, and after authentication they were redirected to resume their traffic with another port? So the server would listen on certain UDP ports, and the players would be distributed over those. At each UDP port there would be a native thread with a handler, and the packets would be delivered to VirtualThreads. I really want to avoid having a single thread for forwarding data to players, since that would mean that all the traffic would have to pass trough one specific queue. (I know this belongs to networking. I was just thinking about how this could be combined with that.)
10  Game Development / Networking & Multiplayer / Re: Netty vs. NIO2 vs ...? for mud on: 2013-02-20 16:15:38
There is support for AIO sockets in Netty 4.0.
11  Java Game APIs & Engines / OpenGL Development / Re: load cubemap with one bytebuffer on: 2012-12-16 20:59:48
Yes, after you map the buffer, you can hand it over to another thread to fill it. After filling it, hand it back to the first thread to unmap and glTeximage it. I suggest the following loop:

Step 1: unmap PBO and glTeximage loaded textures
Step 2: update the scene, collect the list of textures to be loaded
Step 3: map the PBO buffer(s), hand them to the second thread
Step 4: draw the scene
Step 5: repeat

This way the GPU will asynchronously upload textures while the program is doing CPU heavy work (updating the scene).
12  Java Game APIs & Engines / OpenGL Development / Re: load cubemap with one bytebuffer on: 2012-12-15 23:56:28
I'd suggest trying out PBOs. You can upload your data directly to the OpenGL driver in one go, after that you can define your textures from that buffer however you like. Its faster since you upload to OpenGL directly, you don't have to deal with the direct ByteBuffer becoming garbage at some point since the upload memory is provided by the OGL driver itself, you can upload all your data as one chunk and split it up later as you like. Its also available since OGL 1.5, so it should work even on older cards.
13  Discussions / General Discussions / Re: How Long Have You Been Coding? on: 2012-04-22 07:33:52
28 years
14  Discussions / General Discussions / Re: Does really game development on Java suck? Why are we still here? on: 2012-04-20 23:50:01
I really want to like D, it has some great ideas in it, but holy cow is the whole ecosystem around it a fantastic mess.  You've got the Tango/Phobos mess, and it's not so much just "choose one for your project" as "don't even dream of getting DSSS working with both".  And the windows toolchain is beyond horrific, using an obsolete object format that even Microsoft found to be too complex, baroque, and brittle. 

I think the Tango/Phobos exclusiveness was for D v1. Everyone is using D v2, which has Phobos as the system library and Tango is optional (built on top of Phobos), so you can use both at the same time. But i'm not planning on touching Tango, i would prefer a minimalist JDK-like library (for the sake of already knowing what is where), even if i have to write (collect) parts of it myself.

The Visual Studio plugin is quite nice. I had previously tried and dismissed D multiple times because of the lack of an IDE, but this one is working out for me so far.

The object symbol file is converted to MS format, so now integrated IDE debugging is working. This was another deal breaker previously.

I think a lot of people are waiting for D to be included into GCC core (which is in preparation, tho going slowly). When that happens, D will have all the benefit of GCC guaranteed, and the issue of developer tools will go away. The D plugin for Visual Studio has just started supporting the GCC D, and not everything is working. But there may be an LLVM D too. I don't see the multiple compilers issue as a mess. This language is constantly evolving, and there will be a time when D v2 stabilizes to one implementation. Just as more than a decade ago for Java there were a lot of JVM's, but we ended up today with practically one. As long as the SDL/OpenGL bindings are up to date, which seems to be, i don't care for the rest.
15  Discussions / General Discussions / Re: Does really game development on Java suck? Why are we still here? on: 2012-04-20 23:10:37
Having read trough this thread, it is a good description of state of Java gaming in 2012. Problems seem to be still the same as years before.

I started learning D. It has some less elegant naming conventions than Java, and has its own fetishes, but it has all the features i missed in Java so much. Reading trough the languages book and reading about a feature i remember how much i wanted to have that feature in Java. And when the author details why some feature was added, and that reason is exactly the reason i wanted that feature in Java too, well, those are the details that sell me the language. I see that there will be problems with D too, the user base is much less than for Java, and there is currently only one IDE that has the quality and features (D plugin for Visual Studio).

Some example features:
Static is per thread static, not for the whole application. No fiddling with ThreadLocal, no messing up data of other threads, and no per-object overheads as a last resort.
Bound checks can be disabled on a per-module basis.
GC for objects, but structs can be constructed on stack or wherever needed. Also true arrays of structs, thus optimizing for the CPU cache.
Initialization can be deferred to the constructor, or completely disabled, thus reducing object initialization overhead. There was (probably its like that even now) a situation in Java, where allocating and GC-ing an object was cheap, but the initialization was expensive. That has defeated much of the proposed patterns for having immutable objects, etc. D lets you control the object initialization.

The nice thing is that much of all safety guards of Java are available in D too, but you can manually disable it on specific places.

Then there are the features inherited from C++, of which you are not required to use the unsafe ones if you don't want them. Pointers are a marginal feature in D, you can use iterators and references instead.

16  Discussions / General Discussions / Re: Scala gods make me laugh. on: 2010-10-10 19:00:40
"academic "

Someone wrote (don't remember where), that Scala is a typical "academic" programming language. As far as that goes, it has already failed as a broadly accepted language. A programmer (his boss, his client) wants the problem solved, only an academic finds pleasure in using a  language so syntactically complex.
17  Discussions / General Discussions / Oracle not about to sue anybody over Javascript on: 2010-08-17 13:40:05
Split from thread 'Oracle sues Google over use of Java in Android'

JEE isn't going anywhere, let's not forget that Oracle has a lot of business there. And also let's not forget that this is about Android/Dalvik.
I'm concerned too, but I think a lot of people here are waaaay too panicy about the whole thing.

JEE could be much better, it is holding back invention. All those stacks of libraries around and on top of each other, its a mess. Restart ~ 2 minutes, patching ~ 1 hour... Its as messy as Windows apps were with OLE and ODBC.

And Oracle's own software isn't that pretty either.

Not a fan of it, but Node.js could go a long way.
18  Discussions / Miscellaneous Topics / Re: Lady Java! on: 2010-08-16 17:47:04
Actually, i think its pretty good. They don't have to create a "solid" "advertisement", its enough that Java has funny youtube videos and .NET does not (haha).
19  Discussions / General Discussions / Re: Oracle sues Google over use of Java in Android on: 2010-08-16 17:29:09
You might read up on Go too. From the YouTube videos on it it seems pretty thought through.

I'm following the happenings around Go, i do like some of its concepts, but don't like others, its a bit "dirty" language like C is, not as strict and clean like Java.  And i'm starting to dislike Scala more and more. Its not just a better Java, but a syntactically oversize Java. D is still the best Java/C++ mix, but a bit quiet lately.
20  Discussions / General Discussions / Re: Oracle sues Google over use of Java in Android on: 2010-08-13 20:45:56
Since when is the Dalvik VM based on the Harmony VM Huh It uses the class libraries of the Harmony project (or at least a subset of them) but the VM itself is different. It isn't even a Java VM, i.e. i doesn't execute Java byte code. It's register based, not stack based like the usual Java VM and it converts all java byte code into its own format.

I have read that they "based" it on Harmony VM. Just how much of it is changes i don't know. Yes it is not stack based, but nevertheless its a VM which executes programs written in Java (after compiling and translating the byte code).

Just because they are suing for patent violation does not mean they are simply trolling.  Google knew what was in the Java code base and Oracle, now the holders of those patents, are pressing Google for compensation.  It's not as if Google was blind to this, Sun just never pursued.

Note that I am not picking sides here as I have no corporate/personal stake in either side.

There is the list of allegedly violated patents. On first look, those are software patents, related to memory management, threading, permissions, used in the VM.

If someone would try to enforce a patent on me, because my code does: "determine code permissions by reading the stack trace", i would call it patent trolling.

I'm against software patents, and regarding this i'm against Oracle.
21  Discussions / General Discussions / Re: Oracle sues Google over use of Java in Android on: 2010-08-13 19:32:38
...  Google decided to use Sun's IP, modify and not provide any compensation to Sun.  Oracle has the means to

If someone creates a Java VM Oracle has no business in it. AFAIK Java is open technology. Google did not use any Oracle (Sun) software, they just tailored the open-source Harmony VM to their needs. How can Oracle ask for any compensation for a software they have nothing to do? This is patent trolling.
22  Discussions / General Discussions / Re: Oracle sues Google over use of Java in Android on: 2010-08-13 14:31:07
So does this mean that patent trolling has officially started? I mean, after Oracle bought Sun, and started shutting down stuff, all signs were pointing that they mean to use Sun IP for something like this.

This is a bad sign. Not for Google or Android, but for the Harmony VM. Since the Android Dalvik VM is based on the Harmony VM, this move means that Oracle is attacking an independent Java VM. Sure, the Sun JVM is still the best on desktop, but some serious competition doesn't hurt.
23  Java Game APIs & Engines / Android / Re: Can eglSwapBuffers be parallellized? on: 2010-06-28 06:31:12
I still don't follow :/ I can't see any need whatsoever for glFlush in a double-buffered display.... any command requiring that the buffers are flushed, flushes it. That includes swapBuffers of course, too... so I must be being dim. What am I missing?

Cas Smiley

SwapBuffers does no flush the command queue. I assume that no other commands are used which would flush it. That's why it is possible for display to lags behind in addition to double-buffering. When updating the screen in ad-hoc manner (not regularily), then it is unwanted that OGL buffers multiple frames, since we want the new display to be seen as soon as possible, since the screen update was probably initiated as a reaction to user input. In a normal render loop glFlush is bad, and causes lower frame-rate.

EDIT: Actually i'm somewhere mistaking in this, since swapbuffers does do the actual rendering, but my tests showed that glFlush did reduce framerate.
24  Java Game APIs & Engines / Android / Re: Can eglSwapBuffers be parallellized? on: 2010-06-27 11:09:17
That'd be valid in a single-buffered context but... nobody uses single buffering Smiley

Cas Smiley

Not so. It has nothing to do with double or single buffering. Its just that the display is not updated in the render loop at 30 or whatever frames per second, but only when something changes on the screen. glFlush works perfectly with double-buffered display.
25  Java Game APIs & Engines / Android / Re: Can eglSwapBuffers be parallellized? on: 2010-06-27 07:49:18
glFlush() has no place outside of an actual distributed client/server graphics system (eg. remote X). Its presence is really a bit of an anachronism - not even sure why it's in OpenGL-ES at all, as any gl* methods that actually require a flush (eg. picking, reads) perform an implicit flush anyway.

Cas Smiley

I think that glFlush is useful when you only want to update the screen in specific situations only, eg when the program keeps track of the changes to the scene, and only updates the display when necessary. I think that such a scenario is valid for Android, since the display complexity is probably simple, and updating the screen only when necessary would save processor and thus battery power. But i'm not into Android coding (yet), so i don't know how important that is.
26  Java Game APIs & Engines / Android / Re: Can eglSwapBuffers be parallellized? on: 2010-06-21 12:39:29
Don't know if the 'roid has it, but in normal OpenGL, there is glFlush, which forces a flush on the OGL pipeline. If it is not used, (on some cards) it is possible to be 2.5 frames in advance to what is seen on the screen. You could emulate the G1 behavior with adding glFlush after SwapBuffers.
27  Discussions / General Discussions / Re: After Java on: 2010-05-26 18:11:32
Actually, as Android is gaining momentum, it might help Java on PC too. And, imagine when Android hits the TV sets.
28  Discussions / General Discussions / Re: After Java on: 2010-05-11 13:58:18
I think you missed the bit where "youtube quality" won't cut it. Also you tube can encode outside real time. You can't do that with a interactive FPS game which means *much* higher bandwidth for a given quality. 

For mobile devices with small screens, youtube quality is enough. Yes it must be compressed in real-time as opposed of multiple-pass encoding possible when encoding it offline, but also, game display output is much more predictable than random videos up on youtube. The MPEG-4 standard even contains possibilities for encoding videos with well-known properties, such as frame movements, even 3D functionality. Don't know how much of that is contained in H.264 or Theora, but it should be eventually. And that may provide compression speed/quality well beyond what can be achieved with random videos.
29  Discussions / General Discussions / Re: After Java on: 2010-05-11 09:39:57
This. "The cloud" has degenerated into a marketing euphemism. If big corporations said "store your private data on our servers" people would run a mile. Call it "the cloud" and suddenly it's hip and trendy.

It was. But if you look around now, you will see a different picture. Companies are saving tons of cash by running their services on Google or Amazon cloud instead of their own data-centers. Its not "just hype", there is a huge amount of programming articles about writing apps to run on clouds, application frameworks getting cloud-compatible, discussions of users, both good and bad reports. It shows that cloud is not an empty phrase any more. It is different than the "Net computing" initiative was. "Net computing" focused on the client side, and there were neither client machines, nor services usable from the Web. It was a sales slogan, but now "The Cloud" is a working business of both Google and Amazon.
30  Discussions / General Discussions / Re: After Java on: 2010-05-11 08:54:16

Also the "the cloud" crap was called "net computing" about 10-15 years ago. We were all going to have dumb terminals within the decade. It didn't sell at all. 

Net speed is just one thing that got better, but the big difference is that we got a lot more and better mobile devices now. We already have the "dumb terminals", its called the Android, iPhone, iPad and the netbooks. Mobile net speed will get up to 50-100Mbps, and that will be more than enough to stream video. Also consider that mobile devices have smaller displays, so a small (rendering, streaming video) resolution is enough. In the time of "Net computing" there were no applications on the net, now we have Google, and other myriad of Web based applications. There are even programming IDE-s on Web now.

I'm not arguing that a desktop (or game console) game beats streaming video. Its just PC sales are declining, and mobile device sales are exploding. Mobile devices are too weak to run proper 3D games, but are (thanks to hardware acceleration) fast enough to show streaming video.

Pages: [1] 2 3
nelsongames (20 views)
2018-04-24 18:15:36

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

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

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

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

Solater (66 views)
2018-03-17 05:04:08

nelsongames (111 views)
2018-03-05 17:56:34

Gornova (177 views)
2018-03-02 22:15:33

buddyBro (747 views)
2018-02-28 16:59:18

buddyBro (94 views)
2018-02-28 16:45:17
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!