I'm writing a strategy game in XNA and VB.NET. This technology combination looked like quite a good choice, right until I decided I would like to switch to MonoGame (but keep my game logic in VB.Net intact).
The problem is that MonoGame currently does not support VB.Net. I did some research and it seems I have basically two options:
Rewrite my code to C#
Write a small C# wrapper around MonoGame and turn my Game Logic code into a library
Needless to say, both of these options suck. Am I missing another option here? I don't mind giving considerable effort into making this thing work in MonoGame, but rewriting just isn't an option.
My findings so far:
While browsing the web, I stumbled across a MonoGame template for VB.Net. While it looked to be just what i needed, it crashed upon loading even after running a plain new project. I then proceeded to google for the error, but got nowhere near running the thing.
To explain my technology choice (because someone will ask):
Why XNA? I used it before, I'm familiar with it and even though it's outdated, it suits my needs perfectly and should still work for a couple years.
Why VB.Net? I have huge experience with it and I prefer it's syntax over C#. This is important to me since I'm writing a rather large-scale strategy game and keeping the code clean and understandable is essential.
Why not C#? Experience. I worked with C# for a little over a year, but it ain't natural yet. VB is.
I found a solution. A failry painless way to make this work was the MonoGame template I mentioned earlier. There are several small issues with that approach, but nothing too problematic.
Issue #1: Error when starting MonoGame Project.
After running a new VB MonoGame template project, a nasty error is thrown upon startup (System.TypeLoadException in mscorlib.dll). This happened since the template reference an incorrect version of MonoGame library (I'm using windows and there was an android library linked to the project).
Solution: Remove the MonoGame reference from your new project, and use browse to add back the correct version.
Issue #2: Content project missing in MonoGame.
MonoGame does not have a Content Project, but rather a folder called 'Content', which honestly behaves just like the project. Just add all your content from the XNA content project to this folder and it works. Amazing!
What it failed to do however is loading sounds and fonts from uncompiled content files (e.g. myFont.spriteFont). For MonoGame content, sound and font files had to be replaced with their compiled version from the XNA project.
Plus there is one small nuisance - each content file must be marked as 'Copy always' or 'Copy if newer' (default 'Copy Never'). I didn't really find a way to change this for all of them at once, but it doesn't take that much time.
Issue #3: XNA project was automatically resolving imports.
XNA project had one 'Syntactic Sugar' advantage. I never realized it until i switched to mono, but I never saw a single line called 'imports' in my XNA project. I made massive use of this, having many small classes which consisted only of few lines and used a 'list' of 'Vector2', etc. After porting to MonoGame I had to go through several hundred compile errors due to missing imports.
I'm still wondering whether this was caused by the XNA project or some other config in Visual Studio itself, but I must say I liked it. If you know something about this, please do share.
Conclusion:
Looking back, the process of porting to MonoGame took me about a month to figure out - but when I finally had all the pieces, the entire process took about 4 hours for 100+ source file + 100+ content file project. I'd say the guys at MonoGame did a tremendous job, and so did the gentleman who modified the template to work with VB.Net.
Related
I have a few different projects that all get mixed and matched into different types of solutions.
For projects, I currently have
EngineProj: c++, built as a .lib
GameProj: c++, built as a .exe
EditorProj: c++/clr, built as a .exe
For solutions, I currently have
Game: c++, built with EngineProj and GameProj
Editor: c++/clr, built with EngineProj and EditorProj
This has worked great for games. I have been able to make a few different game solutions that keep reusing the shared EngineProj.
The Editor solution has EditorProj build a .exe with a WindowsForm object called EditorForm. This is used to edit generic game data that is common for all game solutions.
Now, though, I want to be able to do the same thing for my Editor that I do with my games. I want to be able to make game specific versions of the Editor that reuse as much project setup and code as possible. Here is what I am working towards.
For projects, I am planning
EngineProj: c++, built as a .lib
GameCoreProj: c++, built as a .lib
GameExeProj: c++, built as a .exe (a very thin and small project)
EditorCoreProj: c++/clr, built as a .lib
EditorGameExeProj: c++/clr, built as a .exe
For solutions, I am planning
Game: c++, built with EngineProj, GameCoreProj, and GameExeProj
GameEditor: c++/clr, built with EngineProj, GameCoreProj, EditorCoreProj, and EditorGameExeProj
I am having troubles getting my GameEditor solution to come together.
The idea is for EditorCoreProj to provide the same EditorForm that EditorProj did; only in a .lib instead. EditorGameExeProj would then build with GameCoreProj.lib and EditorCorProj.lib. EditorGameExeProj would support a new WindowsForm object that derives from EditorForm, but implements new features unique to the needs of GameCorProj.
Various forms of unresolved externals have been plaguing me for a couple days now.
It seems that my issues stem from the fact that EditorCoreProj is a c++/clr project.
I read many articles and tried many different approaches, but eventually I found some reading that suggested that making a .lib would never work. It sounds like c++/clr .libs are not supported.
So, then, I tried making EditorCoreProj build as a .dll. For hours, I tried to get EditorGameExeProj to import the .dll. I read that maybe I need to tag everything for export and import. That sounded like a lot of work, and so I started just making some test solutions. However, that continually resulted in unresolved externals, too.
I am pretty new to making a .dll; I have always preferred .libs. Maybe I am just encountering newb issues with .dlls. At this point though, I have spent a couple days trying to get this setup.
And so, finally, my question.
Am I headed in the right direction? Maybe there is something much easier I should be doing?
Thank you for your time
I ended up sticking to the plan, and got everything working. I don't know if there was a better route to take, but this does full-fill all of my needs.
I'm currently trying to compile an old program (made with C++ builder 2 or 3) with the "current" Embarcadero RAD Studio XE2.
So, I was wondering whether there is an easy way to use the old code, as Borland once claimed to be fully compatible to lower versions... however I couldn't find a "project-file", only source-code (.cpp, .h, .res, etc.).
I tried to "add to project" the main .cpp, however there seem to be some wrong include-paths... it also seem to use the OWL-package and includes its important source-files...
I'm a bit confused which type of main project I have to open first, since you need to open a new project before adding the source to it. As the running .exe has a GUI, I tried a Form-Window first, but it may be better to use a console or service as the real form is produced within the code as far as I understand.
So, after installing OWL and correcting the include-paths, do you think it should be running fine? Or is there something else to take care of?
If your old project was using OWL, you're probably well outside of the supported upgrade path.
That being said, valid C++ code should still compile and work and I've heard of people using OWL with recent versions of C++Builder. (via OWLNext)
Regarding your confusion as to which type of project to use, I believe a console application would be your best bet. A forms application is completely wrong, that will bring in the VCL and give you no end of problems trying to reconcile the different windowing systems. A service application is a completely different beast as well, and isn't meant for GUI applications. A console application should work, but you'll need more. The OWLNext project has a wiki that should help quite a bit.
I come from a Mac background. I developed games with Xcode and Objective-C frameworks.
Recently I moved to Windows and decided to use VB.NET for a while. It is cool.
Here is my intention:
I want to develop a Windows platform game. The game is rather complex, and I will need some kind of "engine" or "editor" to be able to edit my levels and properties easily. The idea is that I can build most of the game with this editor and then the editor will compile the project files and resources into one .exe file for gaming.
Fortunately, I was able to create my editor with VB.NET. I am able to edit levels and such. However, I am not sure about the "compilation" part to create a .exe file and play the game.
Basically I am at the point of designing the "Compile" button in my editor. But I am clueless. I could not find much documentation regarding this topic.
My editor has all variables and information the game needs to run.
I assume that this .exe file is like another VB.NET project (produced by my editor) that will basically take the data it comes with and "run" the game loop alright.
Any ideas, links, etc? Thanks.
**Note: my game is a 2d game with, probably, a vast amount of sprites and such.
Visual Studio is a fantastic IDE for development of Windows apps. Compiling the project is pretty simple. You just compile and it gives you an exe that's in the .NET Framework. Microsoft also has XNA Game Studio to help with game design if you want to look at gaming frameworks for .NET.
Also, you can take files from your editor if they generate vb.net and use the vbc compiler command to compile them into libraries, executables, whatever you like. The command could be something like this:
vbc /reference:Microsoft.VisualBasic.dll File.vb
Here's a link to the .NET command line compiler for VB.NET.
I'm not entirely sure what you mean here. Are you saying that you have an editor (something like a level or map editor?) for your game, and that you want the output of this editor to be embedded into the exe for your actual game application when it compiles?
If that's the case (or something similar to it) then you'll first want to consider how to persist your data to file. Then you could manually add files you've created as embedded resources. Or better yet, create a file type that holds as many 'levels' or 'maps' as you need and embed that. This way as you create more they will just get added to that file and you won't have to keep adding more embedded resources.
I need to build a fairly simple app but it needs to work on both PC and Mac.
It also needs to be redistributable on a disc or usb drive as a standalone desktop app.
Initially I thought AIR would be perfect for this (it ticks all the API requirements), but the difficulty is making it distributable, as the app would require the AIR runtime to be installed to run.
I came across Shu Player as an option as it seems to be able to package the AIR runtime with the app and do a (silent?) install.
However this seems to break the T&C from Adobe (as outlined here) so I'm not sure about the legality.
Another option could be Zinc but I haven't tested it so I'm not sure how well it'll fit the bill.
What would you recommend or suggest I check out?
Any suggestion much appreciated
EDIT:
There's a few more discussions on mono usage (though no real conclusion):
Here and Here
EDIT2:
Titanium could also fit the bill maybe, will check it out.
Any more comments from anyone?
EDIT3 (one year on): It's actually been almost a year since I posted that question but it seems some people still come across it every now and then, and even contribute an answer, even a year later.
Thought I'd update the question a bit. I did not get around to try the tcl/tk option at the end, time constraint and the uncertainty of the compatibility to different os versions led me to discard that as an option.
I did try Titanium for a bit but though the first impressions were ok, they really are pushing the mobile platform more than anything, and imho, the desktop implementation suffers a bit from that lack of attention. There are also some report of problems with some visual studio runtime on some OSs (can't remember the details now though).. So discarded that too.
I ended up going with XULRunner. The two major appeals were:
Firefox seems to work out of the box on most OS version, so I took it as good faith that a XULRunner app would likely be compatible with most system. Saved me a lot of testing and it turned out that it did run really well on all platforms, there hasn't been a single report of not being able to start the app
It's Javascript baby! Language learning curve was minimal. The main thing to work out is what the additional xpcom interfaces are and how to query them.
On the down side:
I thought troubleshooting errors was a sometimes difficult task, the venkman debugger is kinda clunky, ended up using the console more than anything.
The sqlite interface is a great asset for a desktop app but I often struggled to find relevant error infos when something didn't work - maybe i was doing it wrong.
It took a little while to work out how to package the app as a standalone app for both PC and Mac. The final approach was to have a "shell" mac app and a shell pc app and a couple of "compile" script that would copy the shells and add the custom source code onto it in the correct location.
One last potential issue for some, due to the nature of xulrunner apps, your source code will be deployed with the app, you can use obfuscation if you want but that's something to keep in mind if you want to protect your intellectual property
All in all, great platform for a cross-platform app. I'd highly recommend it.
Tcl/Tk has one of the best packaging solutions out there. You can easily wrap a cross-platform application (implemented in a fully working virtual filesystem) with a platform-specific binary to get a single file executable for just about any modern desktop system. Search google for the terms starkit, starpack and tclkit. Such wrapped binaries are tiny in comparison to many executables these days.
Many deride Tk as being "old" or "immature" but it's one of the oldest, most stable toolkits out there. It uses native widgets when such widgets exist.
One significant drawback of Tcl/Tk, however, is that it lacks any sort of printing support. If your application needs to print you'll have to be a bit creative. There are platform-specific solutions, and the ability to generate postscript documents, and libraries to create pdfs, but it takes a little extra effort.
Java is probably your best bet, although not all Windows PCs will necessarily have Java (most should). JavaFX is new enough you can't count on it - you'll probably find a lot of machines running Java 1.5 or (shudder) 1.4. I believe recent Mac OS still ships with 1.5 (latest version may have changed to 1.6).
Consider JavaFX
It would run everywhere with a modern JRE ..!
AIR could be an option, but only if you don't mind distributing two different files (the offline runtime installer and your app), and expecting the user to run one and then the other. You do have to submit an online form at Adobe's site saying you agree to distribute the offline installer as-is, rather than digging out individual DLLs or whatever, before they give you the installer.
Unfortunately there's currently no way to get both an AIR app and the runtime to install from one file though. I'm not sure what the deal with Shu is, or whether it's doing anything that isn't kosher.
i would recommended zink. it has all the functionalities you require for desktop. however, the las time i used it it was a bit glitchy.
i was hung up by trying to write a 6M file to the disk. thought it trough and changed the code to write 512K chunks at a time (3min work, fast).
probably it still has some little annoying glitches like making you think on root lvl but the ease of use and the features are just way too sweet to ignore.
Does anyone know of an alternative IDE for Sybase Powerbuilder? It feels pretty clunky, after working with VS2008 and Eclipse.
If not, has anyone successfully worked with this language outside the IDE? I'm not against using a simple text editor, but I find edit-import-regenerate-test-export-edit is clunkier than simply using the Powerbuilder editor.
To date, the only tools I have had any success with are:
PowerGen, for builds (with NUnit and CruiseControl.NET)
ConTEXT, which has syntax highlighting for Powerbuilder
PBL Peeper, which has some interesting features not present in the IDE
EDIT: I added a bounty to draw some wider attention to the question. It would be a very nice thing to have, if it exists.
EDIT: Well that was disappointing. The bounty apparently did not cause even 1 new person to look at the question.
None that I'm aware of, although you could probably use a source control tool, edit in your source control repository, and Get Latest Version from the PB IDE to shorten your text editor cycle. Be warned that there are hacks required to edit anything over 128 ASCII. (My guess is that this is to allow everything Unicode to be source controlled in the most restrictive source control tools.)
As Paul said, PB12 is coming with based on the Visual Studio shell, and will include things like collapsible code blocks, Intellisense, etc.... However, for PB12, this will only be used for WPF targets and a few .NET-type targets (like assemblies), last I heard. Win32 targets will continue to use the "classic" IDE.
Good luck,
Terry.
P.S. Thanks for the PBL Peeper compliment.
The PowerBuilder IDE is clunky, but I don't think developing completely outside the PowerBuilder IDE is a good idea. I think there are just too many dependencies right now.
However, the IDE for PowerBuilder 12 will be built using Microsoft's Visual Studio Isolated Shell so it ought to be much better when that is released. Also, I believe they'll be doing away with the PBL format which ought to make source control much easier to work with.
Certainly something to watch.
What I do is right-click the object and edit source. Then I copy the text and paste it into Notepad++ to edit. I copy and paste back to PowerBuilder, then I can save and see any errors. I've got a fairly decent User Defined Language for PowerScript if anyone's interested.
Added:
Please be aware that I've seen the PB Source editor corrupt DataWindows. They were all large DataWindows. To be safe always export DataWindows to edit.
One tool that will most probably make your PB experience way better is Visual Expert, which provides a good source browser. Such a tool should have been integrated into the PB IDE a long time ago, IMHO. Only problem is that it's not free, as opposed to the other tools you mention.
Regarding using external source editors, you can probably take advantage of OrcaScript, which is a scripting language that lets you perform actions such as export and import of PB objects from outside of the IDE. It will require some effort, but you can setup a basic dev env using batch files with ORCA scripts and some additional external tools. However, this setup will lack any visual editing capabilities, which means no (feasible) GUI or DW work. If you're mostly into NVOs, it could work. But then if that's the case, why use PB in the first place?...
I too have heard PB12's use of VS will be limited to some .NET stuff, which will probably benefit only a very small portion of the PB programmers community. I'm afraid the rest of us are stuck with the awful IDE for years to come.
Other than exporting the source and editing it I don't know of another IDE for PB. One problem you may have is that the exported source contains a lot of syntax that is not documented in the manuals. The PB IDE generates this code but there is no support for creating it by hand. I think you are stuck with the PB IDE
In my modest five Years of experiences starting with Powerbuilder 5/6, now using PB 10, I tempt to :
build my own browser from the classdefinition object based on Powerbuilder
tried to use autohotkey in order to open datawindows comfortable (we have several thousands in the project and i am two-finger-driven)
truly investigated in the idea using an external editor/IDE suppoted by an autohotkey script which is undermined by sybase allowing only mouse-click-usage of PB
using Visual Expert which is neither a truly integration in the IDE, nor is really worth in analyzing datwindow/powerscript interaction
ending by build hopes on PB12 Visual Studio, which lacks - depending on compatibility issues - ...
... i came to the conclusion that there will be no chance in improving Powerbuilder to an state-of-the-art language
In my philosophy - I obtained during those years - I distinguish between two types of OOP-oriented languages:
the one that award using object-orientation like C#, Python, Ruby (C++) etc. and very much the Java-Eclipse/Netbeans-Universe does
the other one that punish using object-orientation like Powerbuilder and the old Visual Basic, for example (which is causative the OOP-Idea comes afterwards and is "plugged in").
Especially the demand that all object should always be compiled (regenerated) and that you could't work with ancestors and descandants concurrently makes it painful to use real OOP.
...In memory of the good old Unix(Solaris)/C++ days...
I was researching a replacement solution that would be similar to PowerBuilder and I came across two that caught my eye.
The first was 'React Studio' https://reactstudio.com/ which I found via Alternativeto.net .
And the second was from an ad at the top of some Google searches but it was similar enough and looked good enough at first glance for me to want to take a closer look at it, and it's called 'Servoy' https://servoy.com/ .
Still researching but I currently have React Studio at the top of our list.
The TextPad editor has a syntax definition file for PowerBuilder 6.x contributed by anr#aon.at that I downloaded for free and customized several years ago. It works fine for later versions (including 8), doing keyword color highlighting on PowerScript srx files. Editing large source files in PB could get it to crash so it's usually safer, faster and more convenient to export to srx file, edit outside the IDE then re-import.