Software Development

I'm building a demo. I'd call it small, but it's going to be bigger in size than I'd like. The Unicode library I'm using is 10MB just by itself. I doubt I need it all, but I can't be bothered to figure out the settings and recompile it. Hopefully, it'll compress well.

It'll ONLY be a GUI environment Demo. It's not Project V. I've disabled almost everything that has to do with that because it's simply not done yet. I might leave in a few blank components just to have something on the screen, but they'll be empty and useless.

I'll show a few visual components, but that's kind of boring. What I'm going to show is a little from each item in this list.

• Fonts.
  
• Text functionality.
  
• Layering.
  
• Alpha channels.
  
• Video and audio player.
  
• Line drawing.
  
• Spline Drawing.
  
• Rectangles (rounded and outline options).
  
• Circles (full and outlined).
  
• Ability to trigger multiple tasks at once.
  
• A little fun with math and parametric equations.
  
• Textures.
  
• Image loading.
  

I'll be adding more stuff, but I can't remember them all just now. I didn't list it, but this is a full GUI system. Some GUI components I'm still missing, but I have listviews, treeviews, textboxes, popup boxes, listboxes, radio buttons (and ability to group them and make them mutually exclusive), checkboxes, text buttons, image buttons (all buttons can optionally be pushdown buttons), image viewer, panes (containers), views (main display layer), button panels, scrollbars, video player, labels and zoom box. Everything can be custom drawn or you can insert your own graphics for some of the elements. I'm not going to show that in the demo though. So I'm listing it here.

All these GUI components and everything in the list above will be available within Project V. Anyhow, there are two different and unrelated kinds of components. There are Project V components and then there are GUI components. I'm going to show the GUI components and a few examples of what they can do, especially the custom drawing stuff since you have full access to the video card. Project V components will be available at a later time that will allow you to do exactly what you will see in the demo and more.

Requirements are:

- DirectX 9.
- The demo should work on most video cards. Needs PS 1.4 or better. VS 1.1 or better. And 64MB of texture RAM I suppose. I never really measured it.
- DivX, XVID or other Mpeg 4 codec to play the video.
- MP3 codec to play the audio.

Oh, and for those curious as to where I'm at with my events in Project V, I've got about 4 events left to go. I got a cold this weekend so I couldn't finish it. Again, note that these events are for the Project V components and NOT the GUI components. The GUI components have most of their events all set to go.

Not sure if that cleared up anything or just confused things, but there you go. In a few days, Monday at the latest, I'll put up a GUI functionality demo. Don't expect much. I just want to do this to finally get something out there. And that it's possible to actually build stuff with the C++ internal library. The Project V beta (the actual development environment) will be coming a few weeks to a few months from now.

Via proggit comes a Dr. Dobbs article by Andrew Koenig about Dijkstra's Go To Statement Considered Harmful. (And yes, "go to" is two words.) I usually like Andrew Koenig's articles. And this one is no exception. But I do have an issue with it.

First, let's recap his objective. It's that most people dismiss out of hand the use goto's without understand exactly why goto's are considered harmful. He claims, and I have no reason to dispute it, that personal opinions are the end of the argument. Andrew then mentions arguments that are NOT personal opinions. I always see this as a red flag. Not that it's automatically wrong. But an undebatable truth rarely goes unchallenged.

Read more...

I've been hearing about futures for a while. Aside from the fact that there are plenty of old C++ compilers out there that will never support these new features, it's still interesting to see these new additions considering that I said C++ was dead a while back. Uh... that was 2006... January! Three years ago.

Anyhow, I'm doing some unrelated, yet hairy, C++ programming lately. So why not talk about futures too. From this article, which I consider very good in explaining the topic, it looks like you can spawn off computations where you can retrieve the result(s) at a later time.

Does this seem like juggling to anyone? And where have we seen that term used before? Right! With pointers. But now we're gonna be juggling execution. And you can already see in the linked article that the same solutions to pointers are gonna be used with futures.

I understand the need for it. Heck, I'll probably use them myself if I can get a compiler that supports it. But the problems listed at the end of that article are very relevant. Did the C++ committee just decide to avoid what history has taught us these last 20 years?

The funny thing about this is that it resembles what Vladas has been talking about for a while, but with all of the useful things stripped out. No composability. No concurrency. No parallel constructs. No nothing.

I thought I was mistaken with C++ being dead because of the new extensions. But I think that adding features that were never meant to be part of the language is a nail in the coffin. I like C++. It's my favourite language. Well, "like" is perhaps a bit too strong a word. I hate all languages and C++ is the one I hate the least. But I think all current languages, not just C++, are fast approaching the point of no return. You've all seen it. When your program becomes so bloated and has changed so much that a complete rewrite would work better than the alternative. I believe this is called the Big Ball of Mud syndrome.

Time will tell.

Wanted to try and start a discussion about Project V development techniques. These are not set in stone and may change as I go along. Some haven't been decided on yet.

Read more...

Not sure if anyone reading this has ever implemented an event system, but there is one little problem I encountered that can really mess things up. Deletion. And I'm not talking about implementing an event. I'm talking about the other side of the coin. The part of the system that actually invokes or triggers events.

I've now got two event system in Project V. One in the GUI and one in the node system (aka type system). The GUI one works fine, but that's because I've written plenty of GUI systems in the past. But even in the GUI event system, I had to include a separate, global function to delete GUI components. This global function doesn't actually delete anything. It simply queues the GUI component for deletion, but removes it from any and all container components. So any further events can still use said GUI component without crashing or getting a NULL pointer exception. When all events are done, I delete everything in the deletion queue.

I don't have a global creation function in either event systems. Maybe I should. But it doesn't seem necessary at this point. With the GUI, events come in from the OS. So I basically pass it on. So when the GUI event handling function returns, I simply clear the deletion queue. But with the node system, the events don't come from the OS. Rather, they come from the user (or other code) that will add, delete, insert, remove or update nodes. The user can also create and delete sets. So there's no real area when I know for sure that the node system isn't being updated. Since Project V components can themselves be executing at design time, these can trigger events outside of the GUI.

Read more...