Hi !
Featured games (85)
games approved by the League of Dukes
Games in Showcase (623)
Games in Android Showcase (176)
games submitted by our members
Games in WIP (676)
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 ... 10
1  Game Development / Newbie & Debugging Questions / Re: Menu's , how not to brute force it? on: 2015-10-07 09:39:31
Have no idea how that will help me create menu's

Overlap2D is a "menu machine" and level editor. Check all the videos out on YouTube like this; just search for "Overlap2d"  Granted some of the videos are a year old now and they did a big overhaul of the editor runtime.

It exports all of the assets and configuration to a JSON file then has a runtime to load everything for you and you hook up actions to the buttons, etc. There are plenty of videos. I don't use it, but it looks neat especially if you are new to LibGDX...
2  Game Development / Newbie & Debugging Questions / Re: Menu's , how not to brute force it? on: 2015-10-07 00:18:47
Getting a better idea of your skill level and understanding of LibGDX I recommend checking out this UI / level editor. It works w/ LibGDX and looks neat.
3  Game Development / Newbie & Debugging Questions / Re: Bit operating + Handling Weapons and/or Spells on: 2015-10-01 20:27:28
Even better is the extensible enum. It's basically an enum with an interface (can be an empty one say IExtEnum) and you can use multiple enums and define new ones as you add new characteristics as you go and use them all via IExtEnum. Just use the interface and you can use any extensible enum value that implements that interface. The one downside is that the optimized collection EnumSet only works with one particular enum. In my efforts I've created an "ExtEnumSet" collection which allows bit twiddling under the hood to work like EnumSet, but for extensible enums. That way you can stuff all the unconnected state into one collection and even run tests against it with other ExtEnumSets defining exactly what you are looking for.

And while composition was touched on in this thread consider the "entity system" architecture or more generally component architectures. Use the type system of Java to your advantage.

There has been plenty of discussion on entity systems on JGO and elsewhere, but not everything you read will be accurate per se. If you Google "entity system extensible enum" you'll come across some of my ramblings on the subject.
4  Discussions / General Discussions / Re: Threads, games and running on all CPU's on: 2015-09-25 12:58:01
You've kind of side-stepped the point there - that graphics object is not, never was and never will be accelerated!  It would break the BufferedImage API.  That offscreen image needs to be a VolatileImage if you want to speed up rendering to it.

I know... ;P I probably could have added a paragraph break in there somewhere. I'm advocating going all in with the VolatileImage API as it's not too hard to support it and be absolutely certain things are accelerated.

When you move over to the VolatileImage API just implement the loading first as found in the tutorial (Code Example 5 / loadFromFile) and when making the OffscreenImage use createVolatileImage instead.  Once you verify that things are working then figure out a way to do any stale image verification in your render loop.

For classpath stuff...

Try this...
javac -cp ".;tinysound-1.1.1.jar"
jar -cfm neptune.jar Manifest.txt *.class *.png *.wav

java -cp ".;tinysound-1.1.1.jar" -jar neptune.jar
java -cp ".;neptune.jar;tinysound-1.1.1.jar" neptune


BTW as Cas and nSigma mentioned you don't need "-Dsun.java2d.noddraw=true". It actually crashes / prevents your game for running on my Windows box. I just get a white screen with this error:

Exception in thread "main" java.lang.InternalError: Could not set display mode
        at sun.awt.Win32GraphicsDevice.configDisplayMode(Native Method)
        at sun.awt.Win32GraphicsDevice.setDisplayMode(Unknown Source)
        at test.main(

So something might be particularly wrong with your dev box.
5  Discussions / General Discussions / Re: Threads, games and running on all CPU's on: 2015-09-24 22:35:11
I'm not sure why this should improve things but I've done it and it works fine. I've yet to try doing it all in just one call but I'll try this later. I should of kept records of frame rates etc so I could see what improved things and what doesn't.

Less draw calls the better. I don't have any specific implementation details behind the scenes with where accelerated Java2D is at these days, but I'd gather the fillPolygon method is generally expensive in regard to setting up the data and drawing (via Direct3D, etc.). Doing it once versus a 100 or 1000 times should make a difference.

You are correct to measure and only accept a change if things improve. Just be careful what you are measuring at times as micro-benchmarks are not always accurate.

I tried to call drawPolyLine but ran into a compiler error I didn't understand (it was late though)

No capital L.... _drawPolyline_ -- ,%20int[],%20int)][],%20int[],%20int)

So it compiled fine but blew up at run time in main() where I call    TinySound.init(); If I can get it to work will TinySound offer volume and panning?

You need to include it on the classpath when using javac and when running the main jar file. Not the system classpath ala %CLASSPATH%, but the runtime classpath when invoking javac and java.  It's the command line option -cp or -classpath. If you have the tinysound.jar in the same directory as the base of your source code you might be able to use:
javac -cp ./tinysound.jar
java -cp ./tinysound.jar -jar neptune.jar  

It might need to be:
java -cp ./neptune.jar;./tinysound.jar neptune  

BTW instead of using javac perhaps use an IDE. My long time favorite is IntelliJ Idea and there is a free community edition:

I know your code is all in a single file (we can talk about that later... ;P), but always compiling and running by command line is no fun... There are so many useful aspects of using an IDE for development especially when we get to refactoring your code... Tongue


As far as the peanut gallery at JGO goes here re: volatile images I don't think other folks were looking at the decompiled source code, but will give opinions... RE: here is the line in your init method...
this.og = this.OffscreenImage.getGraphics();
right after you create a BufferedImage for OffscreenImage. More or less the general advice you get around JGO is often "defensive" in nature. Last time I heavily worked with Java2D was from '02 to '08 and back then the VolatileImage API was the way to go. It's not clear at which point, re: JDK 6/7/8, BufferedImages get accelerated more or what exactly is the promotion strategy or how translucent images are handled. Using VolatileImage API was very important for translucent images back in the day. If you are trying to support older computers with older versions of Java even Java 5 (1.5) then VolatileImages may be a win. Again measure. The code needed to load and verify VolatileImages is in the tutorial I linked to previously. It's going to add a slightly finicky aspect to your render loop, but one worth measuring especially on any older machines you are testing on..

I don't understand why bufferedImages are better or what a volatile Image is. I'm afraid there were too many acronyms and not enough simple words for me to make sense of things. I'm happy to try both but I'd prefer to know why I'm doing it. Is the idea to use BufferedImage's for the sprites and VolatileImage's for the sea and sky?

BufferedImages are better in general because there is less hand holding involved as a developer. By creating a volatile image you are explicitly creating an accelerated image on the GPU that isn't managed. On some platforms like Windows this image can get stale and you need to reload it; all of this is described in the tutorial I linked to.
6  Discussions / General Discussions / Re: Threads, games and running on all CPU's on: 2015-09-23 22:11:51
For kicks I looked at the rest of your code... Looks more or less fine. You'll want to get rid of new object creation (mostly Color) and bare string creation in methods like drawPlayerInfo / drawOtherInfo (make a cache of strings as necessary). Another thing you can try is to use the VolatileImage API. At least back in my Java2D heyday I used VolatileImages to great effect. This looks like an adequate tutorial: So you'll need to change your findImage method and do a little housekeeping in the render loop. Also make your backing drawing buffer a VolatileImage. It'd be interesting to see where performance is at after these changes. And then we can look at the sea calculations and see if there is a way to speed them up if even necessary. It seemingly is grid oriented, so it should be able to devise some sort of fork / join process right in the main game loop.
7  Discussions / General Discussions / Re: Make Android Apps with Java SE coding !!! on: 2015-09-23 21:30:19
Yeah... I had a huge Java 5 code base for general OpenGL and a lot more I ported over to OpenGL ES 1.0 & Android 1.1 back in the day and this exact problem is why i ditched OOP and went component oriented (ala Entity Systems, but applied across the entire architecture) to make it possible to support desktop and the massive differentiation and actual fragmentation of Android over all it's versions. When writing software for Android over the last 8 years I always abstract away as much as possible and make it pure portable Java. I'm really excited actually as I'm going to double down on Vulkan and get TyphonRT back up and kicking on the desktop and Android. Once LWJGL (come on @Spasi et al!) get desktop Vulkan bindings when drivers are launched I'm immediately diving in porting most of the effects / video engine I've got on Android to Vulkan on the desktop and then port it back to Android when support launches hopefully a year from now. So yeah if you go OpenGL / ES or Vulkan you can write portable apps for desktop and Android with just a little extra effort.   

Of course there are already superior solutions out there ala RoboVM and RoboVM Studio for actual cross-compiling for iOS.   

In the future I'd mess around with it more if Apple ever gives in and supports Vulkan (guessing ~2-3 years from now).
8  Discussions / General Discussions / Re: Threads, games and running on all CPU's on: 2015-09-23 17:57:32
@BurntPizza... Hah.. Was just about to post this too.. ;P Knowing the iterations through the loop "(ScreenWidth / ((int) this.VarVal[8]) + 1;)" One can create one large int[] for x & y and then your loop becomes filling the data into the large int[] and then a single call to fillPolygon...  

Edit... Also use a single drawPolyline call via filling up an existing large int array.  Taking a look at your current game this can run at 60FPS single threaded no problems w/ my guess of around ~20-30% CPU utilization even on low powered boxes probably not exceeding 50% of a single core. As long as you do the proper calculation to have a large enough array for x/y you can reuse these arrays between fillPolygon / drawPolyline.
9  Discussions / General Discussions / Re: Threads, games and running on all CPU's on: 2015-09-23 17:29:53
I'm glad profiling came up as a topic. I wasn't aware if you actually had something working / proof of concept yet with the initial discussion. On quick further inspection w/ a decompile revealed instantly not best practices... For instance in the drawsea method:

   private void drawSea(Graphics graphics) {
        int i = 0;
        int i2 = (int) this.VarVal[8];
        int i3 = ScreenWidth / ((int) this.VarVal[8]) + 1;
        graphics.setColor(new Color(0, 10, 255, (int) this.VarVal[5]));
        int i4 = 0;
        while (i4 < i3) {
            graphics.fillPolygon(new int[]{i4 * i2, (i4 + 1) * i2, (i4 + 1) * i2, i4 * i2}, new int[]{this.WaterY[i4], this.WaterY[i4 + 1], ScreenHeight, ScreenHeight}, 4);
        graphics.setColor(new Color(0, 0, 0));
        while (i < i3) {
            graphics.drawLine(i * i2, this.WaterY[i], (i + 1) * i2, this.WaterY[i + 1]);

Never create objects especially in your rendering loop. That goes for "new Color", but most importantly in even tighter loops ala the while statement and all of the anonymous array creation. In this case the data inside fillPolygon; you are creating two new arrays repeatedly and they are constant length (4). Simply create these arrays once outside of the method and populate them each time through the loop then call fillPolygon... Tons of GC thrashing will occur with this code.

I don't have to look at the rest of the code to know there are likely many things to fix and given this initial jaunt you shouldn't even consider multithreading at this point as you are far from optimum in the "naive" / test implementation.
10  Discussions / General Discussions / Re: Threads, games and running on all CPU's on: 2015-09-19 10:20:06
What's your current organization like for your data?

Are you modeling things w/ OOP for the "sea, waves, splashes, general collisions"?

If yes to the above then restructuring things to a more DOD (data oriented design) ditching OOP may give you a lot more performance. IE primitive arrays of data.

You mention "static arrays for those bits". That kind of connotes that you might already be organizing things by primitive arrays of data.

If memory is not a problem a copy of the relevant data per worker thread and splitting it up for data to potentially be processed by multiple threads is possible. Using a simple ArrayBlockingQueue (other options available under java.util.concurrent) to transfer data between threads can be fine because likely whatever processing that is occurring in worker threads is heavier than any synchronization aspects of the concurrent data structure used.

You can roll your own system with an Executor or you could even use fork / join in your main render thread. See this JGO thread:
11  Discussions / Miscellaneous Topics / Re: Android phone for game development and everyday use on: 2015-09-03 06:47:48
S6 has the best GPU of the current generation IMHO. I have it and the M9 (Snappy 810). I'd recommend getting at least an 810 if you are going with a Snapdragon SoC.  For gaming and actual game development you can't go wrong with an NVidia Shield albeit a tablet, but one you should be able to pick up on the cheap these days. The K1 is still up to ~3 times faster than the current generation of mobile GPUs. It'll have full Vulkan support first (already does, just not released yet). Absolutely solid GL parsers and parity w/ the desktop in terms of quality. The big problem you're going to run into w/ just one device is that there really are little differences between the shader parsers between all the major mobile GPU vendors. It's a real pain in using GLES 3+. Rumors are the next Nexus phone is going to be underpowered. If you can wait though I'm not sure how long you'll have to snagging a Snappy 820 is likely the next generation that Qualcomm is going to possibly have a comeback in the mobile space for a good product; not sure when the first one is coming out though as it could be next spring / summer. 810 kind of got slagged this gen. I'd say try to find a used Shield tablet for $125 or less used then check if it can be replaced via the battery recall and get a new one... ;P
12  Discussions / General Discussions / RoboVM Studio on: 2015-06-19 08:29:15
This looks interesting... The RoboVM folks are making interesting progress these days and increasing the pace!
13  Discussions / Miscellaneous Topics / Re: I've been here one year. on: 2015-05-08 20:50:28
Developers and their cats huh.... Sometimes I can't do any work because of this:

Hang in there buddy... I'm going on 13 years in these parts (1st 2 lurking)..  Grin
14  Discussions / General Discussions / Re: What's your day job? on: 2015-05-07 18:08:14
Contract assassin / cleaner.... err well I usually arrive after a mess has been made by the in house staff and rescue the project. Sometimes I get in at the start and do it right.. Most recently though I was a source code reviewer in a major patent litigation lawsuit (lips are sealed there as things go, but interesting nonetheless). Stoked as that last gig set me up for the rest of the year to finally get something launched of my own. If I was a glutton for punishment and travel I'd probably get into source code reviewing because it pays better than even high-end tech contracting; err cleaning, yeah...
15  Game Development / Newbie & Debugging Questions / Re: Best way to deal with infinite elements? on: 2015-01-21 00:08:52
Depending on your needs as you mentioned using this for something like an endless runner I'd get rid of objects altogether if all you are tracking is one type of data (re: rectangles). Use primitive arrays and keep track of the active count and index by stride of your data. You can get more clever and store multiple types of data perhaps with an increased stride and some sort of index data which identifies the data type. This doesn't require new object creation and also brings cache locality into play when you are working over all the data for rendering / collision detection. IE the only time you are guaranteed to have a contiguous block of data with Java is primitive arrays. It will be at least an order of magnitude faster than creating new objects and iterating over a collection of objects regardless of collection used.

Of note is that I didn't really look into supposed logic issues in the pseudo-code you posted, but here is more or less how you'd do it without objects. It will be a lot faster! Benchmark it and report back..  Grin

static final s_MAX_SIZE = 10;

static final s_STRIDE = 4;

int listRec1[] = new int[s_STRIDE * s_MAX_SIZE];
int listRec2[] = new int[s_STRIDE * s_MAX_SIZE];

int listCount1, listCount2;

Rectangle playerRec = new Rectangle();

render(float delta)
   if (currentTime - previousTime > 5) //5 seconds
      if (listCount1 < s_MAX_SIZE)
         int index = s_STRIDE * listCount1++;  // post increment only happens after mult.
         listRec1[index] = anyX;
         listRec1[index+1] = anyY;
         listRec1[index+2] = anyW;
         listRec1[index+3] = anyH;        

         if (listCount1 == s_MAX_SIZE && listCount2 == s_MAX_SIZE)
             listCount2 = 0; //clear listRec2.
      else if (listCount2 < s_MAX_SIZE)
         int index = s_STRIDE * listCount2++;
         listRec2[index] = anyX;
         listRec2[index+1] = anyY;
         listRec2[index+2] = anyW;
         listRec2[index+3] = anyH;        
      else if (listCount1 <= s_MAX_SIZE && listCount2 < s_MAX_SIZE)
         listCount1 = 0;

         int index = s_STRIDE * listCount2++;
         listRec2[index] = anyX;
         listRec2[index+1] = anyY;
         listRec2[index+2] = anyW;
         listRec2[index+3] = anyH;        
   for (int i = listCount1; --i >= 0;)
      int index = i * s_STRIDE;
      int rectX = listRec1[index];
      int rectY = listRec1[index+1];
      int rectW = listRec1[index+2];
      int rectH = listRec1[index+3];

      //code to draw all rectangle inside listRec1.
      //code to verify collision with player and Recs.
   for (int i = listCount2; --i >= 0;)
      int index = i * s_STRIDE;
      int rectX = listRec2[index];
      int rectY = listRec2[index+1];
      int rectW = listRec2[index+2];
      int rectH = listRec2[index+3];

      //code to draw all rectangle inside listRec2.
      //code to verify collision with player and Recs.
16  Game Development / Newbie & Debugging Questions / Re: Compute + Geometry Shaders on: 2014-12-30 04:18:25
So one neat thing about compute shaders is that they exist within the OpenGL pipeline. So you can use normal texture sampling in compute shaders which is not how OpenCL work.

A simple invert op w/ a sampler:

And in the compute shader:

I also provide the imageLoad version too:
17  Game Development / Newbie & Debugging Questions / Re: Compute + Geometry Shaders on: 2014-12-29 23:04:26
a pretty good article here about how to use compute shaders for realtime raytracing.

And I ported it to OpenGL ES 3.1 for Android with a repo here:

Compute shaders are basically OpenCL light with the added benefit of being a little more integrated into the OpenGL pipeline, so it's easier to access texture data for instance, etc. With SSBOs you can shuffle a lot of data to be processed on by the GPU via a compute shader instead of the CPU. Eventually I'll be getting around to porting some of the Nvidia Gameworks OpenGL examples to another related repo as the one above and the ComputeParticles example is nice:
18  Game Development / Game Mechanics / Re: Savegame structure for Entity/Component System with complex components on: 2014-12-28 21:56:28
Yes i only use the composition as components, i.e, data only. I don't think i could do without composition, as i dont want to write a specific component for each 'Type' of an Entitiy derivation. But all this made me think about my component approach, and honestly, i think i have found my error in the approach of an ECS.

Composition is great and indeed it sounds like you are 10% of the way there for an efficient ECS, but are still clinging to the old ways. It takes time believe me as I've worked on mine for years as things go.

But some of my components are so complex that i really need to create 2-4 specific classes for it.

You're doing it wrong.. ;p  This screams thinking more about the separation of data and the systems that process it. In an ideal scenario a 1:1 or 1:N arrangement is good. 1 data component containing everything a system component needs to process this data and complete a task.

You are making very heavyweight "objects" despite having that 1st tier of implicit composition (seen in your other post). Components are more about the architecture / API that provides implicit composition and ability to manipulate those relationships. IE calling a heavyweight object a component does not make it so.

Allthough i would like my components to be 'Data only', they still are and an external system (static method or object method), runs on it. But i realize a lot of people are having trouble with this.

There is very little codified per se for ECS.

Ok gotta go. Flying and phones off right now.. Cheesy
19  Game Development / Newbie & Debugging Questions / Re: Anybody know where I can find a good glow shader tutorial. on: 2014-12-28 02:59:18
blur the areas you want to glow (perhaps by color or a mask) then potentially adjust contrast or muck about and blend (additive or otherwise) back into the original image. Must use FBO passes.

There is also the trick with code in the Nvidia Gameworks OpenGL demos which will make luminant colors glow.

Lots of other neat techniques in the Gameworks OpenGL samples. Eventually in my "copious spare time" I'm going to port over the Gameworks OpenGL samples to the Java / Android OpenGL demos repo I'll be maintaining.
20  Game Development / Game Mechanics / Re: Savegame structure for Entity/Component System with complex components on: 2014-12-27 19:00:30
You have already posted a similar thread here with more details on your Entity / component API you created. These details do reveal the difficulty of your serialization efforts. More or less your component system from the other post was a bit basic. IE one level of storage under an Entity class as the container.

I'll assume your design hasn't changed much from your other post.

...and also objects of other classes i wrote for specific Components.
...and class objects which again contain other class objects.

Which is sort of like traditional OOP again once you have explicit composition back into the mix. Other standard object serializers will not be able to understand the 1st tier implicit lookup of your Entity class. But potentially serializing the 1st tier of components since they use explicit composition from then on could work by a standard serialization library. (Kryo is a good one for Json).

I assume you at least separate things into pure data components and then system components that work only on the data ones. Perhaps add an annotation to your data components that marks them as such. You'll still have to create a little bespoke save / load parser for serialization that walks the 1st tier of components and looks for any that have the @DataComponent or whatever annotation tag you make at the Class level. Once you find one of those then chuck it into the grinder of whatever standard OOP serializing library you are using. On load you'll have to conceivably partially compose an Entity of a particular type adding all relevant systems then deserialize each data component and add it to the entity. If all goes well the object graph of each data component even the explicit composition aspects are handled by your library of choice.

I tried serialization, but then i would need to implement Serializable on EVERY SINGLE class i used in the component(right? Oo), which seems to me like a dirty solution.

Yeah don't do that. Josh Bloch, the fellow involved in implementing Serializable back in the Java 1.0 days, profusely apologizes for this blight.

On the other hand side, if i were to use something like Json, i would have the problem of needing to save one of my class objects as a string description of some sort, and then load it by identifying the string, get its values stored in a similar descriptive way, and then create the correct class objects from that.

That's what some of the 3rd party libraries already do which is serialize / deserialize an object graph.
21  Game Development / Newbie & Debugging Questions / Re: Which is the "better" practice on: 2014-12-26 23:46:14
Re: KevinWorkman had a great comment earlier.

I too have had to refactor plenty of nasty code in my time for clients where general bad practices just piled up with many hands touching things in the process.

Sure.. As Cas and others mention if you are doing traditional OOP and your scope is limited and you plan to not necessarily carry over ones work to the next game then do whatever works for you and be done with it.

The big problem with the singleton is versioning and modularity. I won't dwell on things too long, but component architectures solve the singleton issue by making versioning and modularity top level concerns as part of a framework providing the tools / API to do it better. As long as one has reference to the relevant container then it's a simple query to find the "GameData" object (or whatever used to be the singleton), etc.  In my efforts there is a way to inject the relevant main container into child components without dependency injection or reflection, so that is the way I handle things.

The defining thing is are you taking a short term "library" approach or working with a framework that solves the stickier parts of traditional OOP design.
22  Game Development / Performance Tuning / Re: GPU Accelerated Image Editing / Techniques - How to? on: 2014-12-25 17:14:04
I have a couple image filter examples using OpenGL ES 3.0 and compute shaders (OpenGL ES 3.1) for Android:

You'll want to check out GPUImage for iOS for a repository of OpenGL ES 2.0 image operations.

All the shader code is just sitting there to do practically everything Photoshop does. In my efforts I took a good chunk of that shader code converted it to OpenGL ES 3.0+ along with improving it and am doing some fun stuff with photos / videos.

I don't really recommend Renderscript since it's Android only and Google has turned it's back on open standards like OpenCL which is far superior for GPGPU; though now we have compute shaders with OpenGL ES 3.1. You can accomplish everything Renderscript can do and more with OpenGL ES 3.1.

Image processing is directly related to GLSL fragment shaders, so no need for actual GPGPU techniques; just straight up standard OpenGL GLSL.

There are "script intrinsics" though with Renderscript for a handful of image operations. It's useful if you want to integrate basic image processing with the Android 2D API / blur a Bitmap and are too lazy to learn OpenGL 3.0+. I still recommend it because once you learn OpenGL it works across platforms. 
23  Java Game APIs & Engines / OpenGL Development / Re: Modern OpenGL ES 3.0 / 3.1 compute shaders for Java with Android 5.0 on: 2014-12-15 04:16:30
Ahh Julien Julien Julien..  Clueless   Kiss   persecutioncomplex  It's not so much as a framework as it is a compact utility library that replaces the very long in the tooth mechanisms that have been around since Android 1.0. The library is for simple demos though I'll in time provide all the utility code that makes it possible to port the NVidia Gameworks samples to Java for Android. I'm trying to strip things down to the bare minimum of what is necessary for modern OpenGL and making the code clean for small demos. It's good for test cases too to test different mobile GPU manufacturers I already found some issues in the Snapdragon 805 Adreno 420 that don't exist in the 320 / 330 or Tegra K1 and have run into the proper folks at Motorola to have them take a look. One of the demos briefly shows the problem; only Nexus 6 / Adreno 420 with current weak drivers is showing the problem. The hardware is supposed to support OpenGL ES 3.1, but a gimped driver was shipped (just GLES 3.0 support). So, having samples that run across platform really show the glaring issues that manufacturers need to fix as some developers notice!

I actually stripped a lot of the utility code out of TyphonRT itself. What I released is definitely not the meat of TyphonRT from an architecture standpoint. That is why FBOData has public fields and accessor methods as I just got rid of the interface as it was one more class to track. IN a component architecture where there is a lookup often to retrieve an object one makes the member for data objects public.

Not trying to take over any binding anytime soon (the utility code posted uses the Android SDK bindings, but makes them pleasant to use). I actually welcome LWJGL3 or even JOGL to GLES / EGL especially whoever will potentially take on making a full profile Java / OpenGL Binding for the Tegra K1 including all the cool NV extensions (NV_command_list), etc.
24  Discussions / Miscellaneous Topics / Re: What I did today on: 2014-12-14 23:06:56
Should be titled what I did yesterday, all last night, this morning, and continuing today...

Finally got some really nice clean and modern OpenGL code up for Android which supports compute shaders and such.

Just got featured on the front page of XDA Developers... Cheesy

Woot woot...  Grin
25  Java Game APIs & Engines / OpenGL Development / Modern OpenGL ES 3.0 / 3.1 compute shaders for Java with Android 5.0 on: 2014-12-14 20:03:27
Hi folks,

Check out these Github repos I just posted this morning for modern OpenGL ES 3.0 / 3.1 demos and a lightweight framework that makes using this tech much easier from Java / Android

The main demo repo is here, but check out the install guide:

Glad I could get my first open source (Apache2) effort up after all these years. There are few if any modern OpenGL ES 3.0 / 3.1 demos for Java with Android and this is important tech. I spent a good chunk of the last week pulling out code from my commercial middleware (TyphonRT) to make a lightweight and concise GL framework that makes working with modern GL much easier. I also provide a few demos with more forthcoming though this is a spare time effort.

I ported over Kai's LWJGL / basic ray tracing in compute shaders demo code to OpenGL ES 3.1 and it works like a charm on the Tegra K1. Can't wait for his follow up post with the full code for something much prettier.

The nice thing is that the demo code is separated from the framework, so the framework can be used separately. Eventually I'll be porting the NVidia Gameworks demos to Java / Android. You do need a Tegra K1 based device to take advantage of OpenGL ES 3.1 as well Motorola and / or Qualcomm shipped deficient drivers that only supports 3.0 for the Snapdragon 805 / Adreno 420 on the Nexus 6 launch; talk about a disappointment there.  This framework and repo is updated for the absolute latest Android Studio 1.0.1 and build tools "21.1.2". There is a reasonable guide on how to check the code out, but a prebuilt apk is also available. Lots more to say, but I'd be glad to answer any questions about modern OpenGL on Android. I'll be expanding the wiki on the repos linked here in the next week.

If you think the code above is useful or cool it's the basis for where I'm headed with building a next-gen video engine for Android. I have ~8 hours left on a crowd funding campaign that will help me get it out sooner than later having bootstrapped to 95% of the way there spending 2.5k hours over the last year building it covering all costs out of pocket ($80k) / not quite close to raising the funding goal ($20k), but I'm most interested in finding early users who are interested about next-gen video and having fun / cool toys before iMeh; if you back the project even though it likely won't time you'll get an early invite regardless! I'll keep it short as there is a video available to check out of it in action.

KS here: At this point I'd really just like to connect with interested early users as the funding goal is well... yeah... Thanks folks!
26  Discussions / Miscellaneous Topics / Re: What I did today on: 2014-12-10 23:16:42
I was planning on coding away today, but when I woke up I had 20 new backers for my Kickstarter which has been the biggest influx yet...

The very nice folks over at Phandroid did a nice little write up and article on the TyphonRT Video Suite:

So I have spent the last 4 hours trying to get some more momentum behind it.. There is some activity on Reddit BTW if any of you use Reddit... "TyphonRT" may be a good search term..  Roll Eyes

About coding though.. I am close to getting a nice little repo up on Github with a very lightweight utility code to do modern OpenGL dev with Android.

The repo is located here and I hope to get things up in the coming days:

So hopefully back to hacking on the modern gl demos.. I'll be porting over the most excellent ray tracing demos posted on the LWJGL blog. Check it out... Good work Kai:
27  Discussions / General Discussions / Re: am thinking of getting this PC, for both gaming and developing on: 2014-12-10 09:05:18
I chose that motherboard over a full size one, as it was the cheapest motherboard that supports overclocking.

Most definitely. I mentioned ATX, because if the case I have to give away (3U rack-mount) is used for the build out it would look "interesting" inside with all that extra space.

We'll get @philfrei jamming soon enough with some new gear!  Grin

Link for the Kickstarter is in my sig... hint hint.. all of you..  Wink 4 days left.. I can use all the help possible on getting the word out. I just couldn't get it into the tech press which was what was needed...
28  Discussions / General Discussions / Re: am thinking of getting this PC, for both gaming and developing on: 2014-12-09 23:10:47
Suppose we start with the purchase of the computer I listed earlier, and add another 4MB RAM for 8 total (16 possible):

Typically you want to have matched RAM. These days 8GB min; preferred 16GB.

How do I find out if it is possible to upgrade the CPU to the recommended  FX 8320 CPU (3.2ghz 8 core)? (I know much less about how interchangeable CPU's might be.)

The CPU will have a socket type the FX-6300 and 8320 are AM3+.

The PCPartPicker site is nice because it lists all the details you need to mix and match parts.

I'm tempted to try and build, but I think my "angel" may be more comfortable with going with the existing pre-built unit.

I'd recommend it for similar reasons folks above have mentioned: better quality parts, easily exchange / upgrade parts due to a case with space, plus then there is just having the satisfaction of knowing you had a hand in building what you are using daily and know exactly what to do to upgrade a part.  Once you build one you'll never go back to pre-built. It'll take ~30 min to put it together.
29  Discussions / General Discussions / Re: am thinking of getting this PC, for both gaming and developing on: 2014-12-09 20:08:13

I've got a spare rack-mount case I haven't used in ~7 years if you'd like to grab it.  From my quick reading of this thread I can also help you put together a box too as it seems like you might not have done this before. Besides we chatted previously about hanging out at some point.  Not too many JGOers have historically been near SF Bay Area as far as I'm aware.

It looks like what @Phased posted is a good build out: at that price range. I'd switch to an ATX motherboard as that is what the case is unless you wanted to buy a microATX case. I guess you can put a microATX board in an ATX case; it'd look empty with the case I have...

I live close by to Central Computers in SF, so if there by chance is a missing cable it's easy to pick it up. If you decide to pull the trigger on ordering those parts PM me..
30  Java Game APIs & Engines / OpenGL Development / Re: [framebuffers] Rendering after another framebuffer was bound on: 2014-12-08 04:43:57
I don't have any way to test this, the call to glClear is done where the framebuffers are bound, so its fine. I just wanted to know if you stopped rendering to a frame buffer then re-bound it and drew anouther object, would both of their content be there.

Yes... Keep in mind though the necessity of correctly setting glViewport when dealing with different sized frame buffers.  An easy way to test is simply bind a FBO, set the glViewport to the backing texture size, draw something, unbind, rebind set glViewport to something smaller and redraw. The 2nd drawing will be in the smaller view port size on top of the original drawing.

So yeah... not knowing what the rest of your rendering code does one does have to keep in mind calls to glViewport when binding / unbinding FBOs.
Pages: [1] 2 3 ... 10
BurntPizza (22 views)
2015-10-08 03:11:46

BurntPizza (15 views)
2015-10-08 00:30:40

BurntPizza (17 views)
2015-10-07 17:15:53

BurntPizza (32 views)
2015-10-07 02:11:23

KaiHH (37 views)
2015-10-06 20:22:20

KaiHH (16 views)
2015-10-06 19:41:59

BurntPizza (32 views)
2015-10-06 19:04:48

basil_ (46 views)
2015-09-30 17:04:40

shadowstryker (24 views)
2015-09-29 15:55:06

TheSpaceHedgehog (31 views)
2015-09-29 01:58:48
Math: Inequality properties
by Roquen
2015-10-01 13:30:46

Math: Inequality properties
by Roquen
2015-09-30 16:06:05

HotSpot Options
by Roquen
2015-08-29 11:33:11

Rendering resources
by Roquen
2015-08-17 12:42:29

Rendering resources
by Roquen
2015-08-17 09:36:56

Rendering resources
by Roquen
2015-08-13 07:40:51

Networking Resources
by Roquen
2015-08-13 07:40:43

List of Learning Resources
by gouessej
2015-07-09 11:29:36 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!