Torque for Delphi/Kylix...
by Brett Fattori · in Torque Game Engine · 12/19/2003 (6:49 am) · 21 replies
Folks,
I know that a lot of people see Delphi (Visual Pascal) as a toy. That it can't do anything, any better, than C++ can. However, Delphi is a well done implementation of Pascal with objects. It is recognized by many people as THE way to rapidly develop applications. It seems to me that if it were allowable, it would be neat to port the entire engine over to Delphi. This may be a pipe dream, and it may not be allowed by the TGE license (I haven't checked into that) but there are many good reasons to port, and maintain the TGE, to Delphi/Kylix.
1) Delphi is based around a KNOWN learning language: PASCAL.
2) Delphi is object based, just like C++, so it can handle many of the implementation issues that would be impossible in a port to, say, Visual Basic.
3) Most of the engine is OpenGL, so we're not depending on how well it compiles into assembly.. Although, I have to say that Borland makes some amazing compilers.
4) Most of the engine depends on OpenGL, which (nowadays) is hardware bound. It doesn't matter how fast the CPU is (as much anymore) because the graphics are handled by graphics hardware.
5) Delphi/Kylix are available on the two main platforms: Windows and Linux. I am sorry that Borland hasn't made a "Kylix" for Mac, because I prolly never would have converted to C++ in the first place.
6) There's evidence that being able to maintain another codebase (albeit a little laggy behind the main codebase) would be effective. Looking at the Delphi JEDI projects, which maintain standard C++ libraries for Delphi, it would be entirely possible to maintain the code.
There are more reasons, that I can't think of right now, to maintain a Delphi implementation of the TGE. I won't kid anyone... This would be a MAJOR undertaking, it would require a team of people to do the conversion (and maintain it), and it would be fun to do.
I would be interested in working with a group of people to do the port, if people were interested. It would certainly open up some more doors (not everyone is a master C++ coder). And, again, I maintain it would be fun.
Any interest?
- Brett
I know that a lot of people see Delphi (Visual Pascal) as a toy. That it can't do anything, any better, than C++ can. However, Delphi is a well done implementation of Pascal with objects. It is recognized by many people as THE way to rapidly develop applications. It seems to me that if it were allowable, it would be neat to port the entire engine over to Delphi. This may be a pipe dream, and it may not be allowed by the TGE license (I haven't checked into that) but there are many good reasons to port, and maintain the TGE, to Delphi/Kylix.
1) Delphi is based around a KNOWN learning language: PASCAL.
2) Delphi is object based, just like C++, so it can handle many of the implementation issues that would be impossible in a port to, say, Visual Basic.
3) Most of the engine is OpenGL, so we're not depending on how well it compiles into assembly.. Although, I have to say that Borland makes some amazing compilers.
4) Most of the engine depends on OpenGL, which (nowadays) is hardware bound. It doesn't matter how fast the CPU is (as much anymore) because the graphics are handled by graphics hardware.
5) Delphi/Kylix are available on the two main platforms: Windows and Linux. I am sorry that Borland hasn't made a "Kylix" for Mac, because I prolly never would have converted to C++ in the first place.
6) There's evidence that being able to maintain another codebase (albeit a little laggy behind the main codebase) would be effective. Looking at the Delphi JEDI projects, which maintain standard C++ libraries for Delphi, it would be entirely possible to maintain the code.
There are more reasons, that I can't think of right now, to maintain a Delphi implementation of the TGE. I won't kid anyone... This would be a MAJOR undertaking, it would require a team of people to do the conversion (and maintain it), and it would be fun to do.
I would be interested in working with a group of people to do the port, if people were interested. It would certainly open up some more doors (not everyone is a master C++ coder). And, again, I maintain it would be fun.
Any interest?
- Brett
#2
I do agree that converting the engine to OOP Pascal would be a difficult undertaking, but not exactly a nightmare. I guess I'm not asking that people with legitimate deadlines (and such) drop everything to do a rewrite in Delphi. However, it would be very advantageous to undertake such a mission. Honestly, the way I learned C++ was to re-code some libraries in Delphi. I think that others would benefit from this kind of experience, if they were good Delphi developers.
It's more of an educational experience, than a plan to replace (or even supercede) TGE in C++ with TGE in Delphi. I guess I'm looking for interest in it as a effort of "love" rather than an effort of "profit." It could, eventually, lead to more indies developing games in many possible, different languages. This really is what Garage Games is about... at least, in my eyes. Not the eventual plan to be picked up by some gargantuan development house (some people may have this plan -- so stick to C++!!) but to develop games independent of rules, restrictions, budgets, and corporate influence.
Your points and opinions, however, are respected. Thanks for your input.
- Brett
12/19/2003 (7:23 am)
James,I do agree that converting the engine to OOP Pascal would be a difficult undertaking, but not exactly a nightmare. I guess I'm not asking that people with legitimate deadlines (and such) drop everything to do a rewrite in Delphi. However, it would be very advantageous to undertake such a mission. Honestly, the way I learned C++ was to re-code some libraries in Delphi. I think that others would benefit from this kind of experience, if they were good Delphi developers.
It's more of an educational experience, than a plan to replace (or even supercede) TGE in C++ with TGE in Delphi. I guess I'm looking for interest in it as a effort of "love" rather than an effort of "profit." It could, eventually, lead to more indies developing games in many possible, different languages. This really is what Garage Games is about... at least, in my eyes. Not the eventual plan to be picked up by some gargantuan development house (some people may have this plan -- so stick to C++!!) but to develop games independent of rules, restrictions, budgets, and corporate influence.
Your points and opinions, however, are respected. Thanks for your input.
- Brett
#3
I don't think any of those points are reasons to go forward with a port - that is, they don't really mention any perks from porting. What benefit would *I* get from the port?
And the engine isn't "mostly OpenGL". :-) That's just the rendering; there's a great deal more logic going on under the hood, from scripting to the network code and more.
12/19/2003 (7:29 am)
Agreed. The time and effort would be insane! In addition, I'd have to say you'd need to be a "master C++ coder" - as you put it - just to do this porting; how can you port complex code you don't really understand?I don't think any of those points are reasons to go forward with a port - that is, they don't really mention any perks from porting. What benefit would *I* get from the port?
And the engine isn't "mostly OpenGL". :-) That's just the rendering; there's a great deal more logic going on under the hood, from scripting to the network code and more.
#4
I never said that you'd have to be a "master C++ coder" to port the engine. I said that "not everyone is a master C++ coder" with respect to people coming to GG looking for options, other than C++. The reason to port the engine is to gain a better understanding of it through a shared experience -- and to gain something from it (another version of the engine). Why would you be so adamant that it would be a waste of anyone's time?
When I wanted to learn sockets programming, I didn't go grab a component and figure out how to implement it -- I grabbed a book on sockets and wrote my own. When I wanted to learn databases, I grabbed some small implementations and tried to make them better. It's about picking through the engine, understanding it, and gaining from it.
Bringing the engine up in Delphi would be a really rewarding experience. It would certainly make people, who participated, feel like they had accomplished something. Plus, it would (I think) give people a deeper knowledge of the engine itself.
I have gone through the engine a few times, just tracing code in my head, trying to glean a better understanding of how it works. The documentation, albeit good for cursory understanding, isn't great. A port of the code, to a different language, would certainly give me (and possibly others) more in-depth knowledge of the engine. Now, choosing something like Perl, or VB is a waste of everyone's time. That's why I suggested Delphi... It's very similar to the way that C++ is structured. Plus, it has the capability and power to do almost everything C++ does.
I'm not asking everyone here to get involved. I'm asking around to see if there would be anyone interested in something like this. I do, however, respect what you're saying, and agree with some of it...
- Brett
12/19/2003 (8:06 am)
Brian,I never said that you'd have to be a "master C++ coder" to port the engine. I said that "not everyone is a master C++ coder" with respect to people coming to GG looking for options, other than C++. The reason to port the engine is to gain a better understanding of it through a shared experience -- and to gain something from it (another version of the engine). Why would you be so adamant that it would be a waste of anyone's time?
When I wanted to learn sockets programming, I didn't go grab a component and figure out how to implement it -- I grabbed a book on sockets and wrote my own. When I wanted to learn databases, I grabbed some small implementations and tried to make them better. It's about picking through the engine, understanding it, and gaining from it.
Bringing the engine up in Delphi would be a really rewarding experience. It would certainly make people, who participated, feel like they had accomplished something. Plus, it would (I think) give people a deeper knowledge of the engine itself.
I have gone through the engine a few times, just tracing code in my head, trying to glean a better understanding of how it works. The documentation, albeit good for cursory understanding, isn't great. A port of the code, to a different language, would certainly give me (and possibly others) more in-depth knowledge of the engine. Now, choosing something like Perl, or VB is a waste of everyone's time. That's why I suggested Delphi... It's very similar to the way that C++ is structured. Plus, it has the capability and power to do almost everything C++ does.
I'm not asking everyone here to get involved. I'm asking around to see if there would be anyone interested in something like this. I do, however, respect what you're saying, and agree with some of it...
- Brett
#5
12/19/2003 (8:45 am)
Go for it! There's nothing in the license that prohibits it (though to be fair you probably shouldn't make the ported source available to non-licensees). Have a blast!
#6
I also discount Kylix, because when I tried it it was a buggy piece of crap, to put it bluntly. Random crashes of both the IDE and the running app. I'm also not sure it would give you access to as many things as Delphi, like accelerated GL, though as I say, I don't know for sure.
I can't call it as a waste of time, because what people choose to do with their time is their own business, but I would suggest there are other projects that would benefit from more manpower (anyone want to write a LW exporter for Cal3D? :D), and that if someone does want to use Delphi they would be better off working to develop a Delphi engine rather than port Torque (or look for an engine that isn't so full of interdependencies).
How's ChopperSim coming along? =)
12/19/2003 (8:52 am)
I think this is only a "because it's there" situation. I don't think there'd be any benefit other than a feeling of finishing a project. Ultimately, you end up with a split project - Delphi users coming to Torque wouldn't have the benefit of any of the excellent resources, code snippits, or community support, unless they are already well-versed in C/C++ and can do the conversion themselves, in which case you have to ask why they're using a Delphi port in the first place. I mean, developing a game is just not the best environment for GUI-focused RAD tools, IMO.I also discount Kylix, because when I tried it it was a buggy piece of crap, to put it bluntly. Random crashes of both the IDE and the running app. I'm also not sure it would give you access to as many things as Delphi, like accelerated GL, though as I say, I don't know for sure.
I can't call it as a waste of time, because what people choose to do with their time is their own business, but I would suggest there are other projects that would benefit from more manpower (anyone want to write a LW exporter for Cal3D? :D), and that if someone does want to use Delphi they would be better off working to develop a Delphi engine rather than port Torque (or look for an engine that isn't so full of interdependencies).
How's ChopperSim coming along? =)
#7
Becides what's the point in converting Torque over to Delphi in the first place? Kylix is pratically dead since it hasn't been updated in a few years from Borland, so I assume they gave up, and I believe Delphi is yet another bad choice of a language to be used for a game engine. Using Delphi is just as bad as using Visual Basic or RealBasic.
12/19/2003 (9:54 am)
Umm... Did you take into account that Torque also uses ASM code as well? I don't believe Delphi has any ASM compiler what so ever.Becides what's the point in converting Torque over to Delphi in the first place? Kylix is pratically dead since it hasn't been updated in a few years from Borland, so I assume they gave up, and I believe Delphi is yet another bad choice of a language to be used for a game engine. Using Delphi is just as bad as using Visual Basic or RealBasic.
#8
If you didn't know, you can insert inline assembler in delphi and regular pascal code.
12/19/2003 (10:16 am)
Nathan,If you didn't know, you can insert inline assembler in delphi and regular pascal code.
asm <Insert Your Assembler Here> end;
#9
Have you ever used Delphi? From your statements, it doesn't sound like it. Not to knock you, or try to deride you, but Delphi is an object oriented language, much like C++, with the ability to generate applications (yes, quickly... RAD, Simon ;-) like Visual Basic. However, it is a powerful implementation of Pascal. True, Pascal was developed as a learning language. However, it has progressed to the point (thanks to Borland's persistence) where it can stand up with C++, Java, and other OOP languages.
It is, truely, only because of its heritage as a "learning language" that it didn't take off like C++ did as the standard of development. As for the comparison to Visual Basic, or RealBasic, people just don't understand that you can't grab Delphi and start using it right away. It has a solid foundation is classes and inheritance, a great compiler, and features that make Visual Basic look like a pop gun compared to a Glock 23, 40 caliber handgun.
- Brett
PS: Simon, ChopperSim is on hold whilst I try to complete a simpler game based around the old Atari game Star Raiders. But let's keep that a secret!
12/19/2003 (11:03 am)
Nathan,Have you ever used Delphi? From your statements, it doesn't sound like it. Not to knock you, or try to deride you, but Delphi is an object oriented language, much like C++, with the ability to generate applications (yes, quickly... RAD, Simon ;-) like Visual Basic. However, it is a powerful implementation of Pascal. True, Pascal was developed as a learning language. However, it has progressed to the point (thanks to Borland's persistence) where it can stand up with C++, Java, and other OOP languages.
It is, truely, only because of its heritage as a "learning language" that it didn't take off like C++ did as the standard of development. As for the comparison to Visual Basic, or RealBasic, people just don't understand that you can't grab Delphi and start using it right away. It has a solid foundation is classes and inheritance, a great compiler, and features that make Visual Basic look like a pop gun compared to a Glock 23, 40 caliber handgun.
- Brett
PS: Simon, ChopperSim is on hold whilst I try to complete a simpler game based around the old Atari game Star Raiders. But let's keep that a secret!
#10
See the Torque source code uses LOTS of stuff that is C++ only.You would "port" to another plaftorm, but not another language. See "port" implies that if changes are made to the original source code for the original platform that it would be relatively trival to "port" the changes.
Torque has all ready been "ported" to Windows, Linux and MacOSX.
If you want Delphi code, go look at Delphi3D
12/19/2003 (11:28 am)
See this why there this is a non-issue, it is not feasible. Besides the fact you don't "port" to another language your re-write.See the Torque source code uses LOTS of stuff that is C++ only.You would "port" to another plaftorm, but not another language. See "port" implies that if changes are made to the original source code for the original platform that it would be relatively trival to "port" the changes.
Torque has all ready been "ported" to Windows, Linux and MacOSX.
If you want Delphi code, go look at Delphi3D
#11
Then Borland went all weird on me, changed itself to Inprise, and Delphi 2.0 and above were remarketed as a high-end database development language. Which, unfortunately, put it WELL outside of my "hobby game programming" budget. I switched to using DJGPP (GCC ported to DOS), learned C++ for the first time, and then never switched back.
Today, I'm using MSVC.
Don't get me wrong, Delphi was a nice compiler and IDE. It's monolithic libraries were annoying (forcing you to recompile the entire library if you wanted to add your own modules), but otherwise I loved how it was put together. Widgets transformed into real code that could be manipulated, unlike the other major RAD tool of the time, Visual BASIC. It reminded me a lot of Clarion.
However, today, if I were to want to do pure applications development -- like, say, a Word spinoff -- I would likely go with Inprise/Borland's C++ Builder. But for flat out game coding, I'm stick with VC on Windows because it's the most supported compiler out there. I mean, now I write my own message handlers and GUI code and such. Therefore something like Delphi's widgets based upon standard Windows GDI calls would be useless to me.
Rewriting Torque into Delphi would be an astronomical undertaking, and considering the amount of effort required, I'd rather just roll my own engine. But since I bought the Torque SDK, that means I'm not WANTING to roll my own engine (well, at least one that does exactly what Torque does), so it's kind of a moot point to me.
However, I agree with Ben. If you want to go for it -- knock yourself out!
12/19/2003 (11:33 am)
Wow, Brett, you sound like I used to sound a few years ago. I was still using Borland Pascal for game development, and Delphi had JUST come out and was knocking my socks off. MUCH better than the previous Object Pascal for Windows release.Then Borland went all weird on me, changed itself to Inprise, and Delphi 2.0 and above were remarketed as a high-end database development language. Which, unfortunately, put it WELL outside of my "hobby game programming" budget. I switched to using DJGPP (GCC ported to DOS), learned C++ for the first time, and then never switched back.
Today, I'm using MSVC.
Don't get me wrong, Delphi was a nice compiler and IDE. It's monolithic libraries were annoying (forcing you to recompile the entire library if you wanted to add your own modules), but otherwise I loved how it was put together. Widgets transformed into real code that could be manipulated, unlike the other major RAD tool of the time, Visual BASIC. It reminded me a lot of Clarion.
However, today, if I were to want to do pure applications development -- like, say, a Word spinoff -- I would likely go with Inprise/Borland's C++ Builder. But for flat out game coding, I'm stick with VC on Windows because it's the most supported compiler out there. I mean, now I write my own message handlers and GUI code and such. Therefore something like Delphi's widgets based upon standard Windows GDI calls would be useless to me.
Rewriting Torque into Delphi would be an astronomical undertaking, and considering the amount of effort required, I'd rather just roll my own engine. But since I bought the Torque SDK, that means I'm not WANTING to roll my own engine (well, at least one that does exactly what Torque does), so it's kind of a moot point to me.
However, I agree with Ben. If you want to go for it -- knock yourself out!
#12
Delphi is a great language indeed!
But... why invest all this time and effort into porting the engine to another language? It's up and running in C++ on three different platforms. I don't see the need to compile it on another language. The time required to maintain it alone would be very high.
I can imagine if you want to use Torque in Delphi, but then maybe writing a COM wrapper would be easier (even though that will require a lot of work too, and I think you could better invest time in learning C/C++).
Just my two cents.
12/20/2003 (4:28 am)
Hello,Delphi is a great language indeed!
But... why invest all this time and effort into porting the engine to another language? It's up and running in C++ on three different platforms. I don't see the need to compile it on another language. The time required to maintain it alone would be very high.
I can imagine if you want to use Torque in Delphi, but then maybe writing a COM wrapper would be easier (even though that will require a lot of work too, and I think you could better invest time in learning C/C++).
Just my two cents.
#13
Have you seen C#? I never thought I would say this, but C# is very impressive. Basically Java for windows. No pointers, automatic garbage collection, and very simple syntax.
I attended Borcon this year and Delphi 8 is a COMPLETLY different language. The VCL no longer maps to win32, it maps to .NET. If I am going to code for .NET Why use Delphi? Yeah I know it (my most fluent language), but why not use C# for a much simpler, and cleaner implementation. The C# Builder and Visual C# IDEs are nearly identical and are AWESOME. I saw a demonstration where the speaker designed his object model in UML in the IDE, he hit generate, and it generated the code...he then hit generate schema and BAM the DB was built to match the object relationships in real time. He ran 2 instances of the databse applicaiton and when the 1 one was modified the 2nd was AUTOMATICALLY updated via caching!!!! AWESOME stuff. I think he wrote 2 lines of code.
Torque in DirectX for .NET... now there is a project (or completly different engine -- but you lose cross platform capability).
People are also forgetting that Delphi uses heap memory NOT stack memory (as C+ can use). Delphi also does not provide for inline functions. Although both of these limitations can be overcome, again, WHY?
I am a professional Delphi programmer for 5 years, and I think Delphi every day for providing food on the table for the family, but sometimes you simply have to ask, am I using the right tool for the job?
The final code will still be roughtly %90-%95 the speed of the C++ engine. And again.. WHY bother? Just bend like a reed in the wind and learn C++ and add another feather to your cap. ;)
12/20/2003 (11:16 am)
"However, today, if I were to want to do pure applications development -- like, say, a Word spinoff "Have you seen C#? I never thought I would say this, but C# is very impressive. Basically Java for windows. No pointers, automatic garbage collection, and very simple syntax.
I attended Borcon this year and Delphi 8 is a COMPLETLY different language. The VCL no longer maps to win32, it maps to .NET. If I am going to code for .NET Why use Delphi? Yeah I know it (my most fluent language), but why not use C# for a much simpler, and cleaner implementation. The C# Builder and Visual C# IDEs are nearly identical and are AWESOME. I saw a demonstration where the speaker designed his object model in UML in the IDE, he hit generate, and it generated the code...he then hit generate schema and BAM the DB was built to match the object relationships in real time. He ran 2 instances of the databse applicaiton and when the 1 one was modified the 2nd was AUTOMATICALLY updated via caching!!!! AWESOME stuff. I think he wrote 2 lines of code.
Torque in DirectX for .NET... now there is a project (or completly different engine -- but you lose cross platform capability).
People are also forgetting that Delphi uses heap memory NOT stack memory (as C+ can use). Delphi also does not provide for inline functions. Although both of these limitations can be overcome, again, WHY?
I am a professional Delphi programmer for 5 years, and I think Delphi every day for providing food on the table for the family, but sometimes you simply have to ask, am I using the right tool for the job?
The final code will still be roughtly %90-%95 the speed of the C++ engine. And again.. WHY bother? Just bend like a reed in the wind and learn C++ and add another feather to your cap. ;)
#14
Now, someone suggested Torque for DirectX... Hrmm, that might be something interesting. Ripping out all the OpenGL stuff and going straight DX. I know, I know, it eliminates the cross-platform stuff, but if you count straigt numbers these days, how many games are made for Windows? Now, let's compare to Linux and Mac. I would have to say that a pure DirectX implementation would be interesting.
However, I'm not going to be taking that on. I guess I'm off to learn the engine better. Thanks all for your input.
- Brett
12/20/2003 (2:22 pm)
I already know C++, that wasn't the point. I guess it was more of an itch to learn the engine deeply. And the best way I've found to learn something that intense is to re-write (thanks Jarrod) the code. I guess people are just to involved in trying to figure it out that they don't want to... err, figure it out. At least, not like I do.Now, someone suggested Torque for DirectX... Hrmm, that might be something interesting. Ripping out all the OpenGL stuff and going straight DX. I know, I know, it eliminates the cross-platform stuff, but if you count straigt numbers these days, how many games are made for Windows? Now, let's compare to Linux and Mac. I would have to say that a pure DirectX implementation would be interesting.
However, I'm not going to be taking that on. I guess I'm off to learn the engine better. Thanks all for your input.
- Brett
#15
Anyways, that's a totally different discussion but I felt the need to share my thoughts :)
Good luck with your journey through the engine source!
12/20/2003 (2:42 pm)
Brett: That's a dangerous statement you make there. More and more games are released for both Windows and Linux. So if you're talking about the commercial value of an engine that runs on both platforms, then there's a lot more to take into account then just the number of games currently released for Windows versus games currently released for Linux. After all, it is only since recently that Linux is being advertised as a workstation. Just compare DOS and Windows when the first 32-bit versions of Windows were released. Who would have thought back then that Windows would rule the PC gaming market?Anyways, that's a totally different discussion but I felt the need to share my thoughts :)
Good luck with your journey through the engine source!
#16
You seem to have a good grasp of both Delphi and C++...would you be interested in porting QuArK from Delphi to C++? This would seem to be a great use of your cross-compiler talents.
12/28/2003 (2:45 pm)
@BrettYou seem to have a good grasp of both Delphi and C++...would you be interested in porting QuArK from Delphi to C++? This would seem to be a great use of your cross-compiler talents.
#17
Why? OGL could do all d3d stuff (i think better).
If you want to use directsound, directinput... on windows, im with you. but ogl have everything on graphics.
And im sure that GG sells very much on mac & linux market, since windows market is plenty of AAA. For a indie, macs are great.
12/30/2003 (1:12 am)
I think is best do a new engine (based or not on torque) with delphi rather than try to port all torque sourcecode.Quote:Now, someone suggested Torque for DirectX... Hrmm, that might be something interesting. Ripping out all the OpenGL stuff and going straight DX. I know, I know, it eliminates the cross-platform stuff, but if you count straigt numbers these days, how many games are made for Windows? Now, let's compare to Linux and Mac. I would have to say that a pure DirectX implementation would be interesting.
Why? OGL could do all d3d stuff (i think better).
If you want to use directsound, directinput... on windows, im with you. but ogl have everything on graphics.
And im sure that GG sells very much on mac & linux market, since windows market is plenty of AAA. For a indie, macs are great.
#18
12/30/2003 (8:25 am)
On win32, Torque runs on DirectX. Only non-DX part is the OpenGL bit. If you use the DLL, then even that is DirectX.
#19
This platform independency is only possible when using OpenGL. Plus, TGE also provides an abstraction layer for the 3D stuff, so it is perfectly possible to use DirectX instead of OpenGL on Windows.
So, why cripple the engine by taking out OpenGL?
12/31/2003 (2:08 am)
Brett: One of the *major* strongpoints of TGE is is platform independency. It is well designed in that respect. In fact, the possibility to publish a game under Windows and Linux and MacOS w/o much porting work was the main reason why I bought this engine. Not everyone loves Microsoft :-)This platform independency is only possible when using OpenGL. Plus, TGE also provides an abstraction layer for the 3D stuff, so it is perfectly possible to use DirectX instead of OpenGL on Windows.
So, why cripple the engine by taking out OpenGL?
#20
12/31/2003 (2:58 am)
I think that this is an awesome dream, but you will spend less time to acquire average c++ skills . delphi is a good enviroment for db access programs and business programs and editors , but if you want the best performance you must use c++.
Associate James Urquhart
The amount of code to convert is ALOT.
Personally, the advantages of having such a port are nothing compared to the time and resources required to undertake such an effort.
In reality, it would be much more of a learning experience just learning c++ to code torque, rather than sticking with pascal and working with a buggy, if not, incompatible version of torque (knowing more than 1 programming language is a good thing)
The JEDI projects seem to be mainly Delphi *wrappers* around *c/c++* library's. They didn't recode the *whole* library (though in some cases this has happened (i presume), but its nothing as major as torque)
There is however a quake 2 port to delphi, but it is important to remember that quake 2 is written in C, and the engine is *much* simpler.