An algorithm problem


Jon

Still Fresh
Joined
Sep 7, 2010
Messages
11
Location
Scotland
I am trying to make an algorithm that reads in basic map data and basically scales it so it will display objects properly on another platform. It only deals with X,Y co-ordinates and its a side scrolling game.


All it really has is simple obstacles that you avoid. But they are drawn at a different size on the other platform. So origionaly their drawn at 40x40 pixels but on the target their drawn at 50x50. The Y value is no problem because its a simple conversion:


If Y = 0 then Y = 500 on the target (you have to reverse the Y but not the X so dont worry)


If Y = 40 then Y = 450 on the target. Basically 500-(40*1.25)


But their is the problem, you cant simply multiply the X value as its constantly increasing as the level plays. The height will always be in the same range but not the length. And the distance between the blocks is important.


A basic example would be


Original map data::


object(1000, 0);


object(1162, 40);



object(1352, 40);



object(1542, 40);



object(1704, 80);



object(1866, 120);



object(1906, 120);



object(1946, 120);



Target map data::


object(1000, 500);


object(1215, 450);



object(1475, 450);



object(1735, 450);



object(1950, 400);



object(2165, 350);



object(2215, 350);



object(2265, 350);



Now I've tried a number of things, looping through the data trying to shift each object one by one depending on the position of the others, but I cant some to get it to work.
 
I am trying to make an algorithm that reads in basic map data and basically scales it so it will display objects properly on another platform. It only deals with X,Y co-ordinates and its a side scrolling game.


All it really has is simple obstacles that you avoid. But they are drawn at a different size on the other platform. So origionaly their drawn at 40x40 pixels but on the target their drawn at 50x50. The Y value is no problem because its a simple conversion:


If Y = 0 then Y = 500 on the target (you have to reverse the Y but not the X so dont worry)


If Y = 40 then Y = 450 on the target. Basically 500-(40*1.25)


But their is the problem, you cant simply multiply the X value as its constantly increasing as the level plays. The height will always be in the same range but not the length. And the distance between the blocks is important.


A basic example would be


Original map data::


object(1000, 0);


object(1162, 40);



object(1352, 40);



object(1542, 40);



object(1704, 80);



object(1866, 120);



object(1906, 120);



object(1946, 120);



Target map data::


object(1000, 500);


object(1215, 450);



object(1475, 450);



object(1735, 450);



object(1950, 400);



object(2165, 350);



object(2215, 350);



object(2265, 350);



Now I've tried a number of things, looping through the data trying to shift each object one by one depending on the position of the others, but I cant some to get it to work.

counter=0.01;


x*1.25+counter


with counter increasing as the map scrolls?
 
I don't really see where the problem is, because imo you CAN simply scale the X value.


Take for example (numbers have nothing to do with your example) you want the player to encounter several objects: One after he travels one screen, one after 1.5 screen lengths and one after 1.75 screens.


On your first target the screen is 1000 pixels wide, on your second target the screen is 1900 pixels wide, which would result in a scaling factor of 1.9


Now on target 1 the first object should be placed at 1000 pixels, centred - on target 2 it obviously has to be at 1900 (one length of the screen on this target == length of the screen on the original target * scaling factor 1.9)


The second object has to go on pixel 1500 (#1) or 2850 (1500 * 1.9 = 1900 * 1.5).


That way the player encounters the obstacles at the same position in the game on each target - which should be the desired effect if I understood your first post correctly.


foxblock out
 
I should probably try explaining it a bit better with an image or two, but your replies have given me an idea I've not tried yet. So I'll try that first and see where I get :)
 
I should probably try explaining it a bit better with an image or two, but your replies have given me an idea I've not tried yet. So I'll try that first and see where I get :)
I don't really see the problem either. I can give a little programmer's tip, though--keep the coordinates the same in both versions. For one version, do conversion of coordinates, but only within the graphics routines. Do NOT save any of the converted coordinates, so these conversions have absolutely no effect outside of the graphics routines.


So, for example, you could have a graphics routine to draw a block on screen. It could look something like this:


define MyDraw(X,Y,blocktype)


begin


Blit(blocktype,X*XSCALINGFACTOR,YORIGIN+Y*YSCALINGFACTOR)


end


At the top of your program, you define constants for XSCALINGFACTOR, YSCALINGFACTOR, and YORIGIN. Depending on what programming language you're using, and how you have implemented things, it will generally be more complicated than this. But the basic idea should be that you only do coordinate transformations for the actual drawing of things on the screen.
 
I am trying to make an algorithm that reads in basic map data and basically scales it so it will display objects properly on another platform. It only deals with X,Y co-ordinates and its a side scrolling game.

Jon, take Isaac's advice, but also, learn vector and matrix math, they'll make really complex mathematical problems really simple (and REALLY FAST) in the future.

I don't really see the problem either. I can give a little programmer's tip, though--keep the coordinates the same in both versions. For one version, do conversion of coordinates, but only within the graphics routines. Do NOT save any of the converted coordinates, so these conversions have absolutely no effect outside of the graphics routines.

Also, you should investigate Wolfire.com's Blog, specifically their linear algebra for game developers series.
 
Last edited by a moderator:
Back
Top