From: NathanCBaker on
On Dec 3, 12:15 am, Chuck Crayne <ccra...(a)crayne.org> wrote:
> On Sun, 30 Nov 2008 12:57:02 -0800 (PST)
>
> NathanCBa...(a)gmail.com wrote:
> > This is crude (un-polished) mock-up of a Fifteen (Sliding) Puzzle
> > game.
>
> Good work!
>
> Now, how about a gui version?
>

Truthfully, if I were to do a Win32 API version, I would cheat and
make it look very much like this CUI version. I'd simply intercept
keyboard events and then draw new text onto the screen.

If I do a clickety-click, mousy-oriented one, I'd simply choose a
better language and framework for the task.

http://shoooes.net/ for instance.

or....

http://love2d.org/
http://scratch.mit.edu/

I *do* admire what the many Masm32 folk and some RosAsm dudes have
done with GUI assembly, but I, myself, have never been very interested
in that sort of thing and never really understood the "point" of it.

Nathan.
From: Chuck Crayne on
On Wed, 3 Dec 2008 16:08:03 -0800 (PST)
NathanCBaker(a)gmail.com wrote:

> Truthfully, if I were to do a Win32 API version, I would cheat and
> make it look very much like this CUI version. I'd simply intercept
> keyboard events and then draw new text onto the screen.

As long as one is merely manipulating text, I agree that there is not
much "point" to the "click". However, I have seen versions in which
sections of a picture are used instead of numbers. For example the Sun
newspaper had what they called a "jugsaw puzzle", which used a photo of
one of their "page 3 girls".

The program logic is, of course, identical, except for the display
routine. As to the appropriate language to use, it really doesn't make
too much difference when one is mostly calling library routines, but
this IS an assembly language group.

--
Chuck
http://www.pacificsites.com/~ccrayne/charles.html


From: NathanCBaker on
On Dec 3, 7:59 pm, Chuck Crayne <ccra...(a)crayne.org> wrote:
> On Wed, 3 Dec 2008 16:08:03 -0800 (PST)
>
> NathanCBa...(a)gmail.com wrote:
> > Truthfully, if I were to do a Win32 API version, I would cheat and
> > make it look very much like this CUI version.  I'd simply intercept
> > keyboard events and then draw new text onto the screen.
>
> As long as one is merely manipulating text, I agree that there is not
> much "point" to the "click". However, I have seen versions in which
> sections of a picture are used instead of numbers. For example the Sun
> newspaper had what they called a "jugsaw puzzle", which used a photo of
> one of their "page 3 girls".
>

A little motivation to actually *solve* the puzzle. I approve!!
Hmm... I'd have to choose the pic with some care... would hate to be
the cause of a medical problem for one of you old geezers. :-)

> The program logic is, of course, identical, except for the display
> routine. As to the appropriate language to use, it really doesn't make
> too much difference when one is mostly calling library routines, but
> this IS an assembly language group.
>

I am convinced that Herbert hasn't gotten that memo. :)

Nathan.
From: NathanCBaker on
On Dec 2, 5:00 am, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote:
> <NathanCBa...(a)gmail.com> wrote in message
>
> news:aa43d0d5-7eaf-4040-b9b9-86ec0e5c1765(a)s20g2000yqh.googlegroups.com...
>
>
>
> > This is crude (un-polished) mock-up of a Fifteen (Sliding) Puzzle
> > game.
>
> > #include( "stdlib.hhf" )
>
> > type
> > blank:class
> > var
> > column :int32;
> > row :int32;
> > left :boolean;
> > right :boolean;
> > up :boolean;
> > down :boolean;
> > board :dword;
>
> ?  What a mess...  (That's from a guy who loves C and likes x86 assembly.)
>
> Hmm, dword, boolean, int32...  Is there a difference between "dword" and
> "int32" in HLA?  Why?!?!...  Why are there both differently sized "words"
> and differently sized "ints"?  I'm assuming both are multiples of 8-bit
> bytes.  Yes?  Is one unsigned and the other signed!?!?!  (Horror of horrors!
> Please don't say "yes"...)  If so, which is which?  No way to tell from
> that.
>

dword = dword
int32 = signed
uns32 = unsigned
boolean = dword (if I recall correctly)

> What exactly is a "boolean" in regards to assembly?  Does this mean every
> time "down" is used it gets logical and-ed with 0x01 ?  What a waste...
> Maybe he should add unions like C - then you get 8 booleans per byte - but
> everything still gets an implicit "and"...
>

Does the C standard specify the the implementation must guarantee "8
booleans per byte", or is that simply an artifact of compiler-
designers' choices?

> > procedure create( field:dword );
> > procedure check( x:int32; y:int32 );
> > procedure mleft;
> > procedure mright;
> > procedure mup;
> > procedure mdown;
> > procedure show;
>
> You have "procedure" declarations in assembly?  Wow, one of C's *worst*
> features sewn onto HLA...

Not usually. These declarations are only needed when using HLA's O-O
facilities. For this particular game, there is absolutely no reason
to use OOP technigues, but I used it as a quick crutch for this
prototype.

> > procedure blank.create( field:dword );
> > begin create;
>
> Odd.  You declare it *and* you have to tell it to begin...  Is one *really*
> allowed to put other stuff between the 'procedure' line and the 'begin'
> line?  Can I declare other procedures there?  Other variables?  Didn't think
> so...

Yes! One can put stuff between those lines. Not other procedures,
but you can (and often do) declare a var section, static section, etc.
in that space.

>
> > push( eax );
> > push( ebx );
> > push( ecx );
> > push( edx );
>
> Is there something wrong with:
>
> push.eax
> push.ebx
> push.ecx
> push.edx
>

He reserved the dot to service the 'namespace' syntax.

> Hey, he says it's not C, therefore it should look more like OOP C++, i.e.,
> action.object .  The hodge-podge, everything-from-everywhere, language
> design of HLA is really irksome.  Don't you think so?
>

The hodge-podge, everything-from-everywhere, language
design of Python is really irksome. Don't you think so?

The hodge-podge, everything-from-everywhere, language
design of Ruby is really irksome. Don't you think so?

The hodge-podge, everything-from-everywhere, language
design of Java is really irksome. Don't you think so?

> > if( esi = 0 ) then
>
> I'll have to assume equality and not assignment...  Use of "=" for
> assignment is likely to permanently braindamage HLA programmers when they
> move on to C or Pascal.  Superb syntax choice, not!

Assignment in Nasm is: mov eax, 42

Use of "=" for assignment is likely to permanently braindamage Nasm
programmers when they move on to C or Pascal.

>
> > mov( field, ebx );
> > mov( ebx, this.board );
> > for( mov( 0, ecx ); ecx < 16; inc( ecx ) ) do
> > mov( 0, (type byte [ebx+ecx]) );
> > endfor;
>
> For want of braces, to terminate a for()... I'm forced to type five more.

I actually appreciate the readability of "endfor;", "endif;", and the
like. A couple months ago, I had the devil of the time attempting to
enhance a semi-complicated piece of Ruby code when I tried to locate
the end of a 'while' loop hidden among a bunch of nested if blocks.
This is what I saw [replacing spaces with "." in case you're not using
a fixed-width font]:

.............end
...........end
.........end
.......end
.....end
...end
end

One of those in the middle was the 'end' associated with the 'while'.
I probably would have pulled out my hair if I had to deal with this:

))))))))))))))

:-)

>
> [snip]
>
> > for( mov( 0, ecx ); ecx < 16; inc( ecx ) ) do
> > mov( (type byte [ebx+ecx]), al );
> > breakif( al = 0 );
>
> breakif?  Oddly interesting...  Are you telling me HLA programmers can't
> figure out how to exit a for()?  Can they program their way out of a paper
> bag?
>

Opps! I thought it was made of plastic! :)

reverse the loop....

test al, -1
jz @F
dec ecx
jnz @B

>
> > stdin.getc();
>
> Is there a need for () on getc here?  Is there any other place a char can
> come from other than the stated stdin?  I.e., I don't think this is legal:
>
> stdin.getc(myfile);
>

A lot of the StdLib functions are re-use in other namespaces. So,
there really is something like:

fileio.getc( myfile );

....because we *do* have to specify the file handle when accessing
anything other than stdin, stdout, and stderr.

>
> Coal for Randall...
>

A programmer's manual for Rod.

Nathan.

From: Rod Pemberton on
<NathanCBaker(a)gmail.com> wrote in message
news:0fe612d9-e074-4f89-9158-0c22ba62eed6(a)j11g2000yqg.googlegroups.com...
> Are you trying to say that a C compiler makes a good assembler?

Not speaking for HK, but "yes," especially with optimization. There are
areas where they are weak. But, for most general programming, they're quite
good.

> Would you teach people assembly language by simply
> teaching them to write C code?

It depends on the processor. I'd also start them on an 8-bit MMU-less
processor so they the basics first. For a CISC processor like x86, I'd say
"no." Assembly on a CISC is far richer than what can be done in C. On a
RISC processor, "still no." *But*, that's only because they must look at
the assembly output of the compiled C to learn assembly... I.e., just
teaching them C won't teach them assembly simply or otherwise. ;-) IMO, C
captures almost the entire essence of RISC.


Rod Pemberton


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13
Prev: Win32 non blocking console input?
Next: hugi compo #29