Re: Working with SDL natively
Re: Working with SDL natively a@23Whether it matters depends on what you're doing, but yes it can matter. Consider client-side interpolation for online games for instance--if you're off by 2 percent then that's not so great for a spell that lasts, say, 2 minutes: the client could say that it stopped anywhere from a couple seconds early to a couple seconds late. Usually late.Again, the difficulty isn't the limiting. Limiting is fine, but you end up potentially limiting *too much* without some extra calls. Practically, is 1-2 ms accuracy either way going to matter? Maybe, maybe not. But if you tick 60 times a second and you haven't set up a very high resolution timer, your ticks are 16 ms vs. a sleep that's 20ms late or more sometimes, which is an entire frame.If you're already incorporating a delta you just measure the duration from the start of the last tick and use that instead, so it's really not that hard to fix.Consider rhythm games. If you're doing a rhythm game 20ms is significant. If you're doing SoundRTS it doesn't matter and you could even update as slow as 5-10 times a second before audiogame players would notice (though if it had graphics that wouldn't be true). You have to pick where you are along the continuum.The issue is that Chris is writing a library. In a library, you have to choose the most suitable trade-off for your users. I don't know what that looks like because I'm a more advanced programmer than most people here and actually fixing this the right way is pretty easy for me. *maybe* the right answer is "we don't care". Maybe BGT did that, say, and we all got away with it. I don't know. But the trade-off has to be decided on and whatever it is gets enshrined in the library forever. URL: https://forum.audiogames.net/post/603863/#p603863 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively
@Camlorn, wouldn't this also be a valid way to limit FPS rate?Const Uint FPS=1000/60;
Uint32 _FPS_Timer;
while (quit!=0){
/ / Stuff
if(SDL_GetTicks()-_FPS_TimerThis is what I got for Googling limiting SDL framerate. You can use the FPS constant as a delta, though you do lose the 0.67 resulting from the division of 1000 by 60. Would that honestly matter, though?
URL: https://forum.audiogames.net/post/603856/#p603856
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively If I'm not mistaken, PySDL2 expects you to already have SDL2.dll lying around somewhere and doesn't provide the DLL its self unless you pip install pysdl2-dll, I think this only works on windows. I know there's a way to bundle DLLs with PyInstaller because Pygame does it, I don't know how though. URL: https://forum.audiogames.net/post/603838/#p603838 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively Agree with 20. Though there's a few timers I know of that would work, none of them are directly accessible, and the overhead of priorities plus scheduler plus interrupts equals inaccuracies. The real time clock for example can tick at up to 122ns per tick, but you run into the problem of "Well this isn't something I can exactly measure". The APIC has microsecond-level granularity, which is wonderful... Until you realize that by the time your program gets woken up from sleeping your interval is long gone. So when you sleep you generally have to just do your best. URL: https://forum.audiogames.net/post/603839/#p603839 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively If I'm not mistaken, PySDL2 expects you to already have SDL2.dll lying around somewhere. I know there's a way to bundle DLLs with PyInstaller because Pygame does it, I don't know how though. URL: https://forum.audiogames.net/post/603838/#p603838 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively You can probably do better than those libraries, this is just more of a you're probably not going to get what you expect conversation because better doesn't mean "perfectly accurate timer".You may not know this, but Synthizer actually doesn't use any timers at all. Even us audio programmers don't have accurate timers. It infers time based off how many samples the audio card has asked it to produce, and currently doesn't read the clock.To my knowledge the minimum resolution for a sleep on windows is 1MS. With caveats. Read "if I'm the only piece of software running". On Linux, by default it's 50 to 100 ms and you'll need to get your threads into SCHED_FIFO if you can, even if you're using something like pyglet which probably doesn't do this by default. Ironically Linux turns out to be much better about really accurate sleeping and fast wakeups but only if you go out of your way to set a bunch of thread characteristics that tell the kernel "this thread is super, super critical. Really. I mean it". I don't know what it is on mac. Realistically, if I had to ballpark it for you, you could get to around 5ms accuracy cross platform.To cover the delta thing for the nth time, what sighted games do and what you're supposed to is you're supposed to figure out how long since the last tick, and then you do things like velocity * delta, maintain game-specific clocks that you do timers against in game time rather than real time (which also lets you pause) and then it just works out because a little bit of inaccuracy will just increase delta by a little bit. You should be doing this even with Pyglet, but the problem is that the level of knowledge here isn't high enough for an idea this simple to work for most people who are stuck on figuring out how to even maintain a list of objects, so I don't know what you want to do about it honestly. URL: https://forum.audiogames.net/post/603789/#p603789 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively @15Oh wow, OK, I didn't think of that.@17Thank you for the compliment, that actually means a lot, especially coming from you. And I don't mean that in the sarcastic way it sounds like when I read it back.If simple stuff like creating a main loop is going to be such a pain in the arse, I think I'll just leave it and let Pyglet do its thing. After all, it's not like what I already have bothers me unduly, and it's definitely sounding like I cannot do better. URL: https://forum.audiogames.net/post/603762/#p603762 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively @17, oh, I understand now. Yeah, getting an accurate enough sleep is tricky especially when you throw in things like the scheduler and priorities. URL: https://forum.audiogames.net/post/603675/#p603675 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively @16That doesn't matter. The issue isn't getting an accurate timestamp. The issue is getting an accurate sleep. Accurate timestamps are easy, except that the call you have to make is OS specific, but SDL does have an abstraction. Accurate sleeps are OS-specific and will often be late (the guarantee is usually "this function doesn't wake you up early, but who knows how late you'll be"). Turning the timer resolution up or spinning to make up for it does incur a rather large CPU/energy/etc cost.The solution to a problem like this is you just record the time between ticks, say it's roughly going to be 1/60th of a second or whatever then factor that into your physics/animation calculations, but frankly Chris is one of the best people here and doesn't know trig as far as I know, so "just use a unit vector and..." stuff doesn't get traction and you have to do something else to make up for the knowledge gaps. I mean hell, most games don't even use floating point positions. URL: https://forum.audiogames.net/post/603657/#p603657 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively @13, this isn't actually right. Normally, your right; timer delays can be excruciating when your trying to maintain a constant tickrate. But SDL_GetPerformanceCounter() calls QueryPerformanceCounter on windows, which, according to this article, uses the Time Stamp Counter (TSC) in the processor, which ticks at the processors nominal frequency. On Linux/Unix: if monotonic time is supported, it uses clock_gettime() with the monotonic clock, or, if on Apple devices, uses mach_absolute_time(). I have no idea how accurate mach_absolute_time() is, but if memory serves the monotonic clock is extremely accurate. (Checking the Linux sources, it seems like the clocks are based on the loaded drivers -- according to the Linux 5.9 source code at least.) Perhaps I'm wrong and those 20ms-100ms performance hits occur but I've researched game loops and most of the pro game loop design articles I can find suggest using QueryPerformanceCounter or an equivalent in instances like this.If I'm indeed wrong and such a performance hit does occur, then that's kinda surprising since the hardware clocks/timers that are available (even in early boot) can tick at incredibly quick frequencies. I wonder if its scheduler/interrupt overhead that causes those hits. URL: https://forum.audiogames.net/post/603648/#p603648 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively @13, this isn't actually right. Normally, your right; timer delays can be excruciating when your trying to maintain a constant tickrate. But SDL_GetPerformanceCounter() calls QueryPerformanceCounter on windows, which, according to this article, uses the Time Stamp Counter (TSC) in the processor, which ticks at the processors nominal frequency. On Linux/Unix: if monotonic time is supported, it uses clock_gettime() with the monotonic clock, or, if on Apple devices, uses mach_absolute_time(). I have no idea how accurate mach_absolute_time() is, but if memory serves the monotonic clock is extremely accurate. (Checking the Linux sources, it seems like the clocks are based on the loaded drivers -- according to the Linux 5.9 source code at least.) Perhaps I'm wrong and those 20ms-100ms performance hits occur but I've researched game loops and most of the pro game loop design articles I can find suggest using QueryPerformanceCounter or an equivalent in instances like this. URL: https://forum.audiogames.net/post/603648/#p603648 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively What's wrong with that is that you peg a CPU core forever. This will run the CPU at max, on single or dual core machines the entire machine will probably lag (and it definitely will if you play with thread priorities), and if it's a laptop you will drain the battery so badly that your 5-10 hour charge suddenly only lasts 1 or 2. This is worse than high resolution media, or anything else you can think of which typically uses processing power. And 99.99% of the time, that loop is going to do absolutely nothing but consume resources. You're proposing using anywhere from 20 to 1000 times more CPU than the game would actually need--20 if it's some complex physics thing, 1000 for typical arcade games or BK3.Then, at some point the OS might or might not come in and just be like "sorry, you're using all the resources and I have bumped you down to the lowest thread priority". Windows is good about not doing that, other OSes are more aggressive.You have to sleep. You have no choice. I know that you had a good timer experience with dart, but that's almost certainly because Dart hooked into requestAnimationFrame which syncs with the vsync of the browser, and you could find out how to sync with the vsync of SDL and actually draw a window that's entirely black if you wanted that level of precision. That's one option, but it's still an option that actually does sleeping--it's generally only accurate to 1/60th of a second, maybe 1/120th, sometimes less if the user sets their display differently. In fact I would be willing to bet Dart's timers only worked as well as they did on your machine and that we could find one on which they didn't work with nearly so much precision, even.Even just asking Windows to go into the super high accuracy timer mode drains battery fast. Not as fast as spinning, but fast. basically the problem you're going to run into here is that audiogame people think about time in games wrong and try for super rigid fixed-rate ticks, but nothing else anywhere wants that because of the horrible power consumption. What's going on under the hood is that processors in laptops and such idle and go into lower power modes when there's nothing to do, said lower power modes are what give you super long battery life, you're talking 2x or 3x or more energy savings. But even just asking for a more precise sleeping function requires telling the timer hardware to wake it up 10 or 20 times faster than it would by default, the OS waking up to figure out if there's timers expiring counts as "something", and even that is enough to keep the laptop from going into the best energy saving modes it could.Asking for higher precision sleeps from the OS is actually perfectly reasonable for games, which are going to be doing something many times a second anyway, but nonetheless there's a trade-off: you can get your microsecond-accurate timers and sleeping with various combinations of just spinning the loop and sleeping for less than you would and stuff, but to do so, well, better have that laptop power cord with you. So you have to accept less accuracy and deal with it. URL: https://forum.audiogames.net/post/603636/#p603636 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively I don't know if I'm just missing the point because I'm extra tired, but why do I need to sleep at all? What's wrong withwhile True: for event in SDL_GetEvents(): process_event(event)If I'm being blatantly stupid, feel free to ignore me. I'm going to read over these messages again tomorrow, because I'm struggling to take anything in. URL: https://forum.audiogames.net/post/603629/#p603629 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively @12No, he can't. My point is that that sleep loop is broken because, for instance, default Windows sleep resolution is up to 20 MS longer without some additional calls to set it up. Linux is even worse, as Synthizer discovered: by default on Linux, it can be up to 100ms late unless you do some additional thread priority/scheduling things. The right answer here is that you use the whole "it's a variable tick rate so I pass around a delta" thing,but people here have trouble with 1-dimensional movement, so "you use unit vectors and deltas" never goes over well and you want a consistent tick if possible.There's SDL_Delay, but who knows how accurate it is.A quick and dirty algorithm if you don't want to be bothered and are willing to assume that audiogames just won't notice is to accumulate the extra in a variable, then trigger multiple times, e.g. something like this, which is very untested and maybe broken because I typed it offhand:tick_accumulator = 0 tick_delta = 1 / ticks_per_second last_time = time.time() while true: since_last = time.time() - last_time tick_accumulator += since_last ticks = tick_accumulator // tick_delta # note that // is integer division. for t in range(ticks): tick() tick_accumulator -= tick_delta * ticks sleep_time = tick_delta - tick_accumulator time.sleep(sleep_time)Which will average the right number of ticks per second in the long run, probably work pretty well if you set up higher resolution sleeping, but will occasionally run two ticks one right after the next. Also, note that you need to reset that accumulator and since_last after pausing or bad things will happen.Aaaand this still doesn't get into what happens if the game ticks start consistently taking longer than the framerate, but since you can't accomplish that without working with deltas it's probably moot. URL: https://forum.audiogames.net/post/603627/#p603627 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively @10, you need a game loop. There are various ways of doing this. For an audio game (since your not using graphics yet -- right?) you can use a constant FPS tickrate:TICKS_PER_SECOND = 60 SKIP_TICKS = int(1000 / TICKS_PER_SECOND) next_game_tick = SDL_GetPerformanceCounter() sleep_time = 0 done = False while not done: next_game_tick += SKIP_TICKS sleep_time = next_game_tick - SDL_GetPerformanceCounter() if sleep_time >= 0: time.sleep(sleep_time) # Handle eventsOr something like that. (sleep_time is in milliseconds -- or should be converted to milliseconds.) URL: https://forum.audiogames.net/post/603621/#p603621 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively The issue is that your event loop *must* sleep. You can't just spin the loop without sleeping, and for most audiogame devs you need to try to provide a pretty regular tick. SDL probably already has something for this. The reason you're supposed to use deltas, though, rather than assuming it's fixed, is this problem.I wouldn't worry about the efficiency of iterating over a list of delayed objects because there's likely always going to be less than 100 of them, but if you want an efficient way to store such a list you use a priority heap. Python already has a module for that called heapq, which is a very cheap way to store items ordered by a key such that you can pull out the "lowest", so your entire algorithm just becomes grab the front of the heapq, check, repeat. The one thing the docs for that module don't mention is that you can peak at the next item in the heap by looking at the first element of the list, since they assume you already know how heaps work. Note that it's not a sorted list, though, so the 2nd item isn't the next item in order or anything--it's only valid to look at the first element. The Python docs have ready-to-go recipes for what you need as well. URL: https://forum.audiogames.net/post/603597/#p603597 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively @9For shorter delays it's not super accurate. While I'm not sure can do any better, SDL will require me making my own event loop, so I imagine something like the following:for event in events: process_event(event) now = time() for delay in delayed_objects: dt = now - delay.last_ran if dt >= delay.interval: delay.func(dt) delay.last_ran = nowI do feel like that's massively inefficient though, so I'll want to d some benchmarks or something.At this stage it's only an idea. I've got enough other things to worry about for the now. URL: https://forum.audiogames.net/post/603575/#p603575 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively I'm just kind of curious what about scheduling specifically was insufficient about the other libraries. Presumably they already did the whole "time the thing" bit as that's actually pretty standardYou'll need a high resolution sleep. I'm not sure what the resolution of the built-in Python one is, but getting this requires OS-specific functionality so you'll need to see about a library. Many of the sleep functions offered by any OS, the easy ones, optimize for battery/energy/system performance, which is incompatible with "I'm accurate to the ms" sorts of statements. To make that extra fun, those functions will have different accuracies on different systems running the exact same OS version due to hardware differences (specifically, there's literal clock chips waking your program up; it's not software). Fixing this isn't complicated in the algorithmic sense and mostly boils down to make sure you're using the right functions, but you'll need to check it if your goal is to be as accurate as you seem to want to be. URL: https://forum.audiogames.net/post/603523/#p603523 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively @7Not a whole lot of much. I mean I get that my scheduling won't be 100% accurate to the hundredth of a second, but for example, with some kind of interval function, instead of doing:f() sleep(interval) f() sleep(interval) ...It might make more sense to do:started = time() f() sleep(max(0, interval - (time() - started)) f() ...To be clear, I know you don't use sleep, but you get the idea.Not sure it'll be any better, but I'd like to at least try, for my own curiosity if nothing else. URL: https://forum.audiogames.net/post/603509/#p603509 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively Would be curious what you want to do for scheduling, though. If you get that wrong, you'll just peg a CPU core. URL: https://forum.audiogames.net/post/603454/#p603454 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively @4 and @5MMM, OK, thanks both. I might have a bash at it at some point. I don't really like the idea of loading Pyglet's stuff, only to then load more SDL stuff myself. Would rather just use SDL and get all the benefits I've already outlined.Thanks again. URL: https://forum.audiogames.net/post/603447/#p603447 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively Yep, agreed with 2 and 4. Graphics with SDL really isn't that hard; SDL pretty much only requires a few function calls and then you can either retrieve an OpenGL context or create a Vulkan one. URL: https://forum.audiogames.net/post/603370/#p603370 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively The long version is that this is perfectly fine and you should have at it. I want to be clear that that's not sarcasm. What you're doing is what Pygame is trying to be, or pyglet, or any of the others. Nothing wrong with making them get out of your way to make your life easier. Also, sdl totally does graphics and stuff if that's ever actually needed. URL: https://forum.audiogames.net/post/603335/#p603335 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively @2Thank you for the advice.I'm thinking I might as well just see what I can come up with, and depending on how hard it is, absorb it into mainline earwax.It would give me greater controls over scheduling ETC. URL: https://forum.audiogames.net/post/603243/#p603243 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Working with SDL natively
Re: Working with SDL natively I guess there is nothing wrong with using PySDL2 instead of pygame, although pygame 2.0.0 already has alot more features than pygame 1.x due to them changing over from sdl1 to sdl2. PySDL2 is already a wrapper though, so you don't have to care about wrapping it yourself, so in the end PySDL2 is just another SDL wrapper like pygame and maybe even more Pythonic than that one, since pygame is already pretty old and thus doesn't feel as Pythonic as e.g. pyglet does.I guess in the end its just personal preference. I cannot see why this makeover should giving you trouble in the long run, so check it out. URL: https://forum.audiogames.net/post/603242/#p603242 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Working with SDL natively
Working with SDL natively So I've been messing about with SDL2 over the last couple of days, and it occurs to me that although I - and others - use pyglet or pygame to achieve their gaming ends, we don't use - or even need - half the stuff it offers: Obviously graphics, most of us use more capable audio libraries, so and so forth.So I'm toying with the idea of reworking Earwax to use pysdl2. I can create my own events, and have more control over when they fire, I can use one library for input processing and rumble effects ETC.What are the potential pitfalls with such a bold undertaking? I don't really know what I'm talking about, so before I run with what seems like a good idea, I'd like the chance for cooler heads to pick apart the idea. URL: https://forum.audiogames.net/post/603229/#p603229 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
