Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (799)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (865)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 110 111 [112] 113 114 ... 216
  ignore  |  Print  
  What I did today  (Read 3551912 times)
orange451 and 1 Guest are viewing this topic.
Offline ShadedVertex
« Reply #3330 - Posted 2015-12-05 13:52:14 »

Would instanced rendering give the same results, instead of packing the different cubes into a single VAO?
Offline Phased
« Reply #3331 - Posted 2015-12-05 13:53:32 »

not sure never tried, but what I did was pretty simple implementation.
Offline ShadedVertex
« Reply #3332 - Posted 2015-12-05 14:01:06 »

Thanks, mate. All I was doing was splitting a huge list of blocks into smaller 18x18x15 lists. My chunk rendering system is half finished.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Icecore
« Reply #3333 - Posted 2015-12-05 20:40:33 »

Would instanced rendering give the same results, instead of packing the different cubes into a single VAO?
nope Sad

As i know:
Best performance you can get from packing all Blocks from chunk to one VBO
(and use it with one texture atlas (sprite sheet))
Faster alternative: only shader render: raycast or calculate VBO with textures on GPU side.

And we don't talking about LOD Wink

Last known State: Reassembled in Cyberspace
End Transmission....
..
.
Journey began Now)
Offline Slyth2727
« Reply #3334 - Posted 2015-12-05 22:29:39 »

Finished the SAT. Feel pretty good about it, but man am I mentally drained.
Offline SHC
« Reply #3335 - Posted 2015-12-07 04:36:10 »

Just in case, I moved my backups of JGO to a sub-domain. You can now access it here:

http://jgorecovery.goharsha.com/

Offline NegativeZero

JGO Kernel


Medals: 347
Exp: 1 month or less


Zero but not.


« Reply #3336 - Posted 2015-12-07 10:59:49 »

I've been messing around with fractals on shadertoy. Accidentally made a frozen over lake or something.

Please check it out, it looks much better with movement Cheesy

https://www.shadertoy.com/view/MdtGWH



EDIT: Slyth2727, did you just randomly medal my 10 month old post? lol

Offline theagentd
« Reply #3337 - Posted 2015-12-07 11:06:39 »

So, the good news is that I've managed to get dynamic atmosphere reflections working. I do this by rendering the procedural atmosphere to a low-res cube map and calculating a reflection vector for the water based on its normal. Here's an exaggerated night-sky to show the effect.



The bad news is that I sent a mail to the person who made this shader asking a bit about how to optimize it, and was promptly told that the shader was under a non-commercial license, which means that I will not be able to use the exact source code from the ShaderToy example. Obviously was an overlook on my end, but it's still a bit frustrating. In addition, the ShaderToy example doesn't look as well when zoomed out as I had hoped. Since the noise octaves are based on sin(uv + noise) the waves have a clearly visible grid pattern to it, which doesn't look good at all. The whole shader also proved extremely hard to optimize. The biggest performance issue came from how the normal was calculated by local differentiating (calculating 3 heights to get a gradient), which required a lot of heavy math. It was also difficult to precompute the expensive noise function as the hardware bilinear filtering only provides around 256 different steps between the filtered colors, causing the waves to stutter which in turn messed up the motion vectors (no motion for 3 frames, then pop -> entire thing is motion blurred for 1 frame). The noise function and the math itself was using an obscene number of sin() and cos() calculations, both for calculating noise and for the wave shape, and they're not particularly cheap on GPUs.

Since I had to rewrite the entire thing anyway, I decided to change the function to something that I could calculate the gradient of analytically or even precompute. I ended up going with an RGB texture with the height in R and the XY gradient in GB, allowing me to just sum up the gradients (modified for amplitude and frequency of the octave) to get the height and normal with just a few texture samples. I've experimented with getting sharper wave edges by modifying the noise texture and it kinda works, but I still haven't managed to reach the same quality as the original. At least it's fast as hell now.

The next step is recalibrating the colors again for HDR. Gonna try to get a similar colors to the original.

Myomyomyo.
Offline KaiHH

JGO Kernel


Medals: 766



« Reply #3338 - Posted 2015-12-07 11:19:26 »

A good pseudo-random number generator is this:
http://amindforeverprogramming.blogspot.de/2013/07/random-floats-in-glsl-330.html
Requires GLSL 330, though.
I am using it for generating random rays in my raytracer, where the tiniest patterns would be very very noticeable.
But unlike the very popular function with the "fract(sin(dot(...)))" - which apparently everyone is using - it does not exhibit any patterns at any scale of the input values.
Offline ags1

JGO Kernel


Medals: 367
Projects: 7


Make code not war!


« Reply #3339 - Posted 2015-12-07 11:49:57 »

I got Vangardians selling excess items in their inventory successfully with very lightweight logic. The only bug is they sell too many of their things but I can see an easy fix. I felt happy to see they applied my business rules consistently and sold stuff I hadn't thought they would need to.

For example, a Healer makes their cures and tonics by combining ForageBehavior, DoRecipeBehavior, GotoBehavior and SellStuffBehavior. ForageBehavior is configured with the items to forage for (weeds, beatles, toadstools...), and DoRecipeBehavior is configured with the appropriate herbalist recipes (strengthTonic, healingSalve...), while goToBehavior and SellStuffBehavior are truly generic and require no parametrization.

After fixing the little bugs, I will need to add the logic to buy needed items. Half the logic is there as characters keep track of a wishlist, so they just need to price up the most desired item and save accordingly. I will have to add in an escape hatch where characters can get into debt should they require an item that is essential for their career. For example, if a woodcutter has no money, and she breaks her axe, she would be unable to earn the money to buy a new axe...

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #3340 - Posted 2015-12-07 12:05:53 »

A good pseudo-random number generator is this:
http://amindforeverprogramming.blogspot.de/2013/07/random-floats-in-glsl-330.html
Requires GLSL 330, though.
I am using it for generating random rays in my raytracer, where the tiniest patterns would be very very noticeable.
But unlike the very popular function with the "fract(sin(dot(...)))" - which apparently everyone is using - it does not exhibit any patterns at any scale of the input values.
Interesting. Might try that, but I suspect performance is worse than the standard rand() floating around. Gonna run some tests.

Myomyomyo.
Offline Roquen

JGO Kernel


Medals: 518



« Reply #3341 - Posted 2015-12-07 12:09:40 »

@theagentd: That code shadertoy code is a mess.  Noise functions have an analytic derivative...no need to approximate.  Baking a multi-resolution noise into an atlas of corner wang tiles could be an option.

Quote
Uggh...that's horrible.  If you're going to use integers on the GPU and don't know what you're doing...use something statistically sound (and faster) that someone who does know what they're doing has already written for you.  (one-at-a-time was written in 97...the hash world has changed alot since then.  A 10 dep-chain 32-bit hash function is very long these days)
Offline KaiHH

JGO Kernel


Medals: 766



« Reply #3342 - Posted 2015-12-07 12:22:33 »

Interesting. Might try that, but I suspect performance is worse than the standard rand() floating around. Gonna run some tests.
Yepp, according to the author, the performance is worse than the fract(sin(...)) approach, but it has so far absolutely no visible patterns, which was the main concern for me. But according to @Roquen it sure can be optimized.
Offline theagentd
« Reply #3343 - Posted 2015-12-07 12:43:55 »

@theagentd: That code shadertoy code is a mess.  Noise functions have an analytic derivative...no need to approximate.  Baking a multi-resolution noise into an atlas of corner wang tiles could be an option.
I know, but there's an added layer where the input to a sin/cos-based function is based on both UV and noise(UV), so you'd need to do some f(g(x)) derivative magic to calculate it analytically. It's definitely doable, but again I can't use his code directly.


Uggh...that's horrible.  If you're going to use integers on the GPU and don't know what you're doing...use something statistically sound (and faster) that someone who does know what they're doing has already written for you.  (one-at-a-time was written in 97...the hash world has changed alot since then.  A 10 dep-chain 32-bit hash function is very long these days)
Well, what are you waiting for? Out with it! Tongue EDIT: And if you can't beat that hash function at speed, it still has its uses.

EDIT: It might be possible to optimize that noise function at the cost of some accuracy. Since we only use the lower 23 bits, wouldn't it be possible to reduce the accuracy even lower to 16-bit and compute it twice as fast by packing it into a 32-bit integer?

EDIT2: GPU ShaderAnalyzer says that hash function has around 65% more instructions (28 vs 17), but they also pipeline a lot less effectively on vector GPUs (26 vs 10 ALU clocks). That only matters on older AMD GPUs though. Gonna benchmark it in real life though.

EDIT3: In a real-life benchmark, computing 64 random numbers per pixel, the 2D hash-based random() takes over 3x as much time as the old sin-fract rand(). Comparison of noise quality: http://screenshotcomparison.com/comparison/153401. The biggest difference for the eye is that the new one doesn't have these awful horizontal lines of black and red pixels (if you look closely).

Myomyomyo.
Offline ShadedVertex
« Reply #3344 - Posted 2015-12-07 13:02:31 »

Are there any game engines like Unity3D and Unreal Engine made in Java? I mean, there's jMoneyEngine, which is more for people who actually know coding. But you don't need to know coding to make games with Unity3D and Unreal Engine, because engines like those just pamper you all the way. I'm planning on making a game engine like that: something with a visual workflow and something that's not necessarily for people who know coding.

EDIT: Sorry, I hate game engines like those, because they really do pamper you all the way, and I hate being pampered. Nah, I ain't gonna make an engine like that.
Offline Opiop
« Reply #3345 - Posted 2015-12-07 14:10:34 »

Are there any game engines like Unity3D and Unreal Engine made in Java? I mean, there's jMoneyEngine, which is more for people who actually know coding. But you don't need to know coding to make games with Unity3D and Unreal Engine, because engines like those just pamper you all the way. I'm planning on making a game engine like that: something with a visual workflow and something that's not necessarily for people who know coding.

EDIT: Sorry, I hate game engines like those, because they really do pamper you all the way, and I hate being pampered. Nah, I ain't gonna make an engine like that.
Oops, accidental medal...

There's this weird stigma around those game engines that I grew out of. I used to think "hah, those n00bz don't actually know how to make games! They don't code!". Which is partially true, a lot of the people that use those engines don't know much about programming. But then you go back to your IDE and hack away for the next couple days and you might have a new feature finished. And then you realize those game engines could have implemented that same feature for you in mere seconds.

Those game engines are targeted towards people who want to finish games. Some people just want to smash a game out with little programming, and that's fine! I enjoy building games from (almost) the ground up, so I don't use them. But if my company suddenly because EA2 and I was tasked to created Battlefield Bad Company 32, no way in hell would I be starting from the bottom with a simple graphics processing library like LibGDX.

I know it's hard to see it now, but those engines aren't "pampering" people. It's a strange mentality to see; New game developers thinking game engines "pamper" people. I think many of the more experienced game developers on here would agree with me when I say that developing a game from the ground up is much, much harder than using one of those engines (once you get the hang of them). So don't discredit those engines solely because you don't have to program much. Instead, rejoice because they exist and you have the opportunity to use them for free.

/Monday morning pre-coffee motivational/rant speech
Offline Roquen

JGO Kernel


Medals: 518



« Reply #3346 - Posted 2015-12-07 14:11:44 »

@theagentd: That code shadertoy code is a mess.  Noise functions have an analytic derivative...no need to approximate.  Baking a multi-resolution noise into an atlas of corner wang tiles could be an option.
I know, but there's an added layer where the input to a sin/cos-based function is based on both UV and noise(UV), so you'd need to do some f(g(x)) derivative magic to calculate it analytically. It's definitely doable, but again I can't use his code directly.
Getting into specifics would require carefully going over the code.  My rough suggestion is corner-wang tiles of some composed noise w/baked normals.  Compose 2 (or perhaps more for very quality levels) layers of this and combine the normal via one of the techniques used in applying a normal map.   There's also the option of using the glsl derivative functions...but I'm guessing that would be pretty noisy.  (https://dl.dropboxusercontent.com/u/55891920/papers/mm_sfgrad_bump.pdf)

Quote
Well, what are you waiting for? Out with it!
Too many use-cases.  In your case, I'm suggesting to move almost all of the work out of the pixel shader anyway, so it's moot.

On this specific example, you don't need to know anything about hashing for red-flags to start popping up:  "The way I combined the inputs is totally arbitrary and rather lazy.  I just experimented with them until I found something that worked on my test inputs." 

And if you know "a little bit" about modern hashing, it results in banging your head on the table:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
uint hash( uint x ) {
  x += ( x << 10u );
  x ^= ( x >>  6u );
  x += ( x <<  3u );
  x ^= ( x >> 11u );
  x += ( x << 15u );
  return x;
}

uint hash( uvec2 v ) { return hash( v.x ^ hash(v.y) ); }


Jenkin's one-at-a-time is modern in design.  hash blobs of data and then "finalize" when you're done.  The hash the author wrote is hash one 32-bit blob and finalize.  See the problem?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
uint hashInit(uint x) {
  x += (x << 10u);
  x ^= (x >>  6u);
  return x;
}

uint hashAdd(uint x, uint hash ) {
  hash += x;
  hash += (hash << 10u);
  hash ^= (hash >>  6u);
  return hash;
}

uint hashFinal(uint hash) {
  hash += (hash <<  3u);
  hash ^= (hash >> 11u);
  hash += (hash << 15u);
}

uint hash(uint v)  { return hashFinal(hashInit(v)); }
uint hash(uvec2 v) { return hashFinal(hashAdd(v.y, hashInit(v.x))); }
uint hash(uvec3 v) { return hashFinal(hashAdd(v.z, hashAdd(v.y, hashInit(v.x)))); }


Assuming I didn't screw up typing in post.  But it's not helpful.  Generalized hashing assumes 1D data.  It assume keys are not low entropy, although it does assume some chunks might vary by one  'value'.  So using a general hashing function for 2,3,4D data vary by counting (...,-2,-1,0,1,...) typically really sucks.  (Either has visible defects or is very slow if not both).

Fast n dimensional hashing on integer grid is tough.  

Is the penetration of GPUs that can perform integer ops at full-speed approaching the point where using integer ops is reasonable?  I haven't been paying attention.
Offline ShadedVertex
« Reply #3347 - Posted 2015-12-07 14:59:27 »

Are there any game engines like Unity3D and Unreal Engine made in Java? I mean, there's jMoneyEngine, which is more for people who actually know coding. But you don't need to know coding to make games with Unity3D and Unreal Engine, because engines like those just pamper you all the way. I'm planning on making a game engine like that: something with a visual workflow and something that's not necessarily for people who know coding.

EDIT: Sorry, I hate game engines like those, because they really do pamper you all the way, and I hate being pampered. Nah, I ain't gonna make an engine like that.
Oops, accidental medal...

There's this weird stigma around those game engines that I grew out of. I used to think "hah, those n00bz don't actually know how to make games! They don't code!". Which is partially true, a lot of the people that use those engines don't know much about programming. But then you go back to your IDE and hack away for the next couple days and you might have a new feature finished. And then you realize those game engines could have implemented that same feature for you in mere seconds.

Those game engines are targeted towards people who want to finish games. Some people just want to smash a game out with little programming, and that's fine! I enjoy building games from (almost) the ground up, so I don't use them. But if my company suddenly because EA2 and I was tasked to created Battlefield Bad Company 32, no way in hell would I be starting from the bottom with a simple graphics processing library like LibGDX.

I know it's hard to see it now, but those engines aren't "pampering" people. It's a strange mentality to see; New game developers thinking game engines "pamper" people. I think many of the more experienced game developers on here would agree with me when I say that developing a game from the ground up is much, much harder than using one of those engines (once you get the hang of them). So don't discredit those engines solely because you don't have to program much. Instead, rejoice because they exist and you have the opportunity to use them for free.

/Monday morning pre-coffee motivational/rant speech

Sure, I get it. It's just that those game engines aren't really meant for serious programmers, because I think a real programmer would appreciate having a challenge to overcome. Like you said, those game engine are for people who want to get things done without dealing much with the backend stuff (scripting, etc.) So it's for people who prefer admiring the result to overcoming obstacles during the creation process. I think a real programmer wouldn't care about the end result as much as the process; coming up with new algorithms, typing away for hours, drinking gallons of coffee to keep them going...that's the sort of thing programmers like. Game engines like UE4, Unity3D...they take that away from programmers. Well, not so much Unity3D, but Unreal Engine and Cry Engine? They just take away what it means to be a real programmer. But that's just my opinion. People who use those engines would definitely disagree with me.

Offline theagentd
« Reply #3348 - Posted 2015-12-07 15:10:04 »

@Roquen: It's pretty easy to use to analytically calculate the derivative. Then you can just sum up the height and derivatives of each octave, and finally calculate the normal as normalize(gradient.x, 1.0, gradient.y) (assuming Y is up). That's what I do now and it it's accurate. Using hardware gradients (dFdx/y) doesn't work since you get almost the same gradient in a 2x2 pixel quad, which causes the normal to look low-res.

GPUs have supported integer arithmetic at full speed since OGL3.

Myomyomyo.
Offline Opiop
« Reply #3349 - Posted 2015-12-07 15:21:32 »

Are there any game engines like Unity3D and Unreal Engine made in Java? I mean, there's jMoneyEngine, which is more for people who actually know coding. But you don't need to know coding to make games with Unity3D and Unreal Engine, because engines like those just pamper you all the way. I'm planning on making a game engine like that: something with a visual workflow and something that's not necessarily for people who know coding.

EDIT: Sorry, I hate game engines like those, because they really do pamper you all the way, and I hate being pampered. Nah, I ain't gonna make an engine like that.
Oops, accidental medal...

There's this weird stigma around those game engines that I grew out of. I used to think "hah, those n00bz don't actually know how to make games! They don't code!". Which is partially true, a lot of the people that use those engines don't know much about programming. But then you go back to your IDE and hack away for the next couple days and you might have a new feature finished. And then you realize those game engines could have implemented that same feature for you in mere seconds.

Those game engines are targeted towards people who want to finish games. Some people just want to smash a game out with little programming, and that's fine! I enjoy building games from (almost) the ground up, so I don't use them. But if my company suddenly because EA2 and I was tasked to created Battlefield Bad Company 32, no way in hell would I be starting from the bottom with a simple graphics processing library like LibGDX.

I know it's hard to see it now, but those engines aren't "pampering" people. It's a strange mentality to see; New game developers thinking game engines "pamper" people. I think many of the more experienced game developers on here would agree with me when I say that developing a game from the ground up is much, much harder than using one of those engines (once you get the hang of them). So don't discredit those engines solely because you don't have to program much. Instead, rejoice because they exist and you have the opportunity to use them for free.

/Monday morning pre-coffee motivational/rant speech

Sure, I get it. It's just that those game engines aren't really meant for serious programmers, because I think a real programmer would appreciate having a challenge to overcome. Like you said, those game engine are for people who want to get things done without dealing much with the backend stuff (scripting, etc.) So it's for people who prefer admiring the result to overcoming obstacles during the creation process. I think a real programmer wouldn't care about the end result as much as the process; coming up with new algorithms, typing away for hours, drinking gallons of coffee to keep them going...that's the sort of thing programmers like. Game engines like UE4, Unity3D...they take that away from programmers. Well, not so much Unity3D, but Unreal Engine and Cry Engine? They just take away what it means to be a real programmer. But that's just my opinion. People who use those engines would definitely disagree with me.


I'm not going to argue my point because you're allowed to have your opinion (obviously), but I just want to you to try to keep an open mind when it comes to these things. Sometimes a "real programmer" does not want to build things from the ground up, hacking away and drinking gallons of coffee. Case in point; most developers in a business oriented /money-earning setting. Hobby devs have the luxury of no deadlines (unless they are "self-inflicted") where professional devs do not, which allows the hobby dev to spend those precious hours building something from the ground up.

People get into programming for different reasons. Some people like the process, some people like the end result. Eventually, though, everyone wants to streamline the process and reach their goal in a smarter way. You'll get to that point someday and you'll understand then why "real programmers" also use game engines when they are the right tool for the job.
Offline princec

« JGO Spiffy Duke »


Medals: 1128
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #3350 - Posted 2015-12-07 16:01:59 »

In danger of veering into the chitchat monster ... what tends to rub some people up the wrong way is when people take these so-called "shortcuts" to end results but then get stymied by trivial problems that they could otherwise have solved if they had any deeper understanding of what they were doing, which they would almost certainly have gained by starting from scratch or at least working on the job for a few years. And that's not the bit that actually makes people grind their teeth - it's when said developers bother everyone else on the internet for answers. Continually.

The same thing happens with Plain Old Java. Programmers who have never had to deal with C have no real understanding underneath how a JVM might be working and subsequently are quite clueless in Java about memory allocation and garbage collection and how references work. It's irritating as hell but these days Java is the first exposure most programmers are actually getting to programming.

Cas Smiley

Offline Roquen

JGO Kernel


Medals: 518



« Reply #3351 - Posted 2015-12-07 16:17:35 »

@Roquen: It's pretty easy to use to analytically calculate the derivative. Then you can just sum up the height and derivatives of each octave, and finally calculate the normal as normalize(gradient.x, 1.0, gradient.y) (assuming Y is up). That's what I do now and it it's accurate. Using hardware gradients (dFdx/y) doesn't work since you get almost the same gradient in a 2x2 pixel quad, which causes the normal to look low-res.

GPUs have supported integer arithmetic at full speed since OGL3.

Yep...just tossing out some cheats that might be lower latency.  On int ops there's ogl3 hardware where int ops have significantly longer latency than FP.  Assuming I'm not misremembering.
Offline KaiHH

JGO Kernel


Medals: 766



« Reply #3352 - Posted 2015-12-07 17:03:32 »

...
You on an imaginary JGO back a few decades:

The same thing happens with Plain Old C. Programmers who have never had to deal with x86 assembly have no real understanding underneath how a processor might be working and subsequently are quite clueless in C about instruction scheduling and latencies. It's irritating as hell but these days C is the first exposure most programmers are actually getting to programming.

Wink
Offline princec

« JGO Spiffy Duke »


Medals: 1128
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #3353 - Posted 2015-12-07 17:37:49 »

And so it goes. Though as each step builds on the foundations of the previous step, the shakiness at the top gets worse the higher up the stack you go.

BWT I really rate Unity... but beware, it is a honey trap. Unless already well versed in game design, programming, project management, etc. you'll just end up with total mediocrity. It is really only a shortcut to rendering fairly nice stuff in 3D made easy, nothing more.

Cas Smiley

Offline Opiop
« Reply #3354 - Posted 2015-12-07 18:04:29 »

I agree you should have a foundation before you start using those tools, as with everything. I was talking to someone on Reddit the other day who was in complete dismay that I believe you should at least understand how basic file IO works in Java before using Apache Commons IO. He thought it shouldn't matter that you know how these things work internally, something I strongly believe the opposite of.

I just want to point out that 'real programmers' use the right tool for the job, and discrediting game engines simply because they provide lots of abstraction over a complex practice isn't looking at the tool with an open mind. Either way you go about it, game development is difficult. But so long as you know what you are doing, why does it matter how you reach the end result? I believe a 'real programmer' knows his/her programming theories very well because they have built these engines firsthand, but I also believe that they know how to use the right tool to get something done. Just because one way does not involve lots of 'grunt' work does not mean it's pampering said developer. That developer is utilizing what he/she has around them, which is smart.

Use whichever method you like, it really does not matter so long as you are satisfied but just keep in mind that that the idea of being a 'real developer' differs from person to person.
Offline J0
« Reply #3355 - Posted 2015-12-07 19:22:45 »

And so it goes.
WHAT IF I CODE DIRECTLY IN BINARY, HAH! Roll Eyes

Offline ClaasJG

JGO Coder


Medals: 43



« Reply #3356 - Posted 2015-12-07 20:03:30 »

https://xkcd.com/378/

-ClaasJG

My english has to be tweaked. Please show me my mistakes.
Offline Slyth2727
« Reply #3357 - Posted 2015-12-07 20:57:31 »

What am I doing with my life

Offline Icecore
« Reply #3358 - Posted 2015-12-07 21:20:16 »

WHAT IF I CODE DIRECTLY IN BINARY, HAH! Roll Eyes
It changes your understanding of usual things in programming
Like Java programmer that first time see unsigned value or multiply extend object,
or 2+ return values from function, or out of bounds function GO TO =)


Last known State: Reassembled in Cyberspace
End Transmission....
..
.
Journey began Now)
Offline wessles
« Reply #3359 - Posted 2015-12-08 02:09:46 »

@Slyth2727

Great things, that's what.
Pages: 1 ... 110 111 [112] 113 114 ... 216
  ignore  |  Print  
 
 

 
Riven (207 views)
2019-09-04 15:33:17

hadezbladez (4943 views)
2018-11-16 13:46:03

hadezbladez (1822 views)
2018-11-16 13:41:33

hadezbladez (5222 views)
2018-11-16 13:35:35

hadezbladez (1029 views)
2018-11-16 13:32:03

EgonOlsen (4406 views)
2018-06-10 19:43:48

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

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

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

nelsongames (4312 views)
2018-04-24 18:15:36
Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45
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!