Next topic

[fervi]

First Game (Catch The Clown)
Works fully

FPS (Doom-like)
Compiling, but no walls (background_get_texture problem?)

Maze Game (Maze)
Works fully

Multiplayer Example
Not compiling - (mplay_init_ipx)

Platform Game Example
Playable, compiling without any problems, but Highscore table doesn't work

Shooter Example (1945)
Playable, compiling without any problems, but Highscore table doesn't work

Isometric Example
Works fully

Parallax demo
Not sure, probably background doesn't work

Parallel demo
Works fully

Scaling example
Background doesn't work and bugged collision

[DaSpirit]

YoYo Games fully removed mplay_* functions in recent GameMaker editions. We shouldn't be supporting it either, as it was never even recommended in GameMaker either.

[fervi]

YoYo Games fully removed mplay_* functions in recent GameMaker editions. We shouldn't be supporting it either, as it was never even recommended in GameMaker either.

In theory yes, but enigma should be compatibile with mplay (or just create mplay like technology)

Fervi

[Goombert]

mplay_init_ipx

DirectPlay has been officially deprecated for like 10 years now and I don't feel like writing the code only for it to buggy and outdated, there is no point in wasting time on it. MPlay is obsolete in both ENIGMA and Game Maker, it never worked well anyway.

In theory yes, but enigma should be compatibile with mplay (or just create mplay like technology)

Sure if someone wants to write a networking system that uses DirectPlay which for reasons I stated above and the fact IsmAvatar already wrote Berkeley Sockets, I feel it is a huge waste of time.

Not sure, probably background doesn't work

Build->Settings "API" tab, sometimes it helps to try these games in different graphics systems.

but Highscore table doesn't work

That is part of widget systems, which is defaulted to Win32 on Windows and I don't think highscore functions were added, on Linux for widgets you need to set GTK+

Compiling, but no walls (background_get_texture problem?)

That should not be happening in the current version, there are collision bugs because game maker returns -4 for noone constant which people do if (!collision) and GML assumes negative values as boolean false, which ENIGMA and no real programming language does so you generally have to do if (!collision == -4) in ENIGMA

But as for the texture problem, try the version on the EDC as it has these changes, and you can also try Build->Settings "API" and switch graphics systems.

[TheExDeus]

Sure if someone wants to write a networking system that uses DirectPlay which for reasons I stated above and the fact IsmAvatar already wrote Berkeley Sockets, I feel it is a huge waste of time.

I think he meant we need to support those functions, not some underlying system. So just create a wrapper around Berkeley sockets. I don't know how hard the current net_ functions are to use, but the mplay ones were easy as far as I remember.

[Goombert]

Harri, with networking you still need to obtain the curl headers for http functions, that is why if it were done it should just use DirectPlay since that is already distributed with our MinGW just like DirectSound, DirectInput, and Direct3D 9 I'd rather not hang on to those functions forever, nor emulate an obsolete part of the DirectX API

[TheExDeus]

with networking you still need to obtain the curl headers for http functions

Why? I don't remember mplay having any http functions.

MinGW just like DirectSound, DirectInput, and Direct3D 9 I'd rather not hang on to those functions forever, nor emulate an obsolete part of the DirectX API

Then that clearly wouldn't work with Linux. So I don't get why BS cannot be used here.

[Goombert]

Why? I don't remember mplay having any http functions.

Not what I said, I said the new Berkeley Sockets have networking, and you have to obtain the curl headers in order to compile with Berkeley Sockets enabled.

Then that clearly wouldn't work with Linux. So I don't get why BS cannot be used here.

Yes, and neither did the original mplay functions. Mplay functions were designed specifically like the DirectPlay version, that is also why joystick functions are named the way they are, and all of the Direct3D functions, a lot of GML functions are named directly after the DX equiv. But anyway, Mplay was shit, and nobody ever used it, me and Josh were fine just leaving it obsolete/deprecated because it performed so fucking horribly, other than the one tutorial, there is not any other game in Game Maker that used mplay, maybe a few side ones, but I have found very very few, and none that are even worth porting. Anybody who knew anything used 39dll, etc. Like I said I am not wasting my time with it, someone else certainly can, but I am not.

Edit: Fuck it, I guess I'll write mplay functions wtfever

[time-killer-games]

I always wondered, why is it called "39dll" if you ask me that is an extremely stupid name, heck, it's some random number. I'm tempted to think the guy who named it was tripping on acid.

[Goombert]

Think it's a pun on a baseball team...
http://39dll.wikia.com/wiki/39sters_39DLL:_winsock_for_Game_Maker_Wiki

[fervi]

@Robert B Colton
I thinking about recreate mplay functions, but using better tools. I understand about mplay-GM - is very bad, but enigma should have better, but compatibile (by GML-code) functions

Fervi

[Goombert]

Fervi, we do, it's called Berkeley Sockets networking, mplay is just Microsofts shitty designed multiplayer, we have real networking.

[TheExDeus]

Not what I said, I said the new Berkeley Sockets have networking, and you have to obtain the curl headers in order to compile with Berkeley Sockets enabled.

Why? I have used BS with mingw without any extra headers before.

Fervi, we do, it's called Berkeley Sockets networking, mplay is just Microsofts shitty designed multiplayer, we have real networking.

But you still don't get it. We are saying that we don't need DirectPlay or whatever, because we have Berkeley implemented. It doesn't matter on what mplay was originally based on and it doesn't matter how it is called. I am saying that mplay can be implemented as a wrapper for the now implemented BS.  So no need for DirectPlay which will only work on Windows and will probably not give any benefit.

[Goombert]

Why? I have used BS with mingw without any extra headers before.

Weird, everyone else has had to obtain the curl headers, I have yet to test it on Windows, but for me it was the same on Linux.

But you still don't get it.

No, I do get it, you want to keep that API alive longer than it should be, it's dead, it was never alive, and should be left to rest in peace :| That said, networking functions would be weird to wrap around the mplay functions, they wouldn't fit nicely together.

[TheExDeus]

Weird, everyone else has had to obtain the curl headers, I have yet to test it on Windows, but for me it was the same on Linux.

On linux you proably have to install loads of crap. On Windows it worked for me with just the MinGW. I once made a server which simulated traffic lights and ran it on Linux - and a client that visualized it in ENIGMA.

No, I do get it, you want to keep that API alive longer than it should be, it's dead, it was never alive, and should be left to rest in peace :| That said, networking functions would be weird to wrap around the mplay functions, they wouldn't fit nicely together.

We can let it die. Just saying that implementing DirectPlay seems useless. Either wrap around BS (which shouldn't be that hard at least as much as I remember both mplay and BS) or don't do anything. Of course implementing the new GM:S networking functions should be more important. While you already added network_ and buffer_ functions (I think) we still need to implement the events. http://www.yoyogames.com/tech_blog/11