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

Invisible wrote:
> Question: Why is this undecidable?

It's due to a proof known as Matiyasevich's theorem which I'm not 
familiar with the details of offhand.  The gist is that you can show 
that every recursively enumerable set* can be represented as the roots 
of such a polynomial.  Since there are non-computable recursively 
enumerable sets there must be such polynomials (known as Diophantine 
equations) which are not computable.

If you're interested in the details, this paper looks like it might be 
useful, although I haven't read it myself:

http://modular.math.washington.edu/edu/Spring2003/21n/papers/hilbert10.pdf

If you're interested in the details, but less so, this is probably more 
useful:

http://en.wikipedia.org/wiki/Hilbert%27s_tenth_problem

More intuitively, note that the problem statement come pretty close to 
having Fermat's last theorem as a subproblem.

> Surely it's a trivial matter of iterating over all integers and testing 
> whether any of them is a root?

If there is no solution to a given polynomial, when does this program 
you describe halt?



* A recursively enumerable set is defines as any set for which these 
exists an algorithm that will eventually list any number in the set, and 
no numbers that are not.  Note that the algorithm is not required to 
ever halt, so you can't , in general, be sure which numbers are not in 
the set and which are in the set but it just hasn't gotten around to 
listing yet.

An example of such a set which is not computable would be the set of 
numbers corresponding to the binary representations of all programs 
which eventually halt.

Post a reply to this message

Eero Ahonen wrote:
> 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 :).

Nice!

-- 
~Mike

Post a reply to this message

>> Question: Why is this undecidable?
> 
>> Surely it's a trivial matter of iterating over all integers and 
>> testing whether any of them is a root?
> 
> If there is no solution to a given polynomial, when does this program 
> you describe halt?

...so it's "undecidable" because you can't always figure out the answer 
in finite time?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message