Print

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

[xboxisfinished]

Code: [Select]

Procedure GET_LAYER0[X,Y]
   Shared LAYER0_BASE,MAP_WIDTH,MAP_HEIGHT

   ' Check that we are within the array bounds
   If X<0 Or X>=MAP_WIDTH Or Y<0 Or Y>=MAP_HEIGHT
      RESULT=-1
      Pop Proc
   EndIf

   ' Compute the memory address of the X,Y location
   ADDRESS=LAYER0_BASE+(Y*MAP_WIDTH+X)*2
   RESULT=Deek(ADDRESS)
End Proc[RESULT]

Procedure SET_LAYER0[X,Y,VALUE]
   Shared LAYER0_BASE,MAP_WIDTH,MAP_HEIGHT

   ' Check that we are within the array bounds
   If X<0 Or X>=MAP_WIDTH Or Y<0 Or Y>=MAP_HEIGHT
      RESULT=-1
      Pop Proc
   Else
      RESULT=0
   EndIf

   ' Compute the memory address of the X,Y location
   ADDRESS=LAYER0_BASE+(Y*MAP_WIDTH+X)*2
   Doke(ADDRESS,VALUE)
End Proc[RESULT]
In the above function I want to add the following things under the layer_tile when I load them in Tiles.dat file:

Graphics Name = String$
Tile Name = String$
Tile Type = Integer
Graphics Number = Integer
Location: X,Y = Integer
Sound Effect = String$
Sound Stepped On = String$
# Animations = Integer
Graphics # / Animation = Integer

So for example when I call this function I want it to be like this:
While Eof()
   ` Do the necessary code from reading from file and set these Tiles layer
   Set_Tiles[X,Y,Graphics$,Tile$,Type, Graphics_Num,SoundEffect$,SoundSteppedOn,AnimationsNum,GraphicsNum]
Wend

How do I go about doing that? And when using GET_LAYER0[X,Y] how do I go about doing that? What I am asking is something like you see in BlitzBasic 2:

Type.l TileTypes
   Name$
   x
   y
   ....
   etc
End Type

[SamuraiCrow]

So far there is no equivalent other than banks with variables storing the offsets. 

[xboxisfinished]

So far there is no equivalent other than banks with variables storing the offsets. 

Understandable but I don't know how to implement banks with variables and storing offsets in the two functions I posted on the OP. Can you give me an example?

Thanks.

[SamuraiCrow]

OK, for starters, a string is a variable length structure in memory.  If all of the string variables are constants in the data file, you could set a fixed length for each string field and retrieve them with the peek$ function.  Once you've got the start and the length of the string, you know what the end address is since each character is a byte.  Just be sure to pad the length with at least one character extra for a zero byte to mark the end of the string.

The tiles are 16 bit so you need to give them an even address and a 2 byte size.  If the x and y coordinates are never going to be bigger than 65535, you could use 2 byte integers for them also.  Deek and doke are used to access those.

Lastly, loke and leek access 32 bit variables and poke and peek access single byte integers.

When arranging the bank structures, put the 4 byte integers first so they get placed on offsets that are multiples of 4 for best performance on a 68020+.  Next put in the 2 byte integers so they get even addresses.  Last put strings and bytes since they don't require any special alignments.  Make sure that the record length totals a multiple of 4 so the compiler doesn't choke.  This is accomplished using byte size pad values at the end.

If you want to store the banks in the executable, put the records in data banks.  If you want them external, use work banks.

I can give an example if you still need one.  Just let me know what you want in each size.

[xboxisfinished]

OK, for starters, a string is a variable length structure in memory.  If all of the string variables are constants in the data file, you could set a fixed length for each string field and retrieve them with the peek$ function.  Once you've got the start and the length of the string, you know what the end address is since each character is a byte.  Just be sure to pad the length with at least one character extra for a zero byte to mark the end of the string.

The tiles are 16 bit so you need to give them an even address and a 2 byte size.  If the x and y coordinates are never going to be bigger than 65535, you could use 2 byte integers for them also.  Deek and doke are used to access those.

Lastly, loke and leek access 32 bit variables and poke and peek access single byte integers.

When arranging the bank structures, put the 4 byte integers first so they get placed on offsets that are multiples of 4 for best performance on a 68020+.  Next put in the 2 byte integers so they get even addresses.  Last put strings and bytes since they don't require any special alignments.  Make sure that the record length totals a multiple of 4 so the compiler doesn't choke.  This is accomplished using byte size pad values at the end.

If you want to store the banks in the executable, put the records in data banks.  If you want them external, use work banks.

I can give an example if you still need one.  Just let me know what you want in each size.

I do need examples thanks because right now what I read right now went through my head...woooosh!

When it comes to name of the tile (string it can range from 1 length to 256 length) as the user will be entering the a tile name from the editor for the engine (in the future). The type is nothing more than an integer where 0 - space, 1 - obstacle, etc.

sound effect and sound effect stepped on are the ones that store the location of the file.abk and then there should be sound effect num where it plays that sound or music from the bank number. More work needs to be determined on this one but still a string is needed to get the file name and the location of the file.

that is how strings are worked on. The person should be able to add 65536 items, 65536 NPC, 65536 objects, etc. That is my intention.

[SamuraiCrow]

Sound banks can't have more than one active bank at a time.  It can store multiple samples in the bank though.

What is the difference between an object and an item?  There is a limit of 65535 banks in memory at once also.

[xboxisfinished]

Sound banks can't have more than one active bank at a time.  It can store multiple samples in the bank though.

What is the difference between an object and an item?  There is a limit of 65535 banks in memory at once also.

Side note: I made a mistake. i shouldn't be putting x,y coordinate in the tile.dat file. I should be putting it in the map.dat file. I need to write these down on paper first before I start coding:

If am limited with 65535 banks at ones then that is all I need. It is a lot of space. If I allow a person to add 255 tiles, 255 objects, 255 NPC, 255 events, 255 sound, 255 music I would have used 1530 out of 65535. I think with 65535 I can have fun and increase more than just 255 giving the user the ability to add decent amount of everything. I don't think in any game even a full blown RPG would need more than 255 anyways so 65535 is truly an over kill for me

In my game I will be having the following:

1) Tile (this is where I need your help to provide me an sample example in how to get the property of the tiles in a map from a file:
   a) Tile Name
   b) Tile type (0-Space, 1-Obstacle, etc)
   c) Graphics file: tiles.abk or whatever file name that stores the tiles
   d) Bank number from the tile.abk
   e) Sound effect (when someone is beside the tile, give the laval effect sound, etc)
   f) Sound effect stepped on (only triggers when someone is stepping on the tile)
   g) Max number of animation (for the tile)
   h) Bank number for that animation: 0,12,15,17,29,40, etc. (which I am thinking needed to be stored in an array as well or something...I don't know yet how to do this)

2) Map and their properties (plot name of the tile and it's x,y on map and use the tile.dat to obtain the property of that tile on the map, plot the event, objects, npc, etc)
3) Objects.dat
4) Events.dat
5) NPC.dat

etc...

Anyways if you can help me with an example of what I am looking for in the original post that will be great because I need to really think how I am going to do this on paper first. Then before I start coding, is it ok if I share what I wrote on paper here and ask your opinion if I am doing it right or wrong before I start coding?

Thanks.

[SamuraiCrow]

AmosPro uses a scripting language called AMAL for animations.  The scripts are stored as long strings or in an AMAL bank containing the strings.

Now for the example in the next post...

[xboxisfinished]

What example in what next post?

[SamuraiCrow]

Here's my next post!  Now for the example:

Code: [Select]

OBJECT_SIZE=0
NAME_OFFSET=OBJECT_SIZE
OBJECT_SIZE=OBJECT_SIZE+256
SOUND_NEXT_TO=OBJECT_SIZE
OBJECT_SIZE=OBJECT_SIZE+2
SOUND=OBJECT_SIZE
OBJECT_SIZE=OBJECT_SIZE+2
...
Once all the offsets are set and their sizes added to the size variable, you can allocate the bank with:

Code: [Select]

RESERVE AS WORK 1280, OBJECT_SIZE
To write the name to its offset, you do this:

Code: [Select]

POKE$ START(1280)+NAME_OFFSET, LEFT$(MYNAME$,256)
Then you can read it back with:

Code: [Select]

VAR$=PEEK$(START (1280)+NAME_OFFSET, 256,CHR$(0))
It's similar for 2 byte integers:

Code: [Select]

DOKE START (1280)+SOUND, 2


[Hungry Horace]

Omg... You know I had no idea there was a PEEK$ and POKE$ !!

I have been doing things the "long" way
with regards to strings in memory for a long time!!

It goes to show... We are always learning! Thank you SamC !

[xboxisfinished]

Here's my next post!  Now for the example:

Code: [Select]

OBJECT_SIZE=0
NAME_OFFSET=OBJECT_SIZE
OBJECT_SIZE=OBJECT_SIZE+256
SOUND_NEXT_TO=OBJECT_SIZE
OBJECT_SIZE=OBJECT_SIZE+2
SOUND=OBJECT_SIZE
OBJECT_SIZE=OBJECT_SIZE+2
...
Once all the offsets are set and their sizes added to the size variable, you can allocate the bank with:

Code: [Select]

RESERVE AS WORK 1280, OBJECT_SIZE
To write the name to its offset, you do this:

Code: [Select]

POKE$ START(1280)+NAME_OFFSET, LEFT$(MYNAME$,256)
Then you can read it back with:

Code: [Select]

VAR$=PEEK$(START (1280)+NAME_OFFSET, 256,CHR$(0))
It's similar for 2 byte integers:

Code: [Select]

DOKE START (1280)+SOUND, 2


Weee this is exciting I am going to fill my engine with poking and peeking hahahahahah!! Ok...* fans face * time to start having fun

[bruceuncle]

Take care using Poke$ as it doesn't put a null terminator on the string for you.  You have to specify one yourself.  So your code will work okay for the first string as banks are cleared to zeroes when they're created.  But any subsequent strings will give you scrambled results.
Just add the null terminator yourself using Left$(MYNAME$,255)+Chr$(0).  Note 255 not 256 so you don't go out of bounds with a long string.
The =Struc()= instruction would be easier and more efficient but has a bug for unsigned byte members (now on the list!).

Sent from my Lumia 800 using Tapatalk

[SamuraiCrow]

Take care using Poke$ as it doesn't put a null terminator on the string for you.  You have to specify one yourself.  So your code will work okay for the first string as banks are cleared to zeroes when they're created.  But any subsequent strings will give you scrambled results.
Just add the null terminator yourself using Left$(MYNAME$,255)+Chr$(0).  Note 255 not 256 so you don't go out of bounds with a long string.
The =Struc()= instruction would be easier and more efficient but has a bug for unsigned byte members (now on the list!).

Sent from my Lumia 800 using Tapatalk

If the length termination parameter works with peek$, you could still allow full 256 character strings with LEFT$ (MYNAME$+CHR$(0),256) I think...

[bruceuncle]

If the length termination parameter works with peek$, you could still allow full 256 character strings with LEFT$ (MYNAME$+CHR$(0),256) I think...

Quite right.  If the full 256 characters is important, that would work for both.  The Chr$(0) delimiter is essential as a terminator for anything less than 256 characters.

The =Struc()= instruction would be easier and more efficient but has a bug for unsigned byte members (now on the list!).

Bug fixed for V2.10 (it was a simple typo in the source - moved D0 to the return value instead of D3).

Apart from that bug, the reason I keep pushing the use of =Struc= is that it's much more efficient.  Okay, you have to put together an AMOS Equates files for it to work, but once it's understood how it works, that's pretty straightforward.  I just backup the original equates file (although that's also got typos in it from the Editor Commands equates!) and use one created just for what I want.  The advantages are:

• When AMOS verifies the program (the Test button, or when it's first Run) the equates file is loaded and the resulting values are calculated for every Equ, Lvo, Struc and Struc$ in the program.  AMOS then stores that value in the AMOS Token Data in the source for those instructions and sets a flag there to indicate that has been done.  (Some AMOS Tokens are followed by some extra word-length internal data which is filled in during the Test process.)
• Subsequent Runs of the program then recognise the flag in the Token's Data and use the value without any further interpretation.  This is much faster than even using variables as offsets.
• Due to the flags and values in the Token Data, the source may be distributed without the recipient needing the original AMOS Equates file.
• The program source is much easier to read.

The disadvantages are:

• If the recipient of a source using Equ, Lvo, Struc or Struc$ changes the source, they may inadvertently force a re-evaluation, which requires the original equates file.  Which they won't have!
• To change any equates already evaluated in a program (eg. if you modify the equates file) there's no command to do it.  The easiest way is to Select All, Cut and then immediately Paste.  This forces AMOS to retokenise and the equates will re-evaluate next Run or Test.  Doing this to the entire program is not recommended if there are any Machine Code Procedures in it for obvious reasons!  Just do it to the lines affected in that case.
• Whilst =Struc()= is useful as it allows Byte and Word data sizes, =Struc$()= is really only useful for Amiga System calls.  Reason being that Struc$()= expects an AMOS-format string but =Struc$() expects the "result" to be an address pointing to a null-terminated string.  This can be made to work using a string buffer in the structure plus a long pointer to its starting address (use Poke$ for the buffer and Struc()= for its pointer).  Then =Struc$ can be used to read the string back with no problems.
• A buffer is needed for =Struc$()= as it will use the AMOS string space otherwise.  If a string garbage collection occurs, the pointer will be invalid with possibly disastrous results!  For it original intended use (Amiga System Calls) this is okay as the AMOS string space will not be updated while the call takes place.  It does mean that the loading and reading of the structure need to be done immediately before and after the call to avoid a problem.

Despite the above (which may be useful to some) AMOS definitely needs an equivalent to the Type definition available in other Basic dialects.  This is feasible as an enhancement down the track.  Awkward.  It will need additions to AMOSPro.Lib as that's the only library that allows "structural" instructions requiring Token Data.  That, in turn, means changes to the whole Tokenise, Detokenise and Verify code plus different variable storage.  Would be no use unless it at least also allowed arrays of types...