Are the new restrictions making GS seem less "drag and drop?"

chaley

I'm a little sad that easy to use things like "animate", "change image", and "timers" are being replaced with a bunch of very "code-like" alternatives. I wish there was a way to have all of that attribute changing happen "behind the scenes." I know that GS is still the best alternative for those who want to avoid the hardcore coding, but I'm just a little disappointed to see things that were very easy to use replaced with complicated attribute structures.

olster1

I completely see whee your coming from. I suppose GS should take upon themselves to make the actual rules such as animate, change images ect the most efficient. It seems silly that they aren't the most efficient way to do them.

The way I see it though it's a good thing. It's good that there are these work arounds as it keeps your mind sharp and helps you think outside the box a little. Problem solving is one of the fun bits of development (only when you find the solution of course) It also means that you will learn a lot more about the programme itself and improve faster. just my opinion.

In terms of development time, it would be quicker and easier for the rules to be the most efficient.

Remember it's in beta so I'm sure it will SLOWLY get sorted out.

chaley

Uptimistik... The "could be worse" argument never really works in the long run.  I've seen code used in programs like "Corona" and it hurts my head to look at it.  All I'm saying is that there were great "drag and drop" features placed in front of me & then they were suddenly yanked away.  

That's unfortunate.

Olster1... Right on, man.

DZTECH

I can code in Xcode, unity, corona and more as well as use game salad and you have no idea how much easier game salad is. I was coding only because at that time game salad didn't exist yet and i didn't hear about game salad until last year. If you want to add an turning image in game salad you drag the image and add a behavior for it to rotate. Here is how you have to set it up in Xcode. It is this long in Xcode because you use open gl and this is how it works for games. And this ifs just for an image. Imagine coding a complex game.

// Display "myImage.png"

// ----------------------------------------------------------------------------
// OpenGLESTextureAppDelegate.m
// ----------------------------------------------------------------------------

#import "OpenGLESTextureAppDelegate.h"
#import "EAGLView.h"
#import "OpenGLESTextureViewController.h"

@implementation OpenGLESTextureAppDelegate

@synthesize window=_window;

@synthesize viewController=_viewController;

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
// Override point for customization after application launch.
self.window.rootViewController = self.viewController;
return YES;
}

- (void)applicationDidBecomeActive:(UIApplication *)application
{
/*
Restart any tasks that were paused (or not yet started) while the application was inactive. If the application was previously in the background, optionally refresh the user interface.
*/
[self.viewController drawFrame];
}

- (void)dealloc
{
[_window release];
[_viewController release];
[super dealloc];
}

@end

// ----------------------------------------------------------------------------
// EAGLView.m
// ----------------------------------------------------------------------------

#import <QuartzCore/QuartzCore.h>
#import "EAGLView.h"

@interface EAGLView (PrivateMethods)
- (void)createFramebuffer;
- (void)deleteFramebuffer;
@end

@implementation EAGLView

@synthesize context;

// You must implement this method
+ (Class)layerClass
{
return [CAEAGLLayer class];
}

//The EAGL view is stored in the nib file. When it's unarchived it's sent -initWithCoder:.
- (id)initWithCoder:(NSCoder*)coder
{
self = [super initWithCoder:coder];
if (self) {
CAEAGLLayer *eaglLayer = (CAEAGLLayer *)self.layer;

eaglLayer.opaque = TRUE;
eaglLayer.drawableProperties = [NSDictionary dictionaryWithObjectsAndKeys:
[NSNumber numberWithBool:FALSE], kEAGLDrawablePropertyRetainedBacking,
kEAGLColorFormatRGBA8, kEAGLDrawablePropertyColorFormat,
nil];
}

return self;
}

- (void)dealloc
{
[self deleteFramebuffer];
[context release];

[super dealloc];
}

- (void)setContext:(EAGLContext *)newContext
{
if (context != newContext) {
[self deleteFramebuffer];

[context release];
context = [newContext retain];

[EAGLContext setCurrentContext:nil];
}
}

- (void)createFramebuffer
{
if (context && !defaultFramebuffer) {
[EAGLContext setCurrentContext:context];

// Create default framebuffer object.
glGenFramebuffers(1, &defaultFramebuffer);
glBindFramebuffer(GL_FRAMEBUFFER, defaultFramebuffer);

// Create color render buffer and allocate backing store.
glGenRenderbuffers(1, &colorRenderbuffer);
glBindRenderbuffer(GL_RENDERBUFFER, colorRenderbuffer);
[context renderbufferStorage:GL_RENDERBUFFER fromDrawable:(CAEAGLLayer *)self.layer];
glGetRenderbufferParameteriv(GL_RENDERBUFFER, GL_RENDERBUFFER_WIDTH, &framebufferWidth);
glGetRenderbufferParameteriv(GL_RENDERBUFFER, GL_RENDERBUFFER_HEIGHT, &framebufferHeight);

glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER, colorRenderbuffer);

if (glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE)
NSLog(@Failed to make complete framebuffer object %x, glCheckFramebufferStatus(GL_FRAMEBUFFER));
}
}

- (void)deleteFramebuffer
{
if (context) {
[EAGLContext setCurrentContext:context];

if (defaultFramebuffer) {
glDeleteFramebuffers(1, &defaultFramebuffer);
defaultFramebuffer = 0;
}

if (colorRenderbuffer) {
glDeleteRenderbuffers(1, &colorRenderbuffer);
colorRenderbuffer = 0;
}
}
}

- (void)setFramebuffer
{
if (context) {
[EAGLContext setCurrentContext:context];

if (!defaultFramebuffer)
[self createFramebuffer];

glBindFramebuffer(GL_FRAMEBUFFER, defaultFramebuffer);

glViewport(0, 0, framebufferWidth, framebufferHeight);
}
}

- (BOOL)presentFramebuffer
{
BOOL success = FALSE;

if (context) {
[EAGLContext setCurrentContext:context];

glBindRenderbuffer(GL_RENDERBUFFER, colorRenderbuffer);

success = [context presentRenderbuffer:GL_RENDERBUFFER];
}

return success;
}

- (void)layoutSubviews
{
// The framebuffer will be re-created at the beginning of the next setFramebuffer method call.
[self deleteFramebuffer];
}

@end

// ----------------------------------------------------------------------------
// OpenGLESTextureViewController.m
// ----------------------------------------------------------------------------

#import <QuartzCore/QuartzCore.h>
#import "OpenGLESTextureViewController.h"
#import "EAGLView.h"

@interface OpenGLESTextureViewController ()
@property (nonatomic, retain) EAGLContext *context;
@property (nonatomic, assign) CADisplayLink *displayLink;
- (void) loadTexture;
@end

@implementation OpenGLESTextureViewController

@synthesize animating, context, displayLink;

- (void)awakeFromNib
{
EAGLContext *aContext = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES1];

if (!aContext)
NSLog(@Failed to create ES context);
else if (![EAGLContext setCurrentContext:aContext])
NSLog(@Failed to set ES context current);

self.context = aContext;
[aContext release];

[(EAGLView *)self.view setContext:context];
[(EAGLView *)self.view setFramebuffer];

[self loadTexture];

self.displayLink = nil;
}

- (void) loadTexture
{
glEnable(GL_TEXTURE_2D);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

glGenTextures(1, &textureID);
glBindTexture(GL_TEXTURE_2D, textureID);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);

NSString *path = [[NSBundle mainBundle] pathForResource:@myImage ofType:@png];
NSData *texData = [[NSData alloc] initWithContentsOfFile:path];
UIImage *image = [[UIImage alloc] initWithData:texData];

GLuint width = CGImageGetWidth(image.CGImage);
GLuint height = CGImageGetHeight(image.CGImage);
CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
void *imageData = malloc( height * width * 4 );
CGContextRef image_context = CGBitmapContextCreate( imageData, width, height, 8, 4 * width, colorSpace, kCGImageAlphaPremultipliedLast | kCGBitmapByteOrder32Big );
CGColorSpaceRelease( colorSpace );
CGContextClearRect( image_context, CGRectMake( 0, 0, width, height ) );
CGContextTranslateCTM( image_context, 0, height - height );
CGContextDrawImage( image_context, CGRectMake( 0, 0, width, height ), image.CGImage );

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, imageData);

CGContextRelease(image_context);

free(imageData);
[image release];
[texData release];

}

- (void)dealloc
{
glDeleteTextures(1, &textureID);

// Tear down context.
if ([EAGLContext currentContext] == context)
[EAGLContext setCurrentContext:nil];

[context release];

[super dealloc];
}

- (void)viewDidUnload
{
[super viewDidUnload];

// Tear down context.
if ([EAGLContext currentContext] == context)
[EAGLContext setCurrentContext:nil];
self.context = nil;
}

- (void)drawFrame
{
[(EAGLView *)self.view setFramebuffer];

// Replace the implementation of this method to do your own custom drawing.
static const GLfloat squareVertices[] = {
-0.5f, -0.33f,
0.5f, -0.33f,
-0.5f, 0.33f,
0.5f, 0.33f,
};

static const GLfloat texCoords[] = {
0.0, 1.0,
1.0, 1.0,
0.0, 0.0,
1.0, 0.0
};

glClearColor(0.0f, 0.0f, 0.0f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);

glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();

glVertexPointer(2, GL_FLOAT, 0, squareVertices);
glEnableClientState(GL_VERTEX_ARRAY);
glTexCoordPointer(2, GL_FLOAT, 0, texCoords);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);

glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);

[(EAGLView *)self.view presentFramebuffer];
}

@end

chaley

zakdavid... again... the "could be worse" argument never really works in the long run.

I KNOW there are programs where the coding language is prohibitive and tedious. It's obvious that GS is easier as I've already stated.

BUT...

The fact remains that GS has a reputation built on "ease of use" , but when you have to take many of the most used "easy" tools off the table and substitute them for tools that are more difficult and less intuitive... then the situation gets cloudy/complicated.

beefy_clyro

To be fair, advertised as drag and drop, which it is, there are better more optimised ways of doing it as has been pointed out recently, if you chose not to do those, thats your call. You can use the drag and drop behaviours they have to do the same job ... just less optimised. Having said that i do agree, if they now know better ways to do things, it would be better if they optimised the drag and drop rules they currently have to perform in those way behind scene.

StusApps

@zakdavid

haha, where did you copy and paste that from?

If you were programming in xcode for iOS devices you would drop it in your resources and use UIimage.

you get the iphone sdk when you download xcode from your dev account. It has an IB and things meaning you don't need all of that code. But I'm sure you know that already

StusApps

Just read you wanted it to turn. that would be 3 lines of code total. first to set the shape and apply the image, second to set a turning point, third to rotate it.

But still i wouldn't use xcode for making a game. i did 6 months of it and figured i would need another 6 years before i could make a workable game.

chaley

I just think that the "defaults" should be optimized.

It's that simple.

It's not my "choice" to do things the hard way when an easier way can be offered up by the software. They advertise "easy." I don't expect a "build entire game" button, but I do expect the default behaviors to work.

I know it's "beta" so things are still being worked out... and I'm not trying to pretend that GS isn't a great tool.

It is. I think GS is great.

BUT... I just think that when you list "features" and "behaviors" and boast about the "ease of use" ...then you have to make good on those. Otherwise... the workarounds and unintuitive band-aid measures turn into the core operating procedures.

That's not really the same thing as "drag and drop." and "free of coding."

StusApps

I am hopeful they will choose other ways to implement the timers, animations, etc.. it would be silly of them not to use the quickest method. i think the reason for these workaround at the moment is that it will be a big job to make the engine work in a different way, that and they didn't realise they had broken stuff.

DZTECH

Stusapps

I got that from one of my games. However yes it only needs this three lines however to animate you use open gl which needs all that just to set it up. However every Xcode developer has a cheat sheet. I do to. Common things like that we copy and paste

Rob2

@Stu I'm so tempted to talk about paper bags but hey http://www.anscamobile.com/corona/comparison/objective-c/display-image/
why bother

Rob2

Back on topic is animate no good anymore ?

tenrdrmer

They have not been yanked away from you Chaley.

Users Asked for GS Suggestions to gain better loading times until the Default loading times and systems are improved. So GameSalad in unusual fashion actually responded and gave some suggestions to work around the current behaviors to gain better loading times.

Theres nothing wrong with the basics being there for new people and advanced work arounds being known for the experienced users.

Some day GS will improve these behaviors but until then they have offered advice to improve your own game performance.

I personally still use those Standard behaviors often and don't feel the need to use a work around for those. So they certainly have not been taken away.

SlickZero

Animate is still good, Rob. There is just a workaround for better performance. If you have a ton of animations, the new workaround would yield better performance than a bunch of Animate behaviors, but if you aren't using a ton of animations, the normal Animate behavior will do you just fine.

Testing out the method, it works great. Side by side with the Animate behavior for just one animation, I see no difference in performance, so unless you get into a lot of animations, I'd continue using the Animate behavior. The game Im working on now has several animations, but nothing too crazy, and i'm using the Animate behavior still.

chaley

Well, it's great that the GS folks have responded and given advice. I really do appreciate that. It sure as heck beats what some companies do... which is blame "operator error" and pretend their software is flawless.

When my game hits my phone, it's WAY too ram intensive to work properly. The main "weapon launch" system works every 5th or so time and it's a very frustrating experience. I couldn't sell that game if I wanted to.

I was using a lot of the "basics" which I now have to track down and alter. I thought I'd be able to use the current "nice, easy, and intuitive" toolset, and as it turns out, the new workarounds aren't very intuitive and require additional support and the tracking down of tutorials/examples. I think I deserve the right to be upset about that.

tenrdrmer

No one said you cannot be upset. I will say though while it may upset you to here user error is likely the cause. 90% of the time it is. Just because all of these behaviors are there and easy to use does not mean they will all play nice with each other. That is no different in any type of coding somethings will not work right when you code them something else. For example. Constrains are very hard on the processor and ram. If you are using a bunch of them you really need to look and see is it nessacary. Maybe 90% of them can be change attributes instead. Also are you using otherwise. If you have 100 separate rules but based on the conditions only one rule runs at a time. Those can be thrown into the otherwise's of each other and then the rule stops being read when the right conditions are meat in stead of every single rule being check each time a condition changes.

So no offense intended. But there is a very good chance the way you have your game setup is causing you problems. It all comes down to learning the best way to use the tool. And you will get that with experience. And finding a way around a frustrating thing like performance is a good place to start.

but you have to take all the information in as a whole. you cannot look at as, well he said I can improve performance by not using animate like this mean I can never use animate again.

Another big place where people lose performance and especially ram is the images they are using. you need to make sure your images files are sized correctly for the actors they are in. If your having a problem where a player will not even fire his gun correctly it sounds to me like you have massive image files for a bunch of small actors.

Developing can be a very frustrating thing and if you look at the problems you are having narrow minded or tunnel visioned in on one specify thing that you cannot figure out your gonna have a lot of trouble with any game. you have to step back and look at all possible problems and Trust me when you do you will understand what I mean by user error being the problem most of the time.

We all have that problem its not just you either.

JohnPapiomitis

tenrdrmer said:
No one said you cannot be upset. I will say though while it may upset you to here user error is likely the cause. 90% of the time it is. Just because all of these behaviors are there and easy to use does not mean they will all play nice with each other. That is no different in any type of coding somethings will not work right when you code them something else. For example. Constrains are very hard on the processor and ram. If you are using a bunch of them you really need to look and see is it nessacary. Maybe 90% of them can be change attributes instead. Also are you using otherwise. If you have 100 separate rules but based on the conditions only one rule runs at a time. Those can be thrown into the otherwise's of each other and then the rule stops being read when the right conditions are meat in stead of every single rule being check each time a condition changes.

So no offense intended. But there is a very good chance the way you have your game setup is causing you problems.

+1

chaley

I don't have to be an experienced game designer to know that a simple "drag and drop" "animate" feature is easier to use than a complicated system of attributes.

I just hope that the folks at GS are working on making things like "animate" work better and not just handing the workarounds out & thinking the problem is now fixed.  Who knows... Maybe it's not possible to have an optimized "animate" feature or a "timer" feature.  My hope though, is that if it IS possible, that it happens.

Also, there's a difference between behaviors fighting with each other and fighting with the engine.  

I know that my inexperience is part of the problem, but like I said... I know "ease of use" when I see it.

It'd be great if GS was looking into ways of making the features work as well or better than the workarounds.  They probably are working on that.  It makes the software easier to learn and use and I don't think it's a bad goal to have.

Yodapollo

Hey, everyone.

I just wanted to point out the the suggested optimizations around "animate" and "change image" and such are not meant to be permanent fixes in any way. We are certainly looking to improve those behaviors.

These workarounds are only meant as a temporary solution in the case that they are causing slowdowns on your project (that does not always seem to be the case, and can vary from project to project).

The dev team is hard at work to improve performance of the engine so that these workarounds will not be needed and all the behaviors will perform just like they should. Thanks to everyone for your feedback and I hope that clears up some of the confusion.

--Yodapollo

WyrdGuitarist

Yoda, bringer of information ftw.

zombieaddict

@yoda. thanks for keeping us updated. But please address the use of the Destroy behaviour. In its current state, its effectively unusable. If memory isn't released upon destroy then why are we using it? We may aswell just push the actor offscreen or turn its alpha off. GS users are often suggested to use recycling instead of spawning. We shouldn't have to. Destroy should do its function. Let us use some kind of garbage collector or something...

chaley

Yoda that clears it up totally. Thanks for the response. I really have to commend the GS staff for their open communication with users. I hope I didn't come across as unappreciative for the workarounds and help that's been given to us. At least we have a way to move forward for the short term. My hope for this thread was to simply open a conversation about "ease of use" and the future of default behaviors. I'm psyched to learn that optimizing the base behaviors is "on the list" for future releases.