Today I'd like to present a project I develop from time to time since several years now : JavaGL (yes, again another one !) . It's a little library of graphical functions between the render API and the 3D engine.Actually, firsly the application possesses a 3D software render system based on the OpenGL model and providing its main functionalities : render parameters (perspective, clipping planes, cullfacing), spatial transformations (rotation, translation, scale, pushMatrix/popMatrix), basical materials (diffuse color, shininess, wire-frame/solid faces), dynamic light, primitives display (triangles, lines, bitmap sprites), etc...Secondly, above this are built some higher level functionalities touching numerous domains : skeletal animation, collisions/physics, file loading (OBJ and Milkshape3D ASCII), scene management, real-time game management (maps, sceneries, entities, events, pathfinding), etc...

I have to specify that the goal isn't to compete with 3DZZD or jPCT which are fantastic engines based on an emulation of graphic chipsets. The purpose is instead to come back to an old-school 3D, like on Atari ST for example, when material acceleration or display buffers didn't exist. So there's a lot of lacks, like the lack of textures, but also a few advantages like allowing large screens without (too many) loss of performances.

And so I announce proudly the release of JavaGL V0.8 !

This version isn't a revolution compared to the last one but corrects its main defaults and provides new functionalities that I learnt to implement since 1 year of Flesh Snatcher .

The improvements :- Timer in nanoseconds (-> JavaGL is now compatible Java 1.5 and + )- Correction of a bug on gravity- Correction of a bug on multiple collisions management- Correction of a bug on bounce management- Correction of a bug on Milkshape3D animations loading- Detection and correction of possible collision errors- Total prevention of file loading crashes- Duplication functions of all the data structures (from the vector to the full game map)- Control of "cleanness" of the BSP trees- Lines display optimization

That's all folks ! The goal of this version is to gather the max possible functions to make a game like Tesseract in a minimum of code. As the lib manipulation can be different of "regular" engines, The accessibility is also a priority with simple functions (I hope so), and a set of demos/tutoriels integrated to explain the most disconcerting features. Finally, pedagogy is also an important aspect of the project (for me in first !), so the code is provided under GPL to allow to developers to criticize the "weirdnesses" I commit, and allow to everyone to comprehend more classical algorithms.

@ReBirthHey, thank you ! I hope they make you wish to play a little with the sources .

@sproingie and ra4kingHa ha, that's a good question ! At the beginning it was to have a good grade in my ingeneer studies , and I loved the idea to program graphical apps from A to Z. Then, as I added functionalities, the software renderer became a feature amongst others, the lib could be used for other reasons (for example I use it in my FPS Flesh Snatcher for math or collisions), so I continued to maintain it.And now, with the "retro" wave that grows up, I think maybe it can be useful to someone (to make, for example, remakes of first 3D games, etc... without using heavy engines).And finally, I must say I believe in the future of software rendering, with projects like Larrabee (infortunately abandoned) the graphic chipset will disappear and maybe the door will be opened for other kinds of 3D . Yeah, javagl accelerated by 32 dedicated CPUs, that would rock ! (Ok, I go back down...)

@Mads and ra4kingThank you ! For the permission, yes I had to sign the jar (the same for all demos) just because of this damned class Robot I use in the "terrain generator", grrr !

And finally, I must say I believe in the future of software rendering, with projects like Larrabee (infortunately abandoned) the graphic chipset will disappear

FYI: the Larrabee was a graphics chipset: it had texture units, but ignoring that, I'd say: unlikely in the next decade. Dedicated hardware will always be faster (or have a more acceptable efficiency) than general purpose hardware.

Some day general purpose hardware will be 'fast enough' for realtime photon mapping. Let's say performance doubles every 18 months (Moore's Law says transistor-count doubles, but what the heck). In 10 years we'll have 2^(10 / 1.5)=~100x the performance we have today on our CPUs, so these futuristic CPUs will still be slower than current GPUs. Needless to say GPUs will advance too, and looking at the performance growth in the last 5 years, their performance is accelerating faster than that of CPUs.

My guestimate is 50 years from now, but until then, keep writing software-rasterizers, if only because it's so much fun

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Moore's Law is about commercially-viable CPUs. I'll take quantum computing serious when it becomes Turing Complete and can perform actual real-world tasks, as opposed to 'we know all answers before we finished the calculations, but we're struggling to feed it a question and selecting the answer(s) we care about'. *ramble ramble*

From TFA:

Quote

But physicists still can’t agree on whether a quantum computer can actually be built.

*ramble ramble*

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Hmm, very interesting, Riven...Maybe the modeling of photons behaviors isn't the only way to use general hardware. maybe we can imagine kind of compromises (improved raycasting, I don't know)... I see that the power of GPUs is used more and more to make other operations than the classical textured triangle rendering : various shaders, GPGPU, complex illumination, etc... Maybe something new will emerge from that...

@ra4king

Quote from: Riven

keep writing software-rasterizers, if only because it's so much fun

Exacty ! The main reason to make that : there's a guilty pleasure to do "as" the hardware developers from your bedroom .

I believe that software 3D engines do have value. While specialized graphics hardware can do great things it always misses out on unique graphics styling that takes away from many game possibilities. I expect some cheap hardware of the future will not have a 3D accelerated graphics chipset.

Looks like it lacks sub-pixel accuracy...apart from that, i always appreciate some good old software rendering...

Regarding the "who needs this?"-discussion: People are still using software rendering these days. I don't know the exact reasons, but they ARE using it. If that wouldn't be the case, i would have removed the software renderer from jPCT some time ago. Instead, i had to extend it recently because some user was missing a feature.

@gouessejHa ha, Julien, I see you behind your little medals ! I know we had lively debates about this lib but I thought you finally appreciated tesseract...

I have always said this project is mainly useful for pedagogical purposes. If you have fun developing it, just go on but don't expect from creating the next replacement of OpenGL. I agree with ra4king and Riven, you cannot make something faster than hardware rendering, GPUs will go on becoming faster as time goes by and they have been used in mobile phones for more than a decade through M3G and JOGL-ES (which has been integrated in JOGL 2.0). Raytracing can be done on GPUs with shaders and it is more efficient than those solutions based on software rendering even on a PS3 (25 FPS just to display a car, the floor and some buildings).

How do you want to target low end machines with software rendering? As there are fewer Celeron 700 Mhz used nowadays, the CPUs will allow you to display much things but 3DzzD has still one of the fastest software renderer, some people claimed it was a fake software renderer until its author open sourced his code under LGPL.

Some people are still using software rendering in Java because it doesn't require signed code, it is a nice alternative to WebGL (which is particularly slow on all machines I tested) for moderately complicated scenes. However, a very few games are using it except Tesseract (whose gameplay is really nice). This game would have been slower with full 3D models. Some people don't want to simplify their models to use software rendering, you have to face it.

Anyway, applets are being killed by Apple, Google, Mozilla and Microsoft, they just use the security concerns as an excuse whereas Silverlight, WebGL and Flash have security flaws too. Therefore, regarding the "who needs this?" discussion, I see fewer people than before because I don't see the interest of software rendering in heavy clients as it seems easier for me to get user permissions for such applications.

To jump into a thread hijack. Software scanline rendering is dead and will remain dead. amen. Moves toward less special purpose hardware rendering will occur...but that's a different animal. (Actually this has been going on for awhile anyway)

@gouessejOh yes, I know all you said, and I agree in majority, I just want to specify I don't want to replace OpenGL at all !And according to your position on software rendering, I don't really understand why you "defend" 3DzzD, it's favouritism !

Quote

some people claimed it was a fake software renderer

C'est petit, c'est mesquin ! (sorry for french )However, what do you mean by lack of full 3D models in tesseract (btw thanks for gameplay ) ?

@QuarryThank you ! As said by gouessej, there won't be textures . I limit the project to make retro games like Carrier Command on Atari ST or StarFox on SuperNES (ah, memories !).

@ReBirth

Quote

I believe the OP will keep on style, no texture.

Ah ah ! That's my point of view.

Concerning IE, I just specify javagl isn't made excusively for applets .

PS : it seems there was a viewport problem in the demos sequence, I just fixed it, enjoy ! (and now only the "terrain generator" needs permission)

And according to your position on software rendering, I don't really understand why you "defend" 3DzzD, it's favouritism !

3DzzD supports both hardware accelerated rendering (JOGL) and software rendering, it is still compatible with oldest and most crappy JVMs, its author has really done a great job, it's highly optimized.

Indeed it is user experience optimal to choose what's good for them. If their running IE (just 25-50% of browsers depending on whom you believe) pop up a "Best experienced in XXX browser".

The fun part of writing webapps professionally is that you have to support IE since so many of your customers force their employees to use it. Thankfully cross-platform Javascript frameworks have gotten pretty good, otherwise my head would explode.

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