 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK, so I downloaded MS's "express" dev env for C# and C++. I figure it's
time to practice some C++, learn the ways of the STL, and so on. Mainly
because it's that or Erlang or Python, and nobody is going to pay me to code
any Erlang, and Python looks pretty trivial to learn.
Sadly, I'm utterly uninspired about what to write past my first usual
program, namely "Jotto". Any suggestions?
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Sadly, I'm utterly uninspired about what to write past my first usual
> program, namely "Jotto". Any suggestions?
Fix POV-Ray 3.7 radiosity?
*runs*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> OK, so I downloaded MS's "express" dev env for C# and C++. I figure it's
> time to practice some C++, learn the ways of the STL, and so on. Mainly
> because it's that or Erlang or Python, and nobody is going to pay me to
> code any Erlang, and Python looks pretty trivial to learn.
>
> Sadly, I'm utterly uninspired about what to write past my first usual
> program, namely "Jotto". Any suggestions?
For learning C++, this looks like a good tutorial:
http://www.cplusplus.com/doc/tutorial/
I'm working my way through it now, to glean information I might have
missed in my haste to jump straight into more difficult applications.
It's best to have a solid understanding of C++ before using third-party
libraries. Avoiding memory leaks is my #1 concern, so trudging through
the basics seems like a good idea :)
As for inspiration, what kinds of programs inspire you? I like 2D video
games and cellular automation sims. I'm guessing you might like to make
graphics programs as well, since you are here and not somewhere else :)
Once you start becoming more familiar with C++, you might want to
download SDL to make some graphics programs. CA sims are easy to make,
and you might even stumble upon something new.
Good luck!
Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> OK, so I downloaded MS's "express" dev env for C# and C++. I figure it's
> time to practice some C++, learn the ways of the STL, and so on.
WTF?! I thought you were a C/C++ ace!! o_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Darren New wrote:
>> Sadly, I'm utterly uninspired about what to write past my first usual
>> program, namely "Jotto". Any suggestions?
>
> Fix POV-Ray 3.7 radiosity?
>
> *runs*
mwahahahaha :D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Darren New wrote:
>> OK, so I downloaded MS's "express" dev env for C# and C++. I figure
>> it's time to practice some C++, learn the ways of the STL, and so on.
>
> WTF?! I thought you were a C/C++ ace!! o_O
I know C inside and out. C++ is quite a bit different. Except for the parts
that are C of course.
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, in that case:
http://mindview.net/Books/TICPP/ThinkingInCPP2e.html
But you probably already know of that. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Well, in that case:
>
> http://mindview.net/Books/TICPP/ThinkingInCPP2e.html
>
> But you probably already know of that. :)
Thanks. Already downloaded it, haven't waded thru it very far. :-) I've been
finding motivation a bit hard to come by lately.
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Sadly, I'm utterly uninspired about what to write past my first usual
> program, namely "Jotto". Any suggestions?
How about a program that takes a multivariate polynomial as input and
determines if it has any roots over the integers ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> How about a program that takes a multivariate polynomial as input and
> determines if it has any roots over the integers ;-)
I know you're joking, but I'm not sure how that would be more useful in
learning C++ than in learning C.
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Kevin Wampler wrote:
>> How about a program that takes a multivariate polynomial as input and
>> determines if it has any roots over the integers ;-)
>
> I know you're joking, but I'm not sure how that would be more useful in
> learning C++ than in learning C.
It wouldn't really, I was just unable to resist giving an undecidable
problem as a programming suggestion.
As a more serious suggestion, and somewhat graphics related, you could
implement an inverse-kinematics system. It lends itself well to an OO
approach, and IIRC there's a clever technique to perform automatic
differentiation using C++ templates that might give you some practice there.
Alternatively, how about implementing the Barnes-Hut algorithm for
N-body simulations? It should give pretty animations and I don't think
is terribly difficult.
In terms of the STL perhaps writing a simple calculator would be a
reasonable task. You can add whatever interesting functionality you
like (variables, complex numbers, exact rationals, matrices, tensors,
symbolic expressions, etc) so you can probably craft it to work whatever
data structures you're least familiar with.
I'm not a C++ expert though, so others may have better suggestions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Sadly, I'm utterly uninspired about what to write past my first usual
> program, namely "Jotto". Any suggestions?
How about something to solve/play a game, like Sudoku, checkers, connect 4,
poker etc. Not a huge OO-based project, but certainly something to get
started with.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Sadly, I'm utterly uninspired about what to write past my first usual
> program, namely "Jotto". Any suggestions?
I was in the exact same situation as you. It depends on your past
programming experience. I knew Assembly and C and wanted to learn C++. I
first started a simple physics simulation "game". It showed bunch of
balls bouncing on the screen. Then I turned it into a 3D path tracing
renderer.
So: write a rendering engine!
Writing a chess engine was also fun.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> How about a program that takes a multivariate polynomial as input and
>>> determines if it has any roots over the integers ;-)
>>
>> I know you're joking, but I'm not sure how that would be more useful
>> in learning C++ than in learning C.
>
> It wouldn't really, I was just unable to resist giving an undecidable
> problem as a programming suggestion.
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?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> Sadly, I'm utterly uninspired about what to write past my first usual
> program, namely "Jotto". Any suggestions?
Coding a small game is always fun, and a good environment for
object-oriented design (there are so many things in a typical game that
can be naturally expressed with classes, such as for example a sprite,
level data, etc.)
OTOH one small problem with C++ is that there is no standard way of
drawing any graphics. Thus you'll have to resort to some third-party
library. The quality (as in C++ design quality) of existing libraries
is very varied, from usable to absolutely horrible. In my experience very
few C++ graphical libraries employ the same level of code design quality
as eg. the STL or the Boost libraries do, and they are often quite hard
to use, error-prone, and in some cases even buggy (there may be memory
leaks inside the library itself).
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
I have only extensive experience on the latter one, and while it's not
horrible, it's not STL-level-of-quality either, and probably not the
easiest possible to use. From the example codes I have seen of the HGE
library, it might not be the easiest possible to use either.
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, nor
do I know how easy it is to integrate in Visual Studio. 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.
(OTOH, you said you do have a lot of experience with C.)
You could try making DirectX or OpenGL code directly, but that would be
even lower-level code, and might become a nightmare. 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.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Coding a small game is always fun
This is the one thing I have never implemented. I'd like to do it at
least once before I die...
> 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.
(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!)
> 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!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> even lower-level code, and might become a nightmare. 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.
My first C program was a program that used the Windows API directly...
Your assessment is about accurate, though.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> However, I unfortunately have absolutely no experience in using it, nor
> do I know how easy it is to integrate in Visual Studio. 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.
There are a few SDL C++ wrappers.
This one looked quite good:
http://sdlmm.sourceforge.net/
This one seems to suck at a first quick look:
http://sdlpp.sourceforge.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> 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...)
Again libSDL :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> Sadly, I'm utterly uninspired about what to write past my first usual
>> program, namely "Jotto". Any suggestions?
>
> How about something to solve/play a game, like Sudoku, checkers, connect
> 4, poker etc. Not a huge OO-based project, but certainly something to
> get started with.
That would be ... "Jotto". ;-) A good idea, tho. :-)
I'm more into the data processing stuff than the heavy calculation stuff,
altho fractals and CAs are always fun. I'll have to see what libraries I can
find for stuff before I decide, methinks.
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Coding a small game is always fun, and a good environment for
> object-oriented design
Thanks for the pointers to the graphics libraries. I'll check it out.
Any suggestions on libraries for things like regular expressions, parsing
CSV files, talking to databases, things like that? Or do people just
interface to C libraries for that sort of thing?
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> ...and this is the reason why. Almost *no* languages have the capability
> to easily draw graphics these days.
Tcl/Tk does, as well as anything built on top of Tk in general (including
Perl, Python, and Erlang). ;-) No 3D stuff, tho.
> This made me actually laugh out loud. For real. Such a glowing
> recommendation of the Win32 API! :-D
It's definitely ugly, and it shows its heritage too.
> (OTOH, I understand that the raw X Windows bindings are even harder...
If you want *raw* X Windows, try formatting the socket data yourself.
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> 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!
>
Nobody even noticed anything. Couple of guys tested it and played for
something like hour oslt and just told me that it's freaking hard :D.
-Aero
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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...)
>
> Again libSDL :)
It seems to do lots of interesting stuff. Sadly, I can't get the Haskell
bindings for it to work. :-(
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Sadly, I'm utterly uninspired about what to write past my first usual
> program, namely "Jotto". Any suggestions?
Actually, I just remembered I wanted to take that permutation code from
bork.bork.bork that Warp posted and try to instrument it to figure out
what's going on. I should be able to do that with text, then turn that up to
using graphics (colored arrows showing things moving about or so) when I get
to the point of using a graphics library.
(You know, sort of like those things you find where they show you
graphically the array after each sort so you can see how the sort works
dynamically? Like that.)
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> 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".
I've written a few graphics apps in Java. I eventually wrote a (very
simple) image-screen class which I could plot to pixel by pixel, then
dump to the window when I wanted an update. Much easier than piddling
around with the AWT!
But you're right, I still had to plumb that into some window container
or whatever it was.
>>> (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!)
Those were indeed the days. Interpreted BASIC, where you could type that
directly into the command prompt and see the dot appear on the other
side of the screen.... *sighs*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> ...so it's "undecidable" because you can't always figure out the answer
> in finite time?
Basically.
A (yes/no) problem is decidable if it's possible to write a program
which will eventually answer the problem for any given input. Your
algorithm will only answer "yes" (ie there is a root), but will fail to
ever give a "no" answer.
It's the same with the halting problem. It's trivial to write a program
which will tell if if another program eventually halts, but impossible
to always determine when it won't.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Eero Ahonen wrote:
> Mike Raiford wrote:
>> 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!
>>
>
> Nobody even noticed anything. Couple of guys tested it and played for
> something like hour oslt and just told me that it's freaking hard :D.
That's awesome.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I've written a few graphics apps in Java. I eventually wrote a (very
> simple) image-screen class which I could plot to pixel by pixel, then
> dump to the window when I wanted an update. Much easier than piddling
> around with the AWT!
>
> But you're right, I still had to plumb that into some window container
> or whatever it was.
Yeah, this is what I ended up doing too. For Java, and more recently for
GTK. (GTK has strong support for vector graphics, but still no help if
you want to do bitmapped stuff algorithmically.) I've yet to find a good
way to handle displaying stuff on the screen so it responds to damage
messages yet your main program still continues executing...
>>>> (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!)
>
> Those were indeed the days. Interpreted BASIC, where you could type that
> directly into the command prompt and see the dot appear on the other
> side of the screen.... *sighs*
Even [gasp] POV-Ray isn't *that* easy...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Warp wrote:
> ...and this is the reason why. Almost *no* languages have the capability
> to easily draw graphics these days.
>
> (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!)
How about C# in a .NET environment? Just have the wizard create a program
template for you, code your custon OnDraw() handler, and hey presto! There you
go.
Okay, it's not "plot 4, 7" but "gr.draw(...);", so a few characters more, but
nothing conceptually challenging. Except that there's no "plot", so you have to
draw small circles or boxes to produce a dot.
But I remember, back in the days when I was learning C, I had similar problems -
all the more since I didn't have the slightest clue about programming for
Windows GUI nor X-Window (I could have gotten access to both at the institute).
But I desperately wanted to code a Quake level mapper, and *needed* some good
graphics output.
Fortunately I happened to know a bit of PostScript coding then, so I ended up
using the laser printers for graphics output :) (Later I also used GhostScript
in order to not waste too much paper, but of course it never came close to the
quality of the A3 laser prints...)
> > 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
Seen it once. I guess it's not *too* difficult for an *experienced* programmer
to get into it, but fortunately there's no need to: Virtually all mainstream
programming languages come with a framework that is *way* easier to use.
The main problem with the Windows API is that it's C, and doesn't actually lend
itself to being driven by C++ programs, plus there's a lot of "bureaucratic"
overhead involved, which begs to be handled by a framework instead of the
application developer.
> (OTOH, I understand that the raw X Windows bindings are even harder...
> apparently... I guess that's why there's so many toolkits!)
I've never seen the X APIs, but I imagine they're probably the same level of
complexity as the Microsoft APIs.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> I've never seen the X APIs, but I imagine they're probably the same level
> of complexity as the Microsoft APIs.
No they aren't. X doesn't provide any UI widgets as far as I know.
Most X example apps use only black and white, which makes me think using
more than two colors is an extra pain. That is because they the only colors
X guarantees that exist.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Thanks. Already downloaded it, haven't waded thru it very far. :-) I've
> been finding motivation a bit hard to come by lately.
It may be a good book, but its examples are not exactly motivational
material.
--
Beware of quantum ducks. Quark! Quark!
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> ...and this is the reason why. Almost *no* languages have the capability
> to easily draw graphics these days.
>
> (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!)
I've heard good things about Pygame.
--
Beware of quantum ducks. Quark! Quark!
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Most X example apps use only black and white, which makes me think using
> more than two colors is an extra pain. That is because they the only colors
> X guarantees that exist.
Last I looked, you not only have to know how many colors the screen
supports, but you have to order the bytes and such in the same order as they
are in the hardware. I.e., you query the X server for how many bits and in
what order the colors are, then you have to give all colors in that form to
the server. You have to convert the images yourself, put them in the right
order with the right stride, etc.
Now, note that "last I looked", an 8-bit color card for a machine that could
run UNIX was a thousand dollars or so, some 15 years ago, so take it with a
grain or two.
--
Darren New, San Diego CA, USA (PST)
The NFL should go international. I'd pay to
see the Detroit Lions vs the Roman Catholics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Or do people just
> interface to C libraries for that sort of thing?
I think most libraries out there are written in C rather than C++.
I suppose the ideology is something like "if I write it in C, it will
be still usable in C++, but I will get a much larger group of users
this way".
Sometimes someone will then write a C++ wrapper to make it easier to
use the library. The quality of such C++ wrappers vary wildly. (In my
little experience the average tends to be on the worse side, unfortunately.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Or do people just
>> interface to C libraries for that sort of thing?
>
> I think most libraries out there are written in C rather than C++.
> I suppose the ideology is something like "if I write it in C, it will
> be still usable in C++, but I will get a much larger group of users
> this way".
>
> Sometimes someone will then write a C++ wrapper to make it easier to
> use the library. The quality of such C++ wrappers vary wildly. (In my
> little experience the average tends to be on the worse side,
> unfortunately.)
A good approach (that few people use) is making the library in C++ and
making a C wrapper :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> No they aren't. X doesn't provide any UI widgets as far as I know.
Hmm...
nemesis@nemesis-desktop:~$ ls -lh /usr/lib/libXaw7.so.7.0.0
-rw-r--r-- 1 root root 358K 2007-07-24 07:00 /usr/lib/libXaw7.so.7.0.0
Looks still in place...
http://en.wikipedia.org/wiki/Xaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
