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

I'll have a look. Are you worried about float being less than 4 bytes (if so, what platforms feature this?), or are you worried that it might be 8 bytes instead of 4?
Heh, either or actually :P

I am a tad busy at the moment, but...
Yep, running under Linux. Several other "test" programs I wrote don't work with GL3, but I haven't tried to narrow down the problem (since I thought it was only affecting me). Since it's a known bug in ENIGMA, I'll track down more info on the GL3 bug, and I'll try some more well-known games.
Try to do a simple draw_text call. I believe the issue lies in my changes to this file...
As a result of me switching to use a union because IEEE does not guarantee a float will always be 4 bytes. Thus the purpose of the union is to allow storing color as 4 bytes. If you could fix that bug you would be my hero, since I can only test from Windows right now and was unable to fix it in my  Ubuntu VM as was Greg unable to fix it on his actual distro.

Please see my comments on the GitHub issue tracker.

DirectX9 -- I cannot, for the life of me, manage to get Enigma to work properly from SVN on Windows.
To work with DirectX as a developer you need to install the DX SDK, however, there is only one problem with that, actually several. Microsoft's code is only compatible with MSVC so you need specific headers for DX that are made for MinGW which is in our ENIGMA redistributable which you can only obtain otherwise with MinGW versions that include DirectX from the WINE team.

OpenGL3 -- Everything compiles and runs, but I get no textures whatsoever (even on master).
Interesting, are you on Linux? Linux is already known to not be drawing with OpenGL 3 for myself and one other user as a result of a change I made in my model class most likely a result of IEEE float specification. Can you also please test some other very basic games to see if they draw for you with OGL3? These are the two things I need to know in order to get OGL3 working for everyone again.

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.