Prev: Win32 non blocking console input?
Next: hugi compo #29
From: NathanCBaker on 3 Dec 2008 19:08 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 3 Dec 2008 19:59 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 3 Dec 2008 20:27 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 3 Dec 2008 21:42 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 4 Dec 2008 04:51
<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 |