After finishing day 10, my machine is only getting around 37 fps, or 26 ms per frame, even using casey's code. Im wondering if this is normal? I don't exactly have a gaming rig, but I can run games that are more than just painting to a window and playing a tone. I checked to see if it was MSVC, but I don't get any sort of speed improvement. Even turning off the sound code doesn't help at all.
-Edit: I'm also getting 60 mc per frame as well. Sounds strange to me.
-Edit: I'm also getting 60 mc per frame as well. Sounds strange to me.
Edited by Justin
on
You do have to remember that we are using a single thread on the CPU no GPU, also Day 10 is very basic to what we have now.(Day 121) so Depending on what kind of processor you have I could see 37fps as reasonable. You would need to provide some information on that. But I would continue on as it gets both better and worse later on.
Also as a note Casey was aiming for 30fps there so you are hitting the rate we were going for.
Also as a note Casey was aiming for 30fps there so you are hitting the rate we were going for.
There are a few things to note here.
First, StretchDiBits is not a "normal" way to render anything anymore - it's an old, legacy path, so it's entirely possible that your system just isn't going to let anyone call it at a high enough throughput to get 60fps or whatnot. The reason we are using it at the moment is because I wanted to show the simplest possible way to get raw memory displayed on the screen, so people could see the connection. In the future, even when running the software rendering path, we will probably go through OpenGL to display to the screen, since that is the tested path nowadays (ie., we will simply submit a texture that is the game output and draw it to the screen as a giant quad).
Second, it does sound slightly odd that if all you were doing is calling StretchDiBits as fast as you could that you would only hit 37fps. Are you sure you're not calling Sleep() or some other functions that would indicate to the operating system that you didn't need the full amount of processor time to which you were entitled?
- Casey
First, StretchDiBits is not a "normal" way to render anything anymore - it's an old, legacy path, so it's entirely possible that your system just isn't going to let anyone call it at a high enough throughput to get 60fps or whatnot. The reason we are using it at the moment is because I wanted to show the simplest possible way to get raw memory displayed on the screen, so people could see the connection. In the future, even when running the software rendering path, we will probably go through OpenGL to display to the screen, since that is the tested path nowadays (ie., we will simply submit a texture that is the game output and draw it to the screen as a giant quad).
Second, it does sound slightly odd that if all you were doing is calling StretchDiBits as fast as you could that you would only hit 37fps. Are you sure you're not calling Sleep() or some other functions that would indicate to the operating system that you didn't need the full amount of processor time to which you were entitled?
- Casey
No, I even commented out the sound code, which I didn't really think was going to make much difference, and it indeed doesn't. Well, maybe I'll go ahead and switch to OpenGL for that then, I think I can figure that out.
After doing a bit of digging, it seems that StretchDIBits really is solely the problem. If I dont call that, my ms/f hovers around 5-7, no matter the window size (Im still filling out the window buffer). That function call can't be that slow, can it? Or is it just from trying to call it so fast maybe?
After doing a bit of digging, it seems that StretchDIBits really is solely the problem. If I dont call that, my ms/f hovers around 5-7, no matter the window size (Im still filling out the window buffer). That function call can't be that slow, can it? Or is it just from trying to call it so fast maybe?