Ancient language - World map

Started by
24 comments, last by Stainless 8 years, 1 month ago

Hello again. I come with completed routine. All works like a charm and I'm satisfied with it. However I'm always open to any improvement so if you find something that can be done better, please do not hesitate to suggest it here.
The AMOS' code is very simple and doesn't need any explanation except Screen Copy so I commented it in the code.


Procedure _WORD_MAP

Rem // Up Left corner of zoom (viewing area is 200x176 pixels)
X1=WORLD_X-100
Y1=WORLD_Y-88
Rem // Dn Right corner of zoom
X2=WORLD_X+100
Y2=WORLD_Y+88


Dim WORLD(5,5)

For CHUNK_X=0 To 5
For CHUNK_Y=0 To 5

WORLD(CHUNK_X,CHUNK_Y)=False

'// UP Left corner X1,Y1
If X1>CHUNK_X*400 and X1<(CHUNK_X+1)*400 and Y1>CHUNK_Y*240 and Y1<(CHUNK_Y+1)*240

WORLD(CHUNK_X,CHUNK_Y)=True

TX=X1-(CHUNK_X*400) : TY=Y1-(CHUNK_Y*240)
BX=X2-(CHUNK_X*400) : BY=Y2-(CHUNK_Y*240)
If BX>400 Then MX=BX mod 400 : BX=BX-MX
If BY>240 Then MY=BY mod 240 : BY=BY-MY

TMPX$=Str$(CHUNK_X) : TMPY$=Str$(CHUNK_Y)
_FNAME$="world_x"+TMPX$+"_y"+TMPY$+".iff"
Load Iff _FNAME$,3
Screen Copy 3,TX,TY,BX,BY To 1,0,0 : Rem // Screen #3 is a temporary buffer and #1 is the visible screen
Rem // Screen Copy (source screen),top x,top y,bottom x,bottom y To (destination screen),top x,top y

End If

'// UP Right corner X2,Y1
If X2>CHUNK_X*400 and X2<(CHUNK_X+1)*400 and Y1>CHUNK_Y*240 and Y1<(CHUNK_Y+1)*240
If WORLD(CHUNK_X,CHUNK_Y)<>True


TMPX$=Str$(CHUNK_X) : TMPY$=Str$(CHUNK_Y)
_FNAME$="world_x"+TMPX$+"_y"+TMPY$+".iff"

Load Iff _FNAME$,3
Screen Copy 3,0,TY,MX,BY To 1,(400-TX),0

End If
End If


'// DN Left corner X1,Y2
If X1>CHUNK_X*400 and X1<(CHUNK_X+1)*400 and Y2>CHUNK_Y*240 and Y2<(CHUNK_Y+1)*240
If WORLD(CHUNK_X,CHUNK_Y)<>True


TMPX$=Str$(CHUNK_X) : TMPY$=Str$(CHUNK_Y)
_FNAME$="world_x"+TMPX$+"_y"+TMPY$+".iff"
Load Iff _FNAME$,3

Screen Copy 3,TX,0,BX,MY To 1,0,(240-TY)


End If
End If


'// DN Right corner X2,Y2
If X2>CHUNK_X*400 and X2<(CHUNK_X+1)*400 and Y2>CHUNK_Y*240 and Y2<(CHUNK_Y+1)*240
If WORLD(CHUNK_X,CHUNK_Y)<>True


TMPX$=Str$(CHUNK_X) : TMPY$=Str$(CHUNK_Y)
_FNAME$="world_x"+TMPX$+"_y"+TMPY$+".iff"
Load Iff _FNAME$,3

Screen Copy 3
,0,0,MX,MY To 1,(400-TX),(240-TY)

End If
End If

Next
CHUNK_Y
Next CHUNK_X

End Proc

As I mentioned before I am going to use this method on just 2MB RAM Amigas. On those with extended memory I'll load the whole map into it so there will be no disk seeking.

Comments, suggestions - I'm around.

And let me thank again to those I quoted before and made use of their suggestions desismileys_4547.gif

Advertisement

Sure this works?


If X2>CHUNK_X*400 and X2<(CHUNK_X+1)*400

I wonder what happens if X2 is a multiple of 400. (Trivial example: X2 is 0). My guess is nothing is loaded.

A second (and third) thing is that you have nested loops


   For CHUNK_X=0 To 5
       For CHUNK_Y=0 To 5

where you test for each combination (ie 36 cases, assuming value 5 is included as last iteration).

Your test for CHUNK_X are however independent of CHUNK_Y (See above "X2>CHUNK_X*400 and X2<(CHUNK_X+1)*400"). You do this test for each value of CHUNK_Y. since CHUNK_Y is not in this part, it gives you 6 times the same answer, so you are wasting 5 test value computations.

The simple improvement here is to do the above test before entering the CHUNK_Y loop. If it fails, it will fail for every value of CHUNK_Y, which means, you can just skip over the entire loop, and go to the next CHUNK_X value.

The more complicated improvement (but with much bigger gain) is to see that


For CHUNK_X=0 To 5
  If X2>CHUNK_X*400 and X2<(CHUNK_X+1)*400
    do_stuff(CHUNK_X) // ignoring Y for now.

is just "do_stuff(X2 div 400)" where "div" is the integer division.

[This depends somewhat on what should happen if "X2 == CHUNK_X*400", but that was my question above.]

In other words, there is no need to loop over chunks, you can derive the CHUNK_X (and similarly CHNUK_Y from Y2) by 2 simple "div" statements.


CHUNK_X = X2 div 400
CHUNK_Y = Y2 div 240

(Unless I am missing something, I haven't studied all the details.)

Sure this works?


If X2>CHUNK_X*400 and X2<(CHUNK_X+1)*400
I wonder what happens if X2 is a multiple of 400. (Trivial example: X2 is 0). My guess is nothing is loaded.


Yes, you're right. X2 sometimes is equal 0 and X1 in some cases has even less than 0. It happens when a pixel position is close to the edge or a corner. The code I posted above do not has such checking so when the X1 was getting 0 or a negative value it's was impossible to center the image (as non of the condition has been met). With additional lines of code every scenario I've checked always worked. And I did a lot f them to make sure.

A second (and third) thing is that you have nested loops


   For CHUNK_X=0 To 5
       For CHUNK_Y=0 To 5
where you test for each combination (ie 36 cases, assuming value 5 is included as last iteration).
Your test for CHUNK_X are however independent of CHUNK_Y (See above "X2>CHUNK_X*400 and X2<(CHUNK_X+1)*400"). You do this test for each value of CHUNK_Y. since CHUNK_Y is not in this part, it gives you 6 times the same answer, so you are wasting 5 test value computations.



CHUNK_X is not independent of CHUNK_Y. What's more, if I hadn't include the CHUNK_Y (and Y1/Y2) checking alongside CHUNK_X and X1/X2 the program wouldn't know which row is actually being checked. Those two loops give me 36 passes and each one is unique. I'm sure because I've literally looked at every pass (36 is not that much after all smile.png).

My loop checking looks like this:

first pass: X (0) Y (0)
0 to 400 and 0 to 240
next pass: X (0) Y (1)
0 to 400 and 240 to 480
next pass: X (0) Y (2)
0 to 400 and 480 to 720
...
next pass: X (0) Y (5)
0 to 400 and 1200 to 1440

Then X changes:

second pass: X (1) Y (0)
400 to 800 and 0 to 240
next pass: X(1) Y (1)
400 to 800 and 240 to 480

next pass: X(1) Y (2)
400 to 800 and 480 to 720
and so on...

Resuming: You're right those condition were incomplete in some cases - edges or corners, to be exact - but I've added what was missing.

(Unless I am missing something, I haven't studied all the details.)

Still thank you for dedicating time to analyze it.


2MB of RAM, 7MHz CPU clock with "simple" 2D graphic acceleration. Amiga's Blitter chip

sounds cool. i started on a 8088 8mhz sperry rand PC w/ _TWO_ 360K floppies (ooh and ah!), a whopping 64K of ram (that was a lot [the max?] back then), and a CGA card (pretty much state of the art). i was doing a text mode d&d game, with some 3d vector drawn still graphics as well. written in basic. it had something like 23 overlay files 'cause all the code wouldn't fit in ram at once.


320x256 at 64 colors

yeah, amiga's always were nice units compared to other PCs.


It has main loop it works on so there is some fps.

turn based, so FPS shouldn't be an issue, unless you do animated moves like total war does when you move an army on the strategic map.

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

sounds cool. i started on a 8088 8mhz sperry rand PC w/ _TWO_ 360K floppies (ooh and ah!), a whopping 64K of ram (that was a lot [the max?] back then), and a CGA card (pretty much state of the art). i was doing a text mode d&d game, with some 3d vector drawn still graphics as well. written in basic. it had something like 23 overlay files 'cause all the code wouldn't fit in ram at once.


That sounds cool too. Although, I was in love from the beginning in C64 and then Amiga (but my first one was ZX Spectrum 48K). 3D vector on 8088 was... WOW, you've started programming as an infant, and straight to the three dee? Impressive.

320x256 at 64 colors

yeah, amiga's always were nice units compared to other PCs.


Indeed, but stopped at some point so almost all abandoned it. I'm happy to be between those who still find it interesting. And programming on Amiga is really fun and challenging.

It has main loop it works on so there is some fps.

turn based, so FPS shouldn't be an issue, unless you do animated moves like total war does when you move an army on the strategic map.

Not really. As I mentioned before it's an economic game. However there will be animated, but completely irrelevant to the game itself, parts of the screen - just a fancy effect. The fluency of these elements depends on the fps. Shouldn't be a problem because AMOS has a built in another language dedicated to stuff like it called AMAL (Animation Language). It has practically direct access to Amiga's hardware so gives the programmer and the end user really nice speed.

There was an attempt to re-launch Amiga a few years ago, but more as an OS than as hardware.

It was based on Taos, which I worked on, and was brilliant.

They had no funding really so only one guy was left working on it (Andy Stout I believe)

This topic is closed to new replies.

Advertisement