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