Skip to main content
gamedev.net
🔒 Locked

C++ to Java

Started by VersusReal 12 replies 500+ views
Original Post
VersusReal
VersusReal
How hard is it to convert a game written in C++ to Java or from Java to C++? And how much would I have to change if I had non-OOP stuff in it or MFC or DirectX? Open the hushed casket...
Open the hushed casket...
VersusReal
VersusReal
Thanks... Maybe I''ll have to do that....

Open the hushed casket...
Open the hushed casket...
nonnus29
nonnus29
"It would be faster and easier to learn Java thoroughly and then code the game from scratch than to convert it. "

That simly isn't true. It is trivial to convert a game from java to c++ especially if you use a lib like **Allegro** or SDL. Its merely a matter of converting your drawing functions to that of the lib and switching your class definitions to c++ syntax and destructing your files into cpp/.h files. The more oop your game, the easier it will be.

Convert from c++ to java will be a bit more problematic but is entirely doable, if you use a lib like the aforementioned **Allegro** or SDL. Just don't expect joystick support or accelerated graphics unless you want to get really involved in JDK 1.4 Volatile Images.

Edit: Assuming you know each language reasonably well and you are using 2d graphics.

[edited by - nonnus29 on September 27, 2002 9:34:58 PM]

[edited by - nonnus29 on September 27, 2002 9:36:23 PM]
Cyberdrek
Cyberdrek
quote:
Original post by Anonymous Poster
converting from C++ to java will probably be impossible. C++ is a much richer language. Most of its features are not present in java and so there are no direct equivilents. Java to C++ should be easy, as C++ has nearly everything that java has.


I''m not a java freak but I know that you can code just about anything you can in C++ in Java and vice-versa. For some proof of that, visit www.topcoder.com and check out the practice rooms, view some of the code for solutions in Java and compare them with the C++ version from other coders, you will see that they achieve the exact same result.




[Cyberdrek | the last true sorcerer | Spirit Mage - mutedfaith.com]
[Cyberdrek | ]
Shannon Barber
Shannon Barber
Let''s start with "const"

It''s the "Turning Complete" thing, but converting C++ code to Java would have to be painful at best.
I think it would be more sane to start over. You could improve the design while you''re at it.
The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
davepermen
davepermen
lets continue with pointers,
then with templated stuff...

impossible..

"take a look around" - limp bizkit
www.google.com
If that's not the help you're after then you're going to have to explain the problem better than what you have. - joanusdmentia
My Page davepermen.net | My Music on Bandcamp and on Soundcloud
nonnus29
nonnus29
quote:
Original post by davepermen
lets continue with pointers,
then with templated stuff...

impossible..



const == final
pointers == all non atomic types are passed by reference
templates == Well, you got me there, but with interfaces and dynamic casting you get pretty close.

Impossible? Not hardly, if I can do it, trust me, anyone can.
Big Sassy
Big Sassy
nonus29 is right. The only thing that C++ has that Java doesn''t (to the best of my knowledge) is MI and templates. Also, I think the only way to create objects (outside of data primitives like int, long, float, etc) is to dynamically allocate them on the heap (because they are all basically pointers).

It''s defiantely possible to port C++ code to Java. But the code in the end would be such a butchered mess that it wouldn''t be worth it. And that''s just for a small program (say 1000 lines or less). I don''t want to think about the nightmare of porting a 10,000+ project to Java. Just do yourself a favor and rewrite it from scratch.

(anybody feel free to correct me if I''m wrong)

***********************
          
HenryApe
HenryApe
quote:
And how much would I have to change if I had non-OOP stuff in it or MFC or DirectX?
That depends much on whether you are just using Java bindings for DirectX and MFC or porting the code to an entirely different, more platform-neutral API such as OpenGL or Java3D. Porting an OpenGL app from C to Java was very easy when I used the Java bindings for OpenGL (GL4Java), but it could have been a lot more difficult to translate the code to an entirely different API such as DirectX.

Game code is probably quite hard to port since it tends to be heavily optimized to use all the strengths of the language it is written in. To get the best result in a porting effort, you would want to rewrite the C++ code to suit Java and vice-versa.

[edited by - HenryAPe on September 28, 2002 4:55:10 PM]
Jiim
Jiim
Being halfway through converting a (2D) game from Java to C++ and DirectX, I would say the biggest thing I had to accomodate for was the sense of ownership of memory that is present in C, but not in Java. What I mean is, some piece of code has to take responsibility for each section of memory and make sure it is deleted, while everything else has to make sure it doesn''t delete it. My game currently has circa 12000 lines, so it isn''t a small project. I''ve generally speaking kept the exact same design, I''ve changed a couple of small details because of the ownership problem mentioned above.

OK, you haven''t got multiple inheritance in Java, but it gets round this by having interfaces, which I believe are an improvement-it can get messy in C++ with a class appearing twice in the same class hierarchy tree. Every class you create in Java extends (eventually) from the ''Object'' class, having this means that you can create a stack implementation (for example) for a particular class through polymorphism as opposed to doing it at compile time through templates or paramaterized types. This also means that in Java you can create a stack which can contain several types of classes with less work than in C++. The easiest way you could do this in C++ using the ANSI classes is to create a stack for void* and cast dynamically at run-time, which is exactly what Java does in essence.

And besides, you can argue until you''re blue in the face that C has feature X but Java doesn''t, but why is this necessarily a bad thing?? Java has alternatives, it would make more sense to compare feature X from C against the alternative in Java!

If you''ve been adopting procedural programming styles in C++, this will make the move from C++ to Java more difficult.

Jiim Jonez.
the Speed Bump
the Speed Bump
quote:
Original post by Jiim
OK, you haven''t got multiple inheritance in Java, but it gets round this by having interfaces, which I believe are an improvement-it can get messy in C++ with a class appearing twice in the same class hierarchy tree. Every class you create in Java extends (eventually) from the ''Object'' class, having this means that you can create a stack implementation (for example) for a particular class through polymorphism as opposed to doing it at compile time through templates or paramaterized types. This also means that in Java you can create a stack which can contain several types of classes with less work than in C++. The easiest way you could do this in C++ using the ANSI classes is to create a stack for void* and cast dynamically at run-time, which is exactly what Java does in essence.



Minor nitpick is all.

An alternative would be to make a stack for a common base class, which, in a lot of situations, already exists, which is also pretty close to what java does. (the Object type)

Also, I like multiple inheritance. I''m wont to make "interfaces" that contain a little bit of actual data, or code, and it''s nice to still be able to mix and match, or to go with pure interfaces and copy/paste code.

I''m hip because I say "M$" instead of "MS".
"There is only one everything"

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.