I am working on a game in Visual Basic 6. It is in the overhead, Zelda-style view (think Nintendo or Super Nintendo). I am currently drawing the character in a picture box, which serves as the main display screen. Should I stick with this, or draw the character directly on the form? Doing it on the form, I think, would simplify things somewhat, programming-wise. However, it would take more code to keep the character inside a specific boundary (unlike with using the picturebox). I also have command buttons on the form, for various functions, such as inventory, status, etc, and I wouldn''t want the character to be able to go through those. I''ve seen some VB games where all the buttons etc are done right on the form, but I think I''m not quite at that level yet- it sounds more complicated. However, I am open to alternate suggestions. So, basically, I would like opinions on the following: -Whether to draw the character in the picturebox. -Or to do it right on the form. If so, should I remove the command buttons and create buttons sitting on the form itself? How would I do that? Thanks for opinions! Grant Palin

What API are you using DX8?, DX7, or GDI?

It sounds like you are using the GDI.
Are you using pictureboxes for your character and monsters or
Direct Draw Surfaces?


Dreddnafious Maelstrom

"If i saw farther, it was because I stood on the shoulders of giants."

Sir Isaac Newton

It would be a much better idea to just use DirectDraw I think.

-- Ivyn --

I''m using BitBlt, to put the character into the picture box, and to move it. I have two source picture boxes on the form, one containing the sprite, and the other containing the mask. There is one destination picture box, the display, which will have the character, and eventually, the visual part of the game. I know zero DirectX, so I cannot use DirectDraw.

Grant Palin

Visual basic is bad (for games). And even worse is using GDI with it.

If you want to stick with VB, go here :

http://www.gamedev.net/reference/articles/article1308.asp

here: http://www.gamedev.net/reference/articles/article1350.asp

and here: http://www.gamedev.net/reference/articles/article1606.asp

sequentially.

My first ''game programming'' experience involved picture/image boxes in VB5. I actually figured out how to move them around with keyboard input, and such, but nothing ever worked right. It was slow and the movement was jerky, and there just wasn''t the functionality needed to program a full game. So I just quit. Now, a couple years later, I''ve come back to the scene and I''m attempting to learn C++/OpenGL/DirectX.

Anyway, good luck and take a look at those links (from this very site)

By the way, those links are to learn DirectX 8.0 in VB. They involve 3d graphics, but since DirectX no longer has 2d, 2d games must be programmed using 3d functionality (a good thing imho). Basically you make flat surfaces (billboards) and apply textures (masked bitmaps) to them.

Man, i really can''t help you much, so let me ramble on with a bunch of unsolicited advice

You really need to learn directX. If you are looking for simplicity then learn DirectX7 here: http://directx4vb.com

If however you have your mind set on using the GDI then blitting
to a picture box will be just fine. Just skin your forms and buttons so they look right, and don''t expect to have lightning fast graphics, it''s just not very likely using that API.

Last word of advice: to do a decent game using the GDI you are going to have to learn a bunch of stuff you don''t know (unless you already know it all) That time would be much better spent on learning DX7 (dx7 is easier than GDI in my opinion.) or if you want to get ambitious learn DX8 (quite a bit tougher but ALOT more features)

and while AeroBlaster is right about VB not being the ideal choice for games, if you use DX and pay attention to code optimizations you can still do a great game. (this is a tough sell to the die-hard C++ people, but trust me it''s true.)

Dreddnafious Maelstrom

"If i saw farther, it was because I stood on the shoulders of giants."

Sir Isaac Newton

quote:Original post by gpalin
Should I stick with this, or draw the character directly on the form? Doing it on the form, I think, would simplify things somewhat, programming-wise. However, it would take more code to keep the character inside a specific boundary (unlike with using the picturebox). I also have command buttons on the form, for various functions, such as inventory, status, etc, and I wouldn''t want the character to be able to go through those.
Grant Palin

Ah...the joy of VB...oh well, I''ve moved to C++ anyway.
OK, creating a picture box just for the character alone is not the best way to do it. In fact, if you do it that way, it''s not gonna be a game, but rather, an animation box.

If you have an environment, and then the character is walking in the environment, you should make both environment and character in one place, either form or picture box, not in two separate place. Otherwise, how you''re gonna do the transparency etc? Picture box doesn''t support transparancy, and don''t use Image control (VB6).

Whether you do it on a picture box or form doesn''t make any difference. However, if you do not want the character goes off screen "messing" up the buttons, go ahead and use picture box.
It''s gonna be like this:




somewhat like that. All things (characters, trees, monsters, etc etc) goes to main screen. invent and stats are the buttons.


My compiler generates one error message: "does not compile."

Perhaps I should clarify things here. It is not a real-time game. It does not have characters moving constantly. Basically, I press the Up key, and the character moves up a space, and the sprite itself changes direction to face up. I don't think I need fast graphics for that, do I?

As for the API, I want to learn as much as I can, so I want to start with BitBlt, master that (more or less), and then move on to DirectX.

Dreddnafious, what do you men by skinning the form and buttons? Changing colors? And what do you mean by learning a bunch of stuff about GDI? Could you elaborate?

nicho, the destination picture box I mentioned earlier will contain the character AND the terrain, obstacles, etc. I'm not actually moving a picturebox with the character in it! I've been reading about different ways to move characters (ie, animation), and I tried the moving picturebox method, which was pretty clunky. I then discovered BitBlt, so all's well, or better anyway!

It's my understanding that when moving the screen with the character, you can clear the picturebox, redraw the background appropriately, and then draw the character again. How am I doing?

I decided that using a picturebox would be easier than drawing on the form, because it would be easier to maintain a boundary the character cannot pass.

Grant Palin

[edited by - gpalin on August 17, 2002 3:41:16 PM]

[edited by - gpalin on August 17, 2002 3:42:59 PM]

[edited by - gpalin on August 17, 2002 3:45:38 PM]

quote:Original post by gpalin
It''s my understanding that when moving the screen with the character, you can clear the picturebox, redraw the background appropriately, and then draw the character again. How am I doing?

I decided that using a picturebox would be easier than drawing on the form, because it would be easier to maintain a boundary the character cannot pass.

You are doing the right thing. If you think BitBlt is enough (and I think it is) for your game where there are no complex animation, so use it.

For the picture box, do not ever clear whatever in the picturebox between frames. That will produce flickers and it''s something that all of us do not want to see in a game. But rather, just overwrite everything without clearing it first. This is what people call double bufferring.

Just a reminder, if you use picturebox and command buttons, beware of FOCUS!

My compiler generates one error message: "does not compile."