Pixels not lining up in editor. 640x480

[Moox]

I am currently making a a turn based strategy game with the AGS editor similar to Final Fantasy Tactics. While looking through possible ways to handle movement/ranges I was experimenting with objects, characters, and raw draw. What I noticed however is that the editors positions things off by a pixel occasionally. To illustrate what I mean here is a sample background I made real fast.


The above is an image that will show up in the grid depending on if the area is within range of attack. Now when trying to place that shape within the background grid such as the stairs it sits 1 pixel above the outline. When it is moved down in the editor by one pixel the actual image moves down by 2 making it impossible to line up the shape with the identical grid space. I feel this problem may occur due to the 640x480 resolution. Is there a workaround for this issue?

If my problem isnt really clear I can get some screens from within the editor while working with objects.

[monkey0506]

Presumably this would be due to AGS's internal co-ordinate system which is always 320x240 resolution, and the sprites being scaled up if your game's resolution is higher.

However, if you're not too deep into game development, you might consider porting your project to the new version of AGS, AGS 3.0. It's currently in the 'release candidate' stage, basically a post-beta, pre-release stage where any remaining major bugs are worked out and soon to be released as the new official version of AGS.

AGS 3.0 introduces the DrawingSurface type to replace the old-style 'RawDraw' family of functions, with the DrawingSurface.UseHighResCoordinates property, which should allow for pixel-perfect alignment for your high-res game.

If you were previously doing something like this:

Code: ags

// do highlight
RawSaveScreen();
RawDrawImage(X, Y, SLOT);

// remove highlight
RawRestoreScreen();

The new code would look something more like this:

Code: ags

// top of script
DrawingSurface *RoomSurface;
DrawingSurface *RoomSurfaceBackup;

// do highlight
RoomSurface = Room.GetDrawingSurfaceForBackground(); // get room background drawing surface
RoomSurfaceBackup = RoomSurface.CreateCopy(); // save copy of old background
RoomSurface.UseHighResCoordinates = true; // tell surface to use high-res coordinates
RoomSurface.DrawImage(X, Y, SLOT); // draw image
RoomSurface.Release(); // update room background

// remove highlight
RoomSurface = Room.GetDrawingSurfaceForBackground(); // get the room's drawing surface
RoomSurface.DrawSurface(RoomSurfaceBackup); // draw the old background
RoomSurfaceBackup.Release(); // and release both surfaces
RoomSurface.Release();

It's a bit more complicated than the old code, but that's partly due to the fact that the DrawingSurface methods work with room backgrounds AND dynamic sprites.

If you're interested in updating to AGS 3.0 and need any help updating the code, I'd be glad to help.

[Moox]

Presumably this would be due to AGS's internal co-ordinate system which is always 320x240 resolution, and the sprites being scaled up if your game's resolution is higher.

Thought it was something like that. I will look into updating to the new version. Do you know if the new drawing method extends into objects and character positions on a high resolution as well?

[monkey0506]

From what CJ told me, he's looking into implementing 'high-res co-ordinates' for other things if the DrawingSurface property proves useful. In other words, no. It's something he's considering for a future version, but for now it only applies to the DrawingSurface functions.

IIRC the way AGS scales it up, things like character and object co-ordinates would correspond to the top-left corner of a 2x2 square in a 640x480 game. If you can live with characters and objects being locked to these positions you should be able to pull it off.

[Khris]

How did you create the background image? I assume you've drawn it manually, right?
I ask because I've noticed some irregularities in the grid.

First of all, it's no true ISO grid, but it doesn't have to be, so that's fine.
The "stairs" near the pic's center are off by one pixel horizontally.
And all stairs are off vertically. The top coord of the stair tile is odd, and the height isn't at the middle of the big step.
That's why you can't place the highlight object correctly.

Here's an "ideal" ISO grid which fits nicely into a 16x8 standard grid:



I urge you to use a nicely manageable grid (mathematically, that is) from the start to avoid code problems later on.

[Moox]

The bg was made real fast just to illustrate the problem, nothing is final in it.

I used an angle of 29.74 degrees for the grid on these. Close enough to illustrate what I mean.

[subspark]

So your true background (the one your actually working with) is perfectly lined up and true to the grid?

Paul.

[Moox]

I haven't actually done any final artwork yet. Just basic outlines to begin coding which is the real challenge in projects like this. As long as the highlight and the grid are the same size however they should theoretically be able to line up flawlessly however the 640x480 resolution paired with the ags internal coordinate system at 320x240 makes this impossible. The fix Monkey pointed out in the new version of AGS seems to be the solution to the problem in terms of drawing the sprites to the bg.

[Khris]

however the 640x480 resolution paired with the ags internal coordinate system at 320x240 makes this impossible

I'm not 100% sure what exactly you're talking about, but this is simply not true. As long as you stick to even coordinates, be it position or size, everything will line up perfectly.

Suppose the highlight sprite is to add a 1px-wide border to a field. When cropping the sprite, simply add another 1px-wide line to all four sides, using the transparent background color. And before you know it, the sprite will line up perfectly again, no matter if it's going to be a character, an object, a GUI or rawdrawn.

There is absolutely no need to use fishy workarounds or to switch the engine version. Just keep your coordinates at multiples of 2.

[Radiant]

There is absolutely no need to use fishy workarounds or to switch the engine version. Just keep your coordinates at multiples of 2.

And also, your sprite sizes - because in some cases, it apepars that the coordinates are calculated from the bottom of the sprite.

[subspark]

Khris and Radiant are correct. These misalignments can be solved with careful consideration of spacing and placement in your painting package. I don't mean to defer you from your topic here but if you read the following thread you can see how Khris's method worked for my sprite production. I understate. It worked marvelously.

http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33099.0

Cheers,
Paul.

[hedgefield]

simply add another 1px-wide line to all four sides, using the transparent background color.

This is how I did it too. I've had this problem when I had taken sections of a background, changed them (like for instance a lamp turning on and off) and imported them as objects, they would never overlap with the original background perfectly. I usually solved it by adding an extra row of transparent pixels on one side, in effect padding the object's image.

[Moox]

Once again, the point of the matter is that the AGS engines internal coordinate system is made for lower resolutions. Adding rows of transparent pixels should not be necessary when working in high resolutions. I prefer monkeys suggestion as it does allow for the incorporation of both odd and even sprites rather then conforming to the latter.

[monkey0506]

There is absolutely no need to use fishy workarounds or to switch the engine version. Just keep your coordinates at multiples of 2.

Actually if you ask me, requiring the user to keep all co-ordinates to multiples of 2 (as well as keeping sprites to even-sized dimensions) in a "high resolution game" is one hell of a fishy workaround.

I didn't know it was possible doing it this way, I just knew that the soon-to-be-official* AGS 3.0 implemented reasonable means for 'raw draw'-ing properly in high-res games.


*If Chris can ever get us to stop demanding feature updates and let him work out any remaining bugs so he can release it!

P.S. CJ, Thanks for the amazing work you've done and are doing with this program!!!

[Khris]

Hm, proper ISO more or less requires using even hires coords and dimensions (due to the grid's 2x1 nature).

Anyway, I merely wanted to clarify that hires doesn't prevent things from lining up exactly. And considering the fact that mouse, GUI, etc. coords all use 320-coords, it's generally a good idea to do things right from the start when using hires.