Find content
Not Telling
So I bought a copy of GM 8.0 a while ago and installed it on my laptop. That's all still working fine.
Now I wanted to install Game Maker on the new rig I just built, but figured it wasa bout time I got around to using 8.1 instead, knowing that I can upgrade for free.
Downloaded and installed 8.1 on the new machine, but the code they game me in the email after I bougnt 8.0 doensn't work. "Unable to obtain a valid license, please check the license key and retry!"
What am I doing wrong?
ynspyred
Member Since 29 Aug 2008Offline Last Active Sep 17 2012 02:22 AM
Topics I've Started
3d Level Editors
26 April 2010 - 05:11 PM
Hello, GMC. In this topic, I have highlighted three 3-dimensional level editors, all high quality tools, that you might appreciate having your attention drawn to.
Whereas the GM level editor is highly 2D-oriented (and pretty basic to be honest), in 3D, you will definitely want to make your levels in nearly any game more interesting. It's amazing how few FPS games etc consist of boring planar worlds. Using one of these three tools, you can visualise your level in three dimensions, and move things about easily. Also, as well as being very easy to use with GM D3D, all three can export to formats friendly to Ultimate3D and GMOgre3D.
I have used irrEdit and CS, and think them excellent programs. I have heard nothing but good things about DeleD as well, so surely one of these three will suit your purposes. They're all small downloads, so why not just grab all three and decide which you like best!
Just click on the name to go to the homepage of the editor.
irrEdit - 10 MB
Although it was designed to be used with another engine, irrEdit is extremely easy to use with Game Maker. It has a default .obj export, and imports a range of different model formats, although if you don't have any models handy, you can create default shapes (cube, wall, etc) from scratch, rather like in Game Maker. Unbelievably easy to get stuff from your "3D Model Collection" folder to a level-in-progress. Furthermore, if you're making an FPS, it comes with a useful preview mode, where you can walk around the level in the editor before you export. The lightmapper is top-notch, allowing you to get awesome static lighting and shadows exported as well.
No legal requirements for commercial games, although they would appreciate a mention in the credits.
Cartography Shop - 7 MB
My personal favourite from these three, Cartography Shop, which was license-paying until recently. The only niggle with this one is that it can be tricky to get models imported - it only imports from it's own file format. However, download the program SDK and you can convert models you already have easily enough, or use the default shapes with abandon. It does helpfully group your models and textures into folders, the compromise being that you have to copy them to the program directory manually, and comes with a range of pre-defined models and textures, including some cool space-station interior models. In terms of general-purpose 3D model exports, it only does the .X format. If you want to convert to .obj, I would use Blender. However, Ultimate3D supports X as default, so that should not be too much of a problem in that respect.
It has a high-quality lightmapper as in irrEdit, which takes advantage of things like alpha channels in model textures.
Finally, the clinching aspect of this editor for me is the way it handles UVs - when you stretch a wall, the texture does not stretch with it, the texture coordinates are scaled alongside. I can't begin to guess how much time this could save some projects.
No licensing fees etc for commercial games
DeleD - 11 MB
I have never used this program, never got around to installing it after I found Cartography Shop, but it looks good, and I have read several other comments by users, on gamedev.net and the XNA forums, and it has a highly satisfied user base.
No licensing fees or legal strings
Getting collisions with your level may prove difficult, although I hear there is a precise 3D mesh collision DLL floating around somewhere, and Ultimate3D has it's own 3D collision functions for you. Also, please bear in mind that with default D3D, you probably won't be able to have levels with the detail level seen in some of the screenshots.
Whereas the GM level editor is highly 2D-oriented (and pretty basic to be honest), in 3D, you will definitely want to make your levels in nearly any game more interesting. It's amazing how few FPS games etc consist of boring planar worlds. Using one of these three tools, you can visualise your level in three dimensions, and move things about easily. Also, as well as being very easy to use with GM D3D, all three can export to formats friendly to Ultimate3D and GMOgre3D.
I have used irrEdit and CS, and think them excellent programs. I have heard nothing but good things about DeleD as well, so surely one of these three will suit your purposes. They're all small downloads, so why not just grab all three and decide which you like best!
Just click on the name to go to the homepage of the editor.
irrEdit - 10 MBAlthough it was designed to be used with another engine, irrEdit is extremely easy to use with Game Maker. It has a default .obj export, and imports a range of different model formats, although if you don't have any models handy, you can create default shapes (cube, wall, etc) from scratch, rather like in Game Maker. Unbelievably easy to get stuff from your "3D Model Collection" folder to a level-in-progress. Furthermore, if you're making an FPS, it comes with a useful preview mode, where you can walk around the level in the editor before you export. The lightmapper is top-notch, allowing you to get awesome static lighting and shadows exported as well.
No legal requirements for commercial games, although they would appreciate a mention in the credits.
Cartography Shop - 7 MBMy personal favourite from these three, Cartography Shop, which was license-paying until recently. The only niggle with this one is that it can be tricky to get models imported - it only imports from it's own file format. However, download the program SDK and you can convert models you already have easily enough, or use the default shapes with abandon. It does helpfully group your models and textures into folders, the compromise being that you have to copy them to the program directory manually, and comes with a range of pre-defined models and textures, including some cool space-station interior models. In terms of general-purpose 3D model exports, it only does the .X format. If you want to convert to .obj, I would use Blender. However, Ultimate3D supports X as default, so that should not be too much of a problem in that respect.
It has a high-quality lightmapper as in irrEdit, which takes advantage of things like alpha channels in model textures.
Finally, the clinching aspect of this editor for me is the way it handles UVs - when you stretch a wall, the texture does not stretch with it, the texture coordinates are scaled alongside. I can't begin to guess how much time this could save some projects.
No licensing fees etc for commercial games
DeleD - 11 MBI have never used this program, never got around to installing it after I found Cartography Shop, but it looks good, and I have read several other comments by users, on gamedev.net and the XNA forums, and it has a highly satisfied user base.
No licensing fees or legal strings
Getting collisions with your level may prove difficult, although I hear there is a precise 3D mesh collision DLL floating around somewhere, and Ultimate3D has it's own 3D collision functions for you. Also, please bear in mind that with default D3D, you probably won't be able to have levels with the detail level seen in some of the screenshots.
Built In Collision Mechanism
21 October 2009 - 02:47 PM
I have a few questions about exactly how game maker handles sprite-sprite collisions. I know of two methods for per-pixel collision checking (both encountered with xna). The first, which I call the pixel loop method is an actual per pixel check, using a nested loop. The colors of each pixel are stored in a color array at compile time, and when a collision is tested, the arrays of each sprite are looped through. If they are found to overlap, true is returned. Furthermore, if the sprites are transformed, a matrix can be constructed, and the nature of this matrix changes the way in which the color arrays are looped through, so it also accurately checks for rotated and scaled sprites.
The second method I call the polygon intersection method. This way, a polygon is assembled from the texels bordering the alpha texels aroudn the border, or the border itself. This polygon is stored for every sprite. So for example, if you had a sprite which looked like this:
the polygon created would look something like this
Of course, it is fairly easy to check intersections between polygons, and to apply a transformation to them beforehand. The polygon method is faster than the pixel loop method, but will not work for hollow sprites, as with this one
unless you have a devilishly clever algorithm generating the polygon
Question one:
Which of these methods does Game Maker use? I suspect it is the pixel loop
The second question requires further information.
If you create a sprite in the editor, then uncheck the box labelled Precise Collision checking, the runner will just use the bounding box to check for collisions. THis of course is much much faster, but woefully inaccurate, but of course if you don't need accurate collisions, as with rectangular buttons, it doesn't matter. The point is, whichever of the above methods GM uses for checking collisions, both require information (color aray or polygon) to be generated at runtime. Without the box checked, will it bother to gather this extra information? Of course, if you had a lot of large animated sprites, non-perfect collisions would save memory (if I am right about this), so it might be worth going through every sprite unticking that box (unless it was necessary).
I have now forgotten my last question.
edit: remembered last question.
If you have a non-precise sprite and a precise sprite, and ask for a collision check between the two, does GM just perform a rectangle check or somehow check if the pixels of the precise sprite intersect the bounding box of the second?
The second method I call the polygon intersection method. This way, a polygon is assembled from the texels bordering the alpha texels aroudn the border, or the border itself. This polygon is stored for every sprite. So for example, if you had a sprite which looked like this:
~~~~~~~~ ~~~###~~ ~~####~~ ~#####~~ ~~~~~~~~ ~ = transparent texel # = opaque texel
the polygon created would look something like this
_____ / | / | /_______|
Of course, it is fairly easy to check intersections between polygons, and to apply a transformation to them beforehand. The polygon method is faster than the pixel loop method, but will not work for hollow sprites, as with this one
~~~~~~~~ ~######~ ~#~~~~#~ ~######~ ~~~~~~~~
unless you have a devilishly clever algorithm generating the polygon
Question one:
Which of these methods does Game Maker use? I suspect it is the pixel loop
The second question requires further information.
If you create a sprite in the editor, then uncheck the box labelled Precise Collision checking, the runner will just use the bounding box to check for collisions. THis of course is much much faster, but woefully inaccurate, but of course if you don't need accurate collisions, as with rectangular buttons, it doesn't matter. The point is, whichever of the above methods GM uses for checking collisions, both require information (color aray or polygon) to be generated at runtime. Without the box checked, will it bother to gather this extra information? Of course, if you had a lot of large animated sprites, non-perfect collisions would save memory (if I am right about this), so it might be worth going through every sprite unticking that box (unless it was necessary).
I have now forgotten my last question.
edit: remembered last question.
If you have a non-precise sprite and a precise sprite, and ask for a collision check between the two, does GM just perform a rectangle check or somehow check if the pixels of the precise sprite intersect the bounding box of the second?
