It''s been a while since I last took my VB3 out of retirement and installed it. SOO.... My question is this. I had soo many problems getting any kind of good programs of even minor value with the coding and all I had to do there. But the thing is I''ve picked up several books on VB3-4 I dont know if they''ll be worth going through. Will I learn anything of value towards game programming? I prefer board type games with counters for units etc etc. I came to a site that linked me here but upon finding it I still am lost. I wanted to see some code to get my brain going again but instead got a bunch of advice. "Code this" and then that and then "something a little harder". Well that''s all good and fine but how does this help me write code? Any insights? I''m looking for a good site to help get started from scratch. I learned to program in HS back when QB didn''t yet exist! As such I learned from my old ZX81 (Timex) and am more visually oriented. When I see and understand code I can manipulate it, change it and get moving. Any help or suggestions from you wiz kids or old hands? Stew,

Well, first I would recommend upgrading to VB 5.0 or VB 6.0. Not saying you can''t still produce good stuff with VB 3, but a lot of people will be unable to offer good advice because they will assume features available in only the later versions. For example: I''m not sure if the DX 7 integrates with VB 3.0 the same way it integrates with the later versions. Heck, I don''t even remember if the event model is the same.

Some VB examples are available off of the CDX project. VB programmers used CDX ActiveX components as the interface to DirectX.

Plus, the executables created by the newer versions of VB are much, much faster than the old ones, which may be important depending on what kind of game you want to make.

And VB 6.0 can produce "real" executables (no more vbrun.dll .

/. Muzzafarath

I think VB6 programs are still dependent on the msvbvm60.dll file, some kind of Visual Basic Virtual Machine. My DLLs compiled with VB6 still has dependencies to this file, even though it's compiled as native code (not p-code).

Edited by - Spiff on 3/26/00 5:18:25 AM

When compiled as native code, msvbvm60.dll contains some startup/shutdown code for the application, most of the code for forms and intrinsic controls and some run-time functions (much the same way the C still depends on run-time libraries). Also, VB 5.0 contained the ability to compile to native code.

I agree 1st thing is to switch to VB6, currently I''m making a simple game to test game developement in VB with DX7. I''ve finally decided to make a simple shooting gallery type of game, which will be using the Act-Labs GS system as input. I''ll post the link once I''m done so other people can see how performance is doing.

-------------------------
-Now Working on Pokemon like Engine!

If you still have to include the dll, what''s the meaning of compiling to native code instead of p-code?

/. Muzzafarath

quote: Original post by Muzzafarath
If you still have to include the dll, what''s the meaning of compiling to native code instead of p-code?

/. Muzzafarath

Ok, it''s oversimplification time:
Let''s say you have a WndProc function you use for each and every one of your programs. It would make sense for you to stuff that WndProc into a DLL and just ship the DLL with your programs instead of compiling it in every time, right? Well VB forms all have basically the same WndProc; they specify different call backs for the WndProc to call. It''s still compiled to x86 code, but the WndProc function is located in the DLL. In comparison, p-code is essentially interpreted at run time by the DLL. The true benefit of compiling to native code is that mathematical operations are carried out entirely in essentially the same code as you would get in C.

Hmm, that makes sense, but the dll must include lots of stuff that isn''t necessary. That means that the exe + the dll would be bigger than if I included the WinProc in the exe, right?

/. Muzzafarath