TFX on a PiStorm32

[Karlos]

Originally Posted by paraj

Thanks for testing! I'll apply this to all versions (also seems to at least be no worse on 060). Maybe a some more chip writes can be avoided... Might as well exhaust all (simple) opportunities while I'm at it

See, now you have caught the bug... the itch. This is what happened to me with TKG.

I am still interested in contributing here at some point but that will involve getting into WHDL.

[Don_Adan]

You dont need to create WHDload slave to catch bugs for HD installable programs/games.
You can use WB31 4 MB fast or 32 MB fast version.

http://whdload.de/apps/alla.html

[tomcat666]

Originally Posted by paraj

TFXAGA_RC2.7z in the zone (no optimizations, but all versions supported with sprite buffer in fast mem)-

So far with testing the 020 plain version everything seems to be working as before, no issues. Will be testing in the afternoon some more Need to start with a new pilot.
btw. there is a cool cheat ... while in game hold down SHIFT key and type "PLOP" ... you will be invincible and will always go to next level after the crash. Cool for testing stuff.

[sokolovic]

Have someone tested it on the A500 mini ?

[paraj]

RC3 in the zone. Just minor stuff:
- Frame rate is now displayed as actual FPS to avoid confusion (NOTE: it's heavily lowpass filtered so takes a little while to stabilize)
- Optimize sprite copy a bit
- 060 unimplemented integer instruction optimizations applied for other variants

I also made an effort to try and get "TFX.020" quicker on 060 since jotd done a great job in trying to it fast with FPU patches, but it's made VERY hard by stupid section merging..
It just seems like too much of a hassle, but feel bad about just always recommending plain 020 version, and think there is some potential in the FPU variants. If they're missing essential features it doesn't seem worthwhile to continue though.

Basically I'm asking: Does it make sense to spend time optimizing versions other than the plain 020 one?

FPS from level flight in arcard mode (after FPS has stabilized, PAL on 060/50):

TFX:
  New: 15-16
  Orig: 8.8
TFX.FPU:
  New: 14-15
  Old: 8.5
TFX.020: Hunk merging hurts :(
  New: 11-12
  Old: 7.4
TFX.040:
  New: 16-17
  Old: 9.1

[tomcat666]

Originally Posted by paraj

Basically I'm asking: Does it make sense to spend time optimizing versions other than the plain 020 one?

To me the visual addition of lights makes the plain 020 the only one worth playing really. I just love that, without that everything seems so empty. So, if there is a vote, I would vote to keep plain 020 only.
Anyone knows of any other differences worth mentioning between the versions?

RC3: on pistorm32 I get :

TFX: 17-24 (level flight at 18.5)
TFX.040: 17-19 (level flight at 18.6)

For some reason the plain ol' TFX seems to run the best on it

[Karlos]

It looks like the 020 version is the most feature complete and the most in need of performance optimising. That seems like a good reason to focus on it.

[paraj]

Thanks, no point in spending more time on the FPU variants then (they'll continue to be supported, but I'll recommend to jotd that they shouldn't be selected automatically).

Think this is pretty close to release, but I wonder why I can't get to one frame even with JIT enabled in WinUAE (or on PIStorm). Not that I need to press this further, but now it's getting annoying

[Aardvark]

The FPS counter is confusing. 24+ with max detail, but sub 20 with minimal detail.
[ Show youtube player ]
Anyway I don't notice any speed difference between 040 and 020 even when running TF1260 at 50mhz.

[abu_the_monkey]

its not an fps counter, smaller numbers are better.

[Aardvark]

Originally Posted by abu_the_monkey

its not an fps counter, smaller numbers are better.

Think you missed this:

Originally Posted by paraj

RC3 in the zone. Just minor stuff:
- Frame rate is now displayed as actual FPS to avoid confusion (NOTE: it's heavily lowpass filtered so takes a little while to stabilize)[/CODE]

[abu_the_monkey]

Originally Posted by Aardvark

Think you missed this:

yep, totally did.

it must not be working correct if you get higher fps by upping the detail.

[paraj]

FPS display is just best effort. It's based on number of vblank ints since last update + CIAB TOD count (which is reset by graphics.library), and will be off by off by some amount.

FPS reliably goes up on 060 with lower detail level. Wouldn't read too much into this variation, but it could mean that some of my replacement functions are doing worse than expected on PIstorm, so not useless information.

Guess I'll have to use proper EClock method for final version

[tomcat666]

I am sorry if this is obvious, was just searching with guugl on the subject of memory copy and stumbled on this:
https://hackaday.io/project/6150-bec...ine-comparison
Seems by using movem to copy 12 long words in two ops the copy is twice as fast.
Didn't see it being mentioned in this thread, sorry if you already use this.

[Karlos]

If the planes are cache aligned, there could be some benefits of move16 on 040+. Chip ram write will be saturated already but you will get a non cache polluting read. Not sure if it will make any real difference here though.

[Angus]

Originally Posted by Karlos

Not sure if it will make any real difference here though.

OTOH...... Cyber Assault 556!


(obscure The One Amiga reference)

[Karlos]

Originally Posted by paraj

Guess I'll have to use proper EClock method for final version

You may be able to get away with a lap timer implementation that only needs one ReadEClock per frame. This is what I ended up with in TKG.

The downside is that suddenly everyone's reported FPS was lower because the previous version had gaps where code was executing outside the timed interval. Lower as it was, it is more accurate.

[paraj]

I am sorry if this is obvious, was just searching with guugl on the subject of memory copy and stumbled on this:
https://hackaday.io/project/6150-bec...ine-comparison
Seems by using movem to copy 12 long words in two ops the copy is twice as fast.
Didn't see it being mentioned in this thread, sorry if you already use this.

Thanks, it's not obvious at all. Linked post is mostly about plain 68000 (which is also interesting!), but on 020+ it's usually about the number of other operations you can squeeze in while the chip ram stores finish. This is especially important if you're doing a C2P (copy speed C2P's are all about doing C2P work while the writes are performed "in the background")

If the planes are cache aligned, there could be some benefits of move16 on 040+. Chip ram write will be saturated already but you will get a non cache polluting read. Not sure if it will make any real difference here though.

Haven't tried, but I doubt there will a benefit. Caches are naturally trashed anyway since we go from the rendering phase to the "update game logic" phase, and 060 caches are tiny.

You may be able to get away with a lap timer implementation that only needs one ReadEClock per frame. This is what I ended up with in TKG.
The downside is that suddenly everyone's reported FPS was lower because the previous version had gaps where code was executing outside the timed interval. Lower as it was, it is more accurate.

It was already just a lap timer.

However.. Changing it to use ReadEClock I also revisited the update logic, and I realized I'd made a mistake. I'd unnecessarily wait for a vblank interrupt to have happened before starting the update, but that was slowing things down (slightly).
That part is removed entirely (and could in theory cause glitches on super fast JIT, but who cares).

So RC4 in the zone with the following changes:
- Rework update logic to not wait for vblank
- FPS counter is based on ReadEClock

Quick swimming video to show it on 060 (because I don't know to fly and therefore stall immediately): https://imgur.com/MvlI6g3
Seems to improve frame rate to the point where it doesn't drop into "bad" territory.

Could also be that I missed some subtle reason, but either way, seems to perform better so I'll take the easy win. Maybe won't improve things on PIstorm, but for sure shouldn't hurt.

[tomcat666]

Originally Posted by paraj

Could also be that I missed some subtle reason, but either way, seems to perform better so I'll take the easy win. Maybe won't improve things on PIstorm, but for sure shouldn't hurt.

Well, it improved things CONSIDERABLY ... we get around 24 FPS average now... unpossible thats a huge improvement:

[ Show youtube player ]

[Karlos]

Originally Posted by tomcat666

Well, it improved things CONSIDERABLY ... we get around 24 FPS average now... unpossible thats a huge improvement:

[ Show youtube player ]

Bloody hell, I hope your pilot had a good compression suit on at 0:40 I think he may black out otherwise.