As for 8.1 bugs, there's been a few discussion threads over the years, that mostly ended with "8.1 sucks, just move to PyGG2"
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.
Author
Topic: Constant tickrate with interpolated FPS: proof-of-concept in GameMaker 8.1.141 (Read 13671 times)
