Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
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 ... 13
1  Discussions / General Discussions / Re: Gosh, it's quiet in here on: 2017-11-05 18:56:04
@SteveSmith I keep up to date on JGO via RSS; I don't think many others do. It actually is enabled:;type=rss2;limit=50

Makes it possible to see all new posts and follow responses to threads of interest.
2  Games Center / WIP games, tools & toy projects / Re: PFTheremin on: 2017-09-02 01:13:41
I don't remember this being here a couple years ago, last time I looked.

The nice thing is that the VST host handles all the MIDI / control data input and forwards it onto the plugin. As mentioned I can't recall which 3rd party Java integration tooling I used.. This also comes up Hah, being SourceForge that is about right circa aughts. It was pretty straightforward and performance was fine and this was a while ago.

It'd be great to see some of your efforts integrate w/ VST as that will provide a continuity w/ general music production environments that is better than standalone apps.
3  Games Center / WIP games, tools & toy projects / Re: PFTheremin on: 2017-09-02 00:59:38
I had closed my mind to making plugins for DAW's because there seems to be so little in terms of Java support for this. Most audio is written in C++ afaik. But maybe if one is including a JVM in the jar, there would be a way to use Java as a VST.

Do you know of resources to learn how to do this? Did you have another plan in mind besides VST?
more effects, as it is easy to add them in the mix on a DAW.

I can't exactly point you to any 3rd party resources I might have used in the distant past (circa '08 last time I recall), but it's possible to create VST plugins with Java w/ a GUI and all. Instead of audio processing I had several Java / VST plugins which didn't process audio at all, but took VST control data input w/ a Java2D GUI outputting OSC to SuperCollider allowing these plugins to be automated in any VST host; AudioMulch was the test bed back then.

Just search for "java VST" or "java VST tutorial". It's definitely possible and things worked fine and I suppose audio processing w/ Java would be as well though I was mainly focused on the GUI / control data to OSC aspect in my own efforts.
4  Discussions / General Discussions / Re: Hoping to make a return to JGO... on: 2017-07-25 05:54:59
I remember ye, glad to have you back... I too have gone to the dark side... JS over the last two years; hell hath frozen over after 20 years of Java dev. I'll soon be releasing a major documentation tool for ES6+ and Typescript (TJSDoc); hah, can't shake that dev tools bug. I'll be back with the one true language soon enough though..  Grin
5  Discussions / Miscellaneous Topics / Re: Passion Projects and Life: Spreading Yourself Too Thin? on: 2017-06-30 17:29:53
What does a medium pizza and a marginally successful Java game developer have in common?

Neither can feed a family of four!
6  Discussions / Business and Project Management Discussions / Re: Licensing overwhelm, asking for advice on: 2017-06-28 17:26:32
@philfrei it's hard to say how strong of a rein to keep on your work. Developer tooling in general is a lost market as there is next to nil chance to "break the market" at this point with a liberal license as the race to the bottom has already progressed thoroughly in this category IMHO. To my understanding if you license with a copy-left variant, but don't accept any outside contributions you are free to relicense as you chose fit without having to get a unanimous consensus from all contributors. I like MPLv2 as it's weak copy-left insofar as not imposing the same license requirement on derivative code that incorporates it separately, but keeping the upstream mechanism intact for any modifications to the target given source. For any work that is clear in purpose that does what it is supposed to do MPLv2 essentially fits like a glove. As far as generative audio is concerned there are options available out there already as you might recall my affinity towards SuperCollider and such even though it's GPL it can be integrated as a separate process / OSC  etc. without assuming any viral license exchange, so there are comprehensive free options. Interestingly enough SuperCollider 1&2 was commercial software w/ 3 going GPL, so perhaps an interesting history to examine in regard to audio software as James McCartney / author of SC made a go in the 90s / early aughts from a commercial angle ultimately settling on the commons / OSS; IMHO breaking the market so to speak for state of the art generative / audio engine software.

So far I've had two completely different experiences when it comes to hard forking others works. I mentioned ESDoc (MIT) previously and here is the thread which ultimately caused me to fork. For nearly a year I was the only one answering questions on in the ESDoc repo issues which now is mostly silent w/ questions piling up and I also provided fully working minor and major proof of concept improvements that were declined with no reason given.

The other major effort I've forked was escomplex with a completely different thread of illlogic leading to a hard fork. escomplex was dying already abandoned by the original author who did all the work and the maintainer at the time was maintainer in name only not doing any work on the project yet ultimately wanted to micro-manage a non-existent dev community. You can read that thread, but the silly thing is that 4 months later that fellow posted he was looking for a new maintainer and his fork was going to be orphaned. Almost immediately there was uptake of my fork though I haven't publicized it's existence outside of some yammering on JGO, however I submitted a patch to a large downstream user (Plato); a few other projects took note that Plato somehow supported ES6+ language features and found my module. The original escomplex still has a lot of downloads as older modules / versions depend on it, but uptake was quick with my effort (graph).

I guess I bring up the escomplex project as you'll find a fair amount of license "zealots" out there that demand a permissive license. When it comes to developers tools though I gather developers just want something that works with a clear integration pathway as well as any legal requirements from businesses / corps. The choice is how much and are you going to control leakage of your work.

About your situation though. The chance of leakage is low. It's also tough to say there is much of a / any market for Java based audio / engine software that is interfaced via an OOP / Java API. Very few on JGO make a standard living from their Java games with Android being the most likely case / Pascal (orange pixel) comes to mind and I think there is a thread or two on JGO where he talks about his efforts. There is the black swan we all know of course. Sans marketing budget dev tools need a killer app / game to sell the tools and chances are you'll have to create that killer game and not just be the audio dev tool provider. Do consider some plugin system though as you could release the core system OSS and then potentially charge for specific value added plugins while allowing 3rd parties to create their own.

Another consideration with releasing your software is that if I recall you haven't worked as a professional developer yet. By releasing your software under any OSS license it will provide a useful data point / proof of competence for any future employer and provide an opportunity for you to discuss it while interviewing. You can't lose there; I've gotten the majority of my jobs from showing code (mainly TyphonRT) I've worked on in the past. To that regard though consider getting things up on Github after you've decided on an OSS license or really just do it now under a private repo and make it public when ready. Having it online and accessible could get your foot in the door for an interview if so desired sans dev employment history. You'd make this the star of your cover letter, etc.

Anyway I'm glad that you are getting to the point of having something that you want to get out there in a more official capacity! Congrats and get 'er done!
7  Discussions / Business and Project Management Discussions / Re: Licensing overwhelm, asking for advice on: 2017-06-27 17:40:35
I'll throw in my 2 cents. I'm a fan of the MPLv2 license when aiming to release production quality code open source that I've funded with my own money / bootstrapping. I've certainly been influenced by the late Pieter Hintjens and enjoyed his book Social Architecture. From his blog and an early draft of the book he has a nice section on licenses and a great story about BSD (MIT and Apache) that certainly informed me on choosing the MPLv2 for TyphonJS and any other open source I release (TyphonRT eventually!). I'm also adopting a modified (info that is technical specifics) C4 contract for governance of all open source repos I release.

From a practical perspective a lot of the work I put out is highly modular where each module follows the single responsibility principle. The MPLv2 works great in this situation. The larger software systems that I'm releasing are all plugin / component based where the runtime is composed of many single modules any of which can be swapped out, but most folks won't swap out the core modules I make as the 1st party dev, but choose to provide further plugin / module extension for customization.

Interestingly the major Javascript documentation tool that I'm still finishing up (TJSDoc) was forked from ESDoc (MIT) after the author refused to accept outside contributions or discuss / engage anyone in the community trying to participate (fellow is also from Japan and doesn't understand English, so there is that difficulty too!). The fellow made it clear that it was his hobby project and wouldn't take outside suggestions small or large or code. I don't take forking lightly, but this was a case where I forked an MIT project and put in considerable time / money to make a production quality system which is even easier for 3rd party developers to extend amongst many other feature / architecture improvements. To protect this effort (~1500 hours / all programming time this year so far!) MPLv2 fits.

I'd say check out the Social Architecture book for an interesting treatise on community building and licensing / other matters that come into play including a good overview of what a software license actually provides as far as it relates to contract / copyright, etc. If anyone has any other pointers to other treatises in this matter I'd be glad to check them out as I find the topic interesting.


If you don't have time to check out the above links these two paragraphs cut to the chase:

"BSD is like food. It literally (and I mean that metaphorically) whispers "eat me" in the little voice one imagines a cube of cheese might use when it's sitting next to an empty bottle of the best beer in the world, which is of course Orval, brewed by an ancient and almost extinct order of silent Belgian monks called Les Gars Labas Qui Fabrique l'Orval. The BSD license, like its near clone MIT/X11, was designed specifically by a university (Berkeley) with no profit motive to leak work and effort. It is a way to push subsidized technology at below its cost price, a dumping of under-priced code in the hope that it will break the market for others. BSD is an excellent strategic tool, but only if you're a large well-funded institution that can afford to use Option One. The Apache license is BSD in a suit.

For us small businesses who aim our investments like precious bullets, leaking work and effort is unacceptable. Breaking the market is great, but we cannot afford to subsidize our competitors. The BSD networking stack ended up putting Windows on the Internet. We cannot afford battles with those we should naturally be allies with. We cannot afford to make fundamental business errors because in the end, that means we have to fire people."
8  Game Development / Game Mechanics / Re: Skeletal Animation structure on: 2017-05-09 20:00:11
I'd say look into Spine for a nice workflow and examine the various runtimes that are provided out of the box (LibGDX for instance) as all the code is already there for usage.
9  Games Center / WIP games, tools & toy projects / Re: Recruiting Java coders for XPilot port on: 2017-04-27 18:35:17
Cool.. I never came across XPilot before. When I get around to releasing TyphonRT it seems like a great vehicle for a demo example client and containerized server effort with a focus on entities / component architecture in implementation. I'll try and keep this in mind!  Grin
10  Game Development / Game Play & Game Design / Re: Working on "How to plan and design a game engine" and I'm looking for feedback on: 2017-04-18 07:19:35
>Now as you can tell it really could escalate in how much work could be done.

Perhaps consider linking to or including a supplemental reading list to others work. The two I'd look at first Game Programming Patterns (free web version) and Game Engine Architecture

I think the biggest benefit to anything you'll create is the comparative implementation of the different components of a game engine particularly if you can pull off doing it in several languages. The biggest criticism I've read about Game Engine Architecture is that it doesn't include source code for a complete engine; it is rather thorough in broadly going over the major components though. I'd find it hard to believe that you'll be able to come up with a 1000 page treatise and that's just one book out there. You could link to supplemental material that is topical and more in depth as well for AI, audio, networking, etc. 

>There are parts of my work that NO other game engines available have.

This is an extraordinary claim, but if so then certainly include thorough descriptions of your work and working code examples if you intend to enlighten.
11  Game Development / Networking & Multiplayer / Re: Saving characters online. on: 2017-04-08 10:23:03
**Disclaimer... I've never worked on a MMORPG.**

MySQL / SQL in general is waning in usage in the game industry from what I gather.

I have been spending a fair amount of time getting up to speed on modern server programming / containers. I'm just going to throw out thoughts as things are likely very dependent on the type of data that needs to be saved and amount of read vs write concerns when it comes to choice of particular solutions and accompanying trade-offs.

First off these days everything should be done with containers (Docker / rkt, etc.) and some sort of orchestration platform (I've chosen Kubernetes as there is a lot of momentum). I'd like to use rkt, but it's a bit light on tooling still as it's more framework than platform like Docker. Self hosted in the cloud or one could use Google Container Engine and other services of this nature.

If you're going Java on the server side two architectures worth looking at are Scala / Akka / actors (probably light on tooling for MMO applications) and the other I'd look at is Aeron. If using Aeron I'd also combine that with the Disruptor. Between Akka or Aeron / Disruptor the goal is to setup pipelines that are event driven. You might for instance use an in memory DB for some things, but to make sure things can be brought back from some failure you'd also journal / save all of the events flowing through the system, so that state can be rebuilt from periodic snapshots (also useful for debugging). Periodically (say twice a minute) for character players the current state of the in memory DB would be punted out likely over the wire to another container / DB for longer term storage or perhaps Amazon S3 or other cloud storage. Perhaps there is no in memory DB at all though I'd gather all of the really big MMOs have some sort of in memory DB as part of the pipeline. For DBs in general I'd look at Riak or Couchbase, but there are many options here. For high throughput everything stays as a binary blob; IE JSON / strings or XML is not desirable in high throughput pipelines, but in others it's fine. I gather in general there is some NoSQL going on for quite a bit of the data modeling / storage though I wouldn't be surprised if Blizzard or any other large game company rolls there own DB versus using off the shelf options. Here is a blog article on Pokemon Go that indicates Couchbase was used for certain parts of the architecture. From there I suppose it really depends on what your game back-end has to do. Perhaps Apache Spark is involved at some point for data analytics. No matter what though analytics at some level needs to be involved to detect problems, scaling issues, and any failures.

I'm sure you've heard about microservices. I guess the nice thing or the bane for documentation / maintenance is theoretically any particular one could be the best stack for the problem at hand including choice of language / DB which would only store the data specific to the microservice (say lobbies / chatting for a game / or user profiles). Instead of a more monolithic server things are broken down as separate stacks for very particular and limited purposes.

I'd suggest looking up articles on Pokemon Go architecture for a game that had to scale rather quickly. There should be plenty out there.
12  Discussions / General Discussions / Re: Need some programming advice on: 2017-04-08 06:28:43
It seems like you are enjoying your first major plateau experience. Plateauing happens to every programmer, but can be more intense and longer in duration especially if you are working alone / self taught. There are articles out there about plateauing and I'm sure you can find more in a search, but here is one. A cycle forms in this process where when you make the jump to that next plateau the first half of the experience is often refactoring your existing code then potentially problems once again pop up and the search for the next cliff to scale starts once again.

From a game dev perspective going down the traditional OOP route leads to not the best modular code / entity system. The anti-pattern that develops is the "god / blob" object; IE your base game object that everything extends from... As more and more systems are developed the tendency is to push the majority of them up to the god object. What you have built so far is not complex enough for this to have reared its ugly head; note OOP dependency injection should be avoided as it's not a good solution; just a band-aid. This is the main impetus to move to an entity / component system.

Some good book resources (I've not read the first two):
Game Programming Patterns (free web version!)
Game Engine Architecture
OpenGL Superbible

On entity systems / components:
Data Oriented Design
Adam Martin's ES series

I'd start with Game Programming Patterns since it's free; jump right to ECS discussion as it gives a good overview on the why. The others will be much more dense in content and take a lot of time to absorb. Adam Martin has quite a few ES / Java articles though don't take the design advice 100% as the way to do things; it's just one way.

Since you are still getting a grasp on OOP two oldie, but goodies for that is Head First Java and Head First Design Patterns which will provide reasonable coverage of "traditional OOP". This will probably help provide the vantage point to embark further down the data oriented design / entity / component system direction.

About data oriented design... At a glimpse this is the discipline in game dev (or any performance oriented programming area) of understanding how the underlying hardware works best to efficiently process data. Your GPU processes data in parallel; you can also process data on the CPU in parallel. Entity / component systems are the high level realization of DOD that organizes ones code / data for better processing. A central premise is that a good data component collects all the data that is associated with a given domain (physics, etc.) such that one can do the processing necessary without retrieving or collating multiple areas of code to get all of the data necessary to perform the processing. There may also be cases where a data component for all entities is pre-processed creating one giant block of data that needs processing in bulk.

Hand in hand IMHO at least with DOD / ECS also comes event driven programming. This is how components communicate with each other and the rest of the system aiding modularity and control flow. You will be familiar with the listener pattern from the various Java SDK implementations for say input, etc. It's 2017 now and the 90's can keep the listener pattern. You'll want to look up "Java eventbus". You may find a bunch of links about Google's Guava; stay away from Guava or at least that is my opinion.

To make the jump to fully understanding how ECS work in Java one needs to thoroughly understand generics and in particular generic methods. As things go this is a rather advanced subject and can be a bit mind bending. The best reference is this resource. It took me 5 years ('05-'10) to fully appreciate Java generics and realize the applications beyond just the syntactic sugar applications (where 95%+ of folks stop).

Eventually you'll need to master concurrency, but this is an advanced topic; a good starter book though. For now just keep all your code single threaded on the CPU.

Though you'll want to learn how GPUs work (older article, but good start). Go directly to shaders and don't bother to implement in your code the much older fixed pipeline approach except at least read about it for educational purposes. What shader programs do is define an algorithm for vertex & fragment (the final pixel rendered) processing that is applied across multiple data at the same time. The OpenGL Superbible is your first stop for this direction.

Since you have a go getter attitude and are using libgdx. Certainly put something together as a demo then examine the libgdx code for how and why it works especially sprite batching (advanced topic). You can also check out the available Java entity / component systems; I'd suggest Junkdog's Artemis ODB as the best candidate. On the latter there though none of the public ones are what I consider to encompass the complete picture of what is possible.

As far as some of the previous discussion. When I mentioned find a team to participate with that is more about the temporary hackathon experience versus finding a distributed ongoing team.

>Another example are bits, I don't seem to understand how to use bits.

Bit masking can be useful as the first implementation of state tracking, but it is fragile. The fragility comes as more and more states are added and that this type of approach is not suited for modularization where one combines state across multiple domains. The better approach is using Enums and EnumSet, however even that is not complete as you can not mix two different types of enums together. You can though create extensible enums and use a HashSet at first. Sadly there is no publicly available ExtensibleEnumSet implementation that I'm aware of out there which is the next step in efficiency allowing EnumSet performance across multiple extensible enums. Some starter references; the grand master is from Effective Java (a good book itself); here are some notes. It should be noted though that Joshua Bloch in his exposition on extensible enums stops just short of some of the really powerful applications.

It should be noted that the info above is coming from my perspective. You'll find a fair amount of folks on JGO that are more pragmatic or eschew some or all that I've mentioned above, so you may come across varying attitudes.

And just be ready to spend _years_ getting a hold of most of the above. Be ready to spend several months to really grasp some of these topics as they can be deep and are complicated. Learning OpenGL / shader programming will be one of those areas that simply put just takes time even if you are already an accomplished programmer. I wouldn't recommend for instance even looking at Vulkan until you have a thorough understanding of OpenGL.
13  Discussions / General Discussions / Re: Need some programming advice on: 2017-04-04 01:08:53
>I'm to the point that I'm getting frustrated and ready to find a new hobby.

I've long held the belief that a programmers greatest asset is patience. It's going to take time to get better especially if you don't work professionally in the field and are taking stabs here and there at it.

> I should be much further along than I am in terms of skill.

As silly as it may sound learning to enjoy the journey is just the nature of tech in general.

Given that you have dabbled with libgdx there are plenty of open source examples of projects out there of the pong / breakout style. Perhaps consider putting what you have worked on up on Github as open source and then post the links for comments and specific questions on JGO. Going through the process of perfecting a simple clone game can be useful and even publishing it via libgdx / Android or wherever such that you go through the all the steps of releasing an app at a state that others may use it however small the audience. If you are in an area where there are tech meetups go to some and talk to others. Perhaps participate in any "hackathons" and be ready to join a team and collaborate at whatever level you can.

Another useful thing to do is to keep a journal. This will definitely help if you are on / off again. There are a lot of articles out there to peruse.
14  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-02-21 01:53:44
Once again a solid effort Spasi! I just sent off the business card mini-flyer for GDC and beyond pimping this major LWJGL announcement. Here it is (looks like the forum cut it off / it's also a link to the image):

I'm going to beat the street and even bit the bullet further and upgraded to a full GDC pass so to not miss any bloggers and other press that might pick up a story. Fingers crossed!  As mentioned in PM I'll try and get around to over the weekend creating an in-depth tutorial wiki entry with step by step picts.

Alright... dev on Android and beyond is going to be exciting from here on out!  Grin

15  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-02-13 21:24:16
We currently require Android N and platform 24+. Which corresponds to too low a percentage of Android users. Making it work on earlier versions should be possible, but I have neither the energy nor the incentive to do it myself.

From my perspective this is fine as Google constantly introduces new SDK APIs that aren't available at lower platform levels. In the coming months I will try and see if things can be back-ported at least for GLES to platform 19 (4.4 / KitKat / GLES 3.0); I'm generally aware of the problems / efficiency though of pre-OpenJDK though. Vulkan itself has more or less a limitation of Android N regardless if going native or through LWJGL, so again not so much of an issue with platform 24.

The amazing part of LWJGL being on Android is that now there is an option for low level graphics that is separate of the SDK / firmware conundrum of how previous SDK graphics APIs are managed. IE As the Vulkan spec continues to be modified we don't have to wait for platform 25, 26 ... X to get these new features enabled like previous Java SDK efforts being locked to the firmware. Granted there are still firmware locked drivers, but if it's an advancement of the Vulkan API itself that isn't dependent on driver updates then these new features will always be available at platform 24.

Not sure if it's even worth doing, given the performance characteristics (I'll write another post with the details).

When you get a chance this will be much appreciated and will provide initial metrics to compare for any back-porting.

There's also the issue of better handling buffer/device lost events, which are fairly common with Vulkan on Android. You may notice it in the above video, when the orientation changes, there's a full destroy and recreation of the whole thing. Moving out of the app and back in again also requires a "soft-reset", but I think I've handled that one sufficiently.

That you got this mostly worked out initially is great work. However this is not an issue as since day 1 with GLES on Android 1.0 onward one simply locks the orientation for game / graphics apps. Very few intense graphics apps don't lock the orientation and and leave the orientation restart process enabled.

I can perhaps see the difficulty of enabling various debug layers of Vulkan and getting all the necessary output perhaps if it's not being logged per se, but that is a separate issue.

The issue is complicated by the fact that I've written VKSurfaceView similarly to GLSurfaceView; everything runs on a separate thread and the UI events arrive asynchronously. If you're familiar with GLSurfaceView's implementation... it's not trivial and I don't have the necessary experience (or time) to make it robust. If I fail, I'll probably make another version that runs on the UI thread and maybe Android engineers can help with properly fixing the concurrent version.

I wouldn't hold my breath per se for any Android engineers being involved; I don't think there are any more Java / graphics champions involved to a meaningful degree on the Android team. If there is collaboration though it will be embraced warmly!

I do have experience in creating an updated GLSurfaceView2, so I'll take a look in time on any improvements there as well for VKSurfaceView, etc. If I recall correctly it was necessary at the time to expose GLES 3.1 since the Android SDK GLSurfaceView is based on the old EGL API (
javax.microedition.khronos.egl.EGL10) instead of 1.4 (android.opengl.EGL14).

Once that's done, I'll update the lwjgl3 android branch and will create another repo with an Android Studio sample project and some instructions.

If the repo can be created sooner than later along with a wiki entry where instructions will go then I can proceed with the mini-flyers.
I'll also gladly contribute the screen shot walk through of setting things up similar to what I did for my GL demos /  source code setup.

Other than that, I won't have time for much else. I'm fairly busy at work and I'm also becoming a father for the 2nd time (today or tomorrow).

Congrats with your new child! I'm always amazed that you consistently move LWJGL and the larger community forward so deftly in your spare time!

It shows that any backpedaling on Google's side is simply that; a lack of will to get things done. It's kind of been that way for a while now as things go. Your effort with LWJGL on Android means that Java will remain a first class citizen for modern app development and this is huge.

People that need to go low-level can easily find it, there aren't many options out there. I certainly don't want to give the illusion that it's a library for the average developer. Especially wrt Vulkan.

I agree the average game developer for a long time now has moved away from engine development.

In this case though the Khronos tutorial day is filled with folks making up the right audience to send a message to and that is Java remaining a first class citizen for advanced graphics development on Android and LWJGL filling the need for a unified cross-platform SDK for low level access which fulfills the promise of Vulkan and is something Google would never do re: one Java API that runs on the desktop and Android.

16  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-02-11 23:38:14
Once again; this is huge! Amazing! Great work! I'll get in contact with Khronos to see if they'll let me do a quick ~3 minute announcement at GDC / Khronos tutorial day. I assume you can do the blog announcement. Also I'll print up ~2k color business card (mini-flyers) with info on LWJGL going cross-platform to Android to pass out. Let me know if you have any logo / branding ideas or other input on graphics involved; I'll keep it classy. Any chance a permanent tutorial guide can be put up I can link to in addition to the main LWJGL web site; a Github wiki with screenshot walkthrough would be great! I'm still tied up for most of next week w/ the TJSDoc launch, but I'm going to get the word out at GDC. I'm sure I'll run into a bunch of Android bloggers too, so if some articles aren't up by GDC I'll see if I can drum up some interest.
17  Game Development / Performance Tuning / Re: Object Pooling and arrays on: 2017-02-09 02:10:05
Unfortunately it's not something I can confirm right away as it's been a while since I've been doing Android dev and my larger TyphonRT projects (video engine) are stuck back at a gradle version well below the current setup I'm running. IE I don't want to spend the ~3+ hours now to get things running to verify this point; updating gradle from an old version and a multi-module IDE project is no fun... 

It was a bit more nuanced and problems only occurred when running a large project based on TyphonRT when using HashMap as the component storage versus IdentityHashMap. The problem occurred when mixing 'Class / .class' and enum types as keys in the same HashMap and not just various enums as keys. When i get back to Android dev after my Javascript adventures / server side stuff is complete later this year I'll do the test and report back if I remember though this thread might be locked by then.  If I recall though it was because Class and Enum have different hashCode implementations; I could be wrong. Pending verification....
18  Game Development / Performance Tuning / Re: Object Pooling and arrays on: 2017-02-08 23:45:01
You guys are nitpicking. It's an extremely poor implementation of hashCode valid or not... Which causes instant clashes with HashMap. You have to use IdentityHashMap when using enums as keys on Android.


Harmony / same code as in Android for 8 years until switch to OpenJDK:
19  Game Development / Performance Tuning / Re: Object Pooling and arrays on: 2017-02-08 23:30:05
How is it valid? It differs from the JDK implementation which is the identity hashcode. It's clearly a mistake in the Harmony implementation never corrected in Android. Even Romain Guy in the discussion went, "oh shit..." or thereabout.. Go look at the JDK source and compare against Android. HashMaps will fail on Android if you have two separate enums with the same name at the same ordinal. QED.
20  Game Development / Game Play & Game Design / Re: Too much abstraction? on: 2017-02-08 23:11:51
Yes, look beyond the listener / observer pattern; it's not the '90s anymore.  Roll Eyes Start here...

In my efforts I have an eventbus implementation which is driven by extensible enums defining categories that also is a system component which can be added to any component manager. The events are also component managers where any data can be attached and recycled after the event propagates.

The benefit of an main / app wide eventbus is that there is a single place where all event bindings are stored and can be removed in one call. Depending on the design only the receiving end of events is registered explicitly with the eventbus as well. Having this intermediary between the triggering and receiving locations is a marked improvement over the classical listener / observer pattern.

>For ECS, you cannot easily prevent someone from removing a component because you cannot remove mutators w/o breaking your ECS.

As mentioned if you are a little clever you can prevent this scenario by adding into the mutation methods of the component architecture invocation of an internally supported component which can have pre & post actions around the mutation itself. The pre action can cancel the mutation action among other use cases. The post action could be whatever you want based on the added component; IE fire an event based on a component being added or whatever.
21  Game Development / Game Play & Game Design / Re: Too much abstraction? on: 2017-02-08 21:43:50
When you say events what are you really saying? The listener pattern or something else? I highly recommend that you do not adopt the old listener pattern and look at the eventbus. From Guava or elsewhere. Though don't use Guava!

Indeed it can be tricky coding to make a type safe component architecture really flexible with Java as it takes an advanced knowledge of generics / particularly generic methods. I'll give a basic example though.

import java.util.HashMap;

public class ComponentManager
    HashMap<Class, ?> componentMap;

    public ComponentManager()
        componentMap = new HashMap<Class, ?>();

    public <T> T getAs(Class<T> componentType)
        return (T)componentMap.get(componentType);

    public <T> void set(Class<T> componentType, T component)
        componentMap.put(componentType, component);

// Simple usage...

ComponentManager entity = new ComponentManager();

entity.set(PlayerState.class, new PlayerState()); // Let's say it has a public health field.

if (entity.getAs(PlayerState.class).health >= 100) { /* yeah!!!! */ };

The above is the simplest type safe example of implicit composition. From there the rabbit hole goes much deeper. The nice thing though with the component architecture approach is that you can have all data fields publicly scoped in the component as there is still type safety and a query from the component manager before things are accessible. IE no "getHealth" method necessary with PlayerState.
22  Game Development / Performance Tuning / Re: Object Pooling and arrays on: 2017-02-08 21:18:02
Indeed it's a problem on Android. I was very lucky to have tackled this area long before starting Android development in '08 on the desktop previously and refined things even further with my TyphonRT efforts especially after switching to a component architecture which is based on HashMaps. I created a custom collections implementation which recycles iterators automatically at the end of iteration in loops in addition to internal objects used in all the collections. Even better is that the component architecture allows easy recycling of components (objects!). So yeah you'll get hit hard on Android using iterators and the standard collection API for anything near real time usage. Even worse was the piss poor annotation support as it lacked all caching and did a bunch of string comparisons (left over poor implementation from Harmony), so I have my own annotation cache for TyphonRT. I had a demo showing milliseconds for my cache and up to 10 seconds for the same amount of queries by the Android API in a tight loop. In addition I found early in ~'12 though never reported a serious flaw in Enums on Android. At that point I just gave up on reporting things as Google simply didn't care about quality or performance to the degree that I thought it was important and worked around it as the workarounds work on any version of Android. Some details on the Enum bug here.

As you noted though that recycling variable length primitive arrays is troublesome in general. That is worked around for say in a component architecture you have a ParticleData component with primitive arrays for tracking X particles. You recycle this object / component and when you pull it off the pool you know the primitive arrays are the right length, etc. So recycling objects with explicit primitive array lengths is fine.
23  Game Development / Game Play & Game Design / Re: Too much abstraction? on: 2017-02-07 22:51:31
It sounds like you are new to ECS / component architectures (CA)... You should probably use one that someone else created first; Artemis-odb being a good candidate. Learn how it works then move on from there as there are some tell-tale problems in what you've described in your own effort. First, it's absolutely possible to create an ECS with Java that is dynamic and type safe. Regarding being able to lock down an Entity or component manager consider a specialized system which has callbacks referenced in the Entity / component manager implementation itself for mutating methods like add / remove / set of components. The internal implementation before completing each operation can callback pre & post actions for the this particular component type offering the ability for pre actions to veto add / remove / set operations. Create a FinalizedSystem component which vetos all mutation operations and once added to an Entity then no longer can components be added or removed. Also consider enum sets and depending on your game create one data component with one or more enum sets tracking relevant data for the game at hand. This is useful for state tracking. Extra credit to create an extensible enum set that can accept more than one extensible enum running at similar performance to EnumSet (limited to one enum as things go). Eventbus / message passing goes hand in hand with ECS / CA and is rather handy with communication between data / system components across module / logical boundaries. A bit of a dump of things that can be done, but it's completely possible to do great things with ECS / CA and Java while keeping things manageable for the developer using this architecture.

So yeah.. examine others work in this area before striking out on your own for sure. The lack of type safety in your efforts do indicate that things are going down the wrong path.
24  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-02-05 18:51:09
Absolutely fantastic progress folks! I've still been tied up releasing TJSDoc (Javascript documentation tooling) and hope to get that finished this week then I'll pick up and start testing and using the Android LWJGL port full time+ for the remaining time leading into GDC. Here's hoping Vulkan comes online too! Grin Keep the info flowing and perhaps point out any pertinent details on where / how to get started with the current state of things. Got a wiki entry yet?
25  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Advantages of Ant? on: 2017-01-29 22:24:45
NPM is indeed great and I'm releasing a bunch of modules currently. I use open semver with whatever is the major version for all dependencies in package.json and then use npm shrinkwrap when doing releases. Problem solved. Before doing a release I'll test with the open semver versioning and update anything that needs updating then use shrinkwrap again as necessary.

I have a standardized build / test NPM module including building documentation, typhonjs-npm-build-test that automates everything in a coherent way across all TyphonJS modules. In the next update I'll be adding automation for the shrinkwrap process in the publish script. Publishing will fail if the shrinkwrap changes as npm-shrinkwrap.json should be committed in the repo.

Of all things I've completely overhauled ESDoc adding tons of features and a much more flexible architecture which supports Babylon for ES6+ doc generation and soon Typescript along with other things like Flow and internationalization of docs generated. I'll soon be releasing a CI support module for building docs on commit and uploading them to a document specific repo for all organizations / repos across a larger multi-repo effort (like TyphonJS) with a container based doc server and web app which pulls down changes automatically and deploys them online as commits happen in addition to hosting older versions.

The next version of typhonjs-npm-build-test will include automation of the shrinkwrap process and switch to TJSDoc (a placeholder presently for the next few days!) from ESDoc.

Apparently I can't shake the tools creation bug...  Roll Eyes
26  Game Development / Newbie & Debugging Questions / Re: Attack action on: 2017-01-22 21:22:53
Check out feedback loops... A good article here page 18.
27  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-01-19 21:13:59
OK.. I'll start taking a look ~mid-next week. I joined the slack channel as "typhonrt". I think starting with the core / bare minimum to get GLES up first is a good idea for sanity then add Vulkan and worry about audio later. I'm generally familiar with the process you outlined and will embrace the black screen of death until I make it blue..  Shocked  Hopefully Travis is up for it as with a cursory review it seems to indicate it may be a bit raw.
28  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2017-01-19 13:52:14
Hi @Spasi.. I hope you are feeling better!

Just dropping a note that I'll be attending GDC for the GL / Vulkan sessions and tutorial day. There will be a talk on native usage of Vulkan / Android, but I'd be glad to submit a lightning talk (5 min) and perhaps have the chance to drop the details on LWJGL support on Android & icing on the cake if Vulkan is supported. Regardless if the lightning talk comes through I'll be able to chat with many high level folks about said support if it was possible to get things working before then. Alas it's 5 weeks away, so a bit tight on the timeline. I just bit the bullet and got a tutorial GDC pass.

If you could perhaps provide some guidance on where to start or what needs to be done I'll try to help out however I can. I can probably put in ~20 hours a week starting next week to help for the following 2 weeks then perhaps jam full time on things the remaining time as necessary to get things stable.

I'm finally getting a new dev laptop tomorrow and will be setting up the latest Android Studio setup in the next couple of days. What else will I potentially need? I assume getting comfortable with building LWJGL on the new lappy will be a good start (MacBook Pro in regard to environment). If there is any info regarding this process do point me to it as I didn't readily find anything on the LWJGL web site.

It'd be absolutely fantastic to get LWJGL 3 on Android and I'll pimp it hard at GDC and inform folks who is behind it all too (err not me!).  Grin I'll also foot the cost to make a nice color business card / flyer about LWJGL 3 w/ Android support info and pass it out to everyone I meet; will also include JGO link too!
29  Game Development / Newbie & Debugging Questions / Re: FPS Sensitive Jumping on: 2016-12-22 23:17:06
So yeah... A few things which will lead in a more solid direction. Things get tricky with dynamics / gravity and other related calculations as you have seen.

The quick hack is this.

The next thing to do is this.

Also there are performance problems with your move method. Never create new objects if at all possible in any game loop. A further optimization is to not poll the input device in the move method of your game / entity class! I'll see if I can get a mostly correct example with the quick hack and these optimizations above mostly worked out in some pseudo-code modifications to your posted class in a follow up post.
30  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2016-12-20 21:23:26
Get well!

I do look forward in how this can proceed and to start can probably squeeze out ~10 hours a week to help test, but certainly would be glad to get up to speed on the LWJGL architecture / build process in time. If there was a time to get this going though it sure does seem like now!  Grin
Pages: [1] 2 3 ... 13
EgonOlsen (58 views)
2018-06-10 19:43:48

EgonOlsen (40 views)
2018-06-10 19:43:44

EgonOlsen (60 views)
2018-06-10 19:43:20

DesertCoockie (225 views)
2018-05-13 18:23:11

nelsongames (141 views)
2018-04-24 18:15:36

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

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

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

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

Solater (158 views)
2018-03-17 05:04:08
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!