Jump to content


Photo

Go faster stripes....


  • This topic is locked This topic is locked
108 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

#101 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

Known as MishMash on the internet, If only my username could be changed :D?

Posted Image

Working on Sharp Edge, a 3D Level designer which exports to GMMOD and textures, with a vast toolset, and fancy GUI. ( So far, software is only going to be distributed with my game, in the future, it will be up for public use and with the ability to customise the software using the Plugin System to suite your games needs.)
Also working on 3D Multiplayer FPS Global Anarchy Denied Operations.


#102 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 1981 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

My KBInput system is now on the marketplace here.  It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput.  The support forum topic for it is here.


#103 Mr. RPG

Mr. RPG

    GMC's Forum Troll

  • GMC Member
  • 3181 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

#104 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

#105 paul23

paul23

    GMC Member

  • Global Moderators
  • 4084 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

#106 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

#107 kburkhart84

kburkhart84

    Firehammer Games

  • GMC Member
  • 1981 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

My KBInput system is now on the marketplace here.  It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput.  The support forum topic for it is here.


#108 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

#109 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4750 posts
  • Version:GM:Studio

Posted 08 May 2011 - 05:49 PM

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




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users