Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Hungry Horace]

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

[SamuraiCrow]

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.

[Hungry Horace]

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

[SamuraiCrow]

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:

Code: [Select]

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

Code: [Select]

'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

Code: [Select]

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.

[Hungry Horace]

discussed at length in chat

i have a working procedure for it now, and will likely be implementing SamuraiCrows idea in the future.

[Hungry Horace]

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:

[SamuraiCrow]

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.

[Hungry Horace]

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.