We Keep Coding

Porting existing c# to java (lots of pinvoke/user32.dll) - Pitfalls?

As states we are in the process of considering porting an existing app which uses the user32.dll quite extensively. Mainly for stuff like taking screenshots of the screen and moving the mouse around.
Using something like JNA we should be able to do the same thing, but are there limitations? Things we should be aware of
Thank you

As a first point I'd have to ask why? If you're using JNA you're losing all the cross platform nature of Java anyway, and losing the tight integration with Windows that C# gives you. There's no limitations that'd stop you doing it, but if you are just tying yourself to using native code anyway then I'd say there's not much point.
If on the other hand you're looking to gain cross platform capability and you're looking at porting, then you can take screenshots and move the mouse around using the Java Robot class easily, no native code required. If you are rewriting in Java, that's by far the approach I'd recommend.

C# XNA: AI Engine?

I'm developing a game with zombie running around in a swamp. I want AIs to have functionality like "chase this target" or "run away". A major stumbling block is pathfinding. Is there a good pathfinding/AI engine in XNA, or should I roll my own?
Does anyone have any experience with this: http://www.codeplex.com/simpleAI?

you may want to look for A-Star algorithms... here is an article that talks about it in the context of a winform, but mentions XNA.

Roll your own! Seriously.
I take it you're making this game as much for the enjoyment of coding, as you are hoping for fame and riches? Pathfinding is one of the staples of AI, and is a well studied and documented topic. It is an excellent introduction to a field you'll need knowledge of in future game endeavours.
The A* Algorithm (as mentioned by others) is the standard solution to this problem - but try other approaches: line-of-sight, scripted movement, flocking... often you can derive interesting behaviour from combining a few techniques.
For a book on the subject, try AI For Game Developers - not the best in the field, but certainly an accessible introduction for the lay-coder.
Have fun mucking about with the zombies!

http://xnapathfindinglib.codeplex.com/
http://swampthingtom.blogspot.com/2007/07/pathfinding-sample-using.html

To everyone that's suggesting A*: you generally wouldn't put vanilla A* into a game. There are a lot of improvements and extensions for A* including (but not limited to) IDA* and transposition tables, that improve performance with A*-based search.
You might want to use a library to get you started but you may ultimately benefit more from your own custom implementation, using your own data types native to your app, instead of having to marshall data back and forth. But you'll need to profile to be sure.

The XNA Creators club has samples for Chase and Evade and Flocking.
I've just started down the path, but they seem to have some good resources on the creators.xna site.
I'll be using some pathfinding logic in my game, the A* Algorithm seems to be the winner for me.

Game engine development question [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I am thinking of making a simple game engine for my course final year project. I want it to be modular and expandable so that I can add new parts if I have time. For example I would make a graphics engine that would be completely independent of the other systems, once that was finished I could add a physics engine etc.
I would also want to make a tool set to go with this engine. For the tools I would like to use C# but I am not sure about the libraries. My question is, if I want a C# GUI program, can I reference a library written in C++? Also would there be any performance problems etc. if I made some of the libraries in C# but wanted to use them from a C++ game.
I would like to avoid C++ as much as possible, my experiences have shown that development time can be a lot higher for a project over that of using C# or Java etc. My graphics development would be in OpenGL, this is all I have been taught. We have only done this in C++ but I have seen that projects such as SharpGL allow for the development with C#. Is there any performance issues with this. I am not looking for a blindingly fast, top graphics game. It will most likely be something simple to show my engine working. My engine probably won't be that great either as I only have a year and am working on my own.
Any advice on this would be appreciated. I am still really in the planning stages so it wouldn't be too much work to completely change what I want to do. I would just like to preempt any major problems I might have.
Thanks

If you can pull this off even under a relaxed set of goals, you're set for a great project. First, you need to get a grasp of scope:
How long do you have to work on the project?
How many people are working on the project?
If you can only create one "piece of the pie" on your own, which one would you pick? Use this to establish a working plan to make sure if you don't get as far as you'd like, you still have enough to make the work show as a great project.
A game engine is a big development task. A game engine with a toolchain is an enormous development task. In a lot of ways, choosing a smaller but more challenging task is preferable because it shows higher-level thinking about problem solving, which is greatly preferred by academics - double that if you are CS and not [Area of] Engineering. Since you are working in managed languages, things you may want to consider are:
Expressing gameplay logic (rules of the game) in a clean manner so as to provide an efficient and reliable path from designer->developer->tester. If you want, this could absolutely include the manner in which you describe the rules (Custom editor? Code API? DSL?)
Game AI has no shortage of extremely challenging problems.
Physics and graphics are interesting and I believe managed languages will eventually be used in these areas, but you may find yourself a bit more limited in your ability to solve these problems. If I were going to work in this area now, I would be trying to answer: "If I could use a managed language for writing [graphics|physics] code without hurting performance, what kinds of [language|runtime] features make the most difference in improving the expressiveness, correctness, maintainability, and reliability of the resulting programs." This goes way past simply having garbage collection and pointer safety.

You should look into XNA. It performs quite well, and from what I've heard, is quite easy to work with.
About referencing C++ code from C#: It's perfectly doable, though it will take some effort from your side to get it right. C++/CLI can work as an intermediate wrapper or you can use P/Invoke. Just remember that C++ is unmanaged and that you will need to do some manual garbage collection, which can be somewhat icky in a managed environment like .Net. Perfomance in the C++ -> C# bridge is okayish, but I'm unsure how it will perform if you need do 100.000 calls to a math-library each second. I guess a small test would be good.. I'll see if I get time to do this later today, though I somewhat doubt it :)

When creating a graphics engine (I'll only really speak about graphics as that is my area of expertise), these are a few of the choices you need to make EARLY in the project:
1) Is it an indoor and/or outdoor engine?
2) What sort of visibility system are you going to use?
3) Forward or deferred renderer?
4) How will you have animation hierarchies?
5) Dynamic or static lighting?
6) How are you going to handle transparency?
7) How will you handle a 2D overlay?
8) What mesh formats will you use? Roll your own?
Bear in mind you need a GOOD solid vector/matrix library and preferably a full maths library that will help with things from eulers to quaternions to axis-aligned bounding boxes.
Do a lot of research as well. Try to find out what the potential problems you are going to face are. Remember things like changing a texture or a shader can have HUGE impacts on your pipelining. You need to minimise these as much as possible.
Bear in mind that getting a rotating bump mapped mesh on the screen is simple by comparison to getting an engine running. Don't let this put you off. It should be no problem to write a fairly simple game rendering engine in a matter of months :)
Also ... find communities specific to this area. You will get a lot of good (though non-OpenGL-centric) information off DirectXDev. There is a fair bit of general game development algorithm information available at GDAlgorithms. There is also an OpenGL specific mailing list here.
Its worth noting that DirectXDev and GDAlgorithms, at least (I don't know so much on the GL mailing list) are populated by some VERY experienced 3D engine and game developers. Don't post up lots of "beginner" questions as this does tend to breed contempt among the members. Though the odd query or 2 at whatever level (beginner to advanced) will get amazing answers.
Good luck! I wish I'd had the chance to do this at University. I might not have gone off and joined the games industry and enjoyed an extra year of sleeping late ;) hehehe

Why do you need any C++ code?
There are already several wrapper libraries exposing OpenGL or DirectX to .NET, such as SlimDX (which, as the name implies, is a much thinner, more light-weight wrapper than something like XNA)
If you're more comfortable with C#, there's no reason why you couldn't write your entire game in that.
Performance generally won't be a problem. In most cases, the performance of C# code is comparable to C++. Sometimes it's faster, sometimes it's slower. But there are few cases where C# isn't fast enough. (However, there is a significant performance cost to interfacing between native and .NET code -- so doing that too often will hurt performance -- so the trick is, if you use native code at all, to have sufficiently big native operations, so the jump to/from .NET isn't done too often)
Apart from that, a word of advice: Don't bother writing an "engine".
You'll be wasting your time producing a big monolithic chunk of code which, ultimately, doesn't work, because it was never tested against the requirements of an actual game, only what you thought your future game would need.
If you want to experiment with game development, make a game. And then, by all means, refactor it and clean it up and try to extract reusable parts of the code. But if the code hasn't already been used in a game, you won't be able to use it to build a game in the future either.
The engines used in commercial games are just this, code extracted from previous games, code which has been tested, and which works.
By contrast, hobbyist engines pretty much always end up taking 2+ years of the developer's time, without ever offering anything usable.
The whole concept of a "game engine" is flawed. In every other field of software development, you'd frown at the idea of one vaguely-defined component doing basically "everything I need to make my product". You'd be especially suspicious of the idea that it is a separate entity that can be developed separate from the actual product it's supposed to support.
Only in game development, which is by and large stuck in 80's methodologies, is it a common approach. Even though it doesn't actually work.
If this is a school project, I'm sure whoever is supposed to grade it will appreciate it if you apply common good software practices to the field. Just because many newcomers to game development don't do that (and prefer to stick to some kind of myth about "engines"), there's no reason why you shouldn't do better.

Make sure your scope is feasible.
As a teenager I went through the build-my-own-engine phase, a few years later I realized I would have gotten a whole lot more done if I had just used pygame and pyopengl and not wasted the effort.
Check out the forums at gamedev.net.

Sounds to me like you have a pretty good plan for your project. (I get your point about XNA in your comment to #Meeh)
You can interop with C++ via P/Invoke directly or COM, you could also I guess come up with some SOA way of doing it, but to be honest as yucky as this sounds I would be inclined to target COM as your API lever of choice...why? because then you open up your API to a lot of common client language's not just C# and VB.NET you will also get Delphi, VBA, Powerbuilder etc.
Performance should not be a problem as the API entry points are just to kick of the work and transport data structures, the real work is done in your library in native code, so don't worry too much about the perf. ATL will be your friend with creating COM Classes that provide entry to your Library.

Whilst it's certainly do-able to bridge between C++ and C# (Via managed C++ is a good way to go if the interface is complex, P/Invoke for a very simple one), for tool<->engine communication I might suggest instead a network based interface. This is ideal for a high-ish level interface, such as you might want for a level editor/model viewer or such. An actual object modeller is not such a good target. What tools do you envision?
If you do it this way you gain the ability to connect to remote instances of the engine, or multiple instances, or even instances running on different hardware platforms. It'll also teach you a bit about sockets if you don't know them already.

Time to transfer skills to java and resources

I'm thinking about learning Java. I'm already a more than competent c# developer. Has anybody else been in a similar situation? Roughly how long (whilst doing a typical 9-5 job) did it take you to transfer your skills? What resources would you recommend?
(When talking about resources, I specifically mean resources aimed at developers who want to learn Java, not newbie material)

I studied Java at university, and did c# at work.
You will find the Sun Java API (Javadocs) to be very informative and will help you dearly. You can find it here. This website should be the first to consult if you need a query, as it is brief, and up-to-date - similar to the MSDN Library for c#.
Also, Java has a strong community who will be willing to help # the forums.
Finally, I think its best to learn Java through practice and experimentation over theory. You will need a good IDE to start you off and there are plenty to choose from. Eclipse and Netbeans are notable Visual Studio contenders, but personally I prefer JCreator(albeit the version with intellisense is not free). It maybe text based, but you have greater control IMO.
If you are going to create GUI applications, then you should learn about swing. Again, the guys at sun provide excellent tutorials on the matter.
There are also books:
Java in a nutshell is a nice book. Click for google preview.
Java: the complete reference By Herbert Schildt is one I would highly recommend. Google Preview.

I'd recommend these books:
Effective Java (Joshua Bloch)
Core J2EE Patterns (Deepak Alur; John Crupi; Dan Malks) - sort of out of date, but still useful for understanding the history of J2EE. A lot of this is still applicable.
Concurrent Programming in Java (Doug Lea) - good guide to Java threading
Here's a more comprehensive list:
http://www.javalobby.org/articles/5books/full.jsp

It shouldn't be a difficult switch. Java is pretty much a subset of C# (Operationally) since C# was a Java clone that has mutated since it was split. (Everyone here remember the fiasco when MS tried to embrace java by modifying it so it would only work with windows, was sued by Sun and then made J++ and C# instead?)
The biggest difference will probably be the libraries, but if you are proficient at C#, then you shouldn't need to do anything more than study the Javadocs to pick up the new libraries.
EE might be a bit of a jump, but that's a whole 'nuther world.
For me, the nicest thing about Java is the minimal syntax. There are very few surprises or tricky parts to remember (Well, Generics have a kind of tricky syntax to implement, but using them is pretty straight-forward). If you agree with this or not--it does tend to make the learning curve a bit more shallow.

I started in Java and went to C#.
I will be honest with you; going back to Java won't be so easy, depending on how you started. It's going to change your world a bit. J2EE is quite different from ASP.NET, even though it looks a bit the same. Forget lots of things you used to hold dear, like == of strings, and switch on strings, and properties, and other such nicities. Oh, and prepare to be welcomed by checked exceptions.
Don't get me wrong, I love Java, and it's a great language, but you'll need be wary of the differences.
I would say a fun way to learn would be to write a program simultaneously in Java and C#, and see how you would do each thing, and note the differences.
I think you may find books hard to read, as they'll cover the basics, which will be boring for you, so you may skip critical things.
Learn by doing :) That is my approach.

.NET Library to draw routed lines avoiding obstacles

I've created a workflow/flowchart style designer for something. At the moment it is using relatively simple Bezier curve lines to connect up the various end points of the "blocks" on the workflow.
However I would like something a bit more intuitive for the user. I want the lines to avoid obstacles like other blocks (rectangles) and possibly other lines too.
I prefer the bezier splines rather than polylines because they are prettier and seem to fit in better with the designer in general. But am willing to compromise if they are much harder to accomplish.
I know there is a whole load of science behind this. I've looked into things like Graphviz, Microsoft's GLEE and their commericial AGL (automatic graph layout) library.
GLEE seems to barely be production worthy. And their commercial alternative is, well, a commercial alternative... it's quite expensive.
Graphviz doesn't seem to have been ported to .NET in any way.
I have seen a polyline implementation used by Windows Workflow Foundation for its "freeform designer". And this works, just, but it is not really of production grade appearance.
I'm surprised there isn't some plug'n'play .NET library for this type of thing? Something like:
Point[] RoutePolyline(Point begin, Point end, Rectangle[] rectObstacles, Point[] lineObstacles);

I haven't tried it (although I'm a happy customer of their Gantt product), but ILOG have a similar tool here.
To quote:
The ILOG Diagram for .NET algorithms
share generic goals such as:
Minimizing the number of overlapping
nodes
Minimizing the number of link
crossing
Minimizing the total area
of the drawing
Minimizing the number
of bends (in orthogonal drawings)
Maximizing the smallest angle formed
by consecutive incident links
Maximizing the display of symmetries
Supporting incremental layout,
partial layout, subgraphs,
intergraph links and nested layouts
Perhaps worth a look, at least.

Diagram.NET is a free, open source diagramming library in C#. It hasn't been updated in quite some time, but it's certainly worth a look - there may something there which you can reuse.
http://www.dalssoft.com/diagram/

Are you limited to managed code only?
I did not have this restriction and the past and effectively integrated GraphViz with .Net. What we did was call an external process containing the natively compiled "dot" and parse the result in a .Net object model. It worked perfectly and was fast enough for our needs.
I'm sure you could do better and easier with C++/CLI today.