As you can see in the above screenshot I have now got the UTF-8 text rendering working perfectly.

The commit link is below.
https://github.com/RobertBColton/enigma-dev/commit/41fc6e7fc9dabd450f27bc8a9fccf200d8ce6458
The change was committed to pull request #623
https://github.com/enigma-dev/enigma-dev/pull/683

As the commit message also states, the only thing left is to add the multiple character ranges to the engine, compiler, and plugin.

But LGM's code editor's encoding has nothing to do with C++ std::string or it's capabilities. I don't see how std::string suddenly supports UTF-8.

I don't know, Josh didn't explain it thoroughly to me, ask him, all I know is that it does.

If the infinity symbol is still out of range I'm going to be pissed.

Yes of course you will be able to use that symbol.

Wow holy shit, you should put up a different image in your post. Their new voxel terrain rastering looks amazing.

1080p @60fps

I also remembered a bug I keep forgetting. It should be relatively trivial to fix. When you load a sprite and want to set the offset with the mouse, the offset is set relative to top-left of the window, not the sprite. So when you press on the sprite you always get bottom-right (because that is what it is limited to). Basically the sprite preview window doesn't take the centered drawing into account and so you cannot effectively use the mouse to set the offset.

I actually just fixed that one. The problem was I switched the image previews for Background and Sprite to center aligned because I thought that looked nicer, but didn't account for it in the mouse coordinates.
https://github.com/IsmAvatar/LateralGM/commit/0f430a9c7a1e4f9dd03eb3b96204c27348d0e56e
This commit followed the former.
https://github.com/IsmAvatar/LateralGM/commit/1a45337891b32a4856781c25f0755d74d68d8921

And for a suggestion: Can you make so that when you type in the font dialog box it filters out the fonts? I am sure the Java's widget already has an option like that, but it must somehow be enabled.

Yes I wanted that too, I'll try to get it added.

It's there. As Robert mentioned Java supports 16bit Unicode and so it supports a lot of characters, but not the whole set. But it does depend on the font as well. For example, I cannot draw Japanese or Chinese characters with Arial font, while I can with some others.

Now as for the fonts, I need to recant. Our code editors are UTF-8 encoded, IsmAvatar did this a long time ago Josh said. I put the label there saying UTF-8 a little bit ago and I actually had no idea, but anyway, most code editors are UTF-8 encoded, I assume GM's to be as well because their file functions support no higher than UTF-8 as well.

So anyway, all of our strings including literals are already UTF-8 encoded, we just need to fix draw_text with the new LGM, and then we add multiple character ranges in a map to replace glyphstart glyphcount.

Here is the download for the soon to be released new plugin and LateralGM.

https://www.dropbox.com/s/wcr3mt8uf19i7ho/enigma.jar
https://www.dropbox.com/s/dnb7caeroqgcael/lateralgm.jar

NOTE: There was a bug with the recent files menu and spaces, basically LGM was delimiting the recent file paths with spaces which would obviously make file paths with spaces incompatible and I switched it to tab delimited, you may need to clear that menu and then close and reload LGM as this version addresses that issue.

Well, as Harri pointed out to me, GM's Unicode font support is limited. How you ask? They use Windows only fonts such Arial Baltic because their IDE is written in Delphi and only for Windows, this is true even for Studio.
http://en.wikipedia.org/wiki/Arial#Code_page_variants


As many of you may have already noticed, LGM does not have these fonts available. Why? Well that's simple, again, GM's IDE relies on native Windows shit for fonts. Java applications and all non-Windows software, provide full Unicode support.



LGM and ENIGMA are capable of getting around this limitation imposed by GM and allowing you full access to all 2,147,483,647 (arbitrary limit imposed by Java int max value) characters supported by the Java/Unicode standard as depicted in the above screenshot. You will however be limited to no more than 1000 characters per sequence, meaning if you want 10,000 sequential unicode characters you will need at minimum 10 character ranges to achieve it with LateralGM, this is to stop the font editor from lagging with excessive ranges. This will require that you set the character ranges yourself, you can do this simply by entering the translated text and hitting preview which will auotmagically calculate the character ranges you have used.

The reason I am posting this topic is both to be informative and to ask everyones opinion. First of all, what do you think of this solution? It is more powerful than GM that limits you to 255 characters. They will also most likely remove the 255 character limit and go this route as well in the future when they do their new IDE. Thoughts, feedback, criticism is again always welcome I would appreciate feedback.

Edit: Studio v1.3 does in fact make this change, but does not yet remove Arial Baltic and such fonts!

Ok, well I changed obj_monster_basic collision event to a collision with obj_wall1 instead of obj_wall_basic, and that also stopped the memory leak. Now I went further and made a test case that shows the bug also occurs without inheritance, just with collisions between objects.
By simply setting obj_monster1's sprite to <no sprite> the memory leak will also disappear, give it back it's sprite, and the memory leak comes back.

As for the instantiation of obj_monster_basic, I know that is not happening because a show_message call in the create event yields nothing. And I do not see them in the room instance list either, obj_wall_basic as well.

Now, I know there are 367 instances of objects that inherit obj_wall_basic, and 50 instances of objects that inherit obj_monster basic, because of the following code in the Room Create code.

Code (EDL) Select Expand

show_message(string(instance_number(obj_wall_basic)));
show_message(string(instance_number(obj_monster_basic)));
Which I also tried the following variation.

Code (EDL) Select Expand

show_message(string(instance_number(obj_wall_basic)));
show_message(string(instance_number(obj_monster1)));
Which yielded the same results.

I'd like the exact EDL for both events, ideally

There's only 1 event, and I have provided the code for it. obj_monster_basic has a collision event with obj_wall_basic, obj_monster1 has no collision code and automatically inherits the collision event with obj_wall_basic

I have created the following minimal test cases that reproduce the bug.
WARNING! Run with caution, they leak 4mb's per second for me.

This is with inheritance.
https://www.dropbox.com/s/moe88bjkebm6ioi/inheritanceleak.gm81
This is one that has no inheritance, just a collision event between one object and another, the memory leak still occurs.
https://www.dropbox.com/s/4ac5evbozjfvczq/collisionmemleak.gm81

Just curious, why did game_end() never get a parameter? In most programming languages, ie. Java has System.Exit(return);

We should overload it to accept variant or some shit for ENIGMA.

DaveDude, open settings.ini, and change the following line.

Code (INI) Select Expand

idecommand="java -jar -Xms256m -Xmx1000m"
Change it to the following.

Code (INI) Select Expand

idecommand="java -jar"

I changed the default Portable ZIP to launch LGM allowing it to have a larger heap size by default, since I figured most computers should have a minimum 256mb.

Josh, I removed all GML code in the event, which is the following.

Code (EDL) Select Expand

{
  x = xprevious;
  y = yprevious;
  if (abs(hspeed) >= abs(vspeed) && not place_meeting(x+hspeed,y,obj_wall_basic))
    { x += hspeed; exit;}
  if not place_meeting(x,y+vspeed,obj_wall_basic)
    { y += vspeed; exit;}
  if not place_meeting(x+hspeed,y,obj_wall_basic)
    { x += hspeed; exit;}
}
I then replaced it with the following.

Code (EDL) Select Expand

// do nothing

And the leak still occurs, it only goes away if you delete the event from the parent object. Read Harri's report, you'll have a better understanding.

Edit: Upon further investigating Harri's claims which I have found to be true. I discovered exactly where and when the error occurs, this was tested with the BBox system. Simply removing line 100, the following code, fixes the memory leak.

Code (C++) Select Expand

        if (left1 <= right2 && left2 <= right1 && top1 <= bottom2 && top2 <= bottom1)
            return inst2;

The question now is why this occurs with parenting and not without parenting. It could be related to the object index which is passed up to the parent in the constructor which is further passed to the object_locals base class. The current system does not allow iterating children of a parent object using the parent object index, I do not know if that is possible in GM or not.

I agree more with what Harri told me the one other time, that GM provided a basic abstraction framework that allowed more advanced things to be done through extensions. GM served as a good windowing and basic platform that could be easily extended. That I found to be a good argument, sadly it's no longer true about GM.

wow TKG thanks for sharing, looks like YYG is doing a good job improving the quality of GameMaker end products

Have you got this working on Linux yet? Or is that part still being worked on? Have you found a way to do this for Linux, but you just haven't implemented it fully yet? In any case I'm glad there's been some rapid progress on this!

What working on Linux? Splash? No, this topic is about me not wanting to add them. If you meant video functions, no as I want to plan them out properly first and I need to get other things ready as well.

1) What API you plan to use for all of that?

I didn't pick one for cross-platform, right now they only exist in DirectShow, and I haven't exactly worked out video_draw_frame() yet. I do know that playing it the default way in DirectShow is already hardware accelerated on Vista or later. I haven't looked into how you do it exactly yet. I may just give people a video_get_surface function, because DirectShow may actually just give you direct access to it's surface or it might not, I don't know.

Would this API allow loading from webcam?

I hadn't planned on it until you asked
But yes we can do that.
https://www.google.com/#q=webcam+directshow

Could OpenCV handle all of our Linux video stuff we need it to though?

They would be several GL windows? So you could render to all of them?

That's the idea yes, but with a window_get_main, only the main window will create its graphics context by default. After calling window_create you will also need to call window_create_graphics if you intend to render to the window. I haven't exactly thought out the implementation fully yet, but the purpose is basically to let you draw directly to the message window for custom dialogs instead of shitty message_box functions which limit how you use them. Also by not creating a graphics context by default on all newly created windows, will make it easier for developers who do want to create Win32 native widgets and the likes, or people who want to use GTK, etc.

This way the very least we can do is provide a properly abstract windowing system like SDL or Qt, etc.

You still haven't even let me properly fix the axis code so that I can commit it to the repository, you stormed off with a version of the code you *thought* worked, but may in fact not work with other joysticks because as I said it wasn't calibrating properly. If you would get on IRC and test the code for me, it would be much easier to fix these bugs as I do not have a game controller.

Edit: We have properly fixed the joystick calibration and committed the code. The commit is in the following pull request and will appear in the next stable release of ENIGMA.
https://github.com/enigma-dev/enigma-dev/pull/683
This is the specific commit.
https://github.com/RobertBColton/enigma-dev/commit/b7a9a4b7f6bc20b3c2a0a4d6d00844f29a341af3

[Koala!]

And ENIGMA doesn't have that because we didn't want to include the parser and the compiler with the game (which would be required for GML/EDL support).

Koala!

The most popular in this regard is Lua, which is fast, small and easy to learn. Something like that is useful, but execute_string() wasn't.

I could write a Lua extension, I've just never seen Lua scripts before or anything. I just wonder how big of a task it would be to provide functions for it, and what the hell that even means.

1) Both GM:S and ENIGMA are compiled C++ now. This means there is not interpreter to run this execute_string. Making one would take a lot of time and the result wouldn't be very fast (as GML/EDL in its core is still C++ and so compilation would be required).

execute_string still exists in Studio ask TKG, DatZach was actually able to get it to work

That would be pointless because what we could do is just add these...

We have to add those when we add game_save, but JDI according to Josh will be able to optimize them out if not used. This is why I documented the functions yesterday with their potential data types.
http://enigma-dev.org/docs/Wiki/Unimplemented#Variable_Access

BTW, while the video is being rendered on a surface,
I assume its audio will also be played back right, (meaning audio/video) the same as the standard video playback right ?

Actually, yes and no, yes meaning you'll be able to control the videos audio streaming, yes as in I am making the function set powerful enough to not only allow you to render to surfaces and use them as textures but to also allow you to only use a few simple calls just to make a video, without having to render to a surface, thus the inclusion of video_play.
Some of the functions are already implemented and usable, I started adding them for TKG. The drag and drop actions also work, simply enable the DirectShow extension.
http://enigma-dev.org/docs/Wiki/Audio_and_Video_Functions

I'm also considering not doing the message_box functions, let me provide my reasons for that.

1) ENIGMA does not need to have a full-blown cross platform widget system, the users can do this themselves if REALLLLLY needed by hacking our widget system code, or they can make a Qt extension or wxWidgets extension, or w/e
2) I plan on gui_* functions that remove the need for draw_text for instance and will have most common controls for dialogs that can be easily styled and textured like Unity3D's.
3) I plan on overloading window functions to allow multiple window handling as well as window_create(), and *gasp* window_set_target

The purpose of window_set_target is of course to set the rendering target to another window you have created, this will allow you to custom render your dialogs easily, and then simply window_reset_target() to the main window.

You see the point is not to be lazy, just provide something much much better.