Other BBSes »
| |
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
Atari demoscene BBS
| Re: Doom floor texturing |
|---|
|
Posted by: dml
|
Jan,22.2013-15:18
|
Great stuff!
I didn't yet measure the cost of copying words directly off the host port to RAM (I was planning to stuff that test into the new Nembench this year) with it's byte oriented transfers - despite using it pretty much all the time for less heavy traffic. I figured it wouldn't offset a few ALU ops on the 030 but that must be wrong. Will need to play with it now...
So far I had been interleaving ALU ops with the tex read and display write, since you can hide 1 or 2 cached ALU ops behind each memory access. However I forget the details now and will need to repeat the measurements to see how far that hiding goes. I was surprised to see that behaviour at all on the 030 but it does exist - just not very deep. Having a tiny CPU-side texturing operation does mean good unrolling too so that's handy.
Do you perform the whole UV/Z solving on the DSP for perspective correction, per pixel, or is it normally a mix of affine mapping and occasional correction? I expect the host transfer can absorb at least one full divide and maybe two partials? I seem to get a lot of DSP ops executed for each word the CPU can lift....
BTW on the d-cache front. I was going to set up a small MMU driver (maybe auto folder based) which rebuilds the page tree using large pages and shadows the entire 16MB at some silly high address, and sets the cache inhibit bit within that space. I can then just set the relevant bits in the display address to stop the display memory polluting the data cache.
I did this stuff before on the 040 but only because I had to write a new 040 PMMU driver anyway to get my machine to work properly! In this case it would just be a patch to speed up Doom in a nasty way for those brave enough to install it :-)
The d-cache is really poor on the Falcon bus but I think I can still get mileage out of it with some care. My Doom code is a little faster with it on (only a little) but mainly because the textures are reoriented to the preferred scanning axis, and there's a fair bit of scaling up involved in large areas. However I should be careful not to trust it too far and will be doing a lot of experiments with freezing and just turning it off completely in places.
,
Thx again - great to have the kind of feedback. I'm making creeping progress and the FPS is rising slowly but relentlessly :) all of this input will help over time.
|
[All messages in this thread] [Start new thread]
|
Topic
|
Posted by
|
Date
|
|
Doom floor texturing
|
dml
|
Jan,21.2013-18:47
|
|
Re: Doom floor texturing
|
dml
|
Jan,21.2013-18:48
|
|
Re: Doom floor texturing
|
dml
|
Jan,21.2013-21:33
|
|
Re: Doom floor texturing
|
Defjam
|
Jan,21.2013-21:44
|
|
Re: Doom floor texturing
|
dml
|
Jan,21.2013-22:38
|
|
Re: Doom floor texturing
|
dml
|
Jan,22.2013-10:48
|
|
Re: Doom floor texturing
|
mikro
|
Jan,22.2013-11:03
|
|
Re: Doom floor texturing
|
dml
|
Jan,22.2013-11:43
|
|
Re: Doom floor texturing
|
mikro
|
Jan,22.2013-13:30
|
|
Re: Doom floor texturing
|
mikro
|
Jan,22.2013-13:36
|
|
Re: Doom floor texturing
|
mikro
|
Jan,22.2013-13:37
|
|
Re: Doom floor texturing
|
dml
|
Jan,22.2013-15:18
|
|
Re: Doom floor texturing
|
mikro
|
Jan,22.2013-16:22
|
|
Re: Doom floor texturing
|
dml
|
Jan,23.2013-00:55
|
|
Re: Doom floor texturing
|
mikro
|
Jan,23.2013-10:12
|
|
Re: Doom floor texturing
|
dml
|
Jan,23.2013-13:00
|
|
Re: Doom floor texturing
|
Calimero
|
Jan,24.2013-03:14
|
|
Re: Doom floor texturing
|
ggn
|
Jan,22.2013-16:41
|
|
Re: Doom floor texturing
|
ggn
|
Jan,22.2013-16:42
|
|
Re: Doom floor texturing
|
dml
|
Jan,23.2013-01:07
|
|
Re: Doom floor texturing
|
dml
|
Feb,03.2013-20:23
|
|
Re: Doom floor texturing
|
mikro
|
Feb,03.2013-22:07
|
|
Re: Doom floor texturing
|
dml
|
Jan,23.2013-18:01
|
|
Re: Doom floor texturing
|
mikro
|
Jan,23.2013-23:39
|
What's the anti-troll code?
That's your personal code to be able to add comments and messages on the dhs.nu site.
Don't have a code or forgot it? Fix it here.
|
