The Gang Garrison 2 Forum
Gang Garrison Development => Development Discussion => Topic started by: BlackDoomer on October 24, 2018, 02:06:15 am
-
welp I've succeed to fool GameMaker again
here it comes
(https://i.postimg.cc/mhyc5zkz/2018-10-24-164635.png) (https://postimg.cc/mhyc5zkz)
a green circle stands for a simple tick-bound object, a cyan is the same but also with the motion interpolation between ticks
arrow keys - move both circles
"systimer" indicates to use WinAPI's GetTickCount(), which is much more accurate, instead of GM's current_time
UPS stands for tickrate ("updates-per-second")
this consumes false 100% of the processor core on which it working, I know how to fix that and will do that later
sources (very bad tho, need to be cleaned up) are included too
https://yadi.sk/d/1-C2LTABe9DQyg - download
any tests / reports / comments / feedback will be very appreciated :)
-
what the everloving fuck are you doing on this dead game
-
what the everloving fuck are you doing on this dead game
I find pleasure in
-
what the everloving fuck are you doing on this dead game
A lot of people like to horse around with GM8.1 in spite of it being a deprecated engine and this is the place to do it.
-
A lot of people like to horse around with GM8.1 in spite of it being a deprecated engine and this is the place to do it.
I just believe that it would be much easier to port GG2 onto GM 8.1, in contrast with Studio, so I proposed that example.
Also 60 fps in GG2 is pretty dumbfucked, interpolation is much reliable and maybe even faster.
-
A lot of people like to horse around with GM8.1 in spite of it being a deprecated engine and this is the place to do it.
I just believe that it would be much easier to port GG2 onto GM 8.1, in contrast with Studio, so I proposed that example.
Also 60 fps in GG2 is pretty dumbfucked, interpolation is much reliable and maybe even faster.
It is, by a lot, but the main devs havre repeatedly said that there are various issues and that the bugs outweigh the benefits. One bug I discovered is that the registry functions often fail
Also deltatime is a thing that works quite well
-
I think one of the big issues was the new handling of strings, where string functions depend on the currently selected font. Since some GM 8 stuff we used depends on using strings as byte arrays, this would cause a lot of trouble. That said, it's certainly not insurmountable.
-
I think one of the big issues was the new handling of strings, where string functions depend on the currently selected font. Since some GM 8 stuff we used depends on using strings as byte arrays, this would cause a lot of trouble. That said, it's certainly not insurmountable.
Could you please tell more about that and maybe provide some examples? I've worked with GM 8.1.141 bugs and managed to get around some of them.
One bug I discovered is that the registry functions often fail
Same request. :)
Also deltatime is a thing that works quite well
True, but the disadvantage lies elsewhere: updating the game state 60 times per second is squander.
-
Maybe you can't port GG2 to GM8.1 or GMS 1.4/2 but how about rewriting the game from scratch then? I know that it's a lot of work and etc but looks like there's no other way.
-
Maybe you can't port GG2 to GM8.1 or GMS 1.4/2 but how about rewriting the game from scratch then? I know that it's a lot of work and etc but looks like there's no other way.
While we do like to complain about some issues, porting the game to a new version of GM is still orders of magnitude less work than a rewrite ;)
-
Maybe you can't port GG2 to GM8.1 or GMS 1.4/2 but how about rewriting the game from scratch then? I know that it's a lot of work and etc but looks like there's no other way.
While we do like to complain about some issues, porting the game to a new version of GM is still orders of magnitude less work than a rewrite ;)
As I said before... Maybe you can't port GG2 to GM8.1 or GMS 1.4/2 but how about rewriting the game from scratch then? I know that it's a lot of work and etc but looks like there's no other way.
but alright! :z5:
-
MedO, I think you're a bit wrong about string functions. The only one that depends on selected font is chr(), but there's a nice replacement such as ansi_char(). Also please note that string_insert() is simply broken in the 8.1.141 (it's actually a "string_insert_byte()" since it doesn't support UTF-8 at all), so you need to write your replacement one using WinAPI's MultiByteToWideChar and WideCharToMultiByte to convert string into the fixed-size Unicode and backwards. And strings still can be used as byte arrays without any problems, AFAIK.
Welp, there's another GMO-free example. Now it's a videosystem concept that supports maintenance of ANY window parameter WITHOUT blurring up everything visible. This also supports FSAA (using my workaround that fixes problems with the related functions in 8.1.141) and optional game view scaling that never touches scale of the GUI.
Still hope that somebody is interested. :)
https://yadi.sk/d/1giw0jO1YCkYVA
-
I'm still interested
As for 8.1 bugs, there's been a few discussion threads (https://www.ganggarrison.com/forums/index.php?topic=25841.msg812337#msg812337) over the years, that mostly ended with "8.1 sucks, just move to PyGG2" (https://www.ganggarrison.com/forums/index.php?topic=31543.msg1056263#msg1056263)
When I ported GG2 to 8.1 I didn't find the game broken, and it was very easy to port, but the registry functions either didn't work or returned something the existing code didn't use properly, so the audio fix that disabled more than 2 sounds at once was disabled on my Win 10 machine, when it should have been enabled. This eventually led to disabling the fix for W10 users (https://github.com/Medo42/Gang-Garrison-2/commit/847d289faeee01c34ec3aababe55d4550625df5f) in vanilla because we found out that the bug doesn't affect them
I haven't yet looked at your source files, but is there any reason why we wouldn't be able to port it to GM8?
Edit: don't answer that, apparently GM8 doesn't have lerp(), I'm trying to write an equivalent script in gm8
-
2 replies in a small amount of time I know, but this now works in GM8
(https://i.imgur.com/AiMyPgc.png)
I still despise trigger events, but hey it works.
Some things very worth noting:
- I had to write a lerp() script because GM8 does not have one by default, while GM 8.1 does
- The max framerate is halved when using GM8. This could be either because GM8.1 is more optimised, or because the built-in lerp of GM8.1 is faster (Edit: yep, using the less precise lerp formula the fps are the same, so GM8.1 probably uses that)
- I have used 8.1 in the past, the GUI feels more responsive
I used YellowAfterlife's Game Maker 8.1 to 8.0 Converter (https://mfgg.net/index.php?act=resdb¶m=02&c=6&id=27657), because I didn't want to pirate GM 8.1
-
As for 8.1 bugs, there's been a few discussion threads (https://www.ganggarrison.com/forums/index.php?topic=25841.msg812337#msg812337) over the years, that mostly ended with "8.1 sucks, just move to PyGG2" (https://www.ganggarrison.com/forums/index.php?topic=31543.msg1056263#msg1056263)
I also thought so before (you can even find my answer in one of these topics :)), but then I got to know 8.1 better, and also learned Python Phytohn. And now I claim that Peeton is simply not suitable. It is a scripting language in the truest sense of the word. It is suitable for working with data, it is suitable for back-end web applications, it is suitable for renaming a handful of pictures in a folder, and so on. But this is a disaster for developing a desktop application. Piton turns even an average-sized codebase into a mess, simply because it is MISCONCEPTED. You will NEVER REWRITE GG2 on it only because of this, but also because GG2 is highly dependent on the GM 8.1 event model, just like any other GM program.
As for the 8.1, it's much less harmless than is commonly believed. For example, almost all display errors (except display_set_colordepth(), which is pretty useless though) could be fixed just by the next line of code placed at the very beginning of the program:
surface_free( surface_create(0, 0) );
And when working with the already mentioned strings, you need to remember only a few things:
- they may contain ANY data, even with GM always expecting an UTF-8 stream in;
- the only string functions that rely on a font currently selected are chr() (ansi_char() must be used instead), string_width(), string_height(), string_width_ext() and string_height_ext();
- since strings are UTF-8 you can't use string functions to manipulate them as byte arrays, but you still able to write your own because even UTF-8 strings are just char*;
- the only exceptions from previous are the 8.1 functions string_byte_at() and string_byte_length(), and the old one string_insert() that wasn't rewritten for UTF-8 support.
Of course, all of the above applies only to the latest version (8.1.141).
When I ported GG2 to 8.1 I didn't find the game broken, and it was very easy to port, but the registry functions either didn't work or returned something the existing code didn't use properly, so the audio fix that disabled more than 2 sounds at once was disabled on my Win 10 machine, when it should have been enabled.
Are you sure that you used the 8.1.141? This sounds rather strange, since I've never experienced such problem with the registry on it.
I haven't yet looked at your source files, but is there any reason why we wouldn't be able to port it to GM8?
Actually not, but GM 8.1 contains a crapload of bugfixes and optimisations, so I see no reason to avoid it.
I still despise trigger events, but hey it works.
Triggers are required to guarantee the order of execution of events. There must be ONLY ONE End Step event for a whole program in my concept, and it's must be responsible for updating the screen and the game state DIRECTLY before the Begin Step event. But since end step events are very useful for us too, we provide a replacement trigger that will be executed just before the actual event and should be used instead.
The max framerate is halved when using GM8. This could be either because GM8.1 is more optimised, or because the built-in lerp of GM8.1 is faster (Edit: yep, using the less precise lerp formula the fps are the same, so GM8.1 probably uses that)
Both things matter. At least, GM 8.1 introduced the hardware acceleration, though it can be turned off in Global Game Settings. And calculations in scripts are slower than in DLL functions, for example.
-
Maybe you can't port GG2 to GM8.1 or GMS 1.4/2 but how about rewriting the game from scratch then? I know that it's a lot of work and etc but looks like there's no other way.
While we do like to complain about some issues, porting the game to a new version of GM is still orders of magnitude less work than a rewrite ;)
about the porting, has anyone entertained the thought of using vanguard as a base?
-
Well, I may be in a bad position to say that but... sounds like a great idea to use Vanguard since it's both not made in GameMaker and has some similarities with GG2.
-
Well, I may be in a bad position to say that but... sounds like a great idea to use Vanguard since it's both not made in GameMaker and has some similarities with GG2.
What is Vanguard?
-
Vanguard's Overwatch But GG2 (https://www.ganggarrison.com/forums/index.php?topic=37227.0)
-
GMStudio or GMS2 would be a better target for a port/remake imo since it has support for a lot of things out-of-the-box, particular steam's p2p networking api which would remove the need for porting forward.
-
GMStudio or GMS2 would be a better target for a port/remake imo since it has support for a lot of things out-of-the-box, particular steam's p2p networking api which would remove the need for porting forward.
Both of them are intended more for creating games for tablets, and poorly designed in general.
-
There are three reasons why I never looked into adding "interpolated fixed timestep" style framerate-independence into GG2: (note: physics is synonymous with physics plus game logic)
1) Game maker.
2) When done with a lot of headroom, it increases the input latency floor. Instead of "framerate interval/2 plus frametime plus ticktime" average latency, you have "framerate interval/2 plus frametime plus tickrate interval plus ticktime" average latency. By design, ticktime is almost always higher than the framerate interval, because people use small physics framerates like 15 or 20.
3) You need to implement some kind of delta time anyway. Sometimes a user really cannot even run the physics simulation at 20 ticks per second.
I have no issues with updating GG2 to newer versions of game maker.
As for other platforms like python or C++, I made a toy game maker-like language in rust that I called gammakit: https://github.com/wareya/gammakit but it's not gonna go anywhere unless someone gives me a million dollars or something.
It's not actually difficult to make something resembling very early versions of GG2. What's hard is making something with support for a very wide range of available functionality so that you don't have to dig into and extend the platform while using it. Having to do that causes bad structural problems unless you are one of the very most skilled AND EXPERIENCED of programmers. This is what killed benetnasch/kotareci.
edit: I fucked up writing point 2 originally, so I rewrote the math explanation. If you're still confused, here:
think_time : time between simulation of a frame's physics/logic beginning and finishing
render_time : same but for rendering
think_interval : time from the beginning of one physics/logic tick to the beginning of the next physics/logic tick
render_interval : same but for rendering
sequential_interval : when you think -> render -> repeat, think_interval and render_interval are exactly this, and think_time and render_time add up to less than or equal to this
when you do things the way game maker currently does, you get this average latency:
think_time + render_time + sequential_interval/2
when you use interpolated fixed timestep, you get this instead:
think_time + render_time + render_interval/2 + think_interval
-
If the registry functions work, or if the Faucet Audio extension is done, I'd be happy to upgrade to 8.1, although performance has never been an issue for gg2, and the lag is only felt because of the lack of client-side input prediction, which will never be implemented, so I believe it won't make a big difference
Making a version of gg2 using this type of interpolation could be interesting, but I don't know how much effort that'd take
-
Making a version of gg2 using this type of interpolation could be interesting, but I don't know how much effort that'd take
Not so much, I believe, since GG2 already supports different timings (30 and 60 FPS) internally.
-
curious to know if you successfully ported gg2 to 8.1 and whats really in the way because from what i can gather, there's a solution to all the previous problems?
-
Just to be sure, the repeat in the init script is useless, right?
repeat 1 {
instance_create(128, 256, circle);
instance_create(128, 320, circle2);
}
-
Just to be sure, the repeat in the init script is useless, right?
Absolutely. It was added only for stress testing purposes.
Also please note that game_init() was supposed to be called from the extension package, to behave just like an entry point. According to my concept of using GM, there should be no implicit programming in the source (ie, code NOT in scripts, predefined instances in rooms, drag-n-drop, code in Room Creation, etc.). That's the reason of commented out room_instance_* functions.