Acorn Arcade forums: Programming: Take two
| |
Take two |
| |
This is a long thread. Click here to view the threaded list. |
| |
|
Jeffrey Lee |
Message #63424, posted by Phlamethrower at 01:23, 17/3/2005, in reply to message #63422 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I can move it if you wish... Did you mean to post this in the '2's complement' thread?
No, the Programming section that you mentioned in your previous post.
Yes but that post was in the 2's complement thread was it not? 
It was Jason that said this thread should be here, not Andrew  |
| |
 [ Log in to reply ] |
| |
|
Richard Goodwin |
Message #63427, posted by rich at 08:09, 17/3/2005, in reply to message #63422 |
 Dictator for life
Posts: 6828
|
Actually I was responding to Jason's post, but it was the one immediately before mine.
________
 Cheers,
Rich.
|
| |
[ Log in to reply ] |
| |
|
Tony Haines |
Message #63442, posted by Loris at 17:30, 17/3/2005, in reply to message #63386 |
 Ha ha, me mine, mwahahahaha
Posts: 1025
|
... could you give us some idea of what sort of map you really want?
I think you want large caverns, but are there any other desires? ...As I said above I used trig. functions as I found it difficult to create the kind of map I was after, otherwise.
The sin and cos lookups (other post) that I am talking about are for something else in the program. The map generator I have ended up storing the result of as a 36K table as I said above. The intention was to create the map on-the-fly but the trig. functions I feared would slow it down too much (although yes I could have a lookup).
The kind of map I was aiming for was shafts and tunnels with caverns but I'm fairly happy with the map personally. However I was going to ask you today about how in Exile bits of scenery might have been generated by the algorithm. Surely they weren't all stored in terms of positions?
If you are happy with the map then just keep it - there is no sense getting fixated on one small part of a program.
I'm kind of tempted to keep investigating this. It might make for an interesting Qercus article or something.
Regarding Exile's scenery, I think most of it was procedually calculated using tile coordinates, possibly dependent on the type of structure being created. If drawing a horizontal passageway, potentially draw a pillar, if a vertical passageway, determine whether to place a fern and so on.
I've occasionally examined the huge map sprite I pulled off the internet, and there is quite a bit to it - there must be lots of conditionals in there. Reverse engineering the algorithm used would be a real challenge. (Of course, it is more fun to make your own instead.) |
| |
[ Log in to reply ] |
| |
|
Tony Haines |
Message #63576, posted by Loris at 14:43, 22/3/2005, in reply to message #63390 |
Ha ha, me mine, mwahahahaha
Posts: 1025
|
He found that LDRs were affected by their addressing operands changing. This is different to what Acorn stated. Can't seem to access the website now, so I can't check.
OK, I'm only going on the documented performance in the datasheets. As an aside, the XScale makes it a lot easier to actually measure the performance of instruction sequences because of its lovely cycle counter
Does moving it beyond 2 instructions change anything? I understood that if it wasn't cached the processor would pause anyway.
TBH I'm not entirely certain. Logically there's no reason for the LDR to stall subsequent instructions unless they require the result, the updated base or the pipeline stage that the LDR occupies (ie. another LDR/STR op), though it could complicate exception handling.
I've now tested this, on StrongARM.
changing base address or offset doesn't make any difference.
Using result in next instruction is slower if cached. Rough calculations were that this was consistent with it costing one cycle.
If not cached, it makes absolutely no difference.
Although on second thought it might in the case where it is the last word of a line loaded.
Maybe I got the wrong end of the stick : perhaps Icebird found moving data away from the destination slowed matters:
MOV R0,R1
LDR R1,[R2]
I'd better test this...
Or maybe it is just different on SA.
Code available on request. |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #63594, posted by adrianl at 03:19, 23/3/2005, in reply to message #63576 |
Member
Posts: 1637
|
Using result in next instruction is slower if cached. Rough calculations were that this was consistent with it costing one cycle.
If not cached, it makes absolutely no difference.
Although on second thought it might in the case where it is the last word of a line loaded.
My understanding is that only an attempt to use the data in the next cycle after the LDR is executed causes a pipeline stall, ie. you can't, the interlock will delay one cycle anyway.
Since any external fetch is going to take longer than 1 cycle, whether the pipeline stalls for a single cycle, because you've used the result in the next instruction rather than next-but-one, is irrelevant. It still pays, I'd imagine, to postpone use of the loaded data for as long as possible to avoid incurring any delay at all.
I've been promoting LDRs wherever possible and interleaving independent calculations to avoid stall cycles for many years now, so that:
(i) my code should be faster if ARMs ever become superscalar.
and (ii) my assembler is harder to read 
Hence, I tend to reserve its use to code that's performance-critical (and then, it would appear, choose projects where performance is critical! )
Maybe I got the wrong end of the stick : perhaps Icebird found moving data away from the destination slowed matters:
MOV R0,R1
LDR R1,[R2]
I'd better test this...
I'd be extremely surprised if it was. No ARM pipline that I know of is that complicated, thank goodness. Decoding and collecting register operands (R1 in the case of MOV R0,R1) is done earlier than writeback of results (R1 in LDR R1,[R2]) so you'd really need parallel pipelines for that case to require an interlock, especially given that MOV R0,R1 is a much simpler/faster instruction than LDR.
IIRC that's called an 'anti-dependency' BTW.
[Edited by adrianl at 03:26, 23/3/2005] |
| |
[ Log in to reply ] |
| |
| Pages (2): |< <
2
|
Acorn Arcade forums: Programming: Take two |
|
