View Single Post
Old 04 March 2018, 15:31   #8
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 3,419
Quote:
Originally Posted by gazj82 View Post
Every position is 32 pixels away from another one. I don't know what exactly the number are at the moment. But it is probably something like 10 horizontal positions and 8 vertical positions.

I think you mean I should store a 10x8 grid with data stored in each position of what directions are available in each.
Yep, that's it. It will also make it much easier to create new maps and levels in the future if that was a consideration. Have a routine to generate the bitmap based on a map that you load in.

Quote:
I guess this could be stored in a 4 bit word to cover all available positions.
Yep, one bit for each wall in any given square, and an array of bytes to store the map should work well.

Quote:
I can then lookup this table every time an enemy / player needs to make a decision about where to go next. Hopefully this would be quicker than testing a huge zone table.
Yep, it should be. Zones work well, but are much more fine-grained than you need really.

The code layout stuff is more for your own benefit really, it's something you'll curse when you go back to your code later and try to figure out how it works I recently recovered some of my old Atari 8-bit code from cassette, and it's horrendous! I have serious trouble understanding most of it. But your techniques are fine, some people struggle to display a sprite on screen so you're already doing well in that regard

Quote:
There are a lot of qwrap commands, mostly in the counters section. Again my self taught hobby coding lets me down and I really don't know what you mean when you mention your substitute.
Sorry, I mean instead of using QWrap, use a couple of If...Then statements to do the same thing with word types. Word and Long types take the same length of time (one transfer cycle) to transfer to/from RAM on an A1200, but on an A500 Long/Quick types take two transfers instead of just one for a Word type. So it can help a lot to limit operations to Word types. For example:


Code:
If var.w > 100
  var.w - 100
Else
  If var.w < 0
    var.w + 100
  End If
End If
I'm not sure how much speed it will gain in reality, but worth trying. Ideally you would replace that with assembly to have it super tight...


Quote:
Originally Posted by Master484 View Post
Another good speed trick is to minimize the amount of operations with NEWTYPE variables like " enemy(id)\x " , because they are lot slower than normal variables.
Quote:
I believe that the slowness of the Newtype variables is caused by them being "references" to variables, rather than actual variables. So every time the program sees stuff like "enemy(id)\x + 1" it first needs to do some processing to get the actual variable behind that newtype reference, and then it does the + 1 operation, and after this it stores the result back to the location where the "enemy(id)\x" is pointing at, which I think causes a second dereferencing operation, and so most CPU time goes into solving those references.
Hmmm... Well, I'm not so sure about this one. Newtype fields are actual variables, not references to them. The exceptions are strings and pointers of course, but that's a different story. If you dump the memory of a Newtype, you can see your actual data stored in there, and a simple check of the size of a Newtype when you change the type of one of the fields will show you that it changes to accommodate the new data type.

Slowdown isn't something I'd noticed before, so I ran a quick test. It's in WinUAE with an A1200/030 setup, running in "cycle exact" mode, so I appreciate things could be a little screwy, but anyway... This was my test code:

Code:
NPrint "Press Enter"
x$=Edit$(1)

NEWTYPE .test
  dummy.l
  sec.l
End NEWTYPE

DEFTYPE .test test

framecount.l = 0

SetInt 5
  framecount + 1
End SetInt

test\dummy = 10
dmy.l = 10
sec.l = 0

framecount.l = 0
For i.l = 1 To 1000000
  test\sec = test\sec + test\dummy
Next i

NPrint framecount
End
It gave me a repeatable result around the 375-379 frames range. I then changed the loop to use the discrete variables instead:

Code:
For i.l = 1 To 1000000
  sec = sec + dmy
Next i
This is giving me consistent results in the 558-562 frames range. So the discrete variables actually appear *slower* for me. Am I missing something here? They're all longwords, so I expect the results would be much higher on 16-bit-bus Amigas, but as far as I can tell, there shouldn't be a difference code-wise. Perhaps the Newtype helped by clustering the variables together in a single, cacheable lump, in which case results may well be different on a plain 68000.

Hmmmm, more investigation needed... Anyway, if it does help speed things up in certain circumstances then great, I haven't noticed any issues myself using Newtypes in arcade-style code (my issues come from a lack of game design creativity ).

Last edited by Daedalus; 04 March 2018 at 15:41.
Daedalus is online now  
 
Page generated in 0.04329 seconds with 11 queries