Access ain't so bad

I have been working on an app for work. It's written in C#, and it's a data app. One database, and several instances of the app connecting at possibly the same time. I haven't really developed anything with data integration before, so I went hunting for info.

I was really surprised at how hard it was to find what I needed. Starting simple, all I wanted to do was to type some text in a text box, then save it to the database. It IS really simple to do, but the hard part was finding how. I eventualy got it.

I started by using SQL Express, without really thinking about it much, but I realized that it was overkill. I switched to Access, since all company computers have that (just in case, I still don't know if the client app needs to run on a computer that does have Access. My guess is no, but better safe than sorry. Call me lazy, I am). Due to ADO.NET, the type of database doesn't really matter, so most of my calls remained the same between using SQL and Access. Cool. I hear LINQ goes even further than ADO.NET, but I'll leave that learning curve for the future.

I also had to share data between a parent and a child form. That was actually a lot harder than it had to be. MS should really have some pipeline between parent to child and child to child. Once you set up an event handler it works great, but it truly is a pain compared to what I think it should be (declare the variable in either form and using syntax, explain to the compiler "this variable belongs to this form, but that, that, and that form can access it". Would be great).

I have the interface almost ready, and the form for adding a new record to the database is working great. Next will be figuring out how to have several instances working at once without corrupting the database. I could have looked it all up before I started but I have been finding out that is not the most efficient way to work, at least for me. I rather get going, get something working somewhat, then fine tune it and add what's left. Seeing something up and running, even in a preliminary stage, is key to keeping me motivated.

Why am I talking about this? Well, C# skills will definitely help me out in TowerSim. That and it's for work. Work pays bills, which allow me to sit in my idle time and code TowerSim. Logic is a beautiful thing.

Charged particle precipitation

I guess they could have chosen this title as their company name, but Electric Rain sounds a lot cooler. I have been super busy at work, creating a pretty important presentation for this Thursday. Instead of the beat-to-the-ground PowerPoint approach, I decided to branch off into the unknown and try Eletric Rain's StandOut. It's still in beta, but it's very cool. It's a presentation software (don't let them catch you calling it a "slide" presentation, in their workflow, slides don't exist) that kicks butt, done completely in WPF. Can you say sharp? Yep, you can, and you should, for that's how everything will look.

The learning curve can be somewhat steep, but by using Blend to build the DLL components you then integrate into layouts, which are the bits you can make a presentation from, you can rock in no time. You're only bound by your creative spirit on this one. Awesome.

Back to work. And more coffee.

Text-to-speech

This is something I will have to implement for a realistic Tower simulator, the planes will have to talk to the user, and vice-versa. On the planes side, their calls are coming from text and will need to be transformed into voice. There are several text-to-speech egines out there, but I came upon one (NeoSpeech) that completely blew me away. It almost sounds like a human being, scary!

I'll be looking into this and other engines.

XNA in a WinForm

Following up on the thinking of a full 3D interface or a WInForm to run the program in, I bumped into this article. Very cool stuff, including WPF!

Interface thoughts

As I sit at EWR airport, on my way to LIT, the thought struck me if I should have a completely 3D interface or if the 3D stuff should run in a window inside a bigger WinForm.

Some of the pros/cons that come to mind are:

3D Interface

This to me is by far the more immersive environment, where you have the outside world as well as the inside of the tower all rendered in 3D. In this case, the user would have to "walk" around in the tower floor to go see different computer screens, to look at different areas of the airport, etc. This also means the input interface would have to be built a little more robust that with the other alternative being discussed here, which could extend the development time a bit, when coupled to actually building the inside of the tower and making it interactive.

WinForm

This would definitelly allow a faster development, as a lot of the information being displayed to the user (such as flight strips) could simply be done via buttons, list boxes, etc.

I am undecided right now and think will be for some time. A decision does not need to be made soon, as I am still coming to grips with XNA and game logic.

Let's keep thinking.

Cool tutorials

In my never-ending search for more information, I bumped into a couple of tutorial sites that are excellent for XNA. CampElmXNA has tutorials on both C# and XNA. Riemer has been known for his DirectX tutorials, and now has a very extensive series (substitute "a very extensive" for "60"!) of XNA tutorials. Nice job guys!

By the way, Riemer's explanation of what is XNA was a breath of fresh air. Perhaps for people involved with it for some time the following statement is obvious, but it took me some time before I figured this out:

Released in December 2006, XNA is intended to push the ease of game programming to the extreme. XNA is new wrapper around native DirectX. As development on a new version of Managed DirectX has been cancelled, XNA can be thought of as the new version of Managed DirectX.

Pre-Development Test

OK, I am pretty happy. I just created a runway (a plane in 3DS) and a tower cab (pretty simple, really, 18 polygons), and using the Grumman J2F, hooked a very simple (but important) pre-development test. I have some keyboard inputs controlling the direction the plane moves in, and the camera located inside the tower cab. The camera tracks the plane, and it looks pretty good. I know, it's a small step, but it's one that gives a lot back. It's very cool to see the plane moving, the camera tracking, I'm excited!

Next I start work on a preliminary, basic flight model.

Render Test

This is a render test I have just cooked up. It uses a free model I got from Turbo Squid of a Grumman J2F Duck. A very nice model with around 8800 polys. I did not use any shaders for multiple instances, just simply loaded each model as if it was different, and drew it, so there are no optimizations at all.

This was to see what kind of performance I got. With the 21 models you see here, fraps (which I used for measuring the frame rates and recording this video) shows I was still rendering at 60 fps. This is in a Dell XPS M1710 laptop (GeForce Go 7900 GTX). Not bad at all!

Google is not the only one that's good at maps

Check this out. ProFX and MaPZone seem to allow procedural texturing on the fly, so that you don't need the gigabytes of textures to ship with your game. More than that, MaPZone can make diffuse, specular, normal, and other maps all fit together effortlessly. Alright, I'm interested. Oh, and did I mention they are an XNA partner, so they have a special (read dumbbed down) version of MaPZone free. Did I mention I was interested?