Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (568)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3
  ignore  |  Print  
  Will JOGL use Java 1.5 features like typesafe Enum  (Read 7794 times)
0 Members and 1 Guest are viewing this topic.
Offline Bombadil

Senior Member





« Posted 2004-10-02 04:23:54 »

The JDK 1.5's enum doc tells some nice old truths like: typesafe, namespace, etc.
I see many occasions JOGL could use this.
For example it would hinder the developer to give the wrong const int parameter to many methods which need some int constants (enums). Compile error instead of runtime errors.

Will JOGL support this in the near future?
Offline MultiMike

Junior Newbie





« Reply #1 - Posted 2004-10-02 05:22:10 »

I think it would be murder for JOGL to use enum, because it's not supported by all JREs out there. Many people are still developing for 1.3.

/Mikael
Offline abies

Senior Member





« Reply #2 - Posted 2004-10-02 07:21:34 »

JOGL is autogenerated, so it would not be a problem to have separate version for 1.5. If you use other 1.5 functionality, having 1.5-specific version of JOGL does no harm.

I was thinking about it some time ago and done some checks - but as far as I remember, it is quite hard to do. Most of opengl calls have very broad parameter lists - and many, many constants would have to be duplicated in multiple enums. Aditionally, all possible extensions for given function would have to be put inside same enum.

One of benefits in addition to type safety would be better logging - currently, enums have to be logged as numbers in trace file, because multiple things have same number. With enum objects, trace could just print out enum name.

Artur Biesiadowski
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zingbat

Senior Member




Java games rock!


« Reply #3 - Posted 2004-10-02 12:08:13 »

Quote
I think it would be murder for JOGL to use enum, because it's not supported by all JREs out there. Many people are still developing for 1.3.

/Mikael



Ignore them. They can use Java3d for other type of applications besides games. JOGL is for making games and game programming requires constant updates to use the latest features.
Online princec

JGO Kernel


Medals: 392
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2004-10-02 13:21:23 »

We eventually ditched this idea in LWJGL for two good reasons:

1. Enums are objects. Pass them into native code and you have to deference them and call a method on them to get some value out. What a pain in the arse.

2. Many OpenGL extensions, when present, effectively change the set of allowed values to functions, thereby rendering the concept of compile time checking totally irrelevant.

None of the OpenGL constants are redefined anywhere by the way. AFAIK, all values are unique in name but overlap in usage.

So in short - don't try this, because it won't work.

Cas Smiley

Offline zingbat

Senior Member




Java games rock!


« Reply #5 - Posted 2004-10-02 19:33:15 »

I don't know about that. I think they should not limit themselves only with enumerations but also use generics and the new loop facility. EnumSets and EnumMaps work very fast.

Quote

1. Enums are objects. Pass them into native code and you have to deference them and call a method on them to get some value out. What a pain in the arse.


Why would they need to call a method to get the value ? Enumerated values are objects so they only need to compare references instead of ints.

Quote

2. Many OpenGL extensions, when present, effectively change the set of allowed values to functions, thereby rendering the concept of compile time checking totally irrelevant.


Think Java. You can extend Java enumerations i think.

Quote

None of the OpenGL constants are redefined anywhere by the way. AFAIK, all values are unique in name but overlap in usage.


Again thats a C problem.
Online princec

JGO Kernel


Medals: 392
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2004-10-02 21:56:04 »

It's not a problem, it's just the way it is, and the way it's designed. OpenGL is a C API, and if you try to make it Java-ified it won't go. I'd love typesafe enum args but the plain fact is that you don't know what values are allowed in any functions until you know what extensions are available in a particular context, which you can't know until runtime.

The usage overlap is an advantage rather than a disadvantage. It means that given a particular int value you can always decode it to the same human-readable value.

Quote
Why would they need to call a method to get the value ? Enumerated values are objects so they only need to compare references instead of ints.
At some point you have to pass an int to the C APIs.

Cas Smiley

Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #7 - Posted 2004-10-03 00:42:50 »

Quote
Ignore them. They can use Java3d for other type of applications besides games. JOGL is for making games and game programming requires constant updates to use the latest features.  


What an arrogant attitude to take. Do that and watch your target audience for potential developers vanish in the blink of an eye.  All those thousands of developers currently developing using J2ME for phones will go, all the developers doing servers for games will go. All of us doing multiplatform software will go. There'll be you and two others using JOGL and it will die a very quick death.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline zingbat

Senior Member




Java games rock!


« Reply #8 - Posted 2004-10-03 07:40:29 »

Quote
It's not a problem, it's just the way it is, and the way it's designed. OpenGL is a C API, and if you try to make it Java-ified it won't go. I'd love typesafe enum args but the plain fact is that you don't know what values are allowed in any functions until you know what extensions are available in a particular context, which you can't know until runtime.

The usage overlap is an advantage rather than a disadvantage. It means that given a particular int value you can always decode it to the same human-readable value.

At some point you have to pass an int to the C APIs.

Cas Smiley



What you are saying makes some sense. But still it could not be such a big impact after doing some tests. The most limitating part of a game is rendering huge amounts of poligons and shading them. It may depend on the method used to set up the scene before being rendered. It could still be good to give it a try and actualy test this stuff.
Offline zingbat

Senior Member




Java games rock!


« Reply #9 - Posted 2004-10-03 08:00:36 »

Quote


What an arrogant attitude to take. Do that and watch your target audience for potential developers vanish in the blink of an eye.  All those thousands of developers currently developing using J2ME for phones will go, all the developers doing servers for games will go. All of us doing multiplatform software will go. There'll be you and two others using JOGL and it will die a very quick death.



You must ask yourself if you want Java games to compete
for the same market where C++ developers are already established. Thats the several million dollars market that gets you the money.

Forget about staying compatible with old versions of the language. This is a very bad strategy for Java games development on the big bucks market.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online princec

JGO Kernel


Medals: 392
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2004-10-03 09:33:42 »

I'd like to agree there too... except that for the foreseeable future one of the most lucrative niche markets, the Mac, hasn't got 1.5, which rules it out for me.

Cas Smiley

Offline Bombadil

Senior Member





« Reply #11 - Posted 2004-10-03 11:36:14 »

The new JBuilder v2005 runs within Java 1.4 on Mac, Win, Linux, Solaris, ... and per option it compiles 1.5 sources to target VM 1.4 - provided you give him a 1.5 SDK to help the compilation. Maybe this backwards compiling is similar to Toby's famous retroweaver compiler?

Anways, this way it's possible to compile and deploy 1.5 sources on J2SE v1.42 and higher machines. With ones exception
Quote
If you're compiling enums to deploy on an earlier JDK, don't use static methods of the java.lang.Enum class or enum runtime exceptions will occur. Also, when compiling annotations, they will compile but won't be contained in the class files.
(JBuilder doc)

Of course using a library like JOGL is another thing, when 1.4 Mac users need to use it...

Still, I see Zingbat's points. The games market is different to the normal market. On Windows for example new games typically need the newest libs (DX blabla).

Because Java 1.5's generics and enums and bla give me much more type safety at compile time, I'd like to use them now wheresoever possible.
Let Java enums be objects (I didn't read that doc yet): Do the few casts hurt, which are needed in order to Java instruct the 3d HW to fill millions of pixels? Hardly.
Online princec

JGO Kernel


Medals: 392
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #12 - Posted 2004-10-03 16:39:18 »

The main problems with the enum approach are that:

1. The decoding of the enum to integer may not take particularly long (although it really does take some time, and it's not insignificant), but it will greatly increase the size of the library.

2. The fact that the OpenGL specification mandates which enums are allowed in which positions, and that the specification is dynamically altered at runtime depending on what extensions are available. So you have it bad both ways - Java successfully compiles the code but you still have to check for GL errors anyway because that's what you have to do to use the GL API properly; and Java fails to compile the code because someone hasn't kept the sets of allowed enums in sync, and it's a very, very complicated job and may not even be possible.

Cas Smiley

Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #13 - Posted 2004-10-04 02:30:11 »

Quote
You must ask yourself if you want Java games to compete  for the same market where C++ developers are already established. Thats the several million dollars market that gets you the money.  


I don't care. I care about my applications, which are not games, working on as many platforms as possible. Game developers can do whatever the hell they want. If they want to use Java 5 in their application development, then go for it. There is nothing stopping them from doing so. Keeping JOGL compatible with JDK 1.4.2 is not going to stop game developers moving to latter versions of Java. There is no reason to require that every single library also move up to a new specification version. In fact, it's typically a really bad thing to do because you'll lock out all the users on other platforms that specifically don't want to upgrade.  What about all those games out there using JOGL right now. They would suddenly fail to run - and Java suffers yet another hit to it's already bad perception by the general public.

If you want to play dick-wagging games, be my guest. My market is bigger than your market, for example. In the development space that I work in (visualisation of all kinds), my annual market is measured in the hundreds of billions of dollars in the US alone, not tens of millions. I'd like to be able to still make money there. My company alone has made bids for just over 100 million dollars worth of projects in the last 2 months for one part of one government agency. That doesn't include the private sector work in the resources, civil or auto industries. Moving JOGL into a space that would remove that market is just plain stupid. Just don't assume that the only reason for JOGL's existance is to satisfy a small niche of game developers.  

Quote
Let Java enums be objects (I didn't read that doc yet): Do the few casts hurt, which are needed in order to Java instruct the 3d HW to fill millions of pixels? Hardly.


Quite the opposite. Remember that OpenGL uses enums in almost every single GL call made. That's potentially tens or hundreds of thousands of casts per frame. Hardly an insignificant number.  Also, remeber that these enums are going to have to be performed on the native side. That means the native code needs to lock the object in the JVM, convert it to a real integer, then unlock the object. That object locking is still a very costly operation, so there's more to the cost than a simple cast.  Also, finally, OpenGL uses bit masks in a lot of places. Enums just don't work at all in this situation. You end up needing to pass Sets of enums, which then incur far greater overheads which includes iterating through the set object on the native side, (lots and lots of JNI->Java code crossing again), as well as assembly of the bitmask to pass to the real OpenGL call.  That's far more work than is needed currently and will serve only to make JOGL far slower than using C to access OpenGL. Which, since the gaming market is so performance sensitive, it will lead to game developers fleeing faster than workers at a burning fireworks factory. Your percieved benefits will actually work as a negative.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline zingbat

Senior Member




Java games rock!


« Reply #14 - Posted 2004-10-04 07:34:21 »

Quote

Moving JOGL into a space that would remove that market is just plain stupid. Just don't assume that the only reason for JOGL's existance is to satisfy a small niche of game developers.  


Like i said use java3d. Don't mess up with technology that is meant for people who are interested in making games.  Your market and the c. game market should clearly used different technologies. C. games is tech intensive and requires constant evolution while yours is a conservative.

We just need something that is on the technological edge and cannot be bothered with compatibility trash code. This is something that needs to be done for game developers. Otherwise Suns better give up on any plans they may have to use their language in the competing game market.
Online princec

JGO Kernel


Medals: 392
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2004-10-04 08:52:59 »

Well, actually... JOGL is meant to be a general purpose binding to OpenGL, and OpenGL is meant to be used in all the spaces from games through to scivis and CAD/CAM. So JOGL fits nicely with this goal.

If you want to write games you ought to use LWJGL because it's explicity and ruthlessly designed for the purpose Smiley

Cas Smiley

Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #16 - Posted 2004-10-04 13:51:59 »

Quote
Like i said use java3d. Don't mess up with technology that is meant for people who are interested in making games.


Ah... excuse me? Did we conveniently forget history or something? Please, go and find a book or six and read about OpenGL.  Let me prime you by telling you that OpenGL in gaming is a relatively new aspect.

Quote
Your market and the c. game market should clearly used different technologies. C. games is tech intensive and requires constant evolution while yours is a conservative.


Exactly. That's why you should be using DirectX, not OpenGL.....

OpenGL, by nature is conservative. DirectX is not. Telling people to get lost because they are conservative is no way of gaining friends and influencing decisions.

Quote
We just need something that is on the technological edge and cannot be bothered with compatibility trash code. This is something that needs to be done for game developers. Otherwise Suns better give up on any plans they may have to use their language in the competing game market.


Right. Care to back that up with facts, or is that just your wish? Who is "we"? Show me how many game companies have released a commercial JOGL game so far. How many have not done so because JOGL was not using latest features of the JDK? How many have because it was not using it? How many are in the final stages of a 3 year development cycle that are based around a known quantity that is JDK 1.4.2 and if you shifted the entire API under them to force them to JDK 1.5 would just not bother to continue with the development and go back to programming in a more stable environment of C++?

Right now, there are two very strong arguments for why JOGL should not perform major surgery to use features of Java. You've completely ignored one (performance), and done a small amount of handwaving of the "but I want it to happen" type for the other. You're going to need to be a hell of a lot more persuasive than that.

And, for what it's worth, we also happen to do professional game development. We're doing one right now that will be released at the end of October. We don't want JOGL to be exclusive to Java 5.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline zingbat

Senior Member




Java games rock!


« Reply #17 - Posted 2004-10-04 17:27:58 »

Actualy for what you guys are telling me i don't intend to use neither one or the other. To use LWJGL or JOGL without being able to use java enumerations, generics and all the rest of the magic in 1.5 is worst than working with C++.

At least C++ enumrations are ints but give some sort of type checking which doesnt happen when using java ints. As for the performance argument sure there will be a certain performance but first research an implementation of java bindings for OpenGL using enums and do some tests with a real game, then say it doesn't work. I think you are giving up on this too soon.

Besides you have to build an engine on top of an extra layer that is worst than C++ and keep rebuidling it completely every one or two years.

Why ? Because thats how it is. Just check Doom3, Half-life 2, Morrowind or any other successful game. Game engines are complelety rebuilt every two years (sometimes more).

I sugest you guys read more:

http://www.gamasutra.com

or

http://www.gamedev.net  

the management sections. Its very rare for someone actualy reusing an old engine.



Let me restate my arguments. What are the advantages of using java for building games that can compete with the best C++ products ?

- Using a clean and high-level lanuage, better optimization of code, garbage collection, more portability among different patforms that can run a javavm.

The advantages are more advanced programming techniques, better developement tools with refactoring and contract programming, less programming effort, less money spent on writing and testing code, more stability on the project, product is delivered sooner and more stable.

The high-level language really pays off when the code complicates itself with advanced AI and a complex scenes that require advanced lod techniques and resource management. So java, in principle, can help making better games.

- Forget about engine reuse and don't mix PC games development market with visualization market or mobile phone games or internet games or any other thing.

- You will need to convince a publisher to sell your game and they have these numbers they get from their sales department that tell them when games are bull and when they can be sold. They may be wrong but they wont buy our games unless we tell them what they want to ear.

First it must run and it must run with a small performance difference.

Second it must be well integrated with the most common art development tools like 3d studio or maya.

Third it must look good and have the latest firworks depending on the game class.

Also depending on the game class (an rpg for instance) you must avoid things like turn-base, 2d isometric, and stuff like that have a very low selling value.

Fourth being a C++ game or based on a known and realtively recent engine. Not saying that a Java game won't sell but it has to be a very good game and not show any weakness towards C++ games.


So to resume my arguments a publisher won't be convinced by telling him the game is made in java or not but i must have a significant advantage using java instead of C++ otherwise doing a game in java to compete with games in the same area as Doom3 or Half-Life 2 is a waste of time.

Its much better to have bindings for a native mini-engine that does the bare minimum but allows me to use 1.5 language features, instead of direct bindings to the opengl apis.
Online princec

JGO Kernel


Medals: 392
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2004-10-04 18:27:28 »

But Zing McBat, it just doesn't work that way! The C++ crowd would have done this already if it were possible, but as it ain't, they ain't bothered. You really need an engine on top of OpenGL, not to tweak OpenGL bindings themselves.

Cas Smiley

Offline zingbat

Senior Member




Java games rock!


« Reply #19 - Posted 2004-10-04 20:43:55 »

Quote
But Zing McBat, it just doesn't work that way! The C++ crowd would have done this already if it were possible, but as it ain't, they ain't bothered. You really need an engine on top of OpenGL, not to tweak OpenGL bindings themselves.

Cas Smiley



I don't understand you. What would they have done already exactly ? And why wasn't that possible ?

What i was sugesting was a native mini-engine. Something like the Irrlicht C++ engine for example but only with the irr:video namespace (from that example) and the graphics device related classes.

As for the rest of the engine functionality like events, io, vector math, network, file formats (sound, image and xml loading), scenegraph, 3d gui this could be done using already existing java packages. The main problem with JOGL direct binding is that it is so low level that it doesn't really fit in Java and it brings C problems to Java code.

I don't know if any of you ever had to mess up with a C bug caused by misused pointers. These are very hard to check and find. The int arguments in JOGL bindings that are suposed to be enums in C are also very dangerous and error prone. Type checking exists for a reason.

You end up building a layer on top of JOGL to hide the nasty and dangerous coding anyway so why not pushing this code into a mini-engine and get rid of the useless  layer that is JOGL ?
Online princec

JGO Kernel


Medals: 392
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2004-10-04 22:06:56 »

They haven't implemented a C++ namespace for OpenGL that uses strict typechecking of enum arguments to the GL API, for the reasons so far outlined. The GL API is designed to work thus:
1  
2  
glDoSomething(GL_WHOOPS); // Illegal argument so do nothing
error = glGetError(); // Check the error at runtime


Cas Smiley

Offline zingbat

Senior Member




Java games rock!


« Reply #21 - Posted 2004-10-05 07:38:40 »

Cas you are simplifying the subject a LOT. Picture a big project like a game you want to sell containing hundreds of source files. A misplaced value on a opengl function call may give an error or it may just do something semanticaly legal but something that is wrong and the lack of type checking will force the tester to spend a lot of unnecessary time looking for something that should have been catched during compile time. And these kind of errors are very hard to come by.

Thats why im going for something similar like i  have described above, if there isn't a clever way to make enum work with JOGL. If i have to mess with low-level C style code in Java then i will have to deal with C style problems i don't want to when working with real game projects. I must have an advantage when working with Java, otherwise whats the point ?
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #22 - Posted 2004-10-05 08:11:33 »

Quote

You end up building a layer on top of JOGL to hide the nasty and dangerous coding anyway so why not pushing this code into a mini-engine and get rid of the useless  layer that is JOGL ?


I don't think JOGL aims to be another layer between the application and graphics hardware, but a binding that simply allows one to utilize the OpenGL API with Java language. What can be built on top of that, is a different story... I think that one could build such a delegating layer (working with enums only) on top of the current JOGL implementation - but it would require a lot of handcrafted work.

Cheers


Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline Bombadil

Senior Member





« Reply #23 - Posted 2004-10-05 10:48:37 »

Quote
I must have an advantage when working with Java, otherwise whats the point ?

Yes, that's the point. This is the reason I can't wait until all APIs which I'm currently using with Java (Xith and Jogl at the mo) switch to Java 1.5's new things like generics and enums.
Sometimes I hardly can believe the Java world stayed away 10 years (!) from generics. To some Java critic dev folks I'd love to present Java 1.5 as the first Java version ever. ;-)

Ok, generics aren't directly usuable with a C based API like OpenGL and hence JOGL. Xith and other highlevel APIs would benefit from generics however.
With enums it should be different however. They could be important to JOGL. Even if OpenGL isn't at all typesafe when it comes to those thousands of "enum" constants: wouldn't it be possible to offer them to Java devs?
I really wished my compiler would finally stop to compile a statement like this:
gl.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_WRAP_R, GL_TEXTURE_MIN_FILTER);
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #24 - Posted 2004-10-05 11:50:16 »

You could implement a delegating wrapper which takes care of the type safety work. For instance:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
public class TypeSafeGL implements GL
{
// delegate all methods to a wrapped GL instance
//   and handle enums where required
//
// Note: there are approx. 1500 methods which use
//  GLenum type and should be treated as enums
}

// Usage:
public void display(GLDrawable glDrawable)
{
TypeSafeGL gl = new TypeSafeGL(glDrawable.getGL());

// Not nice, as you cannot directly use enum member GL_TRIANGLES...
gl.glBegin(glBeginEnum.GL_TRIANGLES)
gl.glEnd();
}


Edit: Sorry, my bad. You can use the GL_TRIANGLES enum directly, if it is declared in a public enum (not inside another class...), in a separate file, that is:

1  
2  
3  
4  
5  
6  
7  
8  
public enum GLBeginEnum
{
GL_TRIANGLES, GL_QUADS, etc
}

//...and then the user class has to use static import:

import static jogl.foo.GLBeginEnum.*;


Cheers

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #25 - Posted 2004-10-05 13:38:27 »

Quote
To use LWJGL or JOGL without being able to use java enumerations, generics and all the rest of the magic in 1.5 is worst than working with C++.


combined with this gem of a quote

Quote
I must have an advantage when working with Java, otherwise whats the point ?


Riiiight. Please, go away to your fantasy land and return to doing stuff in C++ since that's what you prefer doing anyway. If you are incompetent enough to be unable to develop professional applications in the existing pre-1.5 environment, you'll still be incompetent developing them post 1.5. Those of us that have been developing and delivering large-scale applications in Java for the better part of a decade don't need your help in evangalising Java. If you don't already know what the development advantages of Java have been for the time pre 1.5, then you know nothing about Java at all. Come back in 5 years or so when you have some real world experience building large applications.  

Quote
You end up building a layer on top of JOGL to hide the nasty and dangerous coding anyway so why not pushing this code into a mini-engine and get rid of the useless  layer that is JOGL ?


Right, so now your argument boomerangs right back at you. You should go use Java3D if that is an issue for you. JOGL is the <i>Java bindings to OpenGL</i>. It's a binding to a pre-existing API. All it does is provide an absolutely minimalistic interface for exposing the capabilities in Java.

As I stated before. If all you want to use is Java 1.5 features, then there's nothing stopping you from using them right now (other than you making constant whiny excuses). Some, or most of the APIs you'll be working with do not make use of them, but that doesn't stop them from being useful and highly productive.  Once you actually join the real world of large-scale application code, you'll realise that it's never the API that is the problem, it's the documentation and implementation of it that you'll spend far more time debugging. Trivial things like having the wrong int value will be insignificant to dealing with why XYZ video card manufacturer's drivers seem to do weird stuff when you call glFoo after making 4 calls to glBar(), but not 5 calls.

Quote
Cas you are simplifying the subject a LOT. Picture a big project like a game you want to sell containing hundreds of source files. A misplaced value on a opengl function call may give an error or it may just do something semanticaly legal but something that is wrong and the lack of type checking will force the tester to spend a lot of unnecessary time looking for something that should have been catched during compile time. And these kind of errors are very hard to come by.


Or, you haven't worked on a big project at all. That's what unit testing does for you. That's what making calls to glGetError() do for you. If you're not using these very simple tools, then one can hardly expect to see good quality code as a result.  If you can't visually see these errors, then either they're never a problem to begin with, or you need to go visit an opthamologist. Debugging OpenGL code is quite trivial compared to debugging the support functions around it such as culling, state sorting collision detection. In my time working on Aviatrix3D - about a year almost fulltime now, I've had exactly 2 bugs due to the wrong constant being used. Those took me a total of about 5 minutes to notice (unit testing) and correct. Using enums would have not saved me anything.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Giddy

Senior Newbie




Java games rock!


« Reply #26 - Posted 2004-10-05 14:03:37 »

Quote

In my time working on Aviatrix3D - about a year almost fulltime now, I've had exactly 2 bugs due to the wrong constant being used. Those took me a total of about 5 minutes to notice (unit testing) and correct. Using enums would have not saved me anything.


How do you unit test your opengl calls?

I try to cover my engine with tests, but the inner rendering code has a coverage near 0%. I have to test the rendering manualy. (Run a small app and inspect the results visualy)



Online princec

JGO Kernel


Medals: 392
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2004-10-05 14:27:17 »

To unit test GL calls you have to do two things:
1. Inspect the result visually - no way around this.
2. Check the GL error code and throw an exception if it's nonzero.

Cas Smiley

Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #28 - Posted 2004-10-05 15:13:28 »

If you are creating a scene graph, you make unit tests for each scene graph object individually. The unit tests at this level assume you have passed unit tests for lower-level capabilities, such as culling and sorting (or have them turned off in your pipeline if your scene graph API has that capability).  For example, take a geometry object, such as a TriangleStripArray and then have the unit test set all the values in different combinations, one frame at a time. Screen scraping etc allows you to grab each frame or only test one piece at a time and visually inspect the results.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline zingbat

Senior Member




Java games rock!


« Reply #29 - Posted 2004-10-05 17:19:01 »

Quote


Riiiight. Please, go away to your fantasy land and return to doing stuff in C++ since that's what you prefer doing anyway.


I don't think i like the tone you are using in this discussion. If you can't have a discussion like a grwon up person its better you step away.

As for telling me to go to C++ forums let me remind you that this is an open forum to java games strangely called javagaming. Go figure. So why don't YOU go find a forum about Visualization.

Quote

If you are incompetent enough to be unable to develop professional applications in the existing pre-1.5 environment, you'll still be incompetent developing them post 1.5. Those of us that have been developing and delivering large-scale applications in Java for the better part of a decade don't need your help in evangalising Java. If you don't already know what the development advantages of Java have been for the time pre 1.5, then you know nothing about Java at all. Come back in 5 years or so when you have some real world experience building large applications.  


Just because i don't have experience doesn't mean i can't analyse my possiblities and study the market. Instead trying to intimidate people with your great developer pose why don't you actualy show some knowledge about PC games.

So why many successful PC games have you developed and sold ? What is the name of your studio ? What publishers have sold your great games ? Can we see a review of them on gamespy ?

Doing PC games is not the same thing as doing Visualization little applications. Your Aviatrix is nothing in complexity compared to a full-featured game engine. And im saying it nicely and with an educated tone.

Quote

you'll realise that it's never the API that is the problem, it's the documentation and implementation of it that you'll spend far more time debugging. Trivial things like having the wrong int value will be insignificant to dealing with why XYZ video card manufacturer's drivers seem to do weird stuff when you call glFoo after making 4 calls to glBar(), but not 5 calls.


So you're saying that type-checking is not important. And by the way i saw your documentation. Not much of UML in there and javadocs with contract programming isn't there.

Quote

Or, you haven't worked on a big project at all.


And the crap continues. But i see statistics and the crap shows on statistics. Things like high-level language constructs and refactoring is what contributes for reducing the work of very complex projects like PC game engines. The ones you never made remenber ?

Quote

That's what unit testing does for you. That's what making calls to glGetError() do for you. If you're not using these very simple tools, then one can hardly expect to see good quality code as a result.  If you can't visually see these errors, then either they're never a problem to begin with, or you need to go visit an opthamologist.


So you're saying that junit replaces type-checking and high-order language features and i need an opthamologist ? Man im going to stop answer to you becase this is worst than the Texas massacre.

Quote

Debugging OpenGL code is quite trivial compared to debugging the support functions around it such as culling, state sorting collision detection.


So says the great software developer of Visulaization projects.  Roll Eyes

Quote

In my time working on Aviatrix3D - about a year almost fulltime now, I've had exactly 2 bugs due to the wrong constant being used. Those took me a total of about 5 minutes to notice (unit testing) and correct. Using enums would have not saved me anything.


Yes but not everyone has 2 years to make Aviatrix3D. If you want to be competitive you need to work in a team with projects having fully normalized dociumentation so that every understands the project; you need to do it well and FAST and thats why high-level constructs are and software tools that take advantage of these constructs are necessary.

Let me repeat it to you: quality, speed and organization.

I sugest you drop that arrogant great developer tone who thinks everyone is incompetent. Try to discuss arguments instead of attacking people and people may respect you more. Not only it makes you look like an asshole but people who come to these forums may feel intimidated and decide not to post in here. I think moderators should pay more attention to these situations where so called great developers come here telling people to shut up and go away.
Pages: [1] 2 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

Riven (10 views)
2014-10-02 14:36:20

Pippogeek (41 views)
2014-09-24 16:13:29

Pippogeek (32 views)
2014-09-24 16:12:22

Pippogeek (22 views)
2014-09-24 16:12:06

Grunnt (48 views)
2014-09-23 14:38:19

radar3301 (30 views)
2014-09-21 23:33:17

BurntPizza (65 views)
2014-09-21 02:42:18

BurntPizza (37 views)
2014-09-21 01:30:30

moogie (44 views)
2014-09-21 00:26:15

UprightPath (53 views)
2014-09-20 20:14:06
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!