Convert to C# and WPF?

We are always looking for new tools to create to help facilitate the table top gaming experience. Let us know if you have an idea for a new gaming tool you'd like to see. (Note: this is NOT for feature requests on existing tools!)

Moderators: Azhrei, dorpond, trevor

User avatar
loogie
Dragon
Posts: 267
Joined: Wed Sep 05, 2007 4:53 pm
Contact:

Re: Convert to C# and WPF?

Post by loogie »

yeah.. you missed out on a link or name there...


but yes, c# doesn't do the rendering, just that being a microsoft language, it has a lot of easy functionality tied to IE, which makes it easy to use. I'm not trying to argue for it, because in the end thats going away from what i like about maptool.

but yes, i am honestly not experienced in java and much of its development... so i leave that to you :) i have heard of javafx, but i don't know what it is even.. so i can't say much about it... i would like to learn it however, sometime i have time :)

User avatar
jay
RPTools Team
Posts: 1765
Joined: Tue Feb 07, 2006 1:07 am
Location: Austin, Tx
Contact:

Re: Convert to C# and WPF?

Post by jay »


User avatar
RPTroll
TheBard
Posts: 3148
Joined: Tue Mar 21, 2006 7:26 pm
Location: Austin, Tx
Contact:

Re: Convert to C# and WPF?

Post by RPTroll »

Wow, that's a find for Maptool 1.4.

Other Languages Rendered by Lobo
One of the aims of the Lobo Project is to build a RIA platform where not only HTML and Javascript are first-class citizens.

Alternative "web languages" currently rendered by Lobo (0.98+) are the following:

* JavaFX.- JavaFX source files can be rendered by Lobo. JavaFX is a declarative language specifically designed with GUIs in mind.

* Java.- Lobo can load Java source classes directly, so long as they resolve to a GUI component class.


Looks like the last release of the browser was in January of 2009. Still, looks as though someone is still working on it as of October of last year.
ImageImage ImageImageImageImage
Support RPTools by shopping
Image
Image

User avatar
jfrazierjr
Deity
Posts: 5175
Joined: Tue Sep 11, 2007 7:31 pm

Re: Convert to C# and WPF?

Post by jfrazierjr »

PCGen uses it for their output sheets, though they were a version or two behind when I was working on the code with them. The lobo browser IS more html/css compliant (and includes js support) than swing is out of the box, BUT it is still 2-4 years behind modern browsers in full support of CSS 2 to say nothing of CSS 3 stuff.
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
Azhrei
Site Admin
Posts: 12050
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Convert to C# and WPF?

Post by Azhrei »

Yeah, Craig found Lobo about a year ago or so, along with one other whose name I don't recall. Definitely worth keeping an eye on...

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: Convert to C# and WPF?

Post by Craig »

loogie wrote:yeah.. you missed out on a link or name there...


but yes, c# doesn't do the rendering, just that being a microsoft language, it has a lot of easy functionality tied to IE, which makes it easy to use. I'm not trying to argue for it, because in the end thats going away from what i like about maptool.


Actually when it comes to HTML content in maptool using C# would be a step backwards. And this is not a dig at IE -- although I do love to make those :). In java you have have HTML in a lot of areas buttons, labels, tooltips etc etc etc. In C# you cant put an IE "window" in a button or a tool tip etc, not to mention it becomes strictly a windows only platform, and whats worse .NET and IE version dependent.

Darinth
Dragon
Posts: 424
Joined: Wed Oct 21, 2009 2:52 pm

Re: Convert to C# and WPF?

Post by Darinth »

I'd be much more likely to recomend plain ol' C++ over C# the more and more I've heard about it. C++ can be setup to compile on any OS with the right tweaks and runs substantially faster then Java. That said... I don't think the gains are unfortunately worth the time that developing such a port would take.
Loyalty is not blind, and it cannot be forced. It is a sincere bond formed out of respect and gratitude.

User avatar
Azhrei
Site Admin
Posts: 12050
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Convert to C# and WPF?

Post by Azhrei »

And the new announcement about MeeGo (Intel and Nokie joining forces on a mobile platform for Linux) where the C++-based Qt4 library will be the GUI of choice could make for some very fast (and portable) code. The code would need to be compiled for each target platform, but still...

User avatar
syntruth
Giant
Posts: 241
Joined: Mon Aug 18, 2008 7:15 pm
Location: Michigan, USA

Re: Convert to C# and WPF?

Post by syntruth »

Azhrei wrote:And the new announcement about MeeGo (Intel and Nokie joining forces on a mobile platform for Linux) where the C++-based Qt4 library will be the GUI of choice could make for some very fast (and portable) code. The code would need to be compiled for each target platform, but still...


Having developed in Qt (several one-off KDE apps and applets) I really like it. In fact, it's the -only- way I ever want to touch C++ ever again.

Darinth
Dragon
Posts: 424
Joined: Wed Oct 21, 2009 2:52 pm

Re: Convert to C# and WPF?

Post by Darinth »

You have to compile it for each OS, but IMO nothing beats native code running it an environment. It's efficient and there's no 2nd layer to produce it's own set of bugs.
Loyalty is not blind, and it cannot be forced. It is a sincere bond formed out of respect and gratitude.

User avatar
Azhrei
Site Admin
Posts: 12050
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Convert to C# and WPF?

Post by Azhrei »

I agree... with both of you: Qt4 is clean and elegant for the most part, and native code will always run best. :)

We know a language change for RPTools will never happen, but just to continue the fun discussion... 8)

C++ has far fewer programmers available using it. This, and the typical code bloat generated by a not-very-good C++ programmer, is why Linus is so against the Linux kernel having any C++ code in it. And Qt4 is not a language standard, it's a third-party library. That means even if you do find a bunch of C++ folks, they still need to learn the library. Java has the Swing GUI built into it. (Of course, if we switch to another interface layer, that problem may come back but the following issue is still there.)

And in terms of compiling native -- that would always be my first choice! The Java JIT has gotten very good in the last few years. There was a big push by IBM and Sun back in 2003 or so (don't remember exactly) and both of them put a lot of money and sweat into both speeding up the translation process and optimizing the output for the x86 platform. Of course, IBM focused primarily on POWER and Sun on SPARC, but many of the key engineers had Wintel hardware on their desk...

The "native compilation" is only a problem if your toolchain or libraries are not 100% portable. That issue is pretty much gone now. I think the Windows autoconf is slightly old and there was another tool that a little old, but nothing that would prove a difficulty for C++. There are differences that require slightly different build sequences, but nothing that can't be automated.

I've never written anything serious using Qt4, but I did some extensive playing around with Qt3 and the KDE desktop and I was pretty impressed. The KDevelop tool had a few bugs, but the signal-and-slot concept I thought was a great way to build an event-driven app. Although there were way too many weird things going on with the various macros! Man, that got very ridiculous some times. And because they were macros, using the wrong one would produce a whole series of errors messages which had nothing to do with your code. Unfortunately, they can't really fix that without building some kind of custom preprocessor.

Although... What if there was an extra step during compilation that was in front of the preprocessor and all it did was a rudimentary lexical scan looking for gross errors? I'm not sure it's practical, and it would be entirely optional, but it would've toned down my frustration level a little bit. :)

User avatar
syntruth
Giant
Posts: 241
Joined: Mon Aug 18, 2008 7:15 pm
Location: Michigan, USA

Re: Convert to C# and WPF?

Post by syntruth »

Just to be clear, I'm happy that Maptool is Java. ;) If for no other reason than I can easily improve my knowledge of the language from the code, but also because that cross-platform aspect is a no-brainer to me. For better or worse, right now, Java is the best tool for cross-platform.

User avatar
loogie
Dragon
Posts: 267
Joined: Wed Sep 05, 2007 4:53 pm
Contact:

Re: Convert to C# and WPF?

Post by loogie »

i've never really been able to learn C++ very well, java and C# came to me much easier... and easier C++ could only make me happier :P

scottellsworth
Kobold
Posts: 2
Joined: Sat Feb 27, 2010 9:18 pm

Re: Convert to C# and WPF?

Post by scottellsworth »

Darinth wrote:Anyways... in all seriousness. Java's biggest limitations are that it must run inside of the JVM which adds another step on to any attempt at processing commands and slows down applications even further and the lack of ability to dynamically allocate memory.


What follows is the long form of "the JVM is probably not the cause of any slowness. Look to the architecture of the software and the skill of the implementors." By all means create a C# app if that floats your boat - there are good reasons to use native systems, but JVM limitations should probably not be the key driver for that decision.

The JITC that is part of the current JDK produces pretty decent output - better than most C++ code I have seen generated by average programmers. (Hotshots who really know their architecture and platform can do amazing things, but those people are rare.) By using a final platform-specific JITC after creating the bytecodes, the JVM authors have the option to create better code than most static compilers will. (This is not that different from why CLANG/LLVM produces better code than the previous versions of g++)

Assuming the developer bothered to run a profiler, I have not seen a Java app with performance problems attributed to the JVM. I have seen them with performance problems attributable to poorly architected code, and sometimes, the ugly goes all the way to the bone. This is sadly common in FOSS projects, as people often take them up to learn the language, and may well implement a lot of stuff before they discover associative arrays/hashmaps.

As to the specific task of processing user-defined input, I have written Java apps that do this. They work about as well as the other languages I have used to process user-defined input (C++, python, some custom tools, et. al.) You still need to parse the user input template, generate a reasonable intermediate form, and then act accordingly on the user data in response. For any well implemented language, those are not computationally expensive, at least if the input data is not huge, and where it is, good languages have appropriate support (java nio, unix memory mapped files, and the C# cognate whose name I am forgetting at the moment.)

Again, by all means create a C# app if you like. We do projects in our own time because they are fun, and native apps have access to better controls than a cross platform app usually does, modulo a default impl and some JNI.

User avatar
loogie
Dragon
Posts: 267
Joined: Wed Sep 05, 2007 4:53 pm
Contact:

Re: Convert to C# and WPF?

Post by loogie »

If I was to make a suggestion for a conversion of Maptools... I would have to say try to create it using Adobe's FLEX... Its a really great app, open source, works on all browsers for all OS (that support flash.. oh wait thats all of em)... and has some crazy features... Basically anything flash can do FLEX can as well.. including creating buttons and such...

if you look up the VTT program Scenegrinder it can do everything that does, and probably better, since its not relying on HTML5 and java, which isn't designed for graphical animation and such as much as FLEX is... also with built in options like dropshadows, blurs, bevels, etc that can be rendered on the fly... it is a very promising candidate...

I have been playing around with the concept myself, but I am fairly new to FLEX... I can tell that it is possible.. its just getting to the point when I'm comfortable in trying :P

Post Reply

Return to “Ideas for New Applications”