Image questions

#1 In Photoshop (pre 6.0) the alpha channel was used for transparency. In current version (CS) you have to "Save for Web" then declare what colors should be exported as transparency ( think blue screens in the movies)

Dunno about scales, but to set the size of the sprite is setSize("32 32");

There are setBlend() and setBlendColor() in the referances (at least they were in the beta), I never used them except for experimentations I belive they work still.

#2 @Robert: You can set the logical coordindates to match the window coorindates in a couple of lines of code. There's a post somewhere in these forums where we discuss that, can't remember it at the moment. Anthony answered the others.

Basically yes to all. :)

- Melv.

#3 What is you Camera set to?

#4 I belive the default is set to have a width of 100 and a height of 75 a 64 by 64 sprite might very well look as though it consumes the whole space. Try to set the sprite smaller or allow more space in the window with a wider FOV for the camera

#5 If you use: %player.setSize("64 64"); then the sprite is 64x64 world units, and not 64x64 pixels.

It took me a little while to get my head around this, but once you do, you realise the benefits. I played around with various size settings for my sprites until they looked in proportion to the screen. Once you've figured out what that is and you set your sprite size, then the size stays relative regardless of resolution changes.

So at 640x480 your sprite is still the same relative size in the world as it would be at 1280x1024. A genius decision by the GG bods IMHO.

#6 @Robert: I think you're talking about the "pivot point" (or hotspot), but currently there doesn't seem to be support for moving it.

#7 Yes, I'm looking carefully at the decision to allow altering the pivot-point because it does have a rather severe impact on lots of physics calculations. I won't go there unless you guys force me (no pun intended). :)

- Melv.

#8 Assuming you're targeting an 800x600 screen size you could always set up your scene like this:

sceneWindow2D.setCurrentCameraPosition( "400 300 800 600" );

It should act a bit more like more traditional 2d engines that way. It was confusing to me at first too, but it's VERY flexible, and allows games to be resolution independant, which I like.

At least I think that works.. I haven't done too much scripting yet due to lack of time, and I just took some NyQuil.

#9 I'm having trouble with this idea also. I understand the benefits of the dynamic scaling but I'm concerned this is going to make design a pain. As Philip noted you kind of have to play around with sizes to get things to look right... thats fine for a few sprites but an entire scene get's quite messy in a hurry. HOWEVER, I havent worked with it enough to really know for sure but I'm just basing this on what I think it will be like doing art for a game in T2D.

Maybe a fixed camera position and lack of available resolution settings isn't the end of the world. I dont think most "casual" 2D games have much more than a windowed/fullscreen implementation anyway...

#10 @Pete111: No, no, no ... you don't understand. T2D doesn't fix anything. T2D gives you complete choice.

Okay, imagine another 2D engine if you will....

The coordinates you use are (0,0) at the top-left and the resolution in the bottom-right, say (800,600). You design your game to work in pixels and everything is good.

The user changes the resolution to 1600x1200 and your game still renders to (800,600). So you say, well I have some variables that look at the resolution and I change the limits of all my objects, where my center is, where my enemy appear. Boy, what alot of fuss over something not under your control.

Then comes T2D that says, choose your own logical coordinate system. Have any coordinates you want. Now you can use a standard coordinate system that automatically scales your graphics for the resolution with absolutely no changes to your code whatsoever.

Then someone says, but I don't want that, I want my old method where I have coordinates mean pixels. T2D says fine then, do this:-

// When the T2D window has changed...
function sceneWindow2D::onExtentChange( %this, %newExtent )
{
    // Set my view to be the Screen-Resolution
    sceneWindow2D.setCurrentCameraPosition( "0 0" SPC %newExtent );
}

Wow!

Okay, can I have it really old-school and have the (0,0) view at the top-left? Yes, just use...

// When the T2D window has changed...
function sceneWindow2D::onExtentChange( %this, %newExtent )
{
    // Set my view to be the Screen-Resolution
    sceneWindow2D.setCurrentCameraArea( "0 0" SPC %newExtent );
}

.. instead.

T2D allows you to work how you want. We've tried to make as few assumptions as possible that'll impact the way you make your games.

- Melv.

#11 LOL.

Nothing to forgive guys, you purchased T2D, you deserve value for money. :)

- Melv.

#12 @Melv: I'm certainly not complaining it's just going to take time to get used to the added functionality more than anything. You're right, I'm used to a more old school design strategy....

Regarding the image registration point - I can see setting a rotation point but not a movable origin for the individual image.

Wow, it's gotta be hard for you guys to decide how much "functionality" to add and where to let people just code the desired effects. Anyway, keep up the good work.

#13 As Melv once suggested, you can "simulate" a pivot point offset by making your sprite longer, effectively placing the point at the end of the sprite and leaving the rest transparent/invisible. Maybe that requires an image to truly understand, but it seems like it would work ok without resorting to changing the guts of the physics system.

#14 Out with the old, in with the new

T2d is really cool

Someone shoot me in the face

#15 Jason has a good point... you could even have different versions of the image if you really needed ones with different pivot points... shouldn't be too hard to work around that one thing :)

#16 @Robert: Not sure why you'd need lots of different images for the same object. Any object would only naturally rotate around a drawn point. The arm of a player, a gun-turret etc. My original post was saying that the image in the frame should be positioned so that the pivot point is in the center.

I've kinda gone over this a few too many times and perhaps I've not explained the situation very well so here's a graphical example; there's no hardship here.

If you've got an object like this and you mount it, it would rotate around the center of the object (marked with a yellow cross) which isn't what you'd want as you want it to rotate around the little dark-grey disk so you'd simply organise your graphic like this and it would rotate around the correct point.

If you've got a single image and you want to rotate it around lots of different points on the image (cannot think of a reason to do this), only then would you need seperate art.

Until this is changed, stuff rotates around the images center. You can mount it to any point on the target object but it will always rotate around its center. As I've mentioned in other posts, rotating around any point other than the center adds complexity to the physics routines and I'll be looking at efficient methods to get around this. I won't just leave it as it is. It's EA guys. ;)

If this is totally unacceptable then there's an alternative but it involves an extra object. Don't forget that you can generate a fxSceneObject2D as these don't render anything but have all the core capabilities. You can mount this to the position on the target object and mount your object to this offset by a constant like "1 0" or whatever you like. The size of the invisible fxSceneObject2D then determines the offset from the center of the image.

Here's a code example...

t2dSceneGraph.setDebugOn( BIT(1) );

// Create base sprite we want to mount to.	
new fxStaticSprite2D(testSprite1) { scenegraph = t2dSceneGraph; };
testSprite1.setSize( 10 );
testSprite1.setImageMap(tileMapImageMap);
// Move it so we can show we're mounted and not faking it.
testSprite1.setLinearVelocityX( 1 );

// Create hidden mount (articulation frame).
new fxSceneObject2D(hiddenMount) { scenegraph = t2dSceneGraph; };
// Use this size to control the offset.
hiddenMount.setSize( 10 );
hiddenMount.setAutoRotation( 90 );
hiddenMount.mount( testSprite1, "0 0", 0, false );

// Create our object we want to mount.	
new fxStaticSprite2D(testSprite2) { scenegraph = t2dSceneGraph; };
testSprite2.setSize( 10 );
testSprite2.setImageMap(tileMapImageMap,1);
testSprite2.mount( hiddenMount, "0 1" );

Here's an example of that working...

Hope this helps,

- Melv.