This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

121

Discussion / Re: Languages?

« on: April 08, 2006, 11:14:16 pm »

VB is very good to make simple programs, but the problem is that it's a very different language.

I would agree that it is different compared to C++, but then again, so is Delphi. So is Pascal. So, for that matter, so is FORTRAN. Being different is par for the course when it comes to programming languages.

Your assertion that VB is good at making simple programs is absolutely true, but so is C++. The idea that VB is only good for making simple programs is a generalization which is absolutely untrue: VB has nearly all the features that C++ has (with the exception of inheritance, threading, structured exception handling, typecasting, c-style pointers, and bitshifting - note that with the exception of inheritance, all of these functions can be replicated with calls to the Windows API; inheritance can be simulated by nesting objects, which is almost as elegant). Since VB has all of these features - and indeed, makes many of them easier to use (C++ lacks the ability to redimension arrays while maintaining the array's current contents; VB's ability to 'redim preserve' is amazingly useful), there is nothing keeping you from implementing the same program in VB that you would in C++.

I'll close with a quote from Wikipedia's talk page on VB:

Outside of academia and hacker code puritans, VB is not so overwhelmingly controversial. It is a language like any other, and it is just one package available. I'm not defending VB at all, just saying it does not merit a slanted POV.

122

Discussion / Re: Porting games to GBA

« on: April 08, 2006, 09:42:56 pm »

...just don't say there's not an equivalent to a surface.

Since you have direct access to the hardware with the GBA, there's no need to have surface classes (more commonly known as 'textures' when you're working with 3D rendering). You have to create your own surface classes if you want to encapsulate variables with the bitmap data.

If you're talking about surfaces in the mathmatical sense (see wikipedia: http://en.wikipedia.org/wiki/Surface), unfortunately, the GBA doesn't have the power to transform surfaces in real-time because it has a relatively slow processor. You're not going to be able to deform 3D terrain with only 16.8mhz; although you *could* display an explosion sprite instead of cratering the area where an explosion occured. A 64x64 explosion sprite wouldn't cost you more than a few clock cycles to display. If you want to transform and light surfaces on a handheld, you would be better off programming for the PSP =)

An important thing to realize about the GBA is that as long as you draw the kinds of sprites that the GBA was designed to draw, all your drawing operations are nearly free. By comparison, with computer graphics (such as directdraw), you need to copymem32 every pixel that you want to be displayed to the screen, which costs you a ton of clock cycles. Similarly, you can do 4 layers of parallax (sonic on the sega genesis could only do two or three, I think) with no performance penalty! That's absolutely awesome!

To get a handle on what the GBA is designed to do, and what it realistically can't do, take a look at the CowBite Virtual Hardware Specification, located here: http://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm. When I was considering programming on the GBA, I built my own compiler suite based on GBADevAdv (mine gives you a little more leeway when optimizing than the default build; my builds are a few kb bigger, but they can compile code with the -O3 (maximum optimizations switch) that the default compiler would error out on). Unfortunately, I don't have that compiler on my current computer, I'll need to retrieve it off of an external hard drive. If people on ZFGC have interest programming, I'll post it here. =)

123

Discussion / Re: Porting games to GBA

« on: April 08, 2006, 07:44:30 am »

Programming for the GBA is much easier than programming for Win32/DirectX, because you don't have to deal with libraries and surfaces et cetra. You have direct, unquestioned access to the bare hardware: if you want to draw a pixel, all you have to do is write the color to a specific spot in memory that never changes.

On the other hand, on the GBA, you only have 16.8mhz to play with. That gives you only 300k clock cycles per frame (the GBA runs at 60fps, you can't change this, although you could only update the display every second frame, thus 30fps and 600k clock cycles per frame). Mind you, the ARM7 is a beautiful little processor that is more efficient clock-for-clock than a Pentium, but still, you don't have a lot of procesing power which limits what you can't do. You can't reasonably expect to program a 3D game for the GBA; there simply isn't enough power to do it (some professional teams have managed this feat, but they had teams of programmers with years of experience optimizing for the gameboy).

However, you *can* do quality sprite-based 2D games, working with the hardware to give you some great effects. Hardware transparency/alpha blending that doesn't incur a performance hit of any sort? You betcha. =)

Here's a demo of a concept program I did a year and a half ago: http://home.comcast.net/~mithrandel/misc/output.gba. This was actually one of the first real programs that I did in C++ - all of my C++ programming up to the point was limited to math and array dll's. If you think you want to get started with GBA developement, give me the word, and I'll help you get set up with a compiler and all the documentation you'll need to access the display and sound registers and whatnot. =)

124

Discussion / Re: What do you think I should use?

« on: April 08, 2006, 06:50:09 am »

If you're just starting out with programming, I'd suggest looking into a game-centric language, such as GM. I've taken GM for a stroll, and it's a great language to cut your teeth on. It also (and this is the most important reason to start out with GM!) gives you an idea of how you should lay out your variables in code for a game. It took me years to learn this property of programming games, since I learned by trial and error rather than by example.

I know it sounds as if this is such a meager reason to go with GM, but it's really so darn important that you would be crazy to overlook the oportunity.

*****

Another big reason to go with GM: C++, VB, Delphi, most of the languages out there lack easy drawing mechanisms - and the ones that come integrated (such as VB's picture object) are woefully inadequate for programming games (not to knock VB: with the right amount of know-how, one can program a DirectX-based drawing object in VB that rivals drawing managers implemented in any other language). With GM, you can draw sprites and play music right from the beginning: with any other language, you will spend weeks, if not longer, fuddling around with tutorials trying to implement a drawing manager, and I promise you that your first try - like VB's picture object - will be slow and inadequate.

Eventually, you'll run into the boundaries of GM, and you'll want to do things that aren't possible in that language. Then, you'll be more than ready to jump head-first into another language. But you're going to want to get your feet wet with GM. =)

125

Discussion / Re: Languages?

« on: April 08, 2006, 06:24:29 am »

I program in VB6 almost exclusively. It's a wonderful language that is exceptionally easy to program in, and while I do wish VB6 had true pointers (although VarPtr is a decent substitute) and object inheritance (although you can nest objects, which is almost as good syntactically), the benefits of programming in VB more than outweigh the caveats.

One of the great strengths of VB6 which is practically unheard of in other languages is that I can execute my code in the IDE, and break the execution at any time, change code, even add variables and entire routines, and the program doesn't even need to recompile.

Mind you, the array preformance of VB is dismal - about four times slower than VC++ 6.0. Thus, when I need to do array-intensive operations like software alpha-blending, I turn to C++, compiling to DLL's that I can access through VB. However, in all other instances, the preformance of VB is comparable to VC++.

My current project, an isometric game that looks nearly identical to Diablo 2 (and can do some of the same palette-based effects in realtime), runs at 180fps in windowed 640x480x32, and 330fps in fullscreen 640x480x32. Note that my test machine is an 800mhz P4 with an X300 graphics card, so this is hardly a state-of-the-art machine. Of course, these results are due to the fact that I've been programming in VB6 for four years now, and know the language pretty much inside out.