Help with making a maze game with MASM

[wicked357]

I have been working with assembly for some weeks now and I want to actually take on a challenge that actually might interest me in the means to learning it better, so I thought I would try and make a maze game something simple, not sure on size yet I will have to see what my console size is and go from there, I would like some suggestions or maybe a tutorial or example I could get a good idea from and work with. Anything really would help on this, thank you!

[wildgoose]

Make a high resolution random maze. I built one of these a very long time ago and pretty cool!

Set all pixels on. Set the outer edge a different color. When you are done you'll have interlaced pixels of walls and paths. Assuming you only want one path through the maze, look at an adjacent pixel. Is there a wall? Yes? Is there a wall next to it yes, set that pixel and the pixel between the two as path? Then recursively call the maze builder passing that new adjacent pixel. So techically recursion occurs on odd row/col pixels. Even's are walls or wall opernings thus paths. If you get a no, look at the other walls, looking for adjacent pixels. This is lots of recursion up and down, but you will get one unique maze through the entire object. If pixel is a border wall, move to another pixel direction.

Once done, Cut a hole in the wall at two locations, then set a pixel mouse! Have it traverse the maze! Fun to watch!

But build it in C first! Then rewrite to assembly. Your turn around time will be faster!

[wildgoose]

Found it. Built it back in 1992 for a College For Kids class I taught at Columbia College. Haven't found the source but the EXE is in the zip. Press escape key to quit.

[wicked357]

That is pretty cool, I'm really looking do something more simple to start out with. Something like maybe 20x20 characters using a color scheme and making one path to the end, a time limit and maybe a menu to start the game. Do you have any help on something this simple, or along the lines on where to start for the maze rendering part of the characters.

[wicked357]

Ok I would say this how can I display multiple characters on the screen without making a gotoxy macro then telling what character to write to the screen for every single character space. something that is easy I guess or the best way to do it.I think that is where I should probably start I would then think I would create boundaries after that and create the "character" character say a # is the character, then probably take in input from the user like using the arrows keys. But that is all in the future I just want to be able to display all the walls without typing 1000's of lines of code or even 100's because I dont know the efficient way to do it.

[wildgoose]

What I told you is pretty simple. Remember the colored border bit!

The colored border keeps the maze builder confined.

So, make a 20x20 array, instead of full screen.
char ary[20][20];
Fill it with 'X's.
On the perimeter fill it with '@'s. Randomly start at (1...19) | 1;
x = (rand() % (20 -2)) + 1;
y = (rand() % (20 -2)) + 1;
If you encounter a '@', act like its a path so don't go there!
As you mark a path insert a ' ' (space).

You can do something like system("cls"); Then print the array to watch the maze building logic! It would be even better if you could somehow home the cursor to the top of page without erasing it!

Like I said, very simple! All you are doing is randomly probing two cells away and if you find a wall (in a prospective room/hall slot) then recursively call your function passing the new X,Y coordinate of that spot, paint your floor (' ') then probe for missing floors on all four sides of you. If none found then return from your function call. The previous recursion will then probe, and so forth. Once you hit home plate, the very first place you started and probe all its walls and find nothing to do, you're done!

The interesting thing is for more advance steps, paint the border in shapes in your array (or pixel screen). The border should be painted on odd cells, but it will keep the recursion wall builder (actually floor builder) within its confines so it will build a wall to fill the shape!

Then randomize an entry point and exit point on the border.

Then build your mouse!

Look forward to seeing your posted code! I'l help out if you hit a programming snag. Draw a five by five cell on graph paper. Walk through the logic on paper with colored pens. Understand the logic then write the code!

[wildgoose]

This is WAY more then I should start you with but you should get the basic idea from this!

char ary[ MAZE_X ][ MAZE_Y ];


void BuildMaze( int gx, int gy )
{
    int x, y, flg;

  flg = 0x0f;                          // set our random wall tracker
   ary[ gx ][ gy ] = ' ';           // Mark our floor!
                
     while (flg)  // randomizer
     {
           int r = rnd() & 3;      // Randomly pick a wall
           int bit = 1 << r;        // Bit indicating that wall

          if (!(flg & bit))            // If wall already checked...
                continue;

           flg ^= bit;                 // clear flag indicating that wall checked!

           switch ( r )              // Now check it!
           {
               case 0:    // Left
                     if ( 0 < gx - 2 )            // Within array confines?
                     {
                          if (ary[ gx-2 ][ gy ] == 'X')   // Room still a wall?
                          { 
                               ary[ gx-1 ][ gy ] = ' ';   // mark floor between rooms
                                BuildMaze(  gx-2, gy );   // recursion
                          }
                     }
                    break;

               case 1:    // Up
               case 2:    // Right
               case 3:    // Down
                  break;
             }
         }

[wicked357]

I was thinking more like a visible maze map with a time limit to get to the end or the game will end, so the map would be static not randomly generating it.

[wildgoose]

It's your project. Your ultimate goal is to write this in assembly code. C code was merely the inital step to get it working and proof of algorithms.

If you examine the function I partially did, finishing it should be pretty easy!

[wicked357]

It's your project. Your ultimate goal is to write this in assembly code. C code was merely the inital step to get it working and proof of algorithms.

If you examine the function I partially did, finishing it should be pretty easy!

I think you are over estimating me... lol, I am having problems figuring out a timer system I wanna use in this game let alone drawing the maze and determining user input for moving around and collision with walls. I might have bit off more then I can chew here, but I hate to just give up... I honestly think I might quit any form of ASM learning after not being able to complete this task, and that just isn't me I think I will continue trying until the end of the week if not, I give I guess as sad as it is. Who knows maybe I won't quit, but I am getting close I can't seem to find any useful information on the web that had helped me and my book is awful for examples and understanding them.

[wildgoose]

I'm conflicted. You see the maze algorithm I practically gave you in code is almost complete for a simple array like you were trying to do. For pixels, you only need to increase the 'array' size and have the ability to peek at a pixel color and set a pixel color
SetPixelColor( x, y, red );
Something like that! The graphics frame buffer essentially became your array!

Converting it to assembly would have been easy.
Write a paint pixel to screen using the old BIOS Video Interrupt call. (Or using a graphics SDK).

Then call the function in assembly, or change the pixel directly in the frame buffer!

Replicating the C logic in assembly!

So I am pretty disappointed you didn't run with what I had practically give you!

In my mind, finishing your array logic in assembly c to b-
Doing it in graphics with pixels, a little more work A to A+.

As to your timing System?

You can use a rough one such as

static int ticLast = GetTickCount();
int tic, tDelay;
float fTic;

while (bGameIsRunning())
{
    tic = GetTickCount();
    tDelay = tic - ticLast;
    ticLast = tic;
    if (ticDelay > 125)        // Limit if debug breakpoint chewing
          ticDelay = 126;      // up time!
    fTic = ((float)ticDelay) / 1000.0f;           // 1.0 = 1 second


      // Use fDelay for incremental of elapsed time since last frame
}

Use fDelay as a time factor.
mouse moves at a maximum rate of 25 pixels per second

fMouseSpeed = 25.0f;

fX += fMouseRate * fTic;

So after one second has elapsed he'll be around 25 pixels from where they were! More X,Y math then that, but that's the basic idea!

OOPS! But in your case 1 room one second
fTime = 0;

the loop

fDelay += fTic;
if (fDelay > 1.0f)
{
     fDelay -= 1.0f;
     // Move to new grid
}

You can use integer so tDelay, and use 1000 as your threshold since GetTickCount() is in milliseconds. 1/1000s

I like thinks smooth so my timer is more accurate!

static double fFreq;
static __int64 tLastCount;
__int64 tFreq, tCount, tDiff;
float fTic;

QueryPerformanceFrequency((LARGE_INTEGER*) &tFreq );
fFreq = (double)tFreq;
QueryPerformanceCounter(  (LARGE_INTEGER*) &tLastCount );

GAME LOOP HERE

	//	____________________
	//	Calculate frame time

QueryPerformanceCounter((LARGE_INTEGER*) &tCount );
tDiff = tCount - tLastCount;
tLastCount = tCount;
fTic = (float)(((double)tDiff) / fFreq);
if (fTic > 1.0f / 30.0f)
    fTic = 1.0f / 30.0f;		// Debug delay correction

[wicked357]

I am pretty disappointed as well, usually I am good with these things, but ASM has completely confused and frustrated me... normally I get the ahh I get it factor. Using ASM I don't get that "epiphony" so to speak, I try using interrupts and found out that Vista Ultimate 32-bit won't allow me to access those, so now I am stuck on input as well, I thought about trying to do a character conversion with my character and using .if's and a loop specifically for my character, so the maze doesn't redraw every time I move my character. You gave me a lot of information to look over, yet my lack of knowledge with ASM might not allow me to fully grasp how to convert that over. My C/C++ skills haven't been tapped in a little while so I might have to take a look and reference some stuff I haven't used in awhile. Thanks for all your help though and I really appreciate it, for now I think I might try and figure more out about ASM and hope I can one day make this maze. The book I have chooses to use a lot of interrupts which I can't seem to use.

[wildgoose]

Of course. Most of the features of assembly etc. could only be used on Win98 or earlier unless you were making drivers. So interrupts are out of the question. Especially under Vista. There is a assembler 80x86 simulator that you can download. I don't remember the name, but lets you do all that old stuff you could do prior to Win2K and XP. And you're right, Microsoft has set the system layer to block access to certain functionality on their Operating Systems.

My frustration comes to you wanted to make a maze game. I posted simple C code to do just that but you insisted on making it easier by putting a GUI on it so as to build your own mazes but in reality that actually makes it harder. You have to handle data conversion and wrong data entry, etc.

Despite what is taught in school, you should NEVER write your function in assembly language until after you've written it in a high level language, tested it, and then used it for reference when writing your assembly code.

I'd love to review your assembly code (if its not too big. Some people post massive code for people to look at but with minimal formatting, and nil comments, its impossible to read!)

Look forward to your posting!

[wicked357]

I started the maze on a empty program, so my menu system wouldn't get in the way, and going through it all the time gets redundant. Anyways here is what I have been working on for movement but I am unable to get it to work right. I am sure you will look at this and go OMG! WTF is he doing... at least that is how I feel when I do this stuff and I don't get it... lol anyways hopefully you can make sense of it I tried to comment efficiently for you.

Here is my variables:

_x BYTE ? ;x location
_y BYTE ? ;y location
_char BYTE 0DBh
_move DWORD ?

Here is main code:

mGotoxy MACRO X:REQ, Y:REQ
	push edx
	mov dh, Y
	mov dl, X
	call Gotoxy
	pop edx
ENDM
mWrite MACRO text
	LOCAL string
	.data
	string BYTE text,0
	.code
	push edx
	mov edx, OFFSET string
	call writestring
	pop edx
	call crlf
ENDM

;*****************GAME LOOP*********************
;draw a not factor maze to the screen for visual only ATM!
DRAW:
	mWrite "#################X##"
	mWrite "################  ##"
	mWrite "################ ###"
	mWrite "###########      ###"
	mWrite "########### ########"
	mWrite "########### ###   ##"
	mWrite "########### ### ####"
	mWrite "###########     ####"
	mWrite "############ #######"
	mWrite "####         #######"
	mWrite "############ #######"
	mWrite "############ #######"
	mWrite "############ #######"
	mWrite "############ #######"
	mWrite "#######      #######"
	mWrite "####### ############"
	mWrite "        ############"
	mWrite "####### ############"
	mWrite "#######         ####"
	mWrite "####################"
	
	mov _x, 0 ;declare _x as 0
	mov _y,16 ;declare _y as 16
	JMP GAME
GAME:
	call readstring	;read input
	mov _move, eax		;move input to _move
	mGotoxy _x, _y		;move cursor to location of _x and _y
	mov al, _char		;move _char to al register
	call writechar		;write al to console
	.if _move == 119	; UP if w is pressed -- _y
	dec _y	
	.endif	
	.if _move == 115	;DOWN if s is pressed ++ _y
	inc _y
	.endif	
	.if _move == 97	;LEFT if a is pressed -- _x
	dec _x
	.endif	
	.if _move == 100	;RIGHT if d is pressed ++ _x
	inc _x
	.endif
	
	.if _x == 1 || _y == 1 ; if _x and _y equal 1 then game is over
	JMP OVER
	.endif

	JMP GAME
    
;*****************END GAME**********************
OVER:
    
	exit

[wildgoose]

I'm really not sure what you're tryng to do! But looks like you're mixing conditionals with assembly!

.if in assembly is like #if def in C

.if _move == 119	; UP if w is pressed -- _y
  .if

Is a conditional assemble.
In assembly language

KeyEval:
    cmp eax,119
    jne  $L1

    dec   _y
    jmp $Nxt

L1:    cmp eax,115
    jne   $L2:

      inc   _y
     jmp $Nxt

; etc.


$Nxt:
; Now movement handled, do the visuals

I tend to minimimize macro usage as one writes in assembly language for fastest code possible, but macros have fixed register placement as they're defined!

Would be interesting to see your procedures

readstring
writechar
Gotoxy

[wildgoose]

So to help you out, is this a class assignment or are you just learning on your own?

What toolset are you using for this? (In addition to MASM as indicated on this topic!)

Are you mix and matching C and assembly or trying to do pure assembly?