109 replies to this topic

[snake5]

Mike.Dailly:

I'm surprised GM works on them at all because of this limit!

I think I had found an Intel graphics card once that could run D3D9 (with software vertex processing and POW2 textures) and couldn't run GM.

to make sure whatever we decide works for everyone

It's probably not going to happen anyway. I mean - you can make something basic work for everyone (like making a D3D device) but it's simply impossible to get every feature (in every way) on every computer that supports 3D rendering. I think it's quite reasonable to disable mipmapping completely / force POW2 on older PCs.

although I think I still favour something inside GameMaker that you "tick" for a sprite

Agreed. Though additional options to enable mipmapping in sprite/texture creation functions and enabling/disabling mipmaps at runtime (for those textures which have mipmaps generated) are as necessary as that, IMHO.

P.S. One thing came into my mind just now (a bit unrelated though): I think it would help us find the location of many bugs if you could post information about what those errors mean exactly. Or, at least, more detailed error messages. They're quite cryptic even for experienced programmers. I'm seeing "unexpected error" and "runtime error 216" popping up occasionally along with GM hanging after FPU exceptions (or perhaps any exceptions) so I'm wondering about the exact nature of errors there. I think that could really help the creators of DLLs.

[michael pw]

I want this update sooo badly D:!

[kburkhart84]

I think before we try to get too far into deciding what needs to be added/taken away, I think we need to get into what has changed in the C++ runner, as far as the rendering at least. I understand it is no longer using D3D8, rather D3D9, and so we possibly should also be more worried about testing that, including how it runs on older(but still DX9 capable) cards. I'm not suggesting that we have Mike tell us the details of what did/didn't change with the runner, rather that before we worry too much about rendering(3d or 2d), we need to be on the same page with the runner itself. I know Mike is doing these 3d optimizations with the original(but updated) Delphi runner, and some of that could translate into the C++ runner. But seriously, whether or not to enforce POW2 textures, whether it is viable to have/enable mipmapping, etc... Those things seem a little "small" to worry about considering the other runner coming up.

[Mr. RPG]

3Dcude with AA Fallback: 50 FPS
3Dcube Optomised: Does not boot at all. Get error about my graphics card.
3Dcube gm8.1.71: 4-5 FPS

System Specs:
Intel Core 2 Quad CPU Q2800 at 2.33 GHz 2.34 GHz
4.00 GB RAM
Windows 64 bit
ATI Radeon HD 4350 512 MB

[snake5]

and so we possibly should also be more worried about testing that

Testing what? In terms of requirements, D3D9 = D3D8 + D3D9 files must be installed. D3D9 supports D3D6-level graphics cards. So nothing bad can happen to compatibility from a simple API change.

But seriously, whether or not to enforce POW2 textures, whether it is viable to have/enable mipmapping, etc... Those things seem a little "small" to worry about considering the other runner coming up.

They are what can make or break compatibility and are important features to have at the same time.
Check this: http://msdn.microsof...b172513(v=vs.85).aspx
This is what they should worry about (and I think they've done that a lot already).

You could also check the demo I uploaded: http://www.box.net/shared/41sca0888i
Press F3 a few times to compare how the surface looks with and without mipmapping.
Replace nonpow_test.png with your own textures to see how they look with and without mipmapping.
I think that should be enough to see that the feature is really important.

Edited by snake5, 08 May 2011 - 06:49 AM.

[paul23]

and so we possibly should also be more worried about testing that

Testing what? In terms of requirements, D3D9 = D3D8 + D3D9 files must be installed. D3D9 supports D3D6-level graphics cards. So nothing bad can happen to compatibility from a simple API change.

But seriously, whether or not to enforce POW2 textures, whether it is viable to have/enable mipmapping, etc... Those things seem a little "small" to worry about considering the other runner coming up.

They are what can make or break compatibility and are important features to have at the same time.
Check this: http://msdn.microsof...b172513(v=vs.85).aspx
This is what they should worry about (and I think they've done that a lot already).

You could also check the demo I uploaded: http://www.box.net/shared/41sca0888i
Press F3 a few times to compare how the surface looks with and without mipmapping.
Replace nonpow_test.png with your own textures to see how they look with and without mipmapping.
I think that should be enough to see that the feature is really important.

I'd rather have something every game can use: a feature for the LANGUAGE instead of a feature for an engine. But it seems the whole debate about 3d is centered around getting "functions" into gamemaker.. Instead of actual features to gamemaker. I believe if gamemaker really wants to become a tool for 3d games, focus should lay around incorporating a world editor, 3d collision-system, making the "z" variable a build-in (along with z-previous and updating all functions).
Mipmapping is only a single feature you might or might not like/want, it doesn't really extend gamemaker's true potential.

[snake5]

Think of mipmapping as a bugfix, not a feature (which it actually is - people actually prefer not seeing blinking noise where a simple surface should be). And GM is a 2D tool with 3D features for advanced users. For 2D, it's a toolkit, for 3D, it is only the GML interface you get and there's nothing wrong with that. Things for programmers without such tools are much worse, actually. 3D interface is here only as a way to get 3D graphics for 2D games.

Mipmapping is only a single feature you might or might not like/want, it doesn't really extend gamemaker's true potential.

For those who want to sell a game, they actually need such features to make the game more appealing ...and easier to look at, in this case. They need lots of such "tiny" stuff that is taken for granted in lots of other engines, 2D and 3D. In terms of tech demos, this is nowhere near the true potential. In terms of playable 3D games, this is what makes or breaks the true potential. The list of features I'd like to see is actually a lot bigger than just mipmapping. But it's not something that is advertised all the time. Bloom, SSAO, normal mapping - not required. Multitexturing, separated matrix/quaternion math, making Alt+F4 work while making Esc do nothing - all necessary.

[kburkhart84]

Don't take my post wrong. I'm not saying mip-mapping isn't important for a quality game. Rather, I'm saying such features shouldn't be rushed at this point, rather once we get the new runner in. Why invest more time than you really have to on making better the old version, when you already have the new version(which may have already fixed some of the issues we are mentioning)??? I'm not sure what all has changed in the new runner, but I know that time would be better spent finishing the new runner(then adding those missing features) than adding the missing features to the older runner, when the new one is coming soon enough("soon" who knows how long though, but you get my point).

The biggest reason for me not wanting to use GM for 3d at this time is two-fold. One is the lack of fast animation, and the other is the lack of fast collision detection(in 3d that is). A lot of the other stuff is just fluff, and though normal-mapping/bloom/other shader created features are all the rage, they don't really make a game better as far as gameplay. But, animation and collision are necessary to make many games work in the first place. 3d collisions can be done with gml(and are) but you are very limited due to speed. On the other hand, if gml gets faster with the C++ runner like it is supposed to, then that part may no longer be an issue, as I could calculate collisions myself. Then only the animation would be left as far as big issues go.

I personally would rather see a re-write of the sound system before anything 3d is implemented. It is "broken" compared to other systems. No sound instancing, using windows media to play(atleast on windows, and only music I know), I mean those to me are far more important issues than adding mip-mapping to a runner that is likely not to be in use by GM9.0 anyway.

[snake5]

if gml gets faster with the C++ runner like it is supposed to

Moving the runner to C++ doesn't make your scripts as fast as C++. The only optimization you will get is the one that comes from the C++ compiler that might (nothing more, no promises) make something a bit faster IF it's better than the Delphi compiler.

One is the lack of fast animation

There are clever ways to make characters that don't need traditional (skinned mesh) animation - keyframes / splitting a mesh into parts.

and the other is the lack of fast collision detection

IIRC DLLs do a very good job here.

It is "broken" compared to other systems.

I agree, it requires a rewrite. But since we have lots of DLLs here, it's not as important as adding features that are completely impossible to add through a DLL without serious and unstable hacking which includes proxy DLLs and intruding GM's memory space.