 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> > OTOH one small problem with C++ is that there is no standard way of
> > drawing any graphics.
> ...and this is the reason why. Almost *no* languages have the capability
> to easily draw graphics these days.
Some languages, such as Java, come with standard libraries for drawing
graphics, but in general the no-graphics-libraries trend is probably
because languages want to be portable, and it's very hard to make portable
yet efficient generic graphic libraries.
OpenGL is a very good, cross-language attempt, but you can't do
*everything* with it. Its target application range is rather narrow
(basically only hardware-accelerated 3D and 2D graphics, but it doesn't
have any support for eg. windowing systems).
> (Back when I was a kid, you could just say "plot 4, 7" and it would draw
> a dot there. Ah, I had no idea how good I had it!)
In those days portability was not an issue for the people who made the
compilers.
> > And you should forget
> > trying to program with the Windows API directly, unless you have *tons* of
> > experience with it, or you want to die prematurely.
> This made me actually laugh out loud. For real. Such a glowing
> recommendation of the Win32 API! :-D
> (OTOH, I understand that the raw X Windows bindings are even harder...
> apparently... I guess that's why there's so many toolkits!)
I once tried to look how I would create a simple dialog which contained
some radio buttons, textfields and buttons directly with the Win32 API, and
I was absolutely horrified at how horrendously difficult it is.
With a graphical toolkit such as GTK you simply say that you want a modal
window, it's composed of some elements eg. arranged vertically, and then
you simply add those elements to it. You don't have to specify how they
should look like, their coordinates on the window, or anything. You just
tell it *what* you want, and how it should be arranged. It's surprisingly
simple even though it's a C library, once you get used to it.
With the Win32 API you have to define *absolutely* everything by hand.
Every pixel coordinate, every width and height, every color. Everything.
And often in the hardest possible way.
The standard answer to this is "you don't create windows with the Win32
API directly, you use a graphical GUI creation software, and it will
generate the coordinates for you".
The only problem in this particular case is that, AFAIK, VS Express does
*not* come with such a GUI creation module. (At least VS 2005 Express didn't.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> The only problem in this particular case is that, AFAIK, VS Express does
> *not* come with such a GUI creation module. (At least VS 2005 Express didn't.)
>
It is missing MFC. I think it does have the resource editor, though. So
you can define dialogs visually, but you'll have to do your own coding
to manage the dialog.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Some languages, such as Java, come with standard libraries for drawing
> graphics
But using it is still nowhere near the level of "plot a pixel here please".
> but in general the no-graphics-libraries trend is probably
> because languages want to be portable, and it's very hard to make portable
> yet efficient generic graphic libraries.
Yeah, that's about the size of it.
> OpenGL is a very good, cross-language attempt, but you can't do
> *everything* with it. Its target application range is rather narrow
> (basically only hardware-accelerated 3D and 2D graphics, but it doesn't
> have any support for eg. windowing systems).
Indeed. Without having a way to talk to the native graphics control
system to set up a drawing surface, OpenGL is no help. (There also seems
to be some disagreement above whether you can use GLUT on Windows...)
>> (Back when I was a kid, you could just say "plot 4, 7" and it would draw
>> a dot there. Ah, I had no idea how good I had it!)
>
> In those days portability was not an issue for the people who made the
> compilers.
In those days, nobody had multitasking either (so you don't have to
*share* the framebuffer with anybody). That probably helps.
>> This made me actually laugh out loud. For real. Such a glowing
>> recommendation of the Win32 API! :-D
>
> I once tried to look how I would create a simple dialog which contained
> some radio buttons, textfields and buttons directly with the Win32 API, and
> I was absolutely horrified at how horrendously difficult it is.
>
> With the Win32 API you have to define *absolutely* everything by hand.
> Every pixel coordinate, every width and height, every color. Everything.
> And often in the hardest possible way.
Well, I guess that means you have lots of control over what it does. On
the other hand... tedious, much?
> The standard answer to this is "you don't create windows with the Win32
> API directly, you use a graphical GUI creation software, and it will
> generate the coordinates for you".
Indeed. I typically use GTK - because I can't get SDL to work. (Which is
a pitty, because SDL does way more stuff!)
> The only problem in this particular case is that, AFAIK, VS Express does
> *not* come with such a GUI creation module. (At least VS 2005 Express didn't.)
*My* problem is that... well GTK isn't something you usually find on
Windows. :-S
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> My first C program was a program that used the Windows API directly...
Same here. I did allot of C programming using the Windows API, for
Windows 3.1, and then for Windows 95. Back then, I was using Borland
Turbo C++, version 4.5. Things have come a long way from those days.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> OTOH one small problem with C++ is that there is no standard way of
> drawing any graphics.
That's been one of my major hang-ups with getting back into C++
programming. That, and a lack of inspiration, as Darren currently has.
> There are two popular 2D engine libraries for Windows which I know of:
>
> http://hge.relishgames.com/
> http://developer.popcap.com/forums/pop_index.php
>
> You could consider this one too, which would make your program much
> more portable:
>
> http://www.libsdl.org/
>
I'm going to have to look into these myself.
> You could try making DirectX or OpenGL code directly, but that would be
> even lower-level code, and might become a nightmare.
I've been overwhelmed by DirectX before. It's not for the
faint-of-heart, or for someone relearning C++, as I was at the time.
Thanks for this post Warp. It'll be helpful to me too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I once tried to look how I would create a simple dialog which contained
> some radio buttons, textfields and buttons directly with the Win32 API,
> and
> I was absolutely horrified at how horrendously difficult it is.
The only thing I ever do with the Win32 API by hand is to create a simple
window for applications that solely use Direct3D, it is just a few lines of
code and much faster and cleaner than using any IDE.
For a real windows-based application with textfields, buttons etc, you'd be
mad to try and code it by hand, unless you wanted to generate a load of
icons/text boxes algorithmically.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kyle <no### [at] spamok> wrote:
> I've been overwhelmed by DirectX before. It's not for the
> faint-of-heart, or for someone relearning C++, as I was at the time.
From what I have heard, DirectX 9 is much easier to use than earlier
versions. Same is probably true for DirectX 10.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> From the example codes I have seen of the HGE
> library, it might not be the easiest possible to use either.
I wish I knew how to comment from an OOP background, but I've been
putting off learning about classes/inheritance/polymorphism until now :/
> You could consider this one too, which would make your program much
> more portable:
>
> http://www.libsdl.org/
>
> However, I unfortunately have absolutely no experience in using it,
I have experience with it, and I can tell you this: getting a reliable
VSYNC is difficult or impossible. I have looked high and low for a
solution. Either I didn't use the correct search terms, or there isn't
an obvious way to get a VSYNC with SDL on every platform. Most of the
discussion I found was of people having their frame rates capped between
60 and 100 FPS (monitor refresh rate), yet with the same settings I did
not experience an FPS cap in any way. I have been getting between
400-1000 FPS, which means there is no capping going on because I'm not
getting a VSYNC with my programs. This leads to ugly things like jerky
motion and screen tearing. I have a relatively new graphics card, so
outdatedness is not an issue.
> nor
> do I know how easy it is to integrate in Visual Studio.
AFAIK, SDL is easy to set up in any language.
> Being a C library
> it will most probably be of a much lower level library than an abstract
> high-quality C++ library would be, and consequently probably hard to use.
Most tutorials will hand you functions for drawing pixels/loading
images/drawing sprites/etc. on a silver platter.
Other than the VSYNC issue, another thing to consider when using SDL is
the speed at which it operates. Compared to DirectX or OpenGL, SDL is
slow. It's faster at drawing pixels, but slower at drawing sprites and
alpha blending. Forget rotating a sprite unless speed is not an issue.
You can mix SDL and OpenGL, but doing this multiplies the mass of your
code significantly. This is why I'm looking to OOP for answers. The
combination is faster than SDL alone, but you lose some SDL
functionality. But you gain better control over the VSYNC. You get to
rotate sprites, have alpha blending, all those great things.
Watch out for HGE. It may be fast and great, but it hasn't had a good
update for a while.
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> From what I have heard, DirectX 9 is much easier to use than earlier
> versions. Same is probably true for DirectX 10.
DX6 was a nightmare to use, DX7 got a *lot* easier, DX8 and 9 made small
improvements here and there.
The problem with DX10 is that there is no longer any fixed-function
pipeline, so you have to write all the vertex shaders (to handle world and
perspective transforms) and pixel shaders (to do lighting) yourself. This
might be a bit overwhelming for a beginner.
If you were starting out, I'd recommend DX9 for sure, especially because as
a beginner you are unlikely to need any of the features of DX10 and DX10
won't run on XP.
BTW the documentation for DX9 is really good, plenty of tutorials and
samples building up from just drawing a plain triangle on the screen to lit,
textured more complex meshes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Coding a small game is always fun, and a good environment for
I once made a Pong -clone with Pascal. It was very hard to beat the
computer, since I saved memory and used the same variable for the Y-axis
placement for computer player and the ball :).
-Aero
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
