Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (579)
games submitted by our members
Games in WIP (500)
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 ... 93
1  Discussions / Miscellaneous Topics / Re: What are Anti-Virus Developers Protecting us From? on: 2014-04-18 16:21:16
A few years ago I had a new laptop with Norton pre-installed.
I installed a perfectly legitimate copy of some software that I've used for years, and Norton thought it contained a virus so bad that it said something along the lines of it needing to disable itself and reboot in order to 'quarantine' it.
So the laptop rebooted, crashed on Norton again, etc. Did an attempt at removing Norton, which failed. The PC simply wouldn't work anymore until I did a fresh OS install.
I kid you not.

At work our PCs are so aggressively secured and scanned that no matter how fast the PCs are, everything is still slow.
Apparently a colleague opened an email attachment from a strange lady that admitted she was incredibly turned on by the poor fellow. Of course he got malware. True story. At least the virus scanner noticed, which prompted IT to wipe the PC and send out a mass email warning about these emails, which is something I suppose.

I use MS Security Essentials today. I don't know if it's actually doing anything but at least it's unobtrusive.
Just keep in mind that virus scanners just don't protect you from stupidity, and probably won't protect you from viruses either. And Windows isn't as unsafe as it used to be.
2  Game Development / Performance Tuning / weird thing with -verbose:gc on: 2014-04-12 12:58:31
So I with my audio project, I'm getting some glitching: it crackles every now and then.
CPU usage is about 15% of one core, so I thought maybe I'm generating garbage somewhere and enabled -verbose:gc.
It's the damnest thing: the glitching is gone completely with -verbose:gc enabled!

Does anyone have some explanation for that? I sort of expected more the opposite.
According to -verbose:gc, the GC never kicks in (unless I start moving stuff around in the GUI, but that's sort of expected)
Does -verbose:gc actually influence the GC's behaviour somehow?
3  Discussions / General Discussions / Re: The Big Linux Distro Thread on: 2014-04-03 21:07:15
Quote
I've not used a single Linux distro where the mouse was slick. Dunno what it is. Maybe they (the people who work on it) are so used to it they're not aware that it could be a lot better.

To be honest, I'm not sure what you're referring to. The mouse in Linux seems pretty much lag-free to me. I use windows more than Linux (because of work), but my GUI annoyances are pretty consistently with Windows.
But I always have the feeling that I have to click a lot more on Windows; places where I need to be either just require lots more clicking to get to, or are for some reason not responding to the mouse at all without clicking on them first. Stuff like that. Things that make Windows feel quite stiff and cumbersome to me.
Could it be that you've been unlucky with driver issues, while I've just been lucky there?
4  Discussions / General Discussions / Re: The Big Linux Distro Thread on: 2014-04-02 11:33:46
Ubuntu has been great and reliable for me (but I use it with Gnome, which I prefer over Unity. If you hate Unity, you could try UbuntuGNOME or install Gnome yourself on a 'standard' Ubuntu install).
No big problems with drivers or whatever, unlike on my Windows machines I have to say.

Never had stability issues with ubuntu's software repository either, although I do have to admit I always hold my breath with that dependency stuff because I tend to expect it to blow up in my face for some reason. Knock on wood, but it never did.
You can always manually install software, just like on win/mac (which I often do, especially when it comes to IDEs).

I dunno, I always have the feeling that Windows (every single one after XP) is working against me, instead of *for* me. It just seems so... I dunno... stiff, unfriendly, and increasingly imposing.
Ubuntu otoh, while not perfect, has pretty much always been smooth sailing for me. I hated it when they switched to Unity though, because I hate changes like that. But Gnome is nice.
5  Games Center / WIP games, tools & toy projects / Re: audio dsp (now on sourceforge) on: 2014-03-31 20:43:32
Quote
It's on my todo list to remove the distinction between Asio-IN/OUT and JavaSound-IN/OUT, and resolve the best audio implementation

This is done now; if Asio is unavailable for whatever reason (not running on Windows, not having Asio drivers installed), it should fall back to JavaSound.
But again, if you happen to run Windows, install Asio4All or the Asio driver that came with your audio hardware; it'll be better.
6  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-30 21:43:59
Ok, FWIW it's here: https://sourceforge.net/projects/jmodsyn/

Disclaimer: I know it's all rough around the edges and obviously it can be improved in many ways. At this point it's probably not all that useful for most people. Many will say the code is incredibly dirty.
It's basically my toy-project, but just see it as a bunch of code that might be useful one way or another.  If you want to know how you can implement a filter, pitch-shifter, chorus, reverb, etc: there's lots of code here.

If you want to try the editor, try running class org.modsyn.editor.PatchEditor. It will create a folder called 'ModSyn' in your user.home directory. You can copy the files in ModSyn-j2se/example-patches there for a few examples.
But please be aware: these examples depend on ASIO, so that's Windows-only and depend on you having an ASIO driver installed (if you don't: install ASIO4ALL, it works surprisingly well), and some patches use MIDI.
It's on my todo list to remove the distinction between Asio-IN/OUT and JavaSound-IN/OUT, and resolve the best audio implementation based on platform, whether or not you have ASIO installed (or another audio host that doesn't suck as hard as JavaSound) and configuration. Currently, JavaSound (Audio-IN/OUT in the editor) doesn't work at all in the editor.

With all that said, I'm actually using this for my own band so for me it's already useful Smiley. It's quite nice to have this box of tools available if your own synth or effects pedals or whatever don't quite support the sound that you're after. And it's quite easy to add more DSP objects to this box of tools.
7  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-29 20:55:07
small disaster  Emo

So I decided to upload my project to SF and created a project there.
I chose 'share project' in Eclipse, which then decided to completely destroy my workspace and remove 75% of everything.
So thank you Eclipse GIT team provider  Angry

My last backup is a few days old, so it'll take me a day or so to get me back to where I was.
8  Discussions / General Discussions / Re: 30 vs 60 vs 120 FPS on: 2014-03-24 22:33:07
I doubt that will ever happen.
Besides the obvious problem of what to do when you have multiple observers, you'd also need absolutely insane response times for the eye not to register the low resolution/quality peripherial areas when moving focal point.

Bypassing the eye entirely & patching into the optic nerve is the next logical step IMO, though I can't even begin to imagine how that would feel to the user.

With VR you only have one observer: The wearer of the VR headset, so no problem there.
Eye tracking is then also very close to the eyes, so it should be possible to make it quite accurate too using just small cameras.
And I think response times of eye tracking might be not as critical as you think. It should be at most the same as the screen's refresh rate, which is perfectly doable today. And your brain needs a bit of time to adjust to the new FOV anyway.
And what if it takes a bit of time for things to adjust to your new FOV when moving your eyes? It'll still be better than not adjusting at all.

It seems a lot more practical than 'patching into the optic nerve', imho (which seems to be disturbingly close to 'eXistenZ' territory  Shocked).
As a matter of fact I think it could be doable within a few years.

IMHO Moore's law isn't moving fast enough to get us to high resolutions running at above 60fps, so optimizing to what we actually see and perceive with our brain seems to have a lot of untapped potential to me.
9  Discussions / General Discussions / Re: 30 vs 60 vs 120 FPS on: 2014-03-23 19:46:24
I think if one day we'll have VR with working eye-tracking, high frame-rates will be a lot less computationally demanding. Even at proper resolutions for VR (like 4K or even 8K).

Your eyes only see sharply at just about 2 degrees. Outside of that it all quickly becomes a blur. You brain does the rest to make you think it's all sharp.

At a 100 degrees FoV at 8K resolution, that's like 88*88 pixels per eye that need the best quality rendering, and that's with 8K resolution (i.e. 7680*4320) .
Outside of those 88*88 pixels, you can increasingly (and quickly) drop resolution, AA, texture resolution, shader quality etc.
This might be a bit of an oversimplification, but I suppose even today's PCs should be able to handle that at at least 60fps.
But good eye-tracking will be key here.

[edit]
Furthermore, when you quickly look elsewhere by turning your eyes/head, your brain needs a bit of time to adjust and see things sharply and process what you see. Test it yourself by opening a book in a random page and see how much time it takes between reading a word in the middle of the left page and reading a word in the middle of the right page.
How long did it take? Half a second? That's like a week in computer time Smiley
So there are possibilities for optimization there as well.
10  Discussions / General Discussions / Re: 30 vs 60 vs 120 FPS on: 2014-03-23 19:06:07
The past TV (CRT) screens also had some natural smoothing between the frames because the former frame faded only slowly and blended with the next. It's been less sharp this way, but motions appeared smoother, and the screen flickering was less notable.

Computer screens always had less of this smoothing effect, I think intentionally, and needed higher refresh rates.

Are you sure about that? I always thought that CRTs had much faster response times and needed at least 100Hz to avoid flicker.
11  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-22 23:21:03
Ok, I've followed your advice and made the audio single-threaded. It seems to behave better when doing 'expensive' stuff in the GUI, so that's good.
Anyway, I think it's better this way because it's simpler and that's usually a Good Thing Smiley

I'm currently playing around creating a vocoder with this thing.
It's a good test of using MIDI, and Audio I/O together.
I don't have a proper spectrum analysis unit yet, so I'm working around that for now with band-filters and envelope followers, but it's starting to sound quite cool  Cool

Anyway, I think I'll move this to SourceForge or something soon.
I'm a bit nervous about it because I know there are issues in the code that many software architects would snuff at, and it's all very much just a WIP of a hobby project so I hope it won't attract too much attention at this point Grin
The 'core' part of it (the pure DSP part that doesn't depend on J2SE) I'm quite happy about though: It's simple and relatively clean.
12  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-22 17:41:17
Quote
@erikd - apologies if this is diverting your (forum) thread somewhat.

Not at all! Cheesy
I think it's all very interesting and I learn a lot from these discussions.

To be honest, multi-threading isn't really a concern for the time being but I can imagine at a later stage it might become useful to fork certain heavy tasks that don't require inter-thread communication. For example having complete voices of a polyphonic synth spread across multiple cores.
It might not be worth it now, but there is this trend of CPUs getting more and more cores so it's an interesting subject.

For now, I'll follow your advice and simply run everything off Asio's thread.
I do understand the implications of real-time audio, and my project has largely been developed with these idioms in mind, but to be honest I'm not really experienced with doing real-time audio stuff multi-threaded.

Anyway, I have made some progress in other areas Smiley
It's now possible to save a sub-selection of a patch as a 'meta'-unit. This might make things a bit more manageable when your networks get more complex.

I'm also busy with creating a higher-quality version of my main 'oscillator' unit to reduce aliasing.
What it does extra now is oversampling and filtering. Though rather expensive, it already sounds a *lot* better but at higher frequencies there's still a little bit of aliasing so there's room for improvement.
13  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-21 16:23:40
Are you suggesting that eventually using all those delicious CPU cores for fancy real-time audio processing will never really work and we'll be stuck in single-threaded land forever?  persecutioncomplex
14  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-21 14:27:08
Quote
The problem with doing that is that you'd need multiple wave-forms (possibly one per octave), otherwise when you pitch the table up you'll bring in aliasing, but when you pitch down you're missing more and more of the harmonics that give the sound its richness.
Yes, in hindsight it was a bit silly to even go that way  Roll Eyes

Quote
I'm intrigued by why you find a callback API trickier than a blocking one?  Also slightly concerned what you're meaning by "synchronize" things - I'm assuming not in the sense of locks!
It's not really trickier in itself; in fact it's easier. And yes, I meant synchronization in the sense of locks.
But the way it works now is that I have an object called 'Context' where DSP units are registered that need to be updated (for example to generate the next sample of an oscillator).
Then there is a thread that updates the Context. This was fine for blocking I/O such as javax.sound, but with Asio this needs to be synchronized with Asio's thread.

It might be cleaner to refactor this a bit so that the updating of the Context is regulated by the audio I/O units themselves instead of this separate 'I-know-nothing'-thread that blindly updates the Context. That way, no synchronisation/blocking is necessary anymore.
On the other hand, it works fine as it is now so I'm not exactly in a hurry there Smiley
15  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-20 21:42:34
A little update:
I have experimented with band-limiting the oscillators, but I've obviously been on the wrong track there.
The oscillators use pre-calculated wave-forms, and what I did was simply pre-filtering them. Sure it helps with aliasing at higher frequencies, but of course it also made it all sound quite dull.
I think the best solution there is to do real-time oversampling of the oscillators instead.
It might be a bit more expensive, but then again I haven't gone beyond ~2% CPU load of a single core yet (and that is while the CPU was running at about half speed), so I probably shouldn't worry too much about performance yet.

I have also worked a bit on making the editor a bit more manageable. Now you don't really have to add 'controller-knob' units anymore. Instead it will simply show knobs for all editable settings for the selected units at the bottom. Much less clutter!
The following screen shot is of the same patch as the last one (but now including soft clipping):
16  Discussions / General Discussions / Re: JDK 8 is released on: 2014-03-19 21:05:55
There is still an unfixed bug about lambdas when mixing them with anonymous classes, use them with care.

I'm not sure I follow. What is the bug that needs fixing?
17  Discussions / General Discussions / Re: JDK 8 is released on: 2014-03-19 20:19:16
But lots of new code will start using "lambda" expressions and that looks weird and alien and will require quite a bit of brain reprogramming until it's second nature. A bit like generics did.

This is the bit that slightly concerns me.
Generics turned out to be really useful, but lambda expressions seem to me more like making the syntax more compact but more difficult to read by taking away a bit of context.
I'm sure I'll be able to get used to them, but do lambda expressions actually offer more beyond that?
18  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-18 20:06:43
Thanks for the link Smiley

One of my main issues in the editor now is to keep things scalable from a usability p.o.v.

To give you an example, this is a fairly simple emulation of a funky clavinet sound with a resonant filter (think Stevie Wonder Cool) using Karplus-Strong for basic sound generation:

Not only is this mess a fairly simple patch, it's also monophonic. As you can see, things can quickly get quite unmanageable persecutioncomplex

At least I'll have to create some way to collapse a selected network of units into 1 'meta-unit' that can be reused.
And then to make synths polyphonic, I'll probably need to create some specific interface for such a 'meta-unit' so that I can simply duplicate them into multiple voices that can be driven by a polyphonic set-up.
19  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-18 19:22:05
Currently the oscillators are not band-limited so unfiltered you can get some aliasing, but it's on my to-do list.
I'm not sure yet how I'm going to implement that. Perhaps pre-filtering the waveforms, or maybe simply oversampling and/or averaging is enough?
There are various waveforms though (sine, triangle, block, saw and more) and there is a pwm input.

Quote
Am curious, what size buffer are you using in passing audio from one unit to the other?
I'm not buffering anything.
My interface for a SignalInput is
void set(float signal);
and for a SignalOutput, it's
void connectTo(SignalInput input);

So I'm basically simply passing single floats around.
In the units that handle external I/O such as javasound and Asio there is of course some internal buffering, but implementation details like SourceDataLine etc are hidden in such units to make the 'core' of it independent on J2SE-specific APIs like javax.sound.

Quote
Also curious, have you been able to get these tools to work on Android or iOS?
I have done some audio processing on Android (although not with this particular project), but I found that latency is an issue there so for this project I didn't get into that yet. I don't have any iOS devices, but it seems that iOS is more suitable for musical low-latency applications.

Quote
Are you using any native code or any libraries other than javax.sound?
I'm using JAsioHost on Windows because unfortunately javax.sound has way too much latency there. Asio uses a pull-mechanism rather than blocking I/O, so it was a little bit more tricky to properly synchronize things, but you can really have good latency numbers there (about 2.5ms in Asio instead of ~150ms in javasound). I found that using Asio, you can even use it for real time guitar effects with virtually unnoticeable latency.

As an aside, a good source of information is www.musicdsp.org for this sort of thing.
20  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-14 19:20:57
Quote
Partly as I said around sample banks, etc.  If you're using a range of samples stored in memory, ideally you want them loaded up and ready to play instantly (ie. probably in the data format of your pipeline).  Doubling the memory overhead here can be a problem.

Ah, I see what you mean. I'm not using sample banks atm but I can see how that can impact things.
I suppose you can always have them in memory in a smaller data format  Grin

The only places where I store signals in memory now is in buffers for delay lines and such, but even there I could imagine it could more quickly lead to cache misses.

As an aside, I got MIDI working now. I just patched myself a super-dirty dual-osc analog synth for giggles Cool
Things are quickly getting complex though. Just this simple monophonic synth has the screen filled with dsp blocks already.
I'll have to start thinking about the option to create 'meta-blocks' or something (i.e. collapsing a whole network into a single DSP block)
21  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-14 17:23:57
However, the thing that swung me was memory usage, particularly because of using things like in-memory sample buffers.  Also the IO that offers floating-point is likely to be 32-bit I think (not sure on ASIO).

I remember reading somewhere (think CSound docs) that around 6 chained DSP operations can lead to audible differences between 32bit and 64bit signal paths, though depending on the algorithm the number of operations might be higher.  To me it justifies double precision where necessary, but not necessarily double precision throughout.

RasmusDSP (an old project by the author of Gervill in the JRE), is the only Java audio project I'm aware of that uses doubles throughout.

Hm good point about memory usage, I haven't considered that yet. But what sort of memory usage are we talking about here that made you go back to float?
My consideration for using doubles is not necessarily for sound quality, but sometimes you need doubles in algorithms where high precision does make an audible difference (for example when there's a lot of feedback involved). So I thought if performance will be the same anyway, why not use doubles everywhere and forget about precision concerns altogether? It'll be simpler, and I like simple Smiley
Asio is indeed 32bit float, but that would then be the only place where a down-cast is necessary, so I think that would still be cheaper than casting multiple times in your audio chain.

I should probably just test it out.

Quote from: twinflyer
I don't know if it's possible ATM but you could think of a random function to make a simple sound sound different everytime it's played due to random pitch or other effects.
There are noise generators, so that should be useful there probably. And it's very easy to add new dsp blocks.
22  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-14 13:50:52
Regarding opening it up, I think it's a bit too early for that as I'm still tinkering with the general design of it so some things might change drastically in the near future.
The editor is sort of in the prototype phase.

One basic thing is that currently all signals are floats, but I'm considering making it all double. I think it shouldn't negatively impact performance on a 64bit system, and in fact it might even improve since I already use doubles in various places where precision is important so there's already quite some casting going on.
23  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-14 13:22:01
Wow that PraxisLIVE looks fantastic! I'll have to try that out.

Thanks for the hint regarding JAudioLibs; it definitely looks very usable for this.
24  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-14 11:41:28
Nice link, BurntPizza!
I love how Minecraft and Little Big Planet made the list Smiley
25  Games Center / WIP games, tools & toy projects / Re: audio dsp on: 2014-03-14 10:43:35
I've just uploaded a very early demo to play around with.
It's all still quite rough, but it sort of works.

Some pointers:
- You can't yet drag from the left-hand menu: You have to double click on it and it will appear on the top left of the workspace.
- Asio IN/OUT obviously only works on windows if you have audio hw with Asio support (or have Asio4All installed). On other platforms you use Audio In/Out (i.e. JavaSound) instead.
- Connections are always made by dragging from an output (i.e. right side of a DSP block) and dropping on an input (left side).
- To disconnect, drag a connected output on the off it and on the workspace.
- The Keyboard component simulates a piano keyboard on your computer keyboard, but you have to give it focus (i.e. click on the button in the center of the Keyboard block).
- MIDI IN is untested at the moment (I will work on that today).
26  Games Center / WIP games, tools & toy projects / audio dsp (now on sourceforge) on: 2014-03-13 21:26:24
Ok so this isn't strictly gaming-related, but it could be useful as a tool in gaming projects for generating and processing audio.
What I'm working on is a software synthesizer/audio processor. Actually it could be used for any digital signal processing, but my focus is on sound here.
The idea is that you can drag-and-drop DSP objects to your workspace, connect them as you like, and as such create your own sound generators, effects and whatever you can come up with.

Here is a screenshot:


So what you're seeing here is a network of digital signal processors (in this example, it's an 'auto-wah' effect that actually sounds quite funky with a bass-guitar).
You can just drag-and-drop components from the left-side, and connect them together as you please to create your own sounds and save them as XML.
There are actually many more DSP components already there (delay, FM synthesis, reverb, phaser, chorus, wave-shaping etc), but I just need to add them to the left-hand menu to make them available in the editor.

Although I'm mostly focusing on musical applications for this at the moment, I think it could be useful for real-time audio processing in games as well. For example a reverb effect that adjusts itself to the area the player is in. Well, whatever you can think of. Anything that surpasses simply playing back samples I suppose.

If there is enough interest in something like this, I'm considering to make this an open source project (otherwise it'll just be my own toy).
27  Discussions / Miscellaneous Topics / Re: Have you seen this? (real-time raytracing) on: 2013-11-01 18:58:02
Quote
They didn't implement noise. That is what happens when you under-sample using raytracing.

They explained on the blog that there is what they call a 'russian roulette-like mechanism' going on for the more demanding rays when needed to keep it running at 30fps, and that on faster machines there's less noise.
So while true that this results in under-sampling for those pixels, there seems to be a random element implemented there on some level (unless I misunderstood something).
28  Discussions / Miscellaneous Topics / Have you seen this? (real-time raytracing) on: 2013-10-30 20:02:37
http://www.youtube.com/watch?v=pXZ33YoKu9w

Real time ray-tracing on the GPU, quite amazing!
Interesting also how they implemented noise to keep performance up under stress.
29  Discussions / General Discussions / Re: Solving aliasing - noisy rendering on: 2013-08-19 21:48:00
Also, thanks for the feedback BurntPizza and Several Kilo-Bytes (I fixed the link)  Smiley
30  Discussions / General Discussions / Re: Solving aliasing - noisy rendering on: 2013-08-19 21:43:50
Thanks Spasi, that was very informative.
To be honest my knowledge isn't that deep about this stuff on a low level, so I don't want to pretend I have thought of something nobody else had that will change the world (apparently I even confused MSAA with SSAA to begin with).
This was just an idea that I had based on the basic premise that lack of bandwidth should 'naturally' incur noise on all levels instead of simply settling with a fixed distortion of the whole image.

But apparently this can not really be implemented through the existing APIs. Perhaps on the driver level?

I know about the temporal jitter technique (I think it's also used in MGS4 and DMC4), but it's not quite what I was looking for; I'd really prefer this to be per pixel, and without involving blending the complete frames.

Quote
Also, since multiple coverage samples won't improve anything within the triangle, GPUs can afford to apply MSAA only to the triangle edges
Does this actually happen in practice somewhere (considering how expensive MSAA still is)?
Pages: [1] 2 3 ... 93
 

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

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (31 views)
2014-04-15 18:08:23

BurntPizza (28 views)
2014-04-15 03:46:01

UprightPath (43 views)
2014-04-14 17:39:50

UprightPath (26 views)
2014-04-14 17:35:47

Porlus (43 views)
2014-04-14 15:48:38

tom_mai78101 (64 views)
2014-04-10 04:04:31

BurntPizza (124 views)
2014-04-08 23:06:04

tom_mai78101 (224 views)
2014-04-05 13:34:39

trollwarrior1 (190 views)
2014-04-04 12:06:45

CJLetsGame (198 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!