|
Rubidium
|
r27737:728d55b97775
|
15 months ago
|
|
Codechange: automatic adding of _t to (u)int types, and WChar to char32_t
for i in `find src -type f|grep -v 3rdparty/fmt|grep -v 3rdparty/catch2|grep -v 3rdparty/opengl|grep -v stdafx.h`; do sed 's/uint16& /uint16 \&/g;s/int8\([ >*),;[]\)/int8_t\1/g;s/int16\([ >*),;[]\)/int16_t\1/g;s/int32\([ >*),;[]\)/int32_t\1/g;s/int64\([ >*),;[]\)/int64_t\1/g;s/ uint32(/ uint32_t(/g;s/_uint8_t/_uint8/;s/Uint8_t/Uint8/;s/ft_int64_t/ft_int64/g;s/uint64$/uint64_t/;s/WChar/char32_t/g;s/char32_t char32_t/char32_t WChar/' -i $i; done
|
|
Rubidium
|
r27544:ff436bece3b8
|
14 months ago
|
|
|
|
Patric Stout
|
r27487:4d1c2a7bde00
|
15 months ago
|
|
Codechange: remove queue_wrap / last_position from mouse movement
No backend uses it anymore, so also no longer any need to support it.
|
|
Rubidium
|
r27160:192bc991c2e6
|
16 months ago
|
|
|
|
Henry Wilson
|
r26809:d4ad4016fc34
|
21 months ago
|
|
|
|
Patric Stout
|
r26711:a4f8e9c41dea
|
20 months ago
|
|
Codechange: address CodeQL issue "Multiplication result converted to larger type" ( #10306) Most are very unlikely to ever be triggered in our codebase; two stand out: linkgraph and money cheat. Those, potentially, could wrap earlier than expected.
|
|
Patric Stout
|
r25724:cf37407a0fa2
|
3 years ago
|
|
Codechange: use _cur_palette the same in all the drivers
It was a bit of a mixed bag. With this change, gfx.cpp is in control who accesses _cur_palette from the video-drivers.
|
|
rubidium42
|
r25655:1030dcb7eb52
|
3 years ago
|
|
|
|
sean
|
r25019:7bd7e70574c6
|
3 years ago
|
|
|
|
Patric Stout
|
r25014:e1f1bf3a062e
|
3 years ago
|
|
Add: [Video] move GameLoop into its own thread
This allows drawing to happen while the GameLoop is doing an iteration too.
Sadly, not much drawing currently can be done while the GameLoop is running, as for example PollEvent() or UpdateWindows() can influence the game-state. As such, they first need to acquire a lock on the game-state before they can be called.
Currently, the main advantage is the time spend in Paint(), which for non-OpenGL drivers can be a few milliseconds. For OpenGL this is more like 0.05 milliseconds; in these instances this change doesn't add any benefits for now.
This is an alternative to the former "draw-thread", which moved the drawing in a thread for some OSes. It has similar performance gain as this does, although this implementation allows for more finer control over what suffers when the GameLoop takes too long: drawing or the next GameLoop. For now they both suffer equally.
|
|
Patric Stout
|
r25011:61d28a13bb41
|
3 years ago
|
|
Remove: [Video] no longer draw in a thread
Drawing in a thread is a bit odd, and often leads to surprising issues. For example, OpenGL would only allow it if you move the full context to the thread. Which is not always easily done on all OSes. In general, the advise is to handle system events and drawing from the main thread, and do everything else in other threads. So, let's be more like other games.
Additionally, putting the drawing routine in a thread was only done for a few targets.
Upcoming commit will move the GameLoop in a thread, which will work for all targets.
|
|
Patric Stout
|
r24970:1ff44d19fa4a
|
3 years ago
|
|
Add: settings to limit your fast-forward game speed
By default this setting is set to 2500% normal game speed.
|
|
Patric Stout
|
r24940:46781aedfe1c
|
3 years ago
|
|
|
|
Patric Stout
|
r24939:f00f6879a003
|
3 years ago
|
|
Codechange: [Video] make the prototype of PollEvent() the same for all drivers
Additionally, call it from the draw-tick.
|
|
Patric Stout
|
r24855:196c88971d0d
|
3 years ago
|
|
Codechange: deduplicate tick-handlers of all video drivers
They were all identical, so better put this in a single place hoping it is less likely to break.
|
|
Patric Stout
|
r24852:00c1bd78d033
|
3 years ago
|
|
Codechange: be consistent in what CheckPaletteAnim() does and when it is called
Additionally, make sure this is a class method. Later commits will make use of this.
|
|
Patric Stout
|
r24851:a41e925d9dc7
|
3 years ago
|
|
Codechange: be consistent in naming the paint function Paint()
Also move this function to be a class member. This to allow further deduplicating of code in a later commit.
|
|
Patric Stout
|
r24849:01243a72f255
|
3 years ago
|
|
|
|
Patric Stout
|
r24838:7649c96c915f
|
3 years ago
|
|
|
|
Patric Stout
|
r24837:5dde15d396bd
|
3 years ago
|
|
Fix: during switching of game-mode, drawing could show closed windows that shouldn't be closed yet
The higher your refresh-rate, the more likely this is. Mostly you notice this when creating a new game or when abandoning a game.
This is a bit of a hack to keep the old behaviour, as before this patch the game was already freezing your mouse while it was changing game-mode, and it does this too after this patch. Just now it freezes too a few frames earlier, to prevent not drawing windows people still expect to see.
|
|
Patric Stout
|
r24836:1b90bc77ac1d
|
3 years ago
|
|
Feature: configurable refresh-rate and change default to 60fps
Most modern games run on 60 fps, and for good reason. This gives a much smoother experiences.
As some people have monitors that can do 144Hz or even 240Hz, allow people to configure the refresh rate. Of course, the higher you set the value, the more time the game spends on drawing pixels instead of simulating the game, which has an effect on simulation speed.
The simulation will still always run at 33.33 fps, and is not influences by this setting.
|
|
Patric Stout
|
r24835:3784c0862167
|
3 years ago
|
|
Change: sleep till the next tick in the main loop
Sleep for 1ms (which is always (a lot) more than 1ms) is just randomly guessing and hoping you hit your deadline, give or take.
But given we can calculate when our next frame is happening, we can just sleep for that exact amount. As these values are often a bit larger, it is also more likely the OS can schedule us back in close to our requested target. This means it is more likely we hit our deadlines, which makes the FPS a lot more stable.
|
|
Patric Stout
|
r24834:b3e68a97e02c
|
3 years ago
|
|
Change: allow video-drivers to miss deadlines slightly
Before, every next frame was calculated from the current time. If for some reason the current frame was drifting a bit, the next would too, and the next more, etc etc. This meant we rarely hit the targets we would like, like 33.33fps.
Instead, allow video-drivers to drift slightly, and schedule the next frame based on the time the last should have happened. Only if the drift gets too much, that deadlines are missed for longer period of times, schedule the next frame based on the current time.
This makes the FPS a lot smoother, as sleeps aren't as exact as you might think.
|
|
Patric Stout
|
r24833:e40e0f8b2230
|
3 years ago
|
|
Add: draw the screen at a steady pace, also during fast-forward
During fast-forward, the game was drawing as fast as it could. This means that the fast-forward was limited also by how fast we could draw, something that people in general don't expect.
To give an extreme case, if you are fully zoomed out on a busy map, fast-forward would be mostly limited because of the time it takes to draw the screen.
By decoupling the draw-tick and game-tick, we can keep the pace of the draw-tick the same while speeding up the game-tick. To use the extreme case as example again, if you are fully zoomed out now, the screen only redraws 33.33 times per second, fast-forwarding or not. This means fast-forward is much more likely to go at the same speed, no matter what you are looking at.
|
|
Patric Stout
|
r24832:f2376ca1bbb7
|
3 years ago
|
|
Codechange: track _realtime_tick more accurate
_realtime_tick was reset every time the diff was calculated. This means if it would trigger, say, every N.9 milliseconds, it would after two iterations already drift a millisecond. This adds up pretty quick.
|
|
Patric Stout
|
r24831:5af48bd7a880
|
3 years ago
|
|
Codechange: switch all video drivers to std::chrono for keeping time
On all OSes we tested the std::chrono::steady_clock is of a high enough resolution to do millisecond measurements, which is all we need.
By accident, this fixes a Win32 driver bug, where we would never hit our targets, as the resolution of the clock was too low to do accurate millisecond measurements with (it was ~16ms resolution instead).
|
|
milek7
|
r24807:48a7f8b46730
|
3 years ago
|
|
|
|
Michael Lutz
|
r24665:20a8caea4459
|
4 years ago
|
|
|
|
Charles Pigott
|
r24597:afde5721a3b6
|
4 years ago
|
|
|
|
Michael Lutz
|
r24218:c32caa9f014d
|
4 years ago
|
|
|
|
S. D. Cloudt
|
r23917:50c2317ea357
|
5 years ago
|
|
|
|
glx
|
r23630:58df4dafed3e
|
5 years ago
|
|
|
|
Henry Wilson
|
r23607:36c15679007d
|
5 years ago
|
|
|
|
Michael Lutz
|
r23589:b3521e885d81
|
5 years ago
|
|
|
|
Patric Stout
|
r23482:de566f8c088d
|
5 years ago
|
|
Remove: DOS support
In 10 years there was no active development on DOS. Although it turned out to still work, the FPS was very bad. There is little interest in the current community to look into this.
Further more, we like to switch to c++11 functions for threads, which are not implemented by DJGPP, the only current compiler for DOS.
Additionally, DOS is the only platform which does not support networking. It is the reason we have tons of #ifdefs to support disabling networking.
By removing DOS support, we can both use c++11 functions for threads, and remove all the code related to disabling network. Sadly, this means we have to see DOS go.
Of course, if you feel up for the task, simply revert this commit, and implement stub c++11 functions for threads and stub functions for networking. We are more than happy to accept such Pull Request.
|
|
Niels Martin Hansen
|
r22959:8c769e762c2f
|
6 years ago
|
|
Feature: Framerate display window ( #6822) Frame rate and various game loop/graphics timing measurements and graphs. Accessible via the Help menu, and can print some stats in the console via the fps command.
|
|
Patric Stout
|
r22834:7614d5fc156d
|
6 years ago
|
|
|
|
frosch
|
r22011:0dc7eed331dd
|
9 years ago
|
|
|
|
rubidium
|
r21387:4ac1de161213
|
10 years ago
|
|
|
|
rubidium
|
r21383:942c32fb8b0e
|
10 years ago
|
|
|
|
rubidium
|
r21124:6022cb131374
|
11 years ago
|
|
|
|
michi_cc
|
r20633:872eb899e63d
|
11 years ago
|
|
|
|
planetmaker
|
r19944:25a78576fb5e
|
12 years ago
|
|
|
|
rubidium
|
r18631:8f79708f5a6d
|
13 years ago
|
|
|
|
rubidium
|
r18591:727eeaa0e2e0
|
13 years ago
|
|
|
|
rubidium
|
r18589:8ea5c6919bb5
|
13 years ago
|
|
|
|
rubidium
|
r18395:22ade7a0b9e1
|
13 years ago
|
|
|
|
michi_cc
|
r18160:133e96e28508
|
13 years ago
|
|
|
|
rubidium
|
r17271:3e6d78458bdb
|
13 years ago
|
|
|
|
rubidium
|
r16516:3e651c9d6713
|
14 years ago
|
|
|
|
frosch
|
r15613:193c12018337
|
14 years ago
|
|
|
|
frosch
|
r15610:623a23fb6560
|
14 years ago
|
|
|
|
rubidium
|
r15523:81620324a110
|
14 years ago
|
|
|
|
frosch
|
r15217:02b43e900750
|
14 years ago
|
|
|
|
rubidium
|
r15175:66e0817dc450
|
14 years ago
|
|
|
|
rubidium
|
r14248:a9050881acd7
|
15 years ago
|
|
|
|
peter1138
|
r14151:b74c66bf771d
|
15 years ago
|
|
|
|
frosch
|
r13993:05fba9b1b249
|
15 years ago
|
|
|
|
rubidium
|
r13502:434ec5a3ddd4
|
15 years ago
|
|
|
|
rubidium
|
r13268:c5ec69a8761b
|
15 years ago
|
|
|
|
rubidium
|
r13257:4c5b8120be59
|
15 years ago
|
|
(svn r17776) -Codechange: [SDL] make "update the video card"-process asynchronious. Profiling with gprof etc. hasn't shown us that DrawSurfaceToScreen takes a significant amount of CPU; only using TIC/TOC it became apparant that it was a heavy CPU-cycle user or that it was waiting for something. The benefit of making this function asynchronious ranges from 2%-25% (real time) during fast forward on dual core/hyperthreading-enabled CPUs; 8bpp improvements are, in my test cases, significantly smaller than 32bpp improvements. On single core non-hyperthreading-enabled CPUs the extra locking/scheduling costs up to 1% extra realtime in fast forward. You can use -v sdl:no_threads to disable threading and undo this loss. During normal non-fast-forwarded games the benefit/costs are negligable except when the gameloop takes more than about 90% of the time of a tick. Note that allegro's performance does not improve with this system, likely due to their way of getting data to the video card. It is not implemented for the OS X/Windows video backends, unless (ofcourse) SDL is used there. Funny is that the performance of the 32bpp(-anim) blitter is, at least in some test cases, significantly faster (more than 10%) than the 8bpp(-optimized) blitter when looking at real time in fast forward on a dual core CPU; it was slower. The idea comes from a paper/report by Idar Borlaug and Knut Imar Hagen.
|
|
rubidium
|
r13254:0a982a65d9cf
|
15 years ago
|
|
|
|
rubidium
|
r12768:980ae0491352
|
15 years ago
|
|
|
|
rubidium
|
r12275:beb131677d7a
|
15 years ago
|
|
|
|
alberth
|
r12252:2f455828d620
|
15 years ago
|
|
|
|
alberth
|
r12077:baf868e4baf0
|
15 years ago
|
|
|
|
rubidium
|
r11847:235c011992a8
|
15 years ago
|
|
(svn r16242) -Codechange: rework pausing -Fix [FS #2864]: autopause and manual pausing conflict with eachother -Fix: new game + pause on new game + autopause make the game not unpause on the first join
|
|
rubidium
|
r10821:3f1efeb4dbe6
|
16 years ago
|
|
|
|
rubidium
|
r10390:00d287c91d28
|
16 years ago
|
|
(svn r14641) -Change [Allegro]: when making a debug build revert Allegro's hooks on SIGSEGV/SIGABRT so one can actually use gdb. -Change: make it more clear that Allegro's failing to find a driver.
|
|
rubidium
|
r10385:d164fb8e2b21
|
16 years ago
|
|
|
|
rubidium
|
r10381:0855c63c9abf
|
16 years ago
|
|
|
|
rubidium
|
r10380:906a7d946ffe
|
16 years ago
|
|
|
|
rubidium
|
r10379:941352ab53b3
|
16 years ago
|
|
|