Rixeno

Alright, so I'm making a top-down game using my Pixel Perfect Collision Engine (Link). The player moves around using the code I have used in the engine. I want the player to avoid going into the crate, by using the collision detection while still wanting it to be able to push it around. The only method I have been able to find for this is to place this code in the crates step event:

motion=obj_player.motion;
if (place_meeting(x-1,y,obj_player))
	move_step(motion,0,obj_block);
if (place_meeting(x+1,y,obj_player))
	move_step(-motion,0,obj_block);
if (place_meeting(x,y+1,obj_player))
	move_step(0,-motion,obj_block);
if (place_meeting(x,y-1,obj_player))
	move_step(0,motion,obj_block);

Where "motion" is simply the speed of the player.
Here is also the code for move_step, the piece of code used for my engine:

{
 //argument0 - x displacement
 //argument1 - y displacement
 //argument2 - wall parent
 var i,move_check;
 for (i = abs(argument0); i > 0; i -= 1)
 {
  if (i < 0) {i = 0;}
  move_check = sign(argument0)*i;
  if !(place_meeting(x+move_check,y,argument2))
  {
   x += move_check;
   break;
  }
  if !(place_meeting(x+move_check,y-i,argument2))
  {
   y -= i/2;
  }
  if !(place_meeting(x+move_check,y+i,argument2))
  {
   y += i/2;
  }  
 }
 for (i = abs(argument1); i > 0; i -= 1)
 {
  if (i < 0) {i = 0;}
  move_check = sign(argument1)*i;
  if !(place_meeting(x,y+move_check,argument2))
  {
   y += move_check;
   break;
  }
  if !(place_meeting(x-i,y+move_check,argument2))
  {
   x -= i/2;
  }
  if !(place_meeting(x+i,y+move_check,argument2))
  {
   x += i/2;
  }
 }
}

Using these codes, there is a gap of one pixel between the player and the crate as it moves around. I know that it's because of the collision checking is it checks one pixel behind the desired direction to move. However, I don't know how I could get rid of it. I've tried removing the extra pixel in the collision checking, but then the crate doesn't move. I've also tried using a small mask for the player, but the end result is ugly as the player ends up moving one to two pixels into the walls as well.

-Rixeno

So, for my application, there's a menu bar at the top, and a child window at the side connected to the main window (which is the GM window). My problem now is that whenever I open the menu, or press anything in the child window, everything freezes, which means that all the draw functions stop leaving the room black, since the background color is black.
I've briefly looked through the MaxWinAPI Help file and couldn't find anything that could help me in this predicament, so now I'd like to know if anybody knows any tricks to work around this, or if anybody knows a way to stop the whole game from freezing every time I use a MaxWinAPI object.

-Rixeno

Hey, I'm currently working on an application with GM (obviously) and I stumbled upon a small problem. I'm using MaxWinAPI to make the screen maximize, so that I can still see the caption, but sadly, it covers the taskbar, with doesn't look too "application-like." So I'm wondering whether or not there's a way, either using code, MaxWinAPI or a Dll other than the stated one (last resort) which can accomplish this task.

-Rixeno

Hello, I've learned some C++ lately and I'm trying to make my first DLL using the windows.h header file. For now, I just want to test it out by using the MessageBox function. When I have the string pre-defined in the DLL (Ex: "Body","Title") it works perfectly, but now I want to use the "char*" type to let the user define what will be written, yet it always comes out as boxes in the text box.
Here's the CPP file of what I have written:

/* Replace "dll.h" with the name of your header */
#include "dllheader.h"
#include <windows.h>

HWND hwnd;
WNDCLASSEX hwndclass;
MSG msg;

LRESULT CALLBACK hwndprocess(HWND hwnd,UINT msg,WPARAM wParam,LPARAM lParam);

int WINAPI WinMain(HINSTANCE hInst,HINSTANCE hPrevInst,LPSTR lpCmdLine,int nCmdShow)
{
return 0;
}

export double GMMessageBox(char* arg0, char* arg1)
	{
		MessageBox(NULL,(LPCWSTR) arg0,(LPCWSTR) arg1,MB_YESNO);
		return 0;
	}

Then this is what I use to use the function in GM (I merged Init with the function for ease):

/* gmw_init()
** Initializes the GMWinAPI DLL
*/
var dll;
dll="GMWinAPI.dll";
global.GMW_Message_Box=external_define(dll,"GMMessageBox",dll_cdecl,ty_real,2,ty_string,ty_string);

/* gmw_messagebox(body,title)
*/
external_call(global.GMW_Message_Box,argument0,argument1);

I don't see why it can't read the string that GM sends to the DLL.

Version 1 out for testing!

Just recently, I've been working on a new game almost like "GTA" Classic with the top-down stuff and all. I got the top-down movement working perfectly, but now I've come to working on the car engine for the game.
This car engine utilizes GMPhysics v4 for all the physics and such.

CONTROL:
You control the car on the top-left corner of the room when it begins.
W-A-S-D = Move around
SPACE = Hand-Brake

DOWNLOAD:
BOX.net : DOWNLOAD

POSTS:
I'd like it if all the posts here would be to either comment on something good about the engine, to report a bug or to request something added for further testing. Please, no useless posts, follow the rules.

Enjoy