With that out of the way, I need to ask: Do you ever feel like java limits you? Do you ever need to go even lower level? Can you think of any times where someone needs to go deeper? I was wondering, since I read up on native methods, and thought about why you would need to go deeper. I mean, LWJGL has to go deeper (using OGL on the graphics card), right? Lastly, how would you 'go deeper.'

GLOSSARY'need to go deeper' - Inception reference. Here, it would mean going lower level, but still using java.

There are also languages that don't do as much for you as java, but are arguably a little more customizable. C comes to mind. I will say however that I started learning programming in C++ and rapidly switched to java as I find it easier to use... Though I admit, they're really the only two languages I've touched.

Yeah, you don't really have to work hard to go deeper in Java. We have all the power of C by just using a few wrappers. Going any deeper than C ends in assembly... so yeah. Java works and is good enough for me.

With that out of the way, I need to ask: Do you ever feel like java limits you? Do you ever need to go even lower level? Can you think of any times where someone needs to go deeper?

In the past I wa using C++ and coded low level routines like graphics and texture mapping/shading myself. But nowadays hardware got so fast,the Hotpsot compiler got better, and there are good libraries available, so that Java has become quite sufficient for my needs.

I have a few legacy projects in C and C++ but I really don't like that anymore.

I'd like stack allocated instances and something similar to C struct arrays (without the overhead of MappedObject). Stack allocated instances allows you to write much nicer vector math code without creating a mountain of garbage. C-like struct arrays would allow you to get much better memory locality and is also useful for uploading vertex data to OpenGL. Those are the only two features I'm missing at the moment...

Native code is mostly needed to interface with native APIs or when you need to be closer to the metal for speed. You could see libgdx for an example. Eg, it uses native code for the Box2D wrapper. The native code is inline with Java code using a tool called gdx-jnigen, which is pretty damned neat. See JGLFW for more gdx-jnigen code. Another example is Matrix4 which uses native code for speed. This is mostly not an issue on the desktop though, where it is unlikely you'd need native code for speed unless doing something pretty specialized. Using gdx-jnigen is a waaaay nicer approach to writing native code. Not only is it inline with the relevant Java code, but the multi-platform build for is handled for you. Building is just running a Java main method and you're done.

Different kind of answer: I've never had to do it (except for using libraries such as LWJGL for reasons already stated), but if I had to "go deeper" because after thinking long and hard about it I reason that it is the best way to go, I would do it.

On the contrary, I sometimes feel, I am too deep and the things I do could have been abstracted a bit more.

Ever tried out functional programming?

Actually yes, I've used Haskell, took a bit of getting used to, to get the mindset right. In the end I decided that the imperative programming suits my thought patterns better. I might try again, just for beer&brezels.

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

On the contrary, I sometimes feel, I am too deep and the things I do could have been abstracted a bit more.

Ever tried out functional programming?

Actually yes, I've used Haskell, took a bit of getting used to, to get the mindset right. In the end I decided that the imperative programming suits my thought patterns better. I might try again, just for beer&brezels.

Yes. It's about changing the way you think. Learning functional programming is like learning programming from scratch again, it's completely different. But now that I learned haskell I've found many problems to be solved in a more elegant way than in imperative programming

Last time I remember I had to go "deeper" was when I was trying to find out the display rotation angle. My search eventually lead me to conclude that it was a bit of info that had been left out of the Java implementation, and could be reached by JNI... Which lead to C++, platform dependent code, learning the Windows / Linux way of finding that information, etc...

But it was a very specific case, and hardly critical.

My opinion on the matter is that if the tool/API/language you're using makes you need to go "deeper" very often, then it's probably not what you need to be using.

Yes, assembly.I've messed with it, done some stuff with gdb and a C program to get a feel for the processor calls, and just confused myself. It's interesting stuff and I really want to learn it, so yes I do want to go deeper (but I don't feel like Java limits me), but I simply don't have the time with all the activities in my life :/

Yes, assembly.I've messed with it, done some stuff with gdb and a C program to get a feel for the processor calls, and just confused myself. It's interesting stuff and I really want to learn it, so yes I do want to go deeper (but I don't feel like Java limits me), but I simply don't have the time with all the activities in my life :/

I did that for years; I ended up gaining a whole lot of knowledge I don't really apply nowadays. There is so much relevant stuff to learn, I would spend my time on that first unless you are really looking for a complicated hobby for which there is little tooling to make your life easier

Its cool to understand how game developers had to do it "back in the day" of course.

On a technical level, no. I prefer not to go deeper.On a design level, yes. I want to be perfect.On a gameplay, yes. I want to play to the best I can.On sex, yes indeed.Lucid dreams? Oh yes.Programming? Not unless you're really committed to doing things from scratch. (I wished that's the case for me.)Anything else? If time and interests are allowable, yes.

It's no fun anymore with current processor architectures. But as you said, at times it's good to get a feeling for what is really happening "under the hood". Still I wouldn't recommend learning assembly anymore these days. Better leave that to the compilers and code generators.

It's no fun anymore with current processor architectures. But as you said, at times it's good to get a feeling for what is really happening "under the hood". Still I wouldn't recommend learning assembly anymore these days. Better leave that to the compilers and code generators.

I never learned assembly that way. Well, I don't know assembly of current processor architectures either ^^

I learned assembly - or better: whats really happening "under the hood" - by using logisim, a logic simulator, where it's possible to build and simulate almost every logic circuit, including simple CPUs. Combining knowledge from minecraft and a couple of youtube videos I was able to build some CPUs. It's one of the experiences I'd recommend the most!

If one were to go assembly and wanted to go even deeper than that, I would encourage that person to go emulate a hardware device.

As far as I know, there's only one famous person who has ever achieved that: Martin Korth, the creator of no$gba and other no-cash programs. The reason he's famous is due to the fact he single-handedly wrote an assembly program that emulates Nintendo DS on a near-perfect accuracy back in 2006, which is the only emulator capable of playing most commercial games on old operating systems and old hardwares, such as MS-DOS.

Java has limits, not only in the question how close to the iron you can get, but also in some other areas.

C++ has less limits, but it has a whole lot of traps for programmers. I keep being told, that skilled programmers will learn to avoid them, but I find my productivity with Java being conatntly higher than with C++. For me, one of the reasons for higher produzctivity is that fact that Java has limits. These limits streamline the way of development to some extend, and make it easier to read and maintain code, also easier to find bugs.

If you ever had to work with a piece of C++ code where magicians went rampant on template and overloeaded operator use, macros and obscure syntactical tricks in the preprocessor, you know why the limits in Java are good.

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