News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Tita in labyrinths

Started by felipe, June 04, 2018, 02:08:12 PM

Previous topic - Next topic

jj2007

Quote from: zedd151 on June 07, 2018, 07:29:41 PM
Have you tried resizing the console window jj?

Yes. Have you looked at the source?

zedd151

Quote from: jj2007
Yes. Have you looked at the source?

Yep.

aw27

Felipe,

I had a look at the code.
1) You are not obtaining the output handle.
I don't see anywhere this:
mov     rcx,STD_OUTPUT_HANDLE
call    GetStdHandle

2) You need to set the window size with:
SetConsoleWindowInfo

jj2007

Quote from: AW on June 07, 2018, 09:18:56 PM1) You are not obtaining the output handle.
I don't see anywhere this:
mov     rcx,STD_OUTPUT_HANDLE
call    GetStdHandle

He uses WriteConsole instead.

Strange that nobody spots this:firslab0    byte     '********************************************************************************',0dh
            byte     '*       *******************                               **********************',0dh
            byte     '******* ******************* ********************** ***************            **',0dh

aw27

Quote from: jj2007 on June 07, 2018, 09:48:18 PM
Quote from: AW on June 07, 2018, 09:18:56 PM1) You are not obtaining the output handle.
I don't see anywhere this:
mov     rcx,STD_OUTPUT_HANDLE
call    GetStdHandle

He uses WriteConsole instead.

Strange that nobody spots this:firslab0    byte     '********************************************************************************',0dh
            byte     '*       *******************                               **********************',0dh
            byte     '******* ******************* ********************** ***************            **',0dh


He needs the output handle to set the size of the console.
If the console has the correct size the characters will flow from line to line even without crlf and the labyrinth will work.

jj2007

Relying on the "correct" size and line wrapping is a hack for me. If he uses "***", 0Dh, 0Ah it will work with any size that is wide enough.

felipe

I  don't used getstdhandle because i use createconsolescreenbuffer which returns a handle for the screen buffer.

This is just a porting work to an old game (my first in 32 bits). The intention it was not to make a full improvement. Because in the 32 bits version the only problem reported was another issue and was fixed (with help of AW) i didn't even revised again the code. The program still works for me and as far as i know for others too. Until now the problems are in a computer with some "special format" (zedd) and from the one of jj (?).

Also i has changed the console window size before trying the game and i have no problems to play it at all. Neither i see a problem with crlf. You should have a look to the writeconsole funtion and relateds.  :idea:

felipe

Oh btw, the screenshot (last one) from zedd is a little weird too, in the sense that shows the cursor, which is been made invisible in the program. Bur as i said his OS is a little special i will say again.  :idea:

felipe

Also the char for tita in that screenshot is not the one that was intended.  :idea:

zedd151

Quote from: felipe on June 08, 2018, 01:24:21 AM
Oh btw, the screenshot (last one) from zedd is a little weird too, in the sense that shows the cursor, which is been made invisible in the program. Bur as i said his OS is a little special i will say again.  :idea:

This Saturday I plan on doing a fresh factory install,  all drivers included.  I will then find out if the font/hidden cursor is repaired or not,  plus any other anomalies caused by my modified system. Through process of elimination I will get to the bottom of this.   :icon_cool:

I will then make a backup of the "clean" install for future references.    :icon_mrgreen:

jj2007

Quote from: felipe on June 08, 2018, 01:20:20 AMi have no problems to play it at all
That is the right attitude :t

felipe

jj2007 i don't know if that is sarcasm or not. Anyway i have just revised a little the code and i have found a very odd thing here:


   lea     rsi,firslab0  ; Line by line.
        mov     rbx,2024            ; The size of each labyrinth.

completelab:
        mov     rcx,r14 ; stdoutx.
        mov     rdx,rsi
        mov     r8,1
        lea     r9,chrswrit
        mov     dword ptr[rsp+20h],NULL
        call    WriteConsole

        inc     rsi         ; Next line.

        dec     rbx
        cmp     rbx,0         ; Until we finish.
        jne     completelab


And the same problem in the 32 bits version:

            mov                 esi,offset firslab0                                 ; Line by line.
            mov                 ebx,2024                                            ; The size of each labyrinth.

align 4

completelab:

            push                NULL
            push                offset chrswrit
            push                1                                               
            push                esi
            push                stdoutx
            call                WriteConsole
           
            inc                 esi                                                 ; Next line.

            dec                 ebx
            cmp                 ebx,0                                               ; Until we finish.
            jne                 completelab


Both of course are bad comments. And in both the approach is really inefficient. It's not actually writing line by line, it's doing it char by char.  :P

Btw and anyway....soon as i can i will try this (both versions) in a windows 7.  :idea:
I will remind here to all of you that this code may used, reused, improved, corrected, destroyed, ignored, etc, etc. But not necessarily by me.  :biggrin:  :idea:

zedd151

#42
Quote from: felipe
I will remind here to all of you that this code may used, reused, improved, corrected, destroyed, ignored, etc, etc. But not necessarily by me.  :biggrin:  :idea:

This weekend I'll look at the 32 bit version to see what if anything I  could do with it.   :icon_cool:
Will be my first coding session for quite some time.

I need a break from trying to break my OS.   :P

Quote from: felipe
jj2007 i don't know if that is sarcasm or not.
Sounds like jj being jj. You get used to it.

jj2007

Quote from: felipe on June 08, 2018, 03:19:25 AM
jj2007 i don't know if that is sarcasm or not.

Ok, it seems I have to explain it:

Quote from: jj2007 on June 08, 2018, 02:25:51 AM
Quote from: felipe on June 08, 2018, 01:20:20 AMi have no problems to play it at all
That is the right attitude :t

Imagine for a moment that there is a fat bug in M$ Office, and Millions of users complain bitterly that they can't use M$ Word. And then the CEO of Microsoft says "We tested it, and it runs just fine on our computers, where is the problem?".

How would Micros**t's clients react?

In this thread, I have repeatedly pointed to your bug, but you have chosen to ignore that. To help others, I'll explain it briefly here:

If you print to the console, and your strings are ending with 0Dh (aka carriage return, cr) instead of 0Dh, 0Ah (aka carriage return + line feed, crlf, aka 13, 10), then all you can see is one line, because the strings will not advance at all. I have pointed to this phenomenon shortly after the "It looks like there is something wrong with the video drivers" post:

QuoteSame for me on Win7-64 - no labyrinth, just one line of stars. It seems, though, that it prints the labyrinth lines, unfortunately all of them to the same row. Check your data section, and remember what CrLf means.

Finally, and I promise this will be my last comment on your coding:
completelab:

            push                NULL
            push                offset chrswrit
            push                1                                               
            push                esi
            push                stdoutx
            call                WriteConsole
           
            inc                 esi                                                 ; Next line.

            dec                 ebx
            cmp                 ebx,0                                               ; Until we finish.
            jne                 completelab


For a while, I have noted that you don't use invoke. That makes it difficult to read your code, and it is, of course, an elegant way to introduce bugs that are difficult to chase, especially in x64. But it looks very professional and close to the bare metal etc.; to improve the look even further, however, I would suggest to care a little bit for the basics, such as flags:
            dec                 ebx
            cmp                 ebx,0                                               ; Until we finish.
            jne                 completelab

            dec                 ebx
            jne                 completelab                                       ; Until we finish.

felipe

Yes the cmp was inefficient code too. But i don't think that has anything to do with the look of the code.  :idea:

There's no  problem with crlf because of this:

From microsoft win32 api documentation:

Quote
High-Level Console Modes
...

Both of the following console output modes are enabled for a console screen buffer when it is created:

·   Processed output mode
·   Wrapping at EOL output mode
...

ENABLE_WRAP_AT_EOL_OUTPUT   
Used with a console screen buffer handle to cause the current output position (cursor position) to move to the first column in the next row (line) when the end of the current row is reached.
...

That's the reason for the use of only the 0ah control char. Of course that was inefficient too, because even this character wasn't required. :idea:

Btw, as for me, there's no problems to receive more comments, so from my side, there's no need to promises to not make more comments to tita's original code. (i mean this appliying to the 64 bits version as well).  :idea:

As respect to the microsoft comparision...Don't know what to say, probably it's not too much related with my case... :P

Btw as i said before soon as i can i will run both original versions in a windows 7 to see if i can get something similar to your screenshot.  :idea: But as i have said too, this has been an (almost) fully mechanical port from this old (my first 32 bit game) to a 64 bit version, with almost none improvement intended, nor code revision either.  :idea: