Ultimate Amiga
Network Boards => AMOS Programming Environment => AMOS Factory => AMOS BASIC => Topic started by: Hungry Horace on August 12, 2007, 11:56:46 PM
-
as a couple of you know, i'm building this map/data editor for the game Bloodwych, and i'm currently working on implementing the object editing routines.
i've been given some advice on translating the data, and have managed to sucessfully implement a routine which turns a single "reference" (index) number, into coodinates on the game map.
you can read the details here:
http://www.dungeon-maker.com/forums/showthread.php?p=212#post212
the index number, is literally where the game "counts" through the map-data....
index=1, is floor 0 , x=0, y=0 index=2 is floor 0, x=1, y=0 and so on.
oh course, to get this right, you need to know the height/width of each level... but thankfully this is supplied.
anyway, i've attached the code to perform this task correctly in AMOS, with a few comments included.
i was wondering if anyone might be able to help me work out how to achieve the "reverse" procedure in the most efficient way? the code attached is pretty short and i -hope- easy to understand.
anyway, anyone who wants to help out whilst im at work this week is more than welcome to!
*cough* skate */cough*
its probably a very short task for someone who can get their brain into logical gear! (something im struggling to do atm!)
thanks
-
Why not just use your existing formula to load your data into a 3d array and then just save the maximum X,Y,and Z coordinates and data to disk? The way you are doing it only makes sense in C++ where you can dynamically allocate a 1d array of the exact amount of memory you need.
If you insist on trying to save memory in Amos, Why not just load the maximum X and Y coordinates into a separate array and use a case statement to select from 8 2-dimensional arrays as you load the file in.
The reason I'm insisting on changing your working program to do it differently is because you indicated that efficiency is a concern. Using a loop to determine the start and end index of each level is a waste of processor time.
-
i think you are confusing what my exact problem is Samurai , for one thing I -HAVE- to be able to patch back in the original index number.... it's a game data-editor, and thats how that bit of original data is stored. currently i read the index number, and turn it back to coordinates to be able to "read" the data into the map viewer... the editor will have to patch any changed index numbers back in, before re-saving the original memory block as the game exe.
the "max" values for each floor are already stored into memory when the data block is read, so it should be possible to calculate any numbers needed pretty fast. (level sizes are contained in the map-header)
its not that i'm particularly trying to save memory / be efficient .... the problem is that counting through index numbers uniquely until they "hit" the location i am after is... well... bad coding!
there has to be a more effiective way of doing it, that doesnt take AMOS 30 odd sconds just to find one number.
for example, running it would look something like this:
input (level 3, x 10 y 20)
level=0 : counter=0
not target level : counter=counter+ map(0,x size) * map(0,y size) : inc level
level=1
not target level : counter=counter+ map(1,x size) * map(1,y size) : inc level
level=2
not target level : counter=counter+ map(2,x size) * map(2,y size) : inc level
level =3
target level
counter=counter+target Y * width
counter=counter+target x
index number=counter
im not sure.... but i think this would be how it would run, but of course, not how it would be coded
-
Here's a thought: instead of storing the whole map in an array, store each level in a fast work bank or, if you want it to be part of the executable, a fast data bank. That way you'll know where the start and end addresses are for each level without having to recompute all of that constant data each time you need to access the levels.
Here's an example code of how it should be loaded or copied to banks:
For LEVEL=0 To 7
` get next two entries either by reading them from a file or by looking in memory
` assuming they are in Data statements, I'm going to use the Read command to read them in
Read X,Y
`assuming bank 16 is used to store level 0, 17 for level 1, and so on.
`assumes also that each number used is less than 255
SIZE=X*Y
Reserve As Work 16+LEVEL, SIZE+2
Poke Start(16+LEVEL),X
Poke Start(16+LEVEL)+1,Y
For COUNTER=0 To SIZE
Read Q
Poke Start(16+LEVEL)+2+COUNTER,Q
Next COUNTER
Next LEVEL
Then you can calculate each position in the maps using
'calculate start address of the level
SADDR=Start(16+LEVEL)
TILE=Peek(SADDR+Y*Peek(SADDR)+X+2)
And then you could write to that position by using
SADDR=Start(16+LEVEL)
Poke SADDR+Y*Peek(SADDR)+X+2,TILE
Technically, you could use the Blength function to find the end address of the bank so you wouldn't need to store the Y index length at all, but that's another story.
-
discussed at length in chat :)
i have a working procedure for it now, and will likely be implementing SamuraiCrows idea in the future.
-
hmmm... SamuraiCrow: a quick "throwing" of my beta editor/viewer onto PSPUAE, and i suddenly realise i do have some reasons to save on memory!
the matters we discussed on avoiding the use of arrays is one that i -can- see happening if PSPUAE is going to continue to not have HDF support! (i have to fill RAM: up with the HD version & editor)
attached is an ADF of an incredibly beta and sketchy-dave version of the GUI... it's the PSPUAE build, which makes little difference apart from the text on screen atm. You need kickstart 2.0+ and a load of memory on uae to run this, but im uploading it to let anyone who is interested (skate?) see what im working on atm, and the shape it is taking.
p.s. this GUI rewards registered WHDLoad users with more functions. just put your keyfile onto a disk labelled DEVS: or L:
-
In that case, the plans on using array buffers and work banks would both be out of the question. I would still recommend using a single array to indicate the start addresses of each level map so you can Peek and Poke the values directly into the file being modified.
-
I would still recommend using a single array to indicate the start addresses of each level map so you can Peek and Poke the values directly into the file being modified.
this is what i was referring to....
im just going to have it do it all from the one bank-loaded game binary.