Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Goombert

Issues Help Desk / Re: Keyboard/Press/Release for 'any' and 'none' keys
« on: January 16, 2014, 05:40:13 PM »
It appears as though they were implemented they were just never added to the event selector, so I am going to move this to the help desk and commit the fix. The functions already exist, I will have to release a full update to the portable ZIP, they may also not be usable as well if the events are not outlined in the events file.

Code: (EDL) [Select]
if (keyboard_check(vk_anykey)) {

if (keyboard_check(vk_nokey)) {


The issue with them not appearing in the event selector is now resolved in the following commit.
The updated version of LateralGM can be downloaded from the Extra Packages page. Just download the lateralgm.jar and copy and replace it in the enigma-dev folder.
This bug fix will be available by default the next time I patch the Windows Portable ZIP.

I have tested this with making an empty game and utilizing the no key and any key events and they both seem to work perfectly.

Hello Girard, yes there are a lot of issues still as we lack contributors currently. Could you provide one of the games that is having the issue? I can almost certainly figure out what it is.

Issues Help Desk / Re: Sprite font not displayed properly
« on: January 16, 2014, 05:29:44 PM »
Alrighty good to know we've resolved the issue to the metrics of the font sheet then.

When the PNG is imported into ENIGMA, the border looks 100% opaque. Is ENIGMA discarding the alpha information?
There is an easy way to test that, hit the edit button and see if the transparency was lost with Paint.NET or whatever image editing tool you use, and, of course, no it shouldn't be doing that.

Graphics and Video / Re: Royalty Free Resources?
« on: January 16, 2014, 06:20:58 AM »
Actually we maintain a list on the Wiki too.

Issues Help Desk / Re: Sprite font not displayed properly
« on: January 14, 2014, 02:31:59 PM »
Don't worry sorlok you're fine, it's the byte alignment of the font packing function, I am trying to fix it :P

Issues Help Desk / Re: Sprite font not displayed properly
« on: January 14, 2014, 09:49:30 AM »
But what about having the two of them in the editor? As a ENIGMA user, i guess that would be the better choice.
That is just the thing though, to get that size I'd have to write it to the hard drive each time you open an editor or make a change, which I'm afraid would make the editors kind of laggy.

I'd say i prefer memory usage as close as possible, but an approximation is enough.
It is about as close as you can get though, because like every program when it loads an image it becomes decompressed and 4 bytes per pixel. Images are usually never stored with compression in RAM. However, it is important to note, the sound editor does give the exact size of your sound file because it actually stores the file where as images are just converted to BMP when saved into the GMK, I think it is part of the spec?

How do you just bind sprite as a font? You need to use the newly implemented draw_text_sprite (I haven't tested that function though) or we need to implement/fix font_add_sprite function. I will also pull the newest commit and try a sprite font. Usually a bug like that showed by Robert is when a) Batcher didn't change the texture before drawing or b) The texture is just non-existent.
Ok, what Harri? When you use a sprite font you call font_add_sprite which returns an index to a newly added font that is made from the sprite, it packs the subimages together. Also, OpenGL1 does not use batching, which is why that doesn't explain the problem. Anyway, this is the new way sprite fonts were meant to work, thus why draw_text_sprite was deprecated.

At any rate, I realized my Mario game does not actually use the font_add_sprite call it has the sprite with the characters and calculates what subimage to use on it's own, I have no idea why I did it that way.

Edit: Greg's game Ass Blasters uses a sprite font the correct way and it renders properly with dimensions 36x72

Edit 2: I have found the issue. It appears to be an issue with the font packing function, I tried importing the glyphs with a 12x12 and 15x15 pixel size and they stopped coming out all messed up, well they look mashed together because I imported them that way but I mean the image scanlines are not all distorted the characters are legible.

So for now just resize all the glyphs so that width and height are a multiple of 3 or 4 byte aligned, not quite sure. I have submitted a bug to the tracker for you as well.

Issues Help Desk / Re: Sprite font not displayed properly
« on: January 14, 2014, 01:07:27 AM »
I might have it fixed tonight I don't know, I just finished investigating the memory bug in like 5 minutes. But as you can see I can reproduce the drawing bug easily and the glitched texture looks like something I've encountered before, I just need to look.

But on a side note, if you don't mind me asking. In your opinion as a game developer, which is more useful to you...
a) the file size
b) as close to or an approximate of memory usage
Which of those do you find more useful? I decided to use memory usage because you can see file usage on your computer, memory gives you an idea of RAM usage for your game. So do you like it being memory or file size shown in the resource editors?

Issues Help Desk / Re: Sprite font not displayed properly
« on: January 13, 2014, 11:21:51 PM »
Ok so I investigated some more and LGM is definitely reporting the memory usage of the image wrong.

As you can see I imported the image and then deleted all frames at it was reporting 100kb's per frame.

It appears my Mario game has the same issue.

I believe the actually memory usage was correct, since the method I am using asks Java's BufferedImage for its data size. This size is dependent upon the file format the image was loaded and decompressed from. So I believe it is correct in that it is showing the correct serialized memory usage, but incorrect in that it is not showing the correct ENIGMA memory usage without the compression information, which is what we want it to do.

The following stack overflow question seems to back this up.

I have updated LateralGM on the extra packages page with the bug fix that will give a much better estimate of memory usage and actually use the width * height * 4 bytes per pixel formula I originally thought it was using.
Just download it and replace the lateralgm.jar in your enigma folder inside the enigma-dev folder.

As for the drawing bug.
Code: [Select]
draw_text(0, 0,
That code produces the following image with the one character 128x128.

This is interesting because my Mario game uses a sprite font at that exact size and renders fine. So I am still looking for the drawing issue and a resolution to it.

Issues Help Desk / Re: Sprite font not displayed properly
« on: January 13, 2014, 06:41:29 AM »
GM8, the sprite font is occupying 91 KB, but in  ENIGMA it's taking up 28 MB  :o.
File size is not the same as memory size, images generally take up a lot more in memory than they do on your file system. The formula that LGM calculates that size is only an estimate and it is...
Code: [Select]
# of Images * Width * Height * 4 Bytes each pixelThis is just meant to be an estimate of the image decompressed at runtime, since even compressed PNG's or JPEG's or GIF's will be as large as a bitmap in RAM once your game actually loads it, I found it to be more useful than the file size which is what GM shows you.

I went and tested in LGM and created a sprite with 220 subimages all 9x14 and it read the memory usage as 81.21KB. So I will probably need to see that font and the GMK so I can figure out what is going wrong. Also why does it show as 219 subimages in GM and 8x13 which is different than the ENIGMA picture?

Anyway, as Harri said try calling texture_set_interpolation(false); directly before drawing text with that font. And again it would also help if you could give us a GMK with the font causing the issue.

Tips, Tutorials, Examples / Retro Tile Engine Example
« on: January 12, 2014, 08:46:00 PM »

I built this engine to handle a very large tile map for a retro game I am making. The example works in GameMaker: Studio as well and should work in older GM versions. The idea here is to only re-render the tile map when any tiles change or at the end of the month or when the camera moves. It can handle a very large number of tiles the demonstration runs 250x250=62500 tiles at a pretty solid framerate, slower in Studio of course.

Size: 14.39 KB


Issues Help Desk / Re: Problem using joystick functions.
« on: January 12, 2014, 08:33:03 PM »
No problem lol! I am the one who wrote the DirectInput extension :)

Issues Help Desk / Re: Problem using joystick functions.
« on: January 12, 2014, 07:19:34 PM »
Looks like you are on Windows, go to Build->Settings and under the extensions tab enable DirectInput extension. XInput is for Xbox 360 gamepads.

Off-Topic / Re: YoYoLabs ripping off Rockstar Games?
« on: January 12, 2014, 06:06:17 PM »
They're not ripping it off... Mike Dailly is the creator of Grand Theft Auto...
That doesn't explain copy catting Rockstar games now though, the issue was not the game. The issue is them copy and pasting every marketing campaign out there, including Unity3D's exact website! See previous topic for details...

Why so much hate for the competition? They are just a group of people trying to make something people can use to do something cool. They've also made something that inspired people to create ENIGMA.
You haven't kept up with the controversy with them, have you? Like for instance the DRM backfire?

Off-Topic / Re: What is a good programming language to start off with?
« on: January 12, 2014, 06:00:39 PM »
You know I am going to recant, Harri is right about it being a matter of perception, not entirely, but I'd say we're both right actually. Because I can't say what helps other people learn, but I think my arguments as far what people should learn still stand.

Off-Topic / Re: What is a good programming language to start off with?
« on: January 12, 2014, 01:20:57 PM »
Ok, here goes.
And this seams very subjective for me. Of course there is no one way to learn programming, but saying GM is bad because it didn't help YOU isn't a good argument either.
I get that, but my point was that if a 12 year old can learn Basic and C# anybody can, and it is much better if they simply just do that because GM ends up making you also have to unteach yourself a lot of bad programming habits.

It did help me. GML was the first programming language I used (did see some Basic code a short while before, but didn't code anything in it) and I didn't use any other language for about 7 or 8 years. Then when I went to university I started using C++ and I found that it's mostly GML. Then I used different languages as well and in the end GML was stepping stone more for me. GML really looks like every language ever - because it has the most relaxed syntax ever.
I don't agree with any of this, you are talking to the person (me) who argues that all programming languages are fundamentally the same. If you had just learned Basic or C# or Java, take your pick of a noobs language, it would have been a lot easier to just build off of that understanding of programming.

You can write GML that looks like C, you can write GML that looks like Delphi, you can even write GML that looks like python. So for me it helped a lot. Others (especially nowadays) say that Python is something people should start with, and I kind of agree as it is very easy and powerful, but I do dislike it more than GML. I think transition from GML to C (and to C++) is a lot easier than transitioning from Python to C. But I guess all of that is subjective.
I would argue that GML is much more C, just because it has the illusion of encapsulation and maybe a few syntax features doesn't make it very managed or high-level at all it, for god sakes it has 1 data type. In fact most code you find is simply calls to existing built-in functions, most of GML is very very low-level, not as much in theory, but almost all the time in practice. It is also important that we make the distinction we are not talking about EDL here which does address these issues but falls short imo.

And? You do know that we already discussed this. :D I already agreed that GM doesn't have these functions and it does everything in immediate mode - and that means it is a lot more straightforward and easier to learn/use. Like with your functions it can take 4 functions to draw text on screen (create, position, set text, destroy) and while it is good for performance, it is easier for a total noob just to use draw_text(). That is exactly my point and you just keep pointing it out while mysteriously disagreeing. :D
This is the number one thing that you are completely missing and are completely wrong about. Harri it would not be 1 function to make a GUI label, you would still have to call draw set font vs just creating the label object where you want it, setting the font, and letting it be. Even more complex code would be needed for a button such as handling input, doing a mouse hit test and drawing the thing, where as with a simple GUI function call you can create it with the correct size and font, and that's it, you don't have to do any more coding except for where you want to handle when it's pressed or not. I will agree with you that labels don't quite make the argument as good as buttons do, but I would say that this method is much easier for noobs to work with, there is a reason why every other game engine handles GUI stuff for you and it would even more optimal to!

I thought I'd toss in my two cents.
Captain Crunch, I agree with everything your saying, but I am arguing for the sake of people not wasting their time with GML, because it is a broken stepping stone.