• Hey! Guest! The 37th GMC Jam will take place between May 28th, 12:00 UTC and June 1st, 12:00 UTC. Why not join in! Click here to find out more!

d3d GMS2 Import Error


Hey, I while back I started to create a snooker shooter game, I am developing it again. It was a few years back when I started, now I've imported it to GMS2, however some of the d3d is not working correctly.

I see that GMS2 has tried to work with the obsolete d3d functions by creating a variety of scripts. However, while the d3d does work for the most part it does have a major problem. As shown below for balls I drew it is drawing both the front and the back of the model. I used a quarternion based rotation system when I developed the game originally, and another forum user helped me with the specifics of the d3d so I am at a bit of a loss to understand what exactly is going wrong.

This is how the game looks after import:

As you can see the balls seem to be translucent, in some spots you can see right through to the other side. I thought the problem was that d3d culling was perhaps needed. When enable d3d culling using d3d_set_culling(0) the rotation of the snooker balls does not work correctly and there are two spots on the ball at the poles that are entirely transparent, as shown in the image below:

Any ideas?

Thanks for reading :)
These are my initial thoughts.

Are you using 3d models for the balls, or are you using a shader to create a "sphere" effect out of your texture? If you are using 3d models, then:

Culling should be enabled. If the rotation appears wrong then you might be culling in the wrong direction. Look up gpu_set_cullmode.

If you have set your own projection matrix, make sure that the near and far clipping distances are reasonable. Near must be greater than 0.

The transparency at the poles is somewhat mysterious. If there is nothing wrong with your texture, then the vertices might be wound in the opposite direction at the poles, causing the wrong side to be culled. But before you remake your model, check what happens if you reverse the culling direction.


I will give that a go whenever I get home tonight.

Would there be any advantage to removing the d3d stuff at a later stage and simply use the functions in gms2 instead?

Thanks for the help by the way


I will give that a go whenever I get home tonight.

Would there be any advantage to removing the d3d stuff at a later stage and simply use the functions in gms2 instead?

Thanks for the help by the way
If you check the generated compatibility scripts you will find that they contain the native GMS2 functions which use the arguments passed in by the script.

You can do a global search on the script names and comment them out, then replace them with the native functions found in the script and the required arguments.

Change them one by one and then do a test run of the project to make any issues easy to pinpoint, but it's generally a simple process of replacing the script calls with the native functions found in the scripts.


Bump. I've found a potential bit of headway into the problem.

It appears the drawing error is caused by the following code:

The last argument in the above code is for "How many steps are used to make the ellipsoid round" (according to the GMS2 import script)

When I change the 10 in the above code to another number I get the following results:





As you can see the higher n is the smaller the resulting triangles that make up the ball texture are, i.e. for n=40 they are tiny and the image appears translucent, however for 2 the texture seems to be mapped onto a single triangular-based pyramid. What is going on here? How can this be fixed?

EDIT: It should be noted I've tried all combinations of d3d culling also and unfortunately no setting produces a result that is any better, clockwise resutls in everything but the ball textures being black and noculling results in the texture being drawn decently but there are still gaps in the image and the rotation is way off.

If anyone wants the code to see what is going on just ask and I can PM it to you.


I am thinking now that the error is caused by the compatibility script "d3d_model_ellipsoid" autogenerated by GMS2 that is incorrect.

/// @description Adds an ellipsoid shape to the model.
/// @param ind The model index to add the ellipsoid to.
/// @param x1 The initial x coordinate of the ellipsoid.
/// @param y1 The initial y coordinate of the ellipsoid.
/// @param z1 The initial z coordinate of the ellipsoid.
/// @param x2 The opposite x coordinate of the ellipsoid.
/// @param y2 The opposite y coordinate of the ellipsoid.
/// @param z2 The opposite z coordinate of the ellipsoid.
/// @param hrepeat Amount of horizontal repetitions for the texture.
/// @param vrepeat Amount of vertical repetitions for the texture.
/// @param steps How many steps are used to make the ellipsoid "round" (typically 24)
/// @returns

var __ind = argument0;
var __x1 = argument1;
var __y1 = argument2;
var __z1 = argument3;
var __x2 = argument4;
var __y2 = argument5;
var __z2 = argument6;
var __hrepeat = argument7;
var __vrepeat = argument8;
var __steps = argument9;

if (__steps < 3)
    __steps = 3;

if (__steps > 128)
    __steps = 128;

// Create sin and cos tables
var __cc;
var __ss;

__cc[__steps] = 0;
__ss[__steps] = 0;

var __i;
for(__i = 0; __i <= __steps; __i++)
    var __rad = (__i * 2.0 * pi) / __steps;
    __cc[__i] = cos(__rad);
    __ss[__i] = sin(__rad);

var __mx = (__x2 + __x1) / 2;
var __my = (__y2 + __y1) / 2;
var __mz = (__z2 + __z1) / 2;
var __rx = (__x2 - __x1) / 2;
var __ry = (__y2 - __y1) / 2;
var __rz = (__z2 - __z1) / 2;

var __rows = (__steps + 1) / 2;
var __j;

for(__j = 0; __j <= (__rows - 1); __j++)
    var __row1rad = (__j*pi)/__rows;
    var __row2rad = ((__j+1)*pi)/__rows;
    var __rh1 = cos(__row1rad);
    var __rd1 = sin(__row1rad);
    var __rh2 = cos(__row2rad);
    var __rd2 = sin(__row2rad);
    d3d_model_primitive_begin(__ind, pr_trianglestrip);
    for(__i = 0; __i <= __steps; __i++)
        // Some common subexpressions here that could be eliminated
        d3d_model_vertex_normal_texture(__ind, __mx+__rx*__rd1*__cc[__i], __my+__ry*__rd1*__ss[__i], __mz+__rz*__rh1,__rd1*__cc[__i], __rd1*__ss[__i], __rh1, __hrepeat*__i/__steps, __j*__vrepeat/__rows);
        d3d_model_vertex_normal_texture(__ind, __mx+__rx*__rd2*__cc[__i], __my+__ry*__rd2*__ss[__i], __mz+__rz*__rh2,__rd2*__cc[__i], __rd2*__ss[__i], __rh2, __hrepeat*__i/__steps, (__j+1)*__vrepeat/__rows);
Shouldn't there be at least three vertices for every triangle, I only see two d3d_model_vertex_normal_texture in the code above. Is that it I wonder?


Hard so tell from the pics what you mean, there is a lot going on in them.

But I have found from experience issues when importing 3D from 1.4 to 2.x and it has usually revolved around the Y Up (from memory. It's been a while). Re quick modification of the camera system usually fixes it up for me. Paying attention to the view and perspective sections of your system.


I think its an issue relating to culling, because the triangles are drawn in a triangle strip they will alternate from clockwise to counterclockwise to clockwise again and so on... Therefore with counterclockwise culling half of the triangles will be culled and therefore not displayed, this explains the patchy triangular pattern of the balls. I've tried disabling culling but the ball rotation effect does not work correctly then in that case I think because the reverse side of the ball is shown instead of the front side (also there are small circles missing at the poles for some reason). Triangle strip also only requires two vertices per additional triangle I think, that explains why it doesn't have three vertices per iteration of the loop.

I don't understand culling entirely so I am a bit perplexed with it and am simply tinkering until I get the desired results. Still I believe there is a solution that is likely just before us but we cannot see. I just can't put my finger on it.

The code is really efficient and renders 3D ball effects on a 2D plane, I think it'd be a perfect kind of 2D ball engine. I'm hoping to make it an asset for other GM developers to use in future.
Last edited:


Friendly Tyrant
Forum Staff
While I'm afraid I can't help with tis issue as 3D is not my thing, I would like to suggest that you file a bug report and include links to both the 1.4 and 2.x versions of the project. The compatibility scripts should work and if they aren't then this is a bug and should be fixed. AT the very least, you can request in the bug report that they help you resolve the issue in the compatibility script yourself.


Are zwriting and ztesting on? If you disable culling it should look normal, culling is not related to incorrect depth ordering.


I have sent a copy of the code to everyone who has recently commented on the thread. If anyone else wants the code to try to help shoot me a message.


Hmm, seems like when culling is off the model still has a "hole" at only the south pole of the 3D ball. I wonder why that is.

From my testing I can see that it simply doesn't utilise the last 2 lines of pixels of the source sprite to draw the ball texture


I would recommend either trying a different sphere generating script or using an .obj import script to import one from Blender.


I might be on to something. Do you have a screenshot (or a mockup) of what we should be seeing?

Anything like this?



Nice, I’ve just got it working as well did you do the same as me and multiply the sphere rotation variables in the obj_phy_ball object by -1.

I’ve figured out also that the missing south pole gap in the sphere is due to the ellipsoid model not using the last few lines of pixels to render the model. I am on my phone atm so can’t link direct code but changing d3d_ellipsoid code by increasing the row count will fix this issue I think.