Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (697)
Games in Android Showcase (202)
games submitted by our members
Games in WIP (767)
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 ... 12
1  Discussions / Miscellaneous Topics / Re: Dynamically produce a shatter pattern on: 2016-10-25 17:46:28
I like the only answer on this forum post. It brings up BSP trees and links to a discussion from the developer of Smash Hit. You can start playing around with things in 2D as far as choosing arbitrary planes near an impact point.

A seemingly nice tutorial on BSP trees for Java; page 1, 2, & 3 (with 2D BSP Java source).

So from the point of impact you can choose some semi-random planes and continue subdividing and creating polygons and perhaps continue to draw outward and perhaps apply some unique shader effects to the edges.. I'm sure a bit of experimentation would be necessary. Then from there it's kind of going the route of the Smash Hit info above for 3D.

Not a glass shatter video, but something someone made with Java2D.
2  Discussions / Business and Project Management Discussions / Re: Mentor Needed! on: 2016-10-24 23:11:43
Well, good on you for getting things regularly updated on Github. Consider adding a graphic image / snapshot to the README and a clear link to the executable JAR file. As mentioned consider opening a WIP post as that is the best place to provide ongoing advice / critique.

I'm certainly not against Java2D as likely what is actually required for a passing grade by this effort (smaller tech demo) can be fulfilled with it. It'll be easy when keeping things orthographic and more involved to go isometric, but still possible. Libgdx and going the GL route you'll likely have up to a 3 month learning curve though using libgdx takes a lot of the rough edges off over a bespoke GL effort shortening the switch considerably.

It seems like you are hand rolling maps currently? Switching to Tiled / TMX is a next step and don't overlook libtiled-java for loading TMX files and some other basic structure. After that figuring out how to store collision data as a meta layer in Tiled is pertinent. An article about the approach while Cocos2D oriented for code snippets explains the gist of how to approach things with Tiled.

There are various optimizations and other useful comments on the code you have currently posted, but make a WIP thread.

Regarding OO design I'm sure there is a bit to pick up there. Traps galore so to speak, but it's worth fighting through or learning how things get difficult. This applies to any OO entity hierarchy and quest or inventory system; re: for now Entity and EntityPlayer is simple. A fun video that describes the situation you will encounter is this one; the code solution is for Javascript, but the description of the problem is good. Just remember the scenario described and keep that in mind as you go down the traditional OO route.
3  Discussions / Business and Project Management Discussions / Re: Mentor Needed! on: 2016-10-20 19:59:24
Failure is not acceptable to pass but the fact that it can be worked with afterwads, or worked on, its due date can be replaced to august.

I highly suggest you set a firm cut off date to stop going down "the wrong" path. If you can't make suitable progress by the end of the year with Java2D seriously switch to libgdx ASAP in January. A mentor should direct you to the right tools and path, but you got to listen and take heed as well.

I already have the TileMap loading working,

Then start posting code in your Github account.

now it's a matter of getting some small things done.
Such as graphics, but my friend is helping me with sprites etc.

Nothing is trivial or small per se especially at your assumed experience level. Once again as a mentor in absentia I highly suggest that you purchase assets. With a non-exhaustive search
here are likely free assets, but check the licenses. I found 2 $40 sets here:

What is really nice about the latter tower defense assets is that there are 27 characters that already have Spine animations in all iso directions; for $40!

Tools are important and you shouldn't eschew using them. If you are going to be doing any animations I highly recommend Spine. Just like there is an API and support for loading tile maps in libgdx there also is a library addition that handles runtime concerns of using Spine animated models for libgdx. For $40 you can get all those assets and the animation support which can more or less be dropped into libgdx. Spine would be a worthy purchase as well for continuing to tweak or create anything animated.

Don't waste time waiting for custom assets.

For the game itself I'll try using libgdx, but only if I can't progress anymore and if it's really nescessairy.

Consider that libgdx also has controller support. It has everything you need and you can look at the source code to learn how things work under the hood.

The full game is just a working tile map loader a movable sprite, external controls and interactions.
That's really the full scope and that's what I'm doing right now.

Sounds more like a tech demo than a "game"; depending on how much you can fudge things in respect to the definition of "game" you might be able to get away with Java2D.

What do you mean by interactions? Collision detection, animation, sound / music, story / plot? There is also UI, loading / saving, and a bunch more things to consider in an actual game. Let alone the issues you are going to run into with Tiled / tile maps and rendering order and sprite occlusion.

For the mentor part, I'll think I'll try to go with your plan, of asking help for each problem. But it's not really help I need, since most problems
are solved with some research. It's progress evaluation and "re-track" me if I wander off too far.

Once you have the basis of the game / timemap loading and rendering consider opening a "work in progress" thread.

You are already wandering off to start. If I had to describe my understanding of how things are presently it would be: "you don't know what you don't know". Which is fine, but that is why it is crucial to set right now a firm stopping date on your current path, the sooner the better, so that you do have enough time to correct it. I worked in depth professionally with Java2D for 6 years in the aughts before Android dropped, so I do know what is possible there; getting on the OpenGL path via libgdx is pertinent.
4  Discussions / Business and Project Management Discussions / Re: Mentor Needed! on: 2016-10-18 18:07:59
As your mentor in absentia....

Re: >I was just progressing with Java 2D and don't mind spending too much time and do it less efficiënt... It is also a personal achievement doing this mainly with the standard Java libs.

Is failure an acceptable outcome for this project for a passing mark / grade?

To meet "The full goal" as outlined in your first post you need to choose the right tools. You'll be using the standard Java library along with an additional graphics library; whether that is JavaFX (not recommended!) or libgdx or ... The Java 2D API is not well suited to this task at all. Ignore Slick2D as it is outdated.

Consider that you'll need a vector math library regardless of what you are going to do and that is an additional library over the standard libs. This comes as part of libgdx.

You'll either need to drastically reduce the scope of "the full goal" or use additional libraries suited for the task at hand.

Creating just a Tiled / TMX map loader from scratch that ham-fists everything together with Java2D and a vector math library just to load and sort of display a level will take you to June if you're lucky.

Or you could use an outside library if you want to stick to standard libs: libtiled-java.

If the requirement remains to actually produce anything close to a working game you need to use the right tools. Even with using libgdx and the tile map support it provides you are going to have a hell of a time to create something that resembles an actual game by June and this is if you are working full time on it all which I assume is not the case.

Re: >But I'll keep trying to find a mentor since it's kind of 'necessairy'.

I also wanted a mentor at your age, but one never materialized, so be prepared to keep your head down, buck up, and get coding. You'll find that folks will help you with concrete / individual problems on various forums, but a dedicated mentor worth their salt is hard to come by even if you could offer compensation for time involved. Regardless if the mentor requirement is partially attached to your school / class at hand it's going to be dodgy at best to find anyone who will sign on for that role. Also be prepared for dead ends / failure if you find the wrong one.

5  Discussions / Business and Project Management Discussions / Re: Mentor Needed! on: 2016-10-17 21:35:42
Super 1337 info

 Roll Eyes

You'll need to buck up and drop the Java 2D API and get your hands dirty with libgdx.

The "super 1337 info" above will provide plenty of links then check out Tiled.

Get coding / then perhaps ask specific questions you may have on the libgdx forums or here on JGO.
6  Discussions / Miscellaneous Topics / Re: Video Editing and Java on Android on: 2016-10-05 08:15:04
If only I could get access to the pixels in a video in a uniform manor. Have not learned yet, but not prepared to.

Why not learn? There are not too many examples out there per se, but the bigflake collection provides plenty of initial hints; there's a bunch more including multithreaded GL optimizations to really get there. You can directly covert to an OpenGL texture a camera frame or decoding an existing file and when rendering a GL frame / flip buffers you can have that encoded. So you'll be using GL 2+ shaders for real time or offline manipulation.

A great way to learn would be to create your brightness / white balance video conversion app and you could get pretty far modifying certain bigflake examples.
7  Discussions / Miscellaneous Topics / Re: Video Editing and Java on Android on: 2016-09-27 22:22:38
A lot of my bullet points are about the GUI. Although, the real meat lays in editing using effects. I'd be happy with any app that allows for editing brightness of pixels from x to y.
If you got that down, then that would be amazing to release to the community.

Once I finish up all the backend goodness prepping for a larger launch I'll likely consider putting out a free utility app that does basic effects like this to up sell / promote the full deal.
8  Discussions / Miscellaneous Topics / Re: Video Editing and Java on Android on: 2016-09-10 20:26:37
This hasn't gone unnoticed per se. I jumped on creating custom video engines and an effects pipeline that allows up to 8 of 200 different effects to be freely combined for effects composition and custom creation of presets. I started in '13 w/ the Galaxy Nexus, but Nexus 5 was the first device to have a solid GPU that blew the lid off FBO performance. Tried to do a Kickstarter to cover final launch aspects; no one cared. Had to go back doing some contract work, but over the last year I spent time beefing up my server / back-end skills to support a full roll out of the video tech along with a solid server infrastructure for sharing / selling presets and other useful things that are worth a yearly subscription like being able to transport ones work between devices.

So yeah... Again no one really cares (investors) about creative video or creative anything for that matter that isn't selling out your user base and that is if you already have millions of users, so bootstrapping takes time.
9  Java Game APIs & Engines / Engines, Libraries and Tools / Re: JGLOOm - Loading Every File Format for Every OpenGL Lib* on: 2016-08-21 18:32:07
That's awesome! I never considered event busses, I've always used proprietary listeners... I'll see if I can implement guava into the library.

Definitely consider not using traditional / old school listeners if sanity is to be maintained. Wink

**Opinionated** Absolutely avoid Guava at all costs and dubiously view and double check anything that has touched Google engineering hands. Despite reputation laziness abounds within Google engineering. JGloom is already going to be bloated beyond belief as far as API surface is concerned let alone internal implementation going down the traditional OO route. If you add external libraries as dependencies pick the smallest most efficient and purpose built ones for the task. I guess that is another thing that should be in mind now and not later and that is creating the smallest API surface and modularization of JGloom.

JDeferred and Green Robot eventbus seem like reasonable candidates from a cursory search. I haven't used either of these libraries, so evaluate them!.
10  Discussions / Miscellaneous Topics / Re: There is no hope on: 2016-08-21 10:52:21
It's too bad you can't single out individual jerks and sell their "private" data (re: contact address book) to ad networks. Google needs to add cheapskate ratings to users, so devs with any scruples don't punish everyone.. ;P Or you can just sell out all your users; most don't realize the permission overreach and what is happening anyway; bah, this is nothing new sadly.
11  Java Game APIs & Engines / Engines, Libraries and Tools / Re: JGLOOm - Loading Every File Format for Every OpenGL Lib* on: 2016-08-21 07:30:49
Interesting, I should go about implementing an asynchronous architecture... I'm not very good at designing async machines, using an object before it *exists* doesn't excite me.
If anyone has some good reads on async, please PM me. I'm pretty dumbfounded when it comes to anything other than basic OO.

Java definitely has been late to the game for a good promise based solution. Java 8 introduces CompletableFuture. The only problem is that it is just introduced in Android API level 24 which precludes it really being usable per se. JDeferred seems like the best available external option presently. A promise is an object.

There are several OO event bus implementations around. GWT has one, Guava, there are many others. The last one might be a good candidate for an existing solution. Events are fully formed objects... Err of course I think all of them are flawed in respect to a component architecture.

When I mention component architecture essentially I mean a generic application of what has received attention in the Java sphere of things as an "Entity System"; Artemis, Ashley, etc. etc. (all flawed per se). At the heart of it the important design concern is implicit composition. The TyphonRT event bus implementation uses extensible enums as event categories. The all caps "event IDs" that I mention in the previous post like LOAD_GLTF, or CREATE_MODEL are extensible enums. With TyphonRT an event is still an object, but a component manager. You can attach any type of data to it dynamically and other systems register with the event bus under the extensible enum categories or catch alls. In this respect there are no specific event types like the traditional OO approach. An event is defined by the category / extensible enums it's posted under and there is just one type of event which has data implicitly attached.

You can still get away with traditional OO, but there will be a proliferation of concrete event types. If you get the design right up front it all can still work. Consider new extensions to glTF then you have to mutate the events passed through the system or introduce new ones.

I'm playing fast and loose in the conversation in general.
12  Java Game APIs & Engines / Engines, Libraries and Tools / Re: JGLOOm - Loading Every File Format for Every OpenGL Lib* on: 2016-08-20 23:57:37
The direction I recommend is a purely event driven path for model loading and rendering. There are no direct connections between subsystems. Just events that each subsystem responds to and posts further output events handled by the next system in the chain.

So to continue the strawman architecture and why you must consider an asynchronous architecture (event driven / event bus) let's consider the full glTF spec. In my previous outline of what event control flow could look like I took liberties that the glTF file being parsed indeed contained all of the assets; data URIs as per the spec. Most model formats contain all of the assets to load. glTF is different though as any asset in the glTF file may just be an external URI reference relative to the glTF file being loaded that needs to be downloaded separately from the glTF file itself. This presents a direct example why an asynchronous architecture is needed.

Previously in my last reply I mentioned:
Let's assume "load" might introspect the type of file or data being loaded. A modelID is assigned, promise created and returned after posting two events on the internal JGloom event bus. The first, CREATE_MODEL, forwards on the model ID and promise which is received by a management system. The second, LOAD_GLTF, with the raw file data after introspection and associated model ID.

The glTF parser receives the LOAD_GLTF message and then starts unpacking and finds out there are 5 things to load. First it fires an event on the event bus PARSING_GLTF with the model ID and how many assets are being loaded which is received by a collector system which creates the complete model instance / component manager (hopefully). The parser then fires off 5 events (let's say there is 1 texture, 2 shaders, 2 binary blobs), so the following is punted to the event bus with model ID and raw data from the glTF file: LOAD_GLTF_TEXTURE (x1), LOAD_GLTF_SHADER (x2), LOAD_GLTF_BINARY (x2).

Well shoot let's say the glTF file is loaded from a remote URI and the file now includes external URI entries for one or more of the assets to load. The call to JGLoom might now look like:
Promise modelID = jgloom.load('')

This means `jgloom.load` detects the URI and determines it's some remote file to load. Let's say the JGloom load API has an internal implementation that takes the actual loaded file. Like before from the public API a modelID is assigned, promise created and returned. Then LOAD_EXTERNAL_URI is posted on the internal JGloom event bus, with the URI of the file to load the associated model ID to load and a separate promise which accepts the loaded file and invokes the internal load implementation that takes the actual file. The system that receives LOAD_EXTERNAL_URI makes the HTTP request and upon receipt of the file fulfills the loader promise. Now we are more or less back to the control flow initially described. The internal load implementation determines it's a glTF file and fires two events: CREATE_MODEL, LOAD_GLTF. As an aside what if the URI is a local "file://" URI. No problems as the external URI loader system accesses the file system and proceeds just like it would if it were a remote request.

The glTF parser receives the LOAD_GLTF message and then starts unpacking and finds out there are 5 things to load. First it fires an event on the event bus PARSING_GLTF with the model ID and how many assets are being loaded which is received by a collector system which creates the complete model instance / component manager (hopefully). However now all the assets are external URIs not locally available. Now the parser will create 5 promises which receive the file of the asset and like before subsequently punts individually to the event bus with model ID and raw data from the external file: LOAD_GLTF_TEXTURE (x1), LOAD_GLTF_SHADER (x2), LOAD_GLTF_BINARY (x2) So the parser then fires off 5 LOAD_EXTERNAL_URI events to the JGloom internal event bus. The system handling LOAD_EXTERNAL_URI resolves these promises and the control flow resumes as originally described collecting and completing the model loading process.

The event driven / event bus architecture perfectly handles these cases.

What if there is an error though. Let's say an external resource 404s. The system handling external requests resolves the file request promise with an error and message. The error handler of the request promise now posts an event to the internal event bus LOAD_MODEL_ERROR with the model ID and a descriptive message. The collector system receives this message and cleans up resources and removes tracking for the given model ID. The management system receives the message and resolves the modelID promise passed back to the user with an error and removes tracking for that modelID.

Consider up front the benefit of an asynchronous architecture. A traditional OO architecture especially with discrete listeners will fold and be hard to maintain / debug.

I looked around for Java promise libraries that work on Android and it seems like JDeferred might be a good choice.
13  Java Game APIs & Engines / Engines, Libraries and Tools / Re: JGLOOm - Loading Every File Format for Every OpenGL Lib* on: 2016-08-18 21:47:38
That's the part that scared me, but SHC showed you can still use binary formats in GWT!

Yep ArrayBuffer / and whatever view matches for the copy.

Typhon looks very interesting, I knew you had your Java app but you seem to exploded in crazy works. Nice job!

TyphonRT has 13 years of crazy works behind it though just not open source for all to see; so as far as crazy works what's visible is the tip of the iceberg.. Wink I just want to get to something commercially launched that justifies any ROI before open sourcing TyphonRT. TyphonJS I'm open sourcing and that has been refreshing to get things out for folks to use, but haven't publicized anything yet about it. TyphonJS is also a test on building the infrastructure for the many-repo approach. Even a year ago that approach only is possible on Github financially speaking for open source repos (free). I believe ~6 months ago Github finally changed the pricing structure for unlimited private repos per org / user for a flat fee per user. Even then that doesn't fit the model I'm developing as I treat Github organizations as a "component category" hence if I want private repos across ~30 organizations for one user that is ~$210 a month; better than it used to be though. There is Gitlab (free private repos), but I'm going to evaluate that later. TyphonJS is spread over ~25 organizations currently each with repos specific to the category that the organization represents. Some tooling is available (how the listing on is created), but I've got a few unpublished tools that given a regex and Github token for instance all repos of TyphonJS across all organizations can be cloned in bulk and WebStorm projects automatically created and npm / jspm install run in one batch (no need to manually install everything which would be crazy).. Eventually a GUI configuration tool for apps will allow appropriate selections for an end project to be created with referenced NPM / JSPM modules that create the appropriate project with all resources, etc... Lot's more, but I'll stop here though as this is a JGloom thread.. ;P

Thanks for the tips on importing glTF, hopefully that'll be the first format we support.

Also keep in mind the glTF binary extension

So the canary in the coal mine in all the discussion thus far is that what you are trying to pull off is complex. If you go down the traditional OO route you're going to be screwed if not more so than a generic OO entity system. Especially screwed if you ever want to support Vulkan efficiently.

The direction I recommend is a purely event driven path for model loading and rendering. There are no direct connections between subsystems. Just events that each subsystem responds to and posts further output events handled by the next system in the chain. This works for loading and rendering or whatever else JGloom does. Unfortunately there is no publicly available efficient / component oriented event bus for Java out there (yep, TyphonRT is based on this).

Let's assume a JGloom instance manages all models / scenes loaded. JGloom has an event bus internally used.

Promise modelID = jgloom.load(*a loaded gltf file*);

Let's assume "load" might introspect the type of file or data being loaded. A modelID is assigned, promise created and returned after posting two events on the internal JGloom event bus. The first, CREATE_MODEL, forwards on the model ID and promise which is received by a management system. The second, LOAD_GLTF, with the raw file data after introspection and associated model ID.

The GLTF parser receives the LOAD_GLTF message and then starts unpacking and finds out there are 5 things to load. First it fires an event on the event bus PARSING_GLTF with the model ID and how many assets are being loaded which is received by a collector system which creates the complete model instance / component manager (hopefully). The parser then fires off 5 events (let's say there is 1 texture, 2 shaders, 2 binary blobs), so the following is punted to the event bus with model ID and raw data from the glTF file: LOAD_GLTF_TEXTURE (x1), LOAD_GLTF_SHADER (x2), LOAD_GLTF_BINARY (x2). One or more separate loading systems receive these events and then create the proper resources for the GL or Vulkan or whatever environment being used. IE when you create a JGloom runtime for GWT you load GWT loader / renderer systems which for instance store binary data in ArrayBuffers or JOGL, LWJGL with NIO buffers, etc. Each of those loader systems create the proper assets / format and post with the model ID: LOADED_GLTF_TEXTURE (x1), LOADED_GLTF_SHADER (x2), LOADED_GLTF_BINARY (x2). The previously mentioned collector system receives these events and adds the loaded data to the model and once all assets are received given the asset count emits a LOADED_MODEL event with the model ID and model which is picked up by the management system tracking the initially returned promise replacing the promise placeholder with the actual managed model then completes / fulfills the promise.  I guess you could also get fancy and support reactive events (RxJava, etc.) or expose an external eventbus as well as promises.

The user can then retrieve the actual model from JGloom... Let's say jgloom.get(modelID).

Another great reason for this kind of architecture is that it's really easy to provide a JGloom implementation that entirely excludes any renderer and defers to the app to render or even a model creator system that loads assets into an existing engine structure if applicable such as JMonkeyEngine, etc. The latter of course if the engine defines a fine grain API to import assets / scenegraph nodes, etc.

This is still all a strawman architecture idea, but perhaps gives a different perspective. The renderer would a bit more complex... Considering batching, animation, culling, etc. etc. At a certain point the user needs to be in control of these aspects. The nice thing though is that a fully decoupled system could load a user provided system without the complexity of a complicated OO dependency hierarchy.

While not super deep on details check out Dan Baker's / Oxide Games talk on Vulkan and Ashes of Singularity engine.  Take note when he mentions that the renderer can be swapped out and the rest of the engine / architecture doesn't care.
14  Java Game APIs & Engines / Engines, Libraries and Tools / Re: JGLOOm - Loading Every File Format for Every OpenGL Lib* on: 2016-08-17 16:31:55
convert it to pure java (no NIO)
Shocked Huh

It's just JSON, it's very easy to serialize to java objects.

JSON description -> binary blobs + assets -> NIO -> profit...
                        +-> shaders -> profit...
                        + scenegraph -> pure java / component architecture preferably -> profit...                      
Yo, you can talk the talk... But can you walk the walk?

Hey man, I can guide the path, but shine you must..  Tongue  

Currently walking the walk plenty busy creating fundamental tools; that one should be over 3k daily downloads by end of Sept.. rounding out the arsenal so to speak... more to come...  
15  Java Game APIs & Engines / Engines, Libraries and Tools / Re: JGLOOm - Loading Every File Format for Every OpenGL Lib* on: 2016-08-17 02:35:46
Actually, you'll need at least a math library and you'll need to provide something to manage the hierarchies, this is already implemented in numerous typical scenegraph APIs

Cough take a good look at assimp; oops already mentioned this..  Roll Eyes

because it's better to support fewer formats very well than lots of format badly and there are numerous tools to convert 3D models.
Finally, I advise you to take some time to wisely choose a solution to support WebGL.

Khronos Showcases Significant glTF Momentum for Efficient Transmission of 3D Scenes and Models

Oops. Already mentioned that too..   persecutioncomplex  glTF is built for WebGL in mind and then some!

On glTF (don't just take my word):
“The world has long needed an efficient, usable standard for 3D scenes that sits at the level of common image, audio, video, and text formats. Not an authoring format, or necessarily a format you would use for a hyper optimized platform specific application, but something at home on the internet, capable of being directly created and consumed by many different applications,” said John Carmack, CTO of Oculus.

My take is first and foremost provide a knock out glTF implementation 100% and adopt / support any translation efforts (FBX-glTF / FBX2glTF whitepaper / Collada2glTF) that are available. Don't try to solve the all formats issue from scratch. If that really is an itch fully support assimp as a side show, but otherwise create the best glTF importer you can and you'll be ahead of the game. Take cues from the partial assimp glTF import / exporter and examine the major javascript 3D frameworks that have adopted the format (three.js / babylon.js) and consider carefully a Java based format / essential rendering routines if not assimp derived.

Heck I'm tempted to take off a week from what I'm working on now and knock out a solid solution (err, of course based on TyphonRT.. ;P... sigh... open sourcing plenty of things but not this:()..
16  Java Game APIs & Engines / Engines, Libraries and Tools / Re: JGLOOm - Loading Every File Format for Every OpenGL Lib* on: 2016-08-15 03:52:51
Perhaps take a look at assimp / jassimp or consider incorporating it:

Crazy! 40 formats supported, but no XM!

Edit: Oh yeah... Check out glTF as a prime format to support!
17  Game Development / Newbie & Debugging Questions / Re: How Do I time events? on: 2016-08-14 12:39:13
`search` is your friend...
18  Game Development / Newbie & Debugging Questions / Re: Implementing Extensions on: 2016-07-02 04:20:32
For something that runs everywhere...


Wikipedia OSGi

Apache Felix

Eclispse is based on OSGi

A tutorial about OSGi in respect to Eclipse
19  Discussions / General Discussions / Re: Open-source RTS game on: 2016-06-30 11:45:58
This should fit the bill.. Uses libgdx.

Pax Britannica
20  Discussions / Java Gaming Wiki / Re: Java Data structures on: 2016-06-21 23:00:49
Ah, very possibly. But it is not on Android - well, my optimisation of games on Android indicate that these loops still churn out objects.

Indeed though I've done no testing on Android N yet or anything with Jack. A tremendous amount of inefficiency and bugs in the Android Java implementation is due to the adoption of Apache Harmony which was quite weak in many areas. Sadly Google just poked and pecked at things very slowly after much developer outcry spread across many OS releases. There may be some hope with Android N with a switch to OpenJDK / Jack, etc. etc. for better out of the box performance, but if you need to support a wide range of OS versions performance is in your hands. Since day 1 with Android I've been using my own collections API which recycles iterators automatically. Another super weak spot which I'm sure still hasn't been fully addressed is runtime annotation processing. You need to come up with your own caching mechanism otherwise face a ton of generated garbage.
21  Discussions / General Discussions / Re: RSS feeds for JGO still broken since October 2015 on: 2016-05-25 11:21:37
RSS great!!!! ;P I use it quite a bit and.... Um... I follow JGO by RSS and it seems to be working. It looks like I might be one of the only ones doing this.

I use Inoreader and pointing it to "" finds a working RSS feed.


Now the XML address above doesn't resolve, but whatever Inoreader is picking up there indeed is a working RSS feed.  I'd never check JGO without it!
22  Java Game APIs & Engines / Android / Re: Google releases vulkan samples on: 2016-04-13 20:34:13
and don't forget to cast your vote for an official Java / SDK Vulkan binding:

Up to 7 votes now... Though looking forward to LWJGL on Android as well!  Grin

LunarG samples just got posted as well:
23  Games Center / WIP games, tools & toy projects / Re: 3D audio test using JavaFX and procedural java sound on: 2016-04-12 18:10:37

In this case for a spherical wavefronts physics matches perception. IE a sound source with no walls / reflections adding to the direct sound. You may potentially futz with the coefficients to change things somewhat, but still follow an inverse square relationship.

I started experimenting with this. My initial (current jar) algo was to define a max audio distance and get the % of this (expressed as a normal N), and apply it to a N^6 mapping (via LUT). This seemed to create an acceptable drop-off.

I tried a couple more things last night: scaling the distance into "attenuation units" and then deriving the volume factor by putting this value in the inverse form: 1/N. Also tried 1/(N*N). I can't say that it is all that clear to me, from a listener's perspective that one is superior to the other, yet.

More futzing and tweaking required. Come to think of it, I may have forgotten to compensate for the N^6 mapping done at the final stage. Hmmm. Have to work today--won't get a chance to think more on this for a while, except in the cracks/breaks.

I kind of meant to continue the discussion before regarding I suppose a final fun detail to try when dealing with proper scaling / attenuation.  It'd be interesting to see a plot of inverse square versus your other efforts. It could be similar. As you know in games often it's a game of approximation for audio or graphics effects being presented.

One kind of fun thing to do is apply a bias parameter to whatever formula one uses for attenuation. This is more or less the story of the motorcycle and the fly. For ease and clarity of sound generation your samples or procedural audio should be loud with perhaps a few dB below max for each source. The way you handle loud sounds like a motorcycle is have a wide bias that extends the center of the attenuation curve. So your distance (attenuation units / whatever) is much wider for the center of the motorcycle say 30' / AU before the attenuation curve starts to kick in and extends much further from the source. For a buzzing fly though one sets a really small bias of perhaps 2" center or whatever "AU" that is and by 2' away the sound drops off entirely.

I'd have to go search around to find the inverse square attenuation + bias formula I use in my efforts, but that is how you handle really loud objects and really soft ones with a natural attenuation curve if one uses the inverse square law.

This biased attenuation curve also is a good first pass for culling sound sources from the larger scene dynamically.  If you can't hear it don't render it!
24  Game Development / Networking & Multiplayer / Re: Kryonet hosting? Where and how? on: 2016-04-11 22:01:17
>Got it working on digitalocean

Excellent... If / when you move toward production you might want to consider the container direction. Docker being the current solution folks are talking a lot about.

I'm looking at putting together a combination of Rkt (, Kubernetes (, and Rancher ( for server deployment for web and mobile apps primarily, but of course it'd be fine for desktop apps too. I'll definitely make a post on JGO if I get all the tooling working well.
25  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-19 11:12:29
While this thread is mostly LWJGL / Vulkan progress related I just want to post the issue filed in the Android issues tracker for an official SDK binding for Vulkan. And I didn't even file it (stoked that someone else did!):

Please star this issue if you are an Android dev. Of course LWJGL on Android will be great, but for stuff like my video engine updates for Vulkan / MediaCodec API will also need to be completed and an official SDK binding is the first step toward that support.
26  Games Center / WIP games, tools & toy projects / Re: 3D audio test using JavaFX and procedural java sound on: 2016-03-18 01:15:54
OSC is something I plan to look into in more depth. It ranks high on the to-study queue. All I know about it is that as a spec

Indeed a transport independent messaging protocol. Keep in mind that SuperCollider doesn't exactly follow the OSC spec exactly, but is essentially similar. You could send MIDI over OSC for instance.

One consideration: making synths that implement OSC or MIDI with any pretense to completeness is out of scope.

Essentially you'd want your synth to know nothing about OSC or MIDI. You'd marshal data from OSC or MIDI data to whatever internal representation is understood by the synth. Ideally this internal implementation is event driven.

Theoretically, inverse square makes more sense. Ears and art don't always agree with physics, so I like to verify this sort of thing. (Who should I believe, experienced audio engineers or my own lying ears?)

In this case for a spherical wavefronts physics matches perception. IE a sound source with no walls / reflections adding to the direct sound. You may potentially futz with the coefficients to change things somewhat, but still follow an inverse square relationship.

No matrices involved, beyond what JavaFX manages behind the scenes via the PerspectiveCamera.

Matrices are involved under everything in JavaFX. Each Node of which PerspectiveCamera is inherited from has a transform. The rotation of the PerspectiveCamera is all you need for ambisonics.

Having not used JavaFX you'd likely call:


And that is what you'd send to SuperCollider or what have you to manipulate ambisonic rotation.

Maybe in a few days I'll get to the PD, SuperCollider or OSC research. But it seems like a good thing to build stuff and learn from the experience. No strategy is always right.

Like anything it may take some time to explore. It definitely doesn't hurt to know what has come before and depending on goals one might find that the existing solution is solid enough. The task then becomes filling in the gaps. Way back when I thought I'd have to spend a bunch of time creating a DSP engine then SC3 dropped and the split audio DSP server architecture fit my needs.

I fully understand the thinking of independents that don't want to spend anything.

Developers are fickle even considerably more fickle than consumers in many respects. You'll find plenty of developers independent or otherwise that will not be willing to pay for X developer tool. Rather than single tools developers will pay for platforms / ecosystems. The trick then becomes providing more value than one captures for creating some symbiosis that brings in more developers while extracting enough funds, preferably in an ongoing basis (the capture angle), to make it all viable. And at that as mentioned a free platform with some services that can be kept behind a paywall fits that pattern. IE Lumberyard w/ integration with AWS and other for pay services is a big example; tools for free, but hey isn't it sure easy to integrate with our other for pay products. As things go an interactive audio engine for games is not an easy platform to deliver as a service.

Money, money, money. Whatever.

At the end of the day rent has to be paid, food needs to get on the table, and health of all involved needs to be maintained.

Otherwise, no charge. It is a crazy business model, perhaps, trying to maximize the chance of participating in a black swan rather than up front income.

IMHO that relies on expecting the other party is honest and will keep things on the up and up. Collecting anything even from a moderate success will rely on the ethics of the other party which is a risk. If it was a truly black swan event it'd be easy for the other party to simply not pay and make it a legal situation. Anything over values that could be collected in small claims court could get locked up in a costly legal battle.

I'm not saying don't take this approach just consider that other parties may not play by any agreed upon rules as sad as that may be.
27  Games Center / WIP games, tools & toy projects / Re: 3D audio test using JavaFX and procedural java sound on: 2016-03-17 18:55:46
Indeed as @nsigma mentions... I was going to bring up Pure Data / pd as an option. OSC is as fast as anything you can send over the wire. Even 13 years ago when I got things first working via NIO it was blazing fast. Simply create a UDP packet / OSC packet, index it, and hold on to it overwriting just the necessary data sections. In the case of a slider / single parameter that is just a single float then punt it off repeatedly and well, super fast.. I'll see if I can clean up that old code and release it along with an example of getting SC up and running.

As boxsmith mentions whether it's Max / pd / SC you effectively get a patch loaded in any of these environments and at that point in the case of your demo about all you have to do is let the audio engine know the volume coefficients (inverse square law basically) calculated from world coordinates as they change / user moves and a 2D / 3D transform matrix of orientation of the user / listener which in the case of ambisonics is simply multiplied against the encoded entire mixed scene of audio and auto-magically everything rotates perfectly.

In short the biggest concept that SuperCollider 3 introduced is that the audio / DSP engine is a standalone network based server. It only is programmed / configured by OSC. Any language can interface with it. You do have a concept of a patch called a "synthdef" in SuperCollider. It's like the audio equivalent of a SPIR-V encoded shader for Vulkan.

Looks like a nice video tutorial / #3 covers synthdefs:

Remember though in any tutorial they aren't necessarily going to point out that SC3 server can be used headless via any language and purely configured by OSC.

@philfrei Creating a procedural audio engine let alone really well working spatial library is very difficult. Not saying that you don't have the passion for it as from everything I've seen / read you do. If anything use pd / SuperCollider as a strong reference point especially since they are open source. Once the light bulb clicks on getting things to work from Java it will be quite something. If anything as a rapid prototype environment... then take what you can learn about audio DSP back and create your own library for a particular purpose, but a whole procedural engine would no matter what be quite the task..

It's kind of hilarious as if you look back to the first message posted on JGO all those years ago for me it was SC related.. ;P

As far as making money with an audio engine I'm afraid that gig has been up along for the most part any developers tools. That market finally crashed with Unreal / CryEngine / newcomer  Lumberyard (CryEngine reskinned). The trick at this point seems to be to put out enough open source to entice and hope that catches the zeitgeist of people potentially flooding in then create value with pay components or other associated cloud based services that can sit behind a pay wall... As you can see though that still relies of luck. It's no way to pay SF Bay Area rent I'm afraid or that's a nut I could never crack... So contracting in general remains the best way to continue working on the really cool stuff.
28  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-17 06:55:00

Let's just say I just got back from the event and a great event it was... Small plug I'm super stoked that Dan Baker's (1 of 5 Dan's in the day) / Oxide's talk on Vulkan and the slide describing engine architecture fits almost to a T how TyphonRT is structured... And I'm a little tipsy right now.. I lingered, almost uncomfortably for myself as an introvert, and a bit toward the seeming end I disappeared to show a demo of my video engine tech to the Kishonti folks who had a wall wart to power my dead phone though were interested in what it takes to make Android / mobile GPUs sweat (yep got that covered). I came back to the main reception room and was near the last one left and was invited to finish off the wine with a core Khronos member, so much to share and say... This was and may be my only contact with Khronos in 13 years of GL development and into the unknown future. Many things were discussed including the difficulties of establishing communication channels to independent voices that fight the good fight despite any direct connect; erm you know who you are in this thread...  Shocked

From the wine fueled discussion and other discussions I had with a core Nvidia driver developer multi-GPU support is primary goal #1 whether it is first exposed as an extension or Vulkan 1.1 ratified spec nonetheless is up for imminent availability.

While final glasses of wine were consumed I shared this thread and got him to bookmark it on phone with said core Khronos member and made it clear that LWJGL is the future of Vulkan for Java. I'll be so bold in stating that in the after hours of the event when beer started to be consumed and as as a fellow indie dev I imbibed, as well TANSTAFB, nonetheless I poked and prodded anyone from Google. From my understanding from opinions shared (thanks!) there will not be an official Java / SDK binding for Vulkan in Android N, so for LWJGL it's prime time to spring into support for Android as the defacto standard binding for cross-platform Vulkan support. I haven't had time to review the initial Android N pre-release to confirm if a full version of sun.misc.Unsafe is present, but that seemingly is the only barrier for LWJGL to run away with official and the only binding to support Android.

Yep... I wished I could offer more support immediately to LWJGL. I gained enough insight today to know that I have to release my video engine effort via GLES 3.1 and no longer wait for Vulkan support; the main crux being extensions for video encode via Vulkan that are not on the present horizon and could be 1-2 years out easily. For the rest of yah though I'd be super stoked to see LWJGL run away with solid cross-platform support.  Cool Pointing I'm just the latter emoji pointing to y'all...
29  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-16 22:04:43
I'm at the Khronos Vulkan sessions being streamed right now. By chance are there any concerns / questions to ask any of the bigwigs here pertaining to any present issues w/ current LWJGL support for Vulkan?
30  Games Center / WIP games, tools & toy projects / Re: 3D audio test using JavaFX and procedural java sound on: 2016-03-16 03:58:29
I checked things out.

Nice little test setup; you shouldn't need to do much more for a basic environment to navigate around for now.

I'd recommend to changing to voice samples as speech will provide considerably better testing when generators are close together.

>There is a bunch to do, in that first it has to work, then you improve performance and design. I seem to have to do things wrong a few ways before I can figure out a more reasonable way to do things.

I still recommend prototyping Ambisonics directly if you can get 4 or more speakers together and / or also decode to binaural for headphones with SuperCollider with the same JavaFX setup and work backwards instead. That will provide a "gold standard" of accuracy to compare any implementation you come up with separately. Of course there is also the much simpler steps of working backward with all the DSP code on hand.

If I had any free time currently I'd set this up for you, but alas can't help out currently. 

The time you'd spend to get SuperCollider up and running and working within your test framework so you can compare results against will pay off big time.
Pages: [1] 2 3 ... 12
theagentd (26 views)
2016-10-24 17:51:53

theagentd (25 views)
2016-10-24 17:50:08

theagentd (26 views)
2016-10-24 17:43:15

CommanderKeith (42 views)
2016-10-22 15:22:05

Roquen (47 views)
2016-10-22 01:57:43

Roquen (57 views)
2016-10-17 12:09:13

Roquen (57 views)
2016-10-17 12:07:20

Icecore (74 views)
2016-10-15 19:51:22

theagentd (338 views)
2016-10-04 17:29:37

theagentd (342 views)
2016-10-04 17:27:27
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 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!