Invisible wrote:
>>> myself. OTOH, I have yet to write a working Tic-Tac-Toe program, 
>>> so... maybe not. :-/
>>
>> I did that in grade school. :) It was unbeatable.
> 
> The hard part is figuring out how to draw the graphics on screen and 
> register the mouse clicks. Usually you have to mutilate your program to 
> fit the window manager's event loop...

Oh, mine was written in QuickBASIC under DOS. (No window manager, no 
mouse, just good ol' fashioned keyboard. Fun that was..

Then I changed it so it played itself. I ran it for hours and printed 
out the statistics. X wins: 0 O wins: 0 Draw: <insert number of games 
played>

Heh. Good fun that was.

-- 
~Mike

Post a reply to this message

scott wrote:

> 
>> Usually you have to mutilate your program to fit the window manager's 
>> event loop...
> 
> Don't see how, if you have written functions like:
> MouseClicked(int xpixel , int ypixel)
> RedrawScreen()

Dangit! Now I have a the urge to write a C# version. I did the Towers of 
hanoi problem (with a solver) in C#, that entertained me for a while.


> etc, you just need to call them in response to the correct window 
> manager messages.  Of course if you write the whole game as just a big 
> long chunk of code you are going to find it hard to fit it in with a 
> window manager.
> 
> BTW why don't you just do a text based version?
> 
> 


-- 
~Mike

Post a reply to this message

scott wrote:
> 
> Some guy sitting at a computerised milling machine I would imagine.
> 
> And yes, how do you make that, etc etc I think at the beginning someone 
> had to make something with their bare hands :-)

probably a CNC mill with the appropriate toolpath loaded. Push a button 
and wait for the finished die to pop out. ;)



-- 
~Mike

Post a reply to this message

scott wrote:
>> The hard part is figuring out how to draw the graphics on screen
> 
> Choose a language / IDE / API that gives you easy access to graphics?

Does one exist?

>> Usually you have to mutilate your program to fit the window manager's 
>> event loop...
> 
> Don't see how, if you have written functions like:
> MouseClicked(int xpixel , int ypixel)
> RedrawScreen()
> etc.

Typically you have to register callbacks with the GUI system, and then 
call a "main loop" function which calls your callbacks when it feels 
like it. Which is great if you just want something to happen when the 
user presses a button, but becomes problematic if you want things to 
happen while the user isn't pressing anything. (E.g., if you wanted to 
do something compute-bound, now the GUI stops responding until the 
compute task finishes.)

> BTW why don't you just do a text based version?

Because that wouldn't be very exciting?

What I'd really like to have a go at is Mahjong... but that would be 
absurdly hard.

Post a reply to this message

Mike Raiford wrote:
> scott wrote:
>>
>> Some guy sitting at a computerised milling machine I would imagine.
>>
>> And yes, how do you make that, etc etc I think at the beginning 
>> someone had to make something with their bare hands :-)
> 
> probably a CNC mill with the appropriate toolpath loaded. Push a button 
> and wait for the finished die to pop out. ;)

In that case, why are there more jobs of "CNC mill operators" than there 
are for computer programmers? :-P

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> However, often you don't want your final product to be machined, because that's
> prohibitively expensive for a lot of purposes. Pressed (is that the right
> word?) or cast parts or the like are much different: They need special tools
> that need to be made first (e.g., the molds in case of cast parts). Again,
> they're prototypes.

You design your final part in your CAD program, then design the corresponding
tool using the part as a starting point (many CAD applications will do this
semi automatically). You machine your tool, then use it to cheaply punch, cast
etc your main end product.

Bingo!

Post a reply to this message

> Does one exist?

Download and install Visual C# Express edition, click "create new project" 
and then add in a few lines of code to draw stuff on the window (check out 
Mike's recent posts about his flood fill and fire programs).  That's about 
as simple as I can imagine in a window'd OS, I'm sure there are loads of 
tutorials and example projects to get you started.

> Typically you have to register callbacks with the GUI system, and then 
> call a "main loop" function which calls your callbacks when it feels like 
> it.

Dunno about that, in Visual Studio Express I just go to the OnPaint property 
and type in or select a function name from the drop-down menu.  That 
function then gets called when the form/control needs repainting.

> happen while the user isn't pressing anything. (E.g., if you wanted to do 
> something compute-bound, now the GUI stops responding until the compute 
> task finishes.)

Anything that is going to take a while you should probably do in another 
thread so your code can still respond to GUI events.  It's very easy, just 
one call to _beginthreadex windows API function starts off the given 
function in a new thread.

You can also drag and drop a timer onto your form and then tell it to call a 
certain function every so often, which is useful if you want to do some 
simple animation.

And if you want to look into anything more complicated than lines and simple 
pixel animation, DirectX is easier than ever to use now, especially if you 
already understand 3D coordinates and stuff.

Post a reply to this message

Invisible wrote:
> scott wrote:
>>> The hard part is figuring out how to draw the graphics on screen
>>
>> Choose a language / IDE / API that gives you easy access to graphics?
> 
> Does one exist?
> 

C# Maahahaahh ... hahaah.. hah.. <cough> heh.


> 
> Typically you have to register callbacks with the GUI system, and then 
> call a "main loop" function which calls your callbacks when it feels 
> like it. Which is great if you just want something to happen when the 
> user presses a button, but becomes problematic if you want things to 
> happen while the user isn't pressing anything. (E.g., if you wanted to 
> do something compute-bound, now the GUI stops responding until the 
> compute task finishes.)
> 

Huh? Do it on a background thread! For a game that has constant activity 
  (a game loop, many games, but tic-tac-toe doesn't have this 
requirement!) You'd generally have within your message loop a call to a 
function called "DoGameLogicForThisFrame" or some such. It gets a time 
delta from the last frame so you can adapt your logic to the frame work. 
You work your computations in steps, so you don't block the frame for 
too long, which usually works well for most things like character 
movement, etc. Just make sure you calculate the frame quickly so you 
don't kill frame rate. At some point you perform your message pumping if 
any messages are in that thread's message queue.

Keyboard or mouse input can still be handled by event functions, you 
just store the values somewhere convenient for the game loop to get to 
them. I managed to have the keyboard basically act as a game controller 
by handling KeyDown/KeyUp events and mapping to a list of keys.. I could 
then check that list and see if that key were down and up.

>> BTW why don't you just do a text based version?
> 
> Because that wouldn't be very exciting?
> 
> What I'd really like to have a go at is Mahjong... but that would be 
> absurdly hard.

Dude! Mahjong is easy EASY! That was one of the easiest games I ever 
worked on! The ONLY hard part is if you want to give hints or have the 


-- 
~Mike

Post a reply to this message

Invisible wrote:

> In that case, why are there more jobs of "CNC mill operators" than there 
> are for computer programmers? :-P

well, someone has to maintain the machine and kick it when it 
misbehaves. ;) Oh, and they may be in the office with specialized CAD 
programs making sure the tool paths won't cause the machine to bind, 
jam, cut too much, etc..


-- 
~Mike

Post a reply to this message

>>>> The hard part is figuring out how to draw the graphics on screen
>>>
>>> Choose a language / IDE / API that gives you easy access to graphics?
>>
>> Does one exist?
> 
> C# Maahahaahh ... hahaah.. hah.. <cough> heh.

Isn't that based on C? (And hence inherantly "not easy".)

>> (E.g., if you wanted to 
>> do something compute-bound, now the GUI stops responding until the 
>> compute task finishes.)
> 
> Huh? Do it on a background thread!

And now you have to manage thread coordination problems. :-}

But yeah, maybe I'll get to have a go at this some day... when I'm 
feeling brave.

>> What I'd really like to have a go at is Mahjong... but that would be 
>> absurdly hard.
> 
> Dude! Mahjong is easy EASY! That was one of the easiest games I ever 
> worked on! The ONLY hard part is if you want to give hints or have the 


Nooo - the hardest part is drawing thousands of tile images to make the 
game work. :-P

Post a reply to this message