New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Grand Prix 2 does not run optimally #3211
Comments
Time Compression (video, lap): |
GP2 runs on dosbox-x as I remember from the old days on amd k6-2 with voodoo banshee and very similar to dosbox-staging only in VGA mode, i.e. running like this: |
Try to set |
I've already checked various settings. It also doesn't change anything. There is still a slowdown of 16%. After exiting GP2, the time spent in the game is displayed.
This is exactly how it should be. |
I checked it on completely different equipment. In the cloud under google cloud shell (GCS). The effect is very similar. In GP2 with SVGA, the game is slowing down - in this case by about 12%.
Despite its slower clock speed, 2.25GHz is almost to 2-2.5x faster than my old Intel Westmere clocked at 2.4GHz (2.6GHz with turbo). Linux perf is different.
|
Dosbox-x log data.
svga
Data collected with gallium mesa. About three minutes (a lot of data).
With the |
A few more observations. I found a lot of interesting information on the GP2 website at this address. The most important of them are:
From my side. Don't run GP2 under dosbox-x with After starting GP2, from the dosbox-x menu, select CPU -> Edit cycles and change to max. In my case, the key was not to use the button - With these settings finally GP2 works satisfactorily under dosbox-x in SVGA mode. I still don't know why GP2 performs less well under dosbox-x than it does with dosbox-staging and -SVN. Although this is still not obvious to me because in my case, GP2 it uses about 45-75% CPU anyway with dosbox-x. Contrary to popular belief, dosbox-x is not much slower than the other two, at least in my case. On my hardware, this dosbox-x in basic benchmarks - pcpbench, quake, doom is slower - maybe 15% at the most. The useful keys are: |
I did some testing, here. I had the game set for SVGA and max everything for Graphics detail with 21.3 frames/sec. In the Silverstone race I used an external stop-watch to time my race, which went poorly (spun out early on). I ended up with a paltry 5m24.776 for the 3 laps. According to my stop-watch it took 5m12, so a difference of roughly 12sec over 5 minutes. I pressed This is on an AMD Ryzen 5600X with Radeon RX590. edit forgot to mention, my display is running at 75Hz, so dosbox-x does not need to drop frames. |
Thanks for the tests. For me, under dosemu2, the processor occupancy in GP2 does not exceed 8% (Monaco) at the maximum settings. So what is not very playable because the acceleration is close to 20-30%. The main problem stems from the initial GP2 benchmark. These are the gp2log.txt values: SVN (cycles=max), estimated average frame rate >25.6 dosbox-staging (cycles=max), estimated average frame rate >25.6 dosbox-x ---- cycles=max 50000 180000 200000 edit: dosemu2 (linux) edit2: |
With all the graphic details set, the performance in the GP2 approaches the upper limit. Playable, but the power reserve is far too small. The host CPU load is in the range of 70-95%. gp2.dosbox-x.max.graphics.mp4 |
I close. The two main points are mainly related to the performance of the hardware on which we run GP2 or the inappropriate adjustment of the GP2 configuration in relation to the performance of the hardware. This game is quite a challenge for emulators. These individual remarks make sense. Especially regarding the underestimation of the GP2 benchmark with GP2 requires really strong hardware. This applies especially to moments in the game such as - the start (generally the first lap), a large amount of smoke, the load also depends on the track on which we compete, etc. It is good to read the information on the GP2 page mentioned earlier. |
Cause of invalid GP2 benchmark at In my case, the dosbox-x benchmark is usually: @rderooy Focus is lost. Stopping. Running GP2 with edit: |
This is the same case as with the Dimension demo. Dosbox-x then slows down unexpectedly. gp2.dosbox-x.slowdown.mp4Just as there, it was helpful to change the focus of the dosbox-x window, so does it here. This may be related to the code in the |
DOSBox-X and staging are fairly close to each other for CPU speed, but DOSBox-X records much higher video speeds. Also on exiting the game back to DOS, I notice some brief graphical glitches in DOSBox-Staging and DOSBox ECE that I don't see in DOSBox-X. DOSBox-X SDL1Starting the game in fullscreen with cycles=max Starting the game in fullscreen with DOSBox-X SDL1 results in a messed up display where the left 50% of the game screen is stretched to fit the screen (this may be SDL1 getting confused about my dual-screen setup). And the keyboard input is going to the terminal where I started the game from.
Starting the game in windowed mode with cycles=max
DOSBox-X SDL2Starting the game in fullscreen with cycles=auto
Starting the game in fullscreen with cycles=max
Starting the game in windowed mode with cycles=auto
Starting the game in windowed mode with cycles=max
DOSBox-StagingStarting the game in windowed mode with cycles=auto
Starting the game in windowed mode with cycles=max
Starting the game in fullscreen mode with cycles=auto
Starting the game in fullscreen mode with cycles=max
DOSBox ECE r4367Starting the game in windowed mode with cycles=auto
Starting the game in windowed mode with cycles=max
|
@rderooy I suspect you were running dosbox-staging like this: If you run like this, you will have a benchmark maybe 30% higher. Maybe dosbox-ECE was run with settings closer to the latter example. Maybe dosbox-x was running There are a lot of these nuances that affect the result (significantly). I try to take these details into account. Otherwise the results may not be reliable. edit: It makes no sense to test GP2 with |
@rderooy On the second, run dosbox-x with GP2. After GP2 starts, exactly when this sequence appears to lighten the graphics, very quickly move the pointer just outside the dosbox-x window and immediately return to the window area (you can do it twice). I can assure you that in 4-5 times you will see the benchmark result 30-40% higher (may depend on hardware?). |
@rderooy To understand this strange phenomenon, it's best to run under dosbox-x demo dimension. This one is more visible. The sequence of brightening the graphics takes a very long time. In GP2 it is very short (almost imperceptible). |
This GP2 benchmark anomaly looks something like this. Under the old version dosbox-x 0.83.15 SDL1 without opengl, but under it it was easier for me to reproduce and present it. gp2.dosbox-x.anomaly.mp4I am very familiar with dosbox-x's overall performance versus dosbox-SVN or -staging. |
I did not have time to do any testing with GP2, but I noticed that when I start dosbox-x with So I used CPU affinity to pin the process to a single core With that and edit this was tested on an Intel i7-10610U |
I am only interested in the initial benchmark performed in GP2. This is a kind of calibration to estimate average frame rate. It has an impact on the behavior of the game if it is incorrectly estimated. You can read its value in Dosbox-x, apart from this underestimation of the benchmark, is doing fine in GP2 on my hardware. As for the gameplay itself. The lower the CPU usage when playing GP2 under dosbox (with https://www.grandprix2.de/wissen/01wissen.htm
|
CPU usage comparison. Taken during a quickrace at Monza, Italy. Three laps. Similar times. From the first corner to the finish in first position. After I had passed the finish line, I pressed pause. Then I was freezing the cgroup container. start svn==== CPU: 2min 24.584s 2min 17.198s 2min 17.602s 2min 16.779s It's really hard to do exactly. This is only a rough comparison. |
I didn't check so deeply but cpu usage of my host CPU goes up only around 30%. |
@maron2000 You can monitor the CPU load on the GP2 itself. Hold down the 'O' key during the game. The load is variable. Dependent on graphic settings, number of displayed objects, amount of smoke, track, etc. In the game itself, it should not exceed 100%, except occasionally. Choose Quickrace in Monaco. |
I put a test code in my repsitory, replacing some fmod() to fma(). Edit: The graphics setting are SVGA with maximum quality setting. |
Unfortunately, your fix is not working well on my hardware. The difference in CPU time is 13.5 seconds. So much more was consuming dosbox-x with your fix on this run. Quickrace Monza (3 Laps) Leading from the entrance to the first corner to the finish line. It shows in perf.
dosbox-x-0.83.24+your fix
|
@grapeli |
@maron2000 __________| race time | CPU time Perf. This is not the complete output from linux perf (top lines).
|
@maron2000 On a real PC on Interlagos it is around +2%. You can find other extreme cases where the deceleration or acceleration is greater than 20%. |
This huge slowdown (second video from yt) of 83% is due to the fact that this person did not adjust the graphics settings to the hardware (emulation) capabilities. Processor Occupancy in GP2 is on average around 183%. Significant acceleration is due to not very perfect emulation (???). I note such a ~20% acceleration in dosemu2. Edit: Grand Prix 2 processor comparison |
GP2 is not a 3Dfx game. It's not more demanding than GP3 or GP4. Should be fine. I used to play GP2 just fine with DOSBox-X years ago before moving to QEMU. Game even runs fine on my iPhone 12 Mini and DOSPad, a port of dosbox for iOS. |
@brunocastello GP2 is one of the most demanding dos games. I have posted a link to the video. On a Pentium II 366 MHz configuration, the GP2 slows down when starting at the Monaco track. Hardware configuration from Win98SE and not DOS. I ran it in an x86 emulator in a browser. https://copy.sh/v86/ |
I could make a video of GP2 running on my iPhone if you want to see the performance. I tested Monaco right now. PO is 70% for most of the track with some occasional spikes up to 100% and 130% in specific places. But gaming wise the performance is very well playable. I probably tweaked the graphics a bit for a better performance and I am using a custom 1994 carset with updated cars, helmets liveries. But yea I am using VGA instead of SVGA, because I don't think there is a huge difference in terms of graphics between them. The only difference is performance (SVGA is helluva slower, yeah). I'll update my comment soon with two screenshots of my graphics config (for both SVGA and VGA). |
I'm very sorry if this is not the correct place to ask this, or if I am doing something wrong- but I found this page looking for information on how to run gp2 with dosbox-x, as I was motivated to try something new. For years I have been using dosbox ece and it has worked good, but I was turned on by the idea for finding a new dosbox setup that has savestates. I experienced the same thing today with the time of a lap being much longer than the clock time shown in the cockpit of the game. For me, my test track was a monaco version that is a little bit more populated with objects than the original "vanilla" monaco that ships with the game. In my dosbox ECE the time is very close in real life to what I see on the cockpit. In my dosbox-x setup, I was getting lap times that took (in real life) about 1m40s, while the cockpit clock shows about 1m24s. |
Code of Conduct & Contributing Guidelines
Have you checked that no other similar bug report(s) already exists?
What operating system(s) this bug have occurred on?
linux
What version(s) of DOSBox-X have this bug?
newest and older
Describe the bug
Grand Prix 2 does not run optimally under dosbox-x.
Expected behavior
It will work better.
Steps to reproduce the behaviour
The first problem. The real time differs significantly from that in the game. The video recording time is 01:38.80, lap time 01:24.832. Difference -14.32s. Huge.
gp2.dosbox-x.one.lap.mp4
What it looks like in dosbox-staging.
Video time is 01:21.08, laps 01:25.647, acceleration! about +4.57s (slight compared to dosbox-x).
gp2.dosbox-staging.one.lap.mp4
Second point. GP2 could run faster in dosbox-x (related to the previous issue).
Already at the start, the cpu load in GP2 is 61%. In the moment of a lot of smoke, it jumps to 123%.
gp2.dosbox-x.mp4
What does it look like under linux
perf
.Why is
fmod
from libm so CPU intensive? Well, thanks to these functions:PIT_Block::read_counter
+0x2a1 timer.cpp:257PIT_Block::track_time
+0x13d timer.cpp:152Something in this code is not working very well. The most CPU stress should be the dosbox-x code.
It looks completely different under dosbox-staging. There is no overload from libm which translates into much smoother and better performance. These values are from
perf top
.gp2.dosbox-staging.mp4
Third point. GP2 does not work properly with
aspect=false
. I think he should.Used configuration
No response
Emulator log
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: