Porting 'engine' from VB to C++

Started by
3 comments, last by vcv 19 years, 4 months ago
I currently have a Cards Game written in Visual Basic (resources originally didn't allow for anything else really) that uses GDI for drawing graphics. Now, this is fine for the most part, as the game isn't graphics intensive. It just needs to display what I ask and updates every second or so usually. The problem lies in the desire to add basic animation. While the code supports this, it can not handle it efficiently, as it's using GDI. It's also using an external lib to display RGBA PNGs, which is the most costly aspect I would assume. So I looked around and found SDL. I don't need anything as fancy as OpenGL or DirectX, as it's not a full-blown graphics game, just cards. So just SDL itself seems to be more than capable, and I can use SDL_image to load the PNGs easily. So a little information on how the engine currently works. It uses 2 class modules, Canvas and Layer. There can be and is multiple layers on a canvas. These are just regions within the canvas. For example, there is 1 layer to display a players cards. A layer can have multiple images and/or text drawn onto it, and is transparent by default. To draw something onto a layer, you call the ForceUpdate method of the layer. This triggers the NeedsUpdate event for the layer object, where you call .DrawImage and/or .PrintText. The engine also makes sure any overlapping layers are updated in order so that the z-order of layers remains in tact visually. So I want to port the engine to C++ using SDL so I can add basic animation and improve the speed, as already stated. The only way to preserve the object-oriented/event-based code is to use COM, which is cumbersome and I am not comfortable with. I have thought of numerous ways of communicating between this C++ DLL and Visual Basic, but nothing seems to stand out. Time is a bit of an issue. Thoughts? Ideas?
Advertisement
I cant understand why you would need COM for the event handling, there should be no problem in writing your own event handling functionality to the engine.

You could even use the WIN32 SDK for your own event handling, you can register your own custom messages.

Thanks for the input.

I don't completely get exactly what you're suggesting here, could you clarify? I've been up all night doing some work, so sorry if it's very straight-forward and I'm just not grasping it from exhaustion.

What is really troubling me is being able to trigger a piece of code when an event occurs in the engine. A callback would work I suppose.

I've gotten a few more ideas after reading your post. I guess I just didn't give it enough thought really.
Quote:I cant understand why you would need COM for the event handling, there should be no problem in writing your own event handling functionality to the engine.


VB has COM support built in if he wrote his own event handling system it'd need to work with VB.

VCV: Couldn't you just use SDL direct in VB? I know you can call external DLL functions from VB and SDL has a simple C interface so you should be able to use it direct from VB. Or alternatively write a high level wrapper for SDL in C and use that from VB (this may be the easier option). All the event handling etc can still be handled in VB, you'd just call the DLL you wrote which wraps SDL to draw things.
Quote:Original post by Monder
Quote:I cant understand why you would need COM for the event handling, there should be no problem in writing your own event handling functionality to the engine.


VB has COM support built in if he wrote his own event handling system it'd need to work with VB.

VCV: Couldn't you just use SDL direct in VB? I know you can call external DLL functions from VB and SDL has a simple C interface so you should be able to use it direct from VB. Or alternatively write a high level wrapper for SDL in C and use that from VB (this may be the easier option). All the event handling etc can still be handled in VB, you'd just call the DLL you wrote which wraps SDL to draw things.
I can't believe I did not consider this before. This would probably be the easiest route. Thanks for the suggestion.

This topic is closed to new replies.

Advertisement