Archived

This topic is now archived and is closed to further replies.

gpalin

Need opinions for game

Recommended Posts

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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:


  
+----------------------+ +--------+
| | | invent |
| | +--------+
| Main Screen | +--------+
| (Picture Box) | | stats |
| | +--------+
| |
| |
+----------------------+


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."

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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."

Share this post


Link to post
Share on other sites
quote:
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.


It''s my understanding that BitBlt is a good all-round graphics routine, so I''ll stick with that for now. There is no complex animation (yet). I have only just gotten the form running, as well as getting the character to appear. I haven''t added enemies, terrain etc yet.

quote:
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.


I''ve read about that somewhere...I''d better look it up. Basically what happens, you''re just displaying layer of graphics on top of other layers. Is that right?

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


Do you mean like where the button has a black border around it, and you can press SPACE or ENTER to press it? I''ve been wiondering what to do about that. Any suggestions?

Grant Palin

Share this post


Link to post
Share on other sites
quote:

I''ve read about that somewhere...I''d better look it up. Basically what happens, you''re just displaying layer of graphics on top of other layers. Is that right?



It''s kinda like that. Here''s the detail: The picture box is used just to display the final frame. Do not ever draw directly on the picturebox. Draw all sprites on the memory first (or DC), and once you''re done, copy it to the picturebox.


quote:

Do you mean like where the button has a black border around it, and you can press SPACE or ENTER to press it? I''ve been wiondering what to do about that. Any suggestions?



Here''s the deal. If you use just a Form alone, the focus get on the form and it won''t go off anywhere else. Since VB is an event-driven language, you will probably use Form1_KeyPress (or KeyDown, etc) event for the control of your game. But, if you have a picturebox, several command buttons, the focus might go off somewhere else. So, if you put your game control in one event:

Picture1_KeyPress(...)

but if the focus is not on the picturebox, that event won''t be triggered resulting a bug.




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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
About the double buffer...you can get the picture box to do it, look at the autoredraw property. Set it to true, and it creates an offscreen buffer...depending on how you draw to it, you may have to use the refresh method...If you start using windows API calls instead of built-in VB functions to draw..you will have to use the refresh....Also you can change the autoredraw while the program is running, When it''s false you are drawing on the desktop surface, True it''s drawing on the offscreen surface.

So how could this help....One thing you could do is Draw your background tiles with autoredraw = true, then set if false and draw your charactor, now you can cls the picture and the only thing erased would be the charactor.

but if it''s easier to just redraw everything, just set autoredraw to true and leave it. Clear and Redraw everything, then use the refresh method after everything is redrawn..no flicker cause refresh will copy the back buffer to the onscreen very fast.

Share this post


Link to post
Share on other sites
Sorry for the lack of replys from me: I got back from a one-week camping trip just this afternoon. Been getting away from the computer, spending some time outdoors, scratching mosquito bites... Anyway, enough of camping! I'm glad to be home again!

I've read all the messages so far, and have been doing a bit of thinking about the game, and the way I'm doing it. I think I will try to convert the game so it doesn't use seperate command buttons on the form- I will integrate all the controls into the game window. For example, I press "I" to show inventory, "S" to show status, "R" to rest, and so on. Or maybe have a single button bring up a sort of menu, where you choose what to do. I'll have to work on that idea a bit. It should remove the problem of control focus mentioned earlier, plus it would proably look better. Anyway, I still have to get some tiles to use, and figure out how to use them! I'll post back here when I've made progress- doubtless I'll have more questions

Here's a link to a screenshot of the from the way I have it now: it includes the display area, command buttons, and pictureboxes conatining the four different sprites for the character and their masks.
http://freewebz.com/hommworld/other/screenshot.jpg

Grant Palin

[edited by - gpalin on August 26, 2002 1:09:27 AM]

Share this post


Link to post
Share on other sites
if the form has its "KeyPreview" property set to TRUE, the form will get all keypress events before the controls on it, even if they have the focus. so, you CAN do it this way...

Share this post


Link to post
Share on other sites
Ok, to address the "FOCUS" issue, I suggest that you use API for the movements. Declare this:

Public Declare Function GetKeyState Lib "user32" (ByVal nVirtKey As Long) As Integer

Now get rid of your slow Key_Down events and replace them with:

If GetKeyState(vbKeyLeft) < -5 Then... and so on.
This way it is much faster and the character moves right away when you press a key.

Not sure how you want the game to be, but if you want the background to scroll, or make sort of a camera follow your character then use StretchBlt:

StretchBlt hdc, 0, 0, P_Width, P_Height, Background.hdc, OfsetX, OfsetY, P_Width, P_Height, vbSrcCopy

Now say something like: OfsetX = character.x - 400
This way the background will scroll when you move and the character will be in the middle of the screen all the time.

Hope this helps!

Share this post


Link to post
Share on other sites
krez- thanks for the KeyPreview advice. I changed that to True, and it works better now.

Rad76- What does the "-5" mean?
If GetKeyState(vbKeyLeft) < -5 Then... and so on.

As for scrolling, I''m not talking about a side view, Super Mario Brothers sort of scrolling, I mean from screen to screen. When you reach the edge of one screen, you move to the adjacent screen.

Grant Palin

Share this post


Link to post
Share on other sites