Jump to content


Go faster stripes....


  • This topic is locked This topic is locked
109 replies to this topic

Poll: Go faster stripes.... (149 member(s) have cast votes)

How fast does the optimised verison of the demo run?

You cannot see the results of the poll until you have voted. Please login and cast your vote to see the results of this poll.
Vote

#91 CloverGruff

CloverGruff

    GMC Member

  • GMC Member
  • 59 posts
  • Version:GM:Studio

Posted 06 May 2011 - 05:14 PM


How about just a "d3d_set_mipmap();" function?
So it would work like any other of those "d3d_set_..." functions.
Let's say I want everything to use mipmaping - I just enable it once, let's say, in the camera object.
But if I want to make specific objects use it, I just enable the mipmapping before drawing the object, and then disable it afterwards, like this:

   d3d_set_mipmap( 1 );
   d3d_draw_block(-s,-s,-s,s,s,s,tex,1,1);
   d3d_set_mipmap( 0 );
Or the other way around - make specific objects not use it.

Is it impossible, or does it cause too many problems?
Either way, I love that You guys are working on this - best of luck!

It's not that simple, enabling mipmapping won't do anything if the texture (sprite/background/...) you're using doesn't have mipmaps. The mipmaps have to be generated when the texture is created by GM (you would need a checkbox in the sprite/background editor to enable or disable it), you can't do that while you're drawing it.

Yeah, I spoke too soon - I figured that just after I wrote it.

Edited by EanFox, 06 May 2011 - 05:15 PM.

  • 0

#92 snake5

snake5

    GMC Member

  • GMC Member
  • 71 posts

Posted 06 May 2011 - 06:19 PM

Chances are, DX is scaling them to a POW2 for you. Remember mips are 1/2 the original size, and you can't do that if they aren't POW2.

I don't think that was the case since I can't find any official notes about POW2 requirements for mipmapping in D3D documentation but I also can't find any samples to upload that are showing non-POW2 mipmaps in action. I'll probably make one soon then. I've once hacked up mipmapping for GM through a proxy DLL so this shouldn't take a lot of time... :D

Changing to DX9 wouldn't give very much as we currently don't allow shaders anyway. It would also take a lot of effort to change it all. I know this having already done it for the C++ runner.

Having looked at the documentation and worked with both D3D8 and D3D9, I imagined moving from D3D8 to D3D9 being more like a few hours of find-replace work than a lot of effort. Am I missing something here?
  • 0

#93 thatshelby

thatshelby

    GMC Member

  • GMC Member
  • 3823 posts
  • Version:GM8

Posted 06 May 2011 - 06:27 PM

Is having support for non-pow2 textures a big deal? Sure it would be nice, but textures are typically these sizes anyway.
  • 0

#94 GameGeisha

GameGeisha

    GameGeisha

  • GMC Member
  • 4312 posts
  • Version:GM:Studio

Posted 07 May 2011 - 01:46 AM

Here are my stats:

Unoptimized: 2-4 FPS
2xAA: 53-114 FPS
8xAA: 20-35 FPS


My machine specs:

Samsung R480
Core i3 M330, 2.13GHz
Win 7 Premium 32-bit
4GB installed RAM
NVidia GeForce 310M, 512MB dedicated video memory

It's a fairly average machine, nothing gaming-grade, but it does a great job dealing with average work and casual games.

GameGeisha

Edited by GameGeisha, 07 May 2011 - 01:49 AM.

  • 0

#95 bbb0280

bbb0280

    GMC Member

  • GMC Member
  • 570 posts

Posted 07 May 2011 - 02:19 AM

sorry, i misvoted, it doesnt play at all
  • 0

#96 jsorgeagames

jsorgeagames

    GMC Member

  • GMC Member
  • 710 posts
  • Version:GM:Studio

Posted 07 May 2011 - 04:08 AM

FPS
3DCube_gm8.1.71.exe: 4-6 fps
3DCube_24BitZ_2xAA_With_AA_Fallback.exe: 49-52 fps
3DCube_24BitZ_8xAA_Optimised.exe: 17-22 fps

System Specs:
Intel Core 2 Duo
1.40 GHz, 2.00 GB RAM
Windows XP SP3
NVIDIA GeForce 8400M GS

I was quite surprised at the fps of the 2xAA Fallback - very good job on the optimization.
  • 0

#97 snake5

snake5

    GMC Member

  • GMC Member
  • 71 posts

Posted 07 May 2011 - 05:20 AM

Is having support for non-pow2 textures a big deal? Sure it would be nice, but textures are typically these sizes anyway.


GM needs support for many things. Sure, you can enforce something, remove something else, but that makes it less accessible to the target audience, which includes beginner game developers. Which probably aren't introduced to the concept of avoiding non-POW2 textures like plague. :D

Anyway, Mike.Dailly, here's a sample for you: http://www.box.net/shared/41sca0888i .
Took code from CodeSampler as a starting point.
Luckily the old D3DXCreateTextureFromFileEx function didn't change anything in the image (as you probably know, the D3D9 version of D3DXCreateTextureFromFileEx scales textures to next nearest power of two size by default).
It would be really easy to notice scaling on that texture (nonpow_test.png) I chose. The result would be something like nonpow_test_manual_pow2_example.png.
The controls are in the .cpp file. You're probably interested in the F3 key which changes the mipmap filtering algorithm.
I hope this proves what I said. :)

Edited by snake5, 07 May 2011 - 05:21 AM.

  • 0

#98 michael pw

michael pw

    GMC Member

  • GMC Member
  • 1488 posts
  • Version:GM8.1

Posted 07 May 2011 - 11:43 AM

This is awesome :D!!!

3DCube_gm8.1.71.exe 3-4FPS
3DCube_24BitZ_2xAA_With_AA_Fallback 900-1422FPS
3DCube_24BitZ_8xAA_Optimised 350-800FPS



Specs:


Nvidia GTx580
AMD Phenom IIx6 (3.3Ghz)
  • 0

#99

  • Guests

Posted 07 May 2011 - 01:02 PM

snake5: Yes, that's definitely part of the reason. We don't want to complicate things for newcomers. I had a look at the demo, and it does indeed look like newer cards don't care. Because of the results we've had on this test, and the scope of the cards being used, I'm a little worried that this would be incompatible with older cards. I know older cards simply didn't allow this, although having said that... I'm surprised GM works on them at all because of this limit!

Our biggest issue is the way GameMaker creates all it's sprite/textures internally, it isn't done the way you'd expect, and that hurts. However, I was pleased to see the mipmap bias was available on DX8 (which I was unsure about as I'd never used it back then!), so it might be we can just create mipmap chains all the time, and use the bias to switch them off by default. This would then let you "select" which ones you WANT to have mipmapping (so "sprites" don't have mipmapping, and textures do).

We'll need to do lots of tests with it, and probably get the community to run some more tests for us to make sure whatever we decide works for everyone. We might be able to detect errors, but I'd need to get an old card (which I might have lying around) to check and see what happens in these cases.

All going well, then yes.... a future update could enable mipmapping as discussed above - although I think I still favour something inside GameMaker that you "tick" for a sprite. I think that would be nicer for folk to use....


EDIT: Oh... and incidentally, iOS requires POW2 textures at all time, so it might make sense to enforce this to get folk used to the idea. Sprites get away with it because we PACK them onto POW2 textures.

#100 Copernicus

Copernicus

    GMC Member

  • GMC Member
  • 27 posts

Posted 07 May 2011 - 02:12 PM

My machine:
Windows Vista Home Basic 32bit
Processor: Intel Pentium 4 CPU 3.2 GHz
Display Adapter: Intel 82945G Express Chipset Family
Memory: 501 MB.

Performance:
3DCube_gm8.1.71: 1 fps.
3DCube_24BitZ_8xAA_Optimised: Failed to initialize drawing surfaces.
3DCube_24BitZ_2xAA_With_AA_Fallback: 125 fps, but no texture (only white lines were drawn).
  • 0

#101 snake5

snake5

    GMC Member

  • GMC Member
  • 71 posts

Posted 07 May 2011 - 04:23 PM

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. :D

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.
  • 0

#102 michael pw

michael pw

    GMC Member

  • GMC Member
  • 1488 posts
  • Version:GM8.1

Posted 07 May 2011 - 10:09 PM

I want this update sooo badly D:!
  • 3

#103 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 1921 posts
  • Version:GM:Studio

Posted 08 May 2011 - 03:07 AM

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.
  • 0

#104 Mr. RPG

Mr. RPG

    GMC's Forum Troll

  • GMC Member
  • 3114 posts
  • Version:GM:Studio

Posted 08 May 2011 - 06:39 AM

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
  • 0

#105 snake5

snake5

    GMC Member

  • GMC Member
  • 71 posts

Posted 08 May 2011 - 06:42 AM

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.

  • 0

#106 paul23

paul23

    GMC Member

  • Global Moderators
  • 3840 posts
  • Version:GM:Studio

Posted 08 May 2011 - 11:02 AM

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.
  • 1

#107 snake5

snake5

    GMC Member

  • GMC Member
  • 71 posts

Posted 08 May 2011 - 01:00 PM

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.
  • 0

#108 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 1921 posts
  • Version:GM:Studio

Posted 08 May 2011 - 03:31 PM

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.
  • 0

#109 snake5

snake5

    GMC Member

  • GMC Member
  • 71 posts

Posted 08 May 2011 - 05:41 PM

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.
  • 0

#110

  • Guests

Posted 08 May 2011 - 05:49 PM

Okay.. this has gotten way off topic, so I'm closing it.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users