Best way to do lots of moving things on screen?
Re: Best way to do lots of moving things on screen?
I did tests with the code given by Bugala here. Here are the results:
Mac Mini G4 1,5 GHz: about 4100 ms
PowerBook G4 1,67 GHz: about 14300 ms
PowerMac G5 2,7 GHz: about 11600 ms
That doesn't make sense. The slowest machine gets the best result?
Mac Mini G4 1,5 GHz: about 4100 ms
PowerBook G4 1,67 GHz: about 14300 ms
PowerMac G5 2,7 GHz: about 11600 ms
That doesn't make sense. The slowest machine gets the best result?
Re: Best way to do lots of moving things on screen?
very interesting and good you noticed that so I can tell to people in final release to take that into account.
By the way, I am about to make a new build which will have scaling turned on. I wonder if it will make any difference on yout G5 machine, since basically game is meant to be ran on 1920x1080 screen but you had 1920x1200 screen, with scaling engine on it might make some difference, although it could be just making it slower too.
By the way, I am about to make a new build which will have scaling turned on. I wonder if it will make any difference on yout G5 machine, since basically game is meant to be ran on 1920x1080 screen but you had 1920x1200 screen, with scaling engine on it might make some difference, although it could be just making it slower too.
Re: Best way to do lots of moving things on screen?
OK, some clarifying news on topic: It seems that "fresh install" (or fresh boot from installation media) MorphOS systems perform much better in this benchmark (and the game that Bugala is writing) than the ones working for a long time. As I get home today I'll boot my G5 off the USB stick and re-run the test.
- airsoftsoftwair
- Posts: 5443
- Joined: Fri Feb 12, 2010 2:33 pm
- Location: Germany
- Contact:
Re: Best way to do lots of moving things on screen?
I think the slowdown might be because Hollywood falls back to software double buffering because of a lack of video memory. This would also explain why it works on a fresh system but not on an established system because the fresh system might not have any programs consuming video memory running.
How much free video memory do your test systems, on which the program slows down, have available when you start the program?
For full HD double buffering Hollywood probably needs about 1920x1080x4x2 = 16588800 bytes free video memory. With some generous padding involved I'd say that anything less than 32 MB free video memory could make Hollywood fall back to the slower software mode
How much free video memory do your test systems, on which the program slows down, have available when you start the program?
For full HD double buffering Hollywood probably needs about 1920x1080x4x2 = 16588800 bytes free video memory. With some generous padding involved I'd say that anything less than 32 MB free video memory could make Hollywood fall back to the slower software mode
Re: Best way to do lots of moving things on screen?
I'm sure this isn't the case. I have quite a lot VMEM free when running the benchmark (about 220 MB - surely more than on a 64 MB Mac Mini). When running the Bugala's benchmark (changed to windowed 1680x1050) it drops to about 197 MB.
Re: Best way to do lots of moving things on screen?
This is a weird issue... I modified the test code a bit to open a small window (800x600) and to run the test first with software rendering and then with hardware rendering:
I don't see much difference between software and hardware double buffering on MorphOS, and actually on Mac mini hw rendering seems to be slightly slower than sw, but other way around on PB...
But the main issue here still is, that on my installed systems both outputs are massively slower than on fresh unmodified system. Here are the results on two machines when ran three times on each situation:
I tried to hunt this down earlier, but didn't figure out anything yet. Removing LIBS:Hollywood/ didn't make difference, removing all 3rd party libs didn't make difference, screen modes don't seem to make differences... and I had enough vmem available, over 100MB on PB and over 30MB on mini.
Here's the compiled exe of my source code: speedtest
Maybe we should also try to check if this happens with anything else too, if it's not just Hollywood's issue...
Code: Select all
EscapeQuit(True)
@DISPLAY {Width = 800, Height = 600}
CreateBrush(1, 5, 5, #WHITE, {hardware=False})
BeginDoubleBuffer(False)
StartTimer(1)
SetFillStyle(#FILLCOLOR)
For move=1 To 30
For a = 0 To 99
For b = 0 To 99
DisplayBrush(1, a*8 + move, 8*b)
Next
Next
Flip
Cls
Next
ConsolePrint("Software rendering:", GetTimer(1))
EndDoubleBuffer()
CreateBrush(1, 5, 5, #WHITE, {hardware=True})
ConsolePrint("Creating hardware brush", IIf(GetAttribute(#BRUSH, 1, #ATTRHARDWARE), "succeeded.", "failed."))
BeginDoubleBuffer(True)
StartTimer(1)
SetFillStyle(#FILLCOLOR)
For move=1 To 30
For a = 0 To 99
For b = 0 To 99
DisplayBrush(1, a*8 + move, 8*b)
Next
Next
Flip
Cls
Next
ConsolePrint("Hardware rendering:", GetTimer(1))
EndDoubleBuffer()
But the main issue here still is, that on my installed systems both outputs are massively slower than on fresh unmodified system. Here are the results on two machines when ran three times on each situation:
Code: Select all
Powerbook 1.67, live-CD/ISO:
Software rendering: 3087
Creating hardware brush succeeded.
Hardware rendering: 3052
Software rendering: 3495
Creating hardware brush succeeded.
Hardware rendering: 3070
Software rendering: 3332
Creating hardware brush succeeded.
Hardware rendering: 3077
Powerbook 1.67, HD installed:
Software rendering: 14962
Creating hardware brush succeeded.
Hardware rendering: 14400
Software rendering: 14814
Creating hardware brush succeeded.
Hardware rendering: 14309
Software rendering: 14984
Creating hardware brush succeeded.
Hardware rendering: 14415
Mac mini 1.5, live-CD/ISO:
Software rendering: 2966
Creating hardware brush succeeded.
Hardware rendering: 3387
Software rendering: 2960
Creating hardware brush succeeded.
Hardware rendering: 3374
Software rendering: 2963
Creating hardware brush succeeded.
Hardware rendering: 3372
Mac mini 1.5, HD installed:
Software rendering: 15369
Creating hardware brush succeeded.
Hardware rendering: 15730
Software rendering: 15208
Creating hardware brush succeeded.
Hardware rendering: 15750
Software rendering: 15306
Creating hardware brush succeeded.
Hardware rendering: 15829
Here's the compiled exe of my source code: speedtest
Maybe we should also try to check if this happens with anything else too, if it's not just Hollywood's issue...
Re: Best way to do lots of moving things on screen?
Well, I did a quick Q3 timedemo test and here are the results:
established: 102.6 FPS
USB boot: 114.3 FPS
Sure there's a 10% difference between results, but nothing as spectacular as in Hollywood benchmarks.
established: 102.6 FPS
USB boot: 114.3 FPS
Sure there's a 10% difference between results, but nothing as spectacular as in Hollywood benchmarks.
Re: Best way to do lots of moving things on screen?
Here are my results for your new speedtest:
Code: Select all
Powerbook 1.67, live-CD/ISO:
Software rendering: 3247
Hardware rendering: 3012
Powerbook 1.67, HD installed:
Software rendering: 12982
Hardware rendering: 13500
PowerMac G5 2.7 GHz, live-CD/ISO:
Software rendering: 3530
Hardware rendering: 4330
PowerMac G5 2.7 GHz, HD installed:
Software rendering: 10079
Hardware rendering: 10903
- airsoftsoftwair
- Posts: 5443
- Joined: Fri Feb 12, 2010 2:33 pm
- Location: Germany
- Contact:
Re: Best way to do lots of moving things on screen?
Ok, I've debugged it and this seems to be a major issue in MorphOS to me. If you add this line to the top of the script
the script will fly. So the bottleneck is in event handling and not drawing. After some further debugging I've noticed that a timer.device function is abysmally slow when called on a real installation whereas it's very quick when calling it from a live CD. I've just reported it to the MorphOS team so let's see what they say...
Code: Select all
DisableLineHook
Re: Best way to do lots of moving things on screen?
In the meantime Korni from PPA found that if you delete the TZ (timezone) variable in ENVARC: then everything gets back to normal (that is - fast) speed. Interesting...