This one has me stumped. So much so that I'm not even sure what questions to ask.
The basic problem is the builds that work on a 32 bit fail on the 64 bit machine. Example: Sound. The 64 bit machine played the sound exactly once (the first time sound was introduced) and never again on any build. When the performance timers were added the assert for seconds elapsed per frame triggers all the time.
I have been building the project on my "standard" 32 bit windows machine with the intention of seeing how far it would go before the 32 bit limitation broke it. It's a Dell Inspiron 530 Quad core @2.4 Ghz with 3Gb running Vista. (It's not a game machine; not meant to be.)
So when the pre-allocated memory changes came in the 64 bit memory pointers had problems. Memory isn't flat on this machine and I wanted to work through that issue but since I came so late to the project I decided to jump to the 64 bit machine and get it set up. I wanted to get caught up.
When the sound dropped out I wasn't too surprised since I felt sound has been a fragile part of the code for a while. I have a parallel project on the 32 bit machine that has extensive error checking and I felt when I ported that over the issue would be detected. The 64 bit system is using the speakers and I'm not sure how DSound works with that, etc. So I pushed that issue until later.
When I hit the frames per second assert, I was surprised. The 64 bit machine is a Toshiba Satellite C55D-B with and AMD A8 with a Radeon R5 Graphics @ 2Ghz with 4 Gb running windows 8.1. (Again, not a game machine but more than sufficient.)
The surprise was that the CPU speed fluctuates all over the map. This was mentioned on the stream but I've never experienced it. I discounted it since I felt that if the CPU was powerful enough to alter the clock speed on the fly then it would be "smart" enough not to do it such that programs failed.
So as I say, I'm stumped. I don't know enough about the issue to ask an intelligent question. How can I measure time with any degree of accuracy when the clock speed staggers so wildly?
Up until now replicating the project on my systems hasn't been very difficult and I understood the limitations of prototype code that does limited error checking, etc.; those can be worked through. But this is different. This feels like the fundamental behavior of the machine has changed.
So I'm looking for a clue.
- tim
p.s. The build Day 020 the sound comes back and the assert goes away. I'm all for progress but don't believe in "works for me" programming.
The basic problem is the builds that work on a 32 bit fail on the 64 bit machine. Example: Sound. The 64 bit machine played the sound exactly once (the first time sound was introduced) and never again on any build. When the performance timers were added the assert for seconds elapsed per frame triggers all the time.
I have been building the project on my "standard" 32 bit windows machine with the intention of seeing how far it would go before the 32 bit limitation broke it. It's a Dell Inspiron 530 Quad core @2.4 Ghz with 3Gb running Vista. (It's not a game machine; not meant to be.)
So when the pre-allocated memory changes came in the 64 bit memory pointers had problems. Memory isn't flat on this machine and I wanted to work through that issue but since I came so late to the project I decided to jump to the 64 bit machine and get it set up. I wanted to get caught up.
When the sound dropped out I wasn't too surprised since I felt sound has been a fragile part of the code for a while. I have a parallel project on the 32 bit machine that has extensive error checking and I felt when I ported that over the issue would be detected. The 64 bit system is using the speakers and I'm not sure how DSound works with that, etc. So I pushed that issue until later.
When I hit the frames per second assert, I was surprised. The 64 bit machine is a Toshiba Satellite C55D-B with and AMD A8 with a Radeon R5 Graphics @ 2Ghz with 4 Gb running windows 8.1. (Again, not a game machine but more than sufficient.)
The surprise was that the CPU speed fluctuates all over the map. This was mentioned on the stream but I've never experienced it. I discounted it since I felt that if the CPU was powerful enough to alter the clock speed on the fly then it would be "smart" enough not to do it such that programs failed.
So as I say, I'm stumped. I don't know enough about the issue to ask an intelligent question. How can I measure time with any degree of accuracy when the clock speed staggers so wildly?
Up until now replicating the project on my systems hasn't been very difficult and I understood the limitations of prototype code that does limited error checking, etc.; those can be worked through. But this is different. This feels like the fundamental behavior of the machine has changed.
So I'm looking for a clue.
- tim
p.s. The build Day 020 the sound comes back and the assert goes away. I'm all for progress but don't believe in "works for me" programming.
Edited by Timothy McCarthy
on
Reason: new data
Since I can't see your code, I can't exactly help with the 32bit vs 64bit build, and you seem to be saying that the two builds you are using are different, and both seem to be different to what is on screen.
But, the variability on the laptop I should be able to manage.
First, are you running the laptop on battery power? If you are, then the laptop has to lower the amount of energy it uses no matter what, since the battery can only put out so much power. This is a much bigger issue if you have a dedicated GPU, but is still applicable to your APU, since the GPU still has to operate within that power budget.
You can always plug it in if it isn't. Most gamers play with their laptops plugged in, though not all.
Second, Windows has power plans that dictate how the processor scales. You can either change your current plans settings to force the CPU to run at 100% at all times, or you can just change the plan to High Performance preset, and change it back during normal operation.
You can do this on Windows 8/8.1 by right clicking the lower left hand corner/ Start Button and selecting "power options" menu item. Then show other power plans on the window that shows up, and choose High Performance.
You could also open the Mobility Center in that same menu, which has power plans as a drop down menu, along with some other useful tools.
Keep in mind this fixes the variability by setting the CPU to operate at 100% at all times, so will use up your battery much faster, so you should only change this when plugged in. Also, this only solves the problem on your machine, you still have to worry about it on other machines.
Also, why do you have 2 different code bases? You should be able to compile the build Casey has on both 32bit and 64bit, since he has kept that in mind and mentioned areas that might need to be changed for the different CPU types.
But, the variability on the laptop I should be able to manage.
First, are you running the laptop on battery power? If you are, then the laptop has to lower the amount of energy it uses no matter what, since the battery can only put out so much power. This is a much bigger issue if you have a dedicated GPU, but is still applicable to your APU, since the GPU still has to operate within that power budget.
You can always plug it in if it isn't. Most gamers play with their laptops plugged in, though not all.
Second, Windows has power plans that dictate how the processor scales. You can either change your current plans settings to force the CPU to run at 100% at all times, or you can just change the plan to High Performance preset, and change it back during normal operation.
You can do this on Windows 8/8.1 by right clicking the lower left hand corner/ Start Button and selecting "power options" menu item. Then show other power plans on the window that shows up, and choose High Performance.
You could also open the Mobility Center in that same menu, which has power plans as a drop down menu, along with some other useful tools.
Keep in mind this fixes the variability by setting the CPU to operate at 100% at all times, so will use up your battery much faster, so you should only change this when plugged in. Also, this only solves the problem on your machine, you still have to worry about it on other machines.
Also, why do you have 2 different code bases? You should be able to compile the build Casey has on both 32bit and 64bit, since he has kept that in mind and mentioned areas that might need to be changed for the different CPU types.
Sorry if I didn't make this clear.
The code base is the project code base. I'm using the archive code base.
I have a separate code base use for personal changes. I'm not talking about that.
The same project archive code is used on both systems. The behavior varies. You have the same code I have.
The code will compile on both systems. But 32 bit system can't use the virtual memory as specified. The code assumes a flat memory space and a pointer can address all of it. All the memory address have to be scaled down to 4 Gb and even then there are issues.
Also, machine is plugged in and not using battery only. Power should not be an issue. Sigh, I would really prefer not have to change the basic system settings. That "goes against the grain". You shouldn't have to tweak the system to get the code to properly, I would think.
The code base is the project code base. I'm using the archive code base.
I have a separate code base use for personal changes. I'm not talking about that.
The same project archive code is used on both systems. The behavior varies. You have the same code I have.
The code will compile on both systems. But 32 bit system can't use the virtual memory as specified. The code assumes a flat memory space and a pointer can address all of it. All the memory address have to be scaled down to 4 Gb and even then there are issues.
Also, machine is plugged in and not using battery only. Power should not be an issue. Sigh, I would really prefer not have to change the basic system settings. That "goes against the grain". You shouldn't have to tweak the system to get the code to properly, I would think.
Edited by Timothy McCarthy
on
Reason: additional info.
Yes this is expected. Casey has mentioned this in some other topics. When game will come closer to finish he will spend time to fix issues with 32-bit builds. Currently there is no need to do that because he is developing on 64-bit OS, so there are no guarantees current code will work as 32-bit code.
yeah, he did mention that. I wondered if I was one of the minority 32 bit builders. And working it out was keeping me from catching up. (Sadly, I'm coming to the conclusion that I never will.)
The 64 bit issue has mysteriously disappeared and that's disturbia. I'll keep a note on it and see if it replicates after I get through the first archive batch. The code is going into a local SVN repository so I can restore it later.
I'd like to be able to get within a couple of months of the stream if possible. :dry:
- tim
The 64 bit issue has mysteriously disappeared and that's disturbia. I'll keep a note on it and see if it replicates after I get through the first archive batch. The code is going into a local SVN repository so I can restore it later.
I'd like to be able to get within a couple of months of the stream if possible. :dry:
- tim
In episode 016 "Visual Studio Compiler Switches", I hit a similar problem:
The 32-bit build intermittently will or will not play sound at all when run from my 64-bit Windows 10 host. Running it from within my Windows XP VM in VirtualBox, the sound never played. I did get audio from elsewhere within the VM, so it wasn't a configuration issue.
As soon as Casey covered -Od in the Q&A, I tried that out:
- The intermittent failure to play sound on the 64-bit machine vanished.
- The Windows XP VM started playing sound!
The 32-bit build intermittently will or will not play sound at all when run from my 64-bit Windows 10 host. Running it from within my Windows XP VM in VirtualBox, the sound never played. I did get audio from elsewhere within the VM, so it wasn't a configuration issue.
As soon as Casey covered -Od in the Q&A, I tried that out:
- The intermittent failure to play sound on the 64-bit machine vanished.
- The Windows XP VM started playing sound!